Back to list
マージ前に AI エージェントの権限変更をレビューする
Reviewing AI Agent Permission Changes Before Merge
Translated: 2026/4/25 4:57:53
Japanese Translation
AI コーディングエージェントは、コードレビューに何を含ませるかを変化させています。プルリクエストはアプリケーションコードだけではありません。MCP サーバーを追加し、AGENTS.md を変更、Cursor や Claude のルールを変更、GitHub Actions の権限を拡大、パッケージライフサイクルスクリプトを追加することも可能です。
これらの変更はレビューに値するのです。なぜなら、エージェントが実行可能なツール、期待するトークン、CI 自動化が公開・デプロイできる範囲が変わるからです。
私は ScopeDiff という小型のローカル CLI を構築し、マージ前にこれらの変化が見えるようにしました。ScopeDiff はレビューの補助であり、完全なセキュリティ監査ではありません。全ての AI エージェントや MCP リスクを防止することは主張していません。よりシンプルな目標は、通常の PR レビュー中に権限やツールの変更を簡単に目につけることです。
エージェント関連の設定は、ソースコードの隣に住み始めるようになりました:
- MCP サーバーの定義
- AGENTS.md その他のリポジトリレベルの指示文
- Cursor ルール
- Claude スキル
- GitHub Actions ワークフロー
- パッケージライフサイクルスクリプト
- Docker と compose ファイル
その中のいくつかは無害なドキュメントです。いくつかは能力の境界を変わらせることができます。
例えば、PR が MCP サーバーを追加し、GITHUB_TOKEN を期待し、ワークフローを pull_request_target に切り替え、権限を read から write に拡大し、unpinned npx コマンドを追加した場合を想像してください。それらはいずれも自動的に「悪い」ことを意味しません。しかし、レビューに値します。
ScopeDiff は以下のようなリポジトリファイルをスキャンまたは差分抽出します:
- .mcp.json
- mcp.json
- .cursor/mcp.json
- .cursor/rules/**
- .claude/settings.json
- .claude/skills/**/SKILL.md
- AGENTS.md
- CLAUDE.md
- GEMINI.md
- .github/copilot-instructions.md
- .github/workflows/*.yml
- package.json
- Dockerfile
- docker-compose.yml
- .env.example
それらは以下のコンテンツを持つ Markdown と JSON レポートを生成します:
- finding title
- severity
- file and line evidence
- confidence
- 発見が新しい能力を追加しているかどうか
- 権限を拡大しているかどうかの判断
- 提案されるレビュー手順
ある PR が以下の MCP 設定を追加したと仮定します:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}
ScopeDiff は以下のような内容を報告できます:
- MCP サーバーが追加された
- クレデンシャルのような環境変数が参照されている
- unpinned リモートパッケージ
- 実行可能なコマンドが導入された
もし同じ PR がワークフローを pull_request から pull_request_target に変更し、権限を write に拡大した場合、ScopeDiff もその変化を報告します。
目的は PR を自動的にブロックすることではなく、レビュワーに簡潔なチェックリストを与えることです:
- このサーバーが必要か?
- パッケージバージョンは固定すべきか?
- このトークンは書き取りアクセスが必要か?
- フォークからの PR に安全か?
- これは CI で実行すべきか、あるいは信頼できるワークフローでしか実行すべきか?
公開パッケージを試すには以下のコマンドを使用できます:
npx scopediff@latest scan
npx scopediff@latest diff --base main
npx scopediff@latest report --format markdown
CI 内での設定:
name: ScopeDiff
on:
pull_request:
permissions:
contents: read
jobs:
scopediff:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- run: npx scopediff@0.1.0 ci --fail-on high
デフォルトでは、CI モードは GitHub Step Summary に書き込みます。PR に対してコメントは出さないのです。
v0.1.0 において、ScopeDiff は意図的に慎重です:
- local-first
- read-only スキャン
- テレメトリなし
- コードアップロードなし
- 隠れたネットワークリクエストなし
- デフォルトでは .env の読み取りなし
- デフォルトでは PR コメントなし
- パッケージ評判検索なし
- 検出されたコマンドの実行を試みるなし
レポートは、マネージャーに何をレビューすべきか助けるべきであり、人間の判断を置き換えるべきではありません。
ScopeDiff は:
- 完全なセキュリティ監査ではない
- 脆弱性情報スキャナではない
- MCP ファアウォールではない
- パッケージ評判サービスではない
- サンボックスではない
- PR が安全であると保証するものではない
それは見逃すこともでき、偽陽性も発生させます。それが理由として、レポートはどの発見が攻撃である pretend せず、証拠と提案されたレビューアクションを含んでいます。
現時点で最も有用なフィードバックは実践的なものです:
- MCP 設定が ScopeDiff に見逃しを与える影響
- 検出に値する Cursor/Claude/Codex 指示パターン
- 共有されるべき GitHub Actions 権限拡大ケースなど
Original Content
AI coding agents are changing what belongs in code review.
A pull request may no longer be only application code. It might also add an MCP server, modify AGENTS.md, change Cursor or Claude rules, expand GitHub Actions permissions, or add package lifecycle scripts.
Those changes are worth reviewing because they can alter what tools an agent can run, which tokens it expects, or what CI automation can publish or deploy.
I built ScopeDiff as a small local CLI to make those changes visible before merge.
ScopeDiff is a review aid, not a complete security audit. It does not claim to prevent every AI agent or MCP risk. The goal is simpler: make permission and tooling changes easier to notice during ordinary PR review.
Agent-related configuration is starting to live next to source code:
MCP server definitions
AGENTS.md and other repo-level instructions
Cursor rules
Claude skills
GitHub Actions workflows
package lifecycle scripts
Docker and compose files
Some of those files are harmless documentation. Some of them can change capability boundaries.
For example, a PR might add an MCP server that expects GITHUB_TOKEN, switch a workflow to pull_request_target, expand contents from read to write, or add an unpinned npx command.
None of those automatically means "bad". But they are review-worthy.
ScopeDiff scans or diffs repository files such as:
.mcp.json
mcp.json
.cursor/mcp.json
.cursor/rules/**
.claude/settings.json
.claude/skills/**/SKILL.md
AGENTS.md
CLAUDE.md
GEMINI.md
.github/copilot-instructions.md
.github/workflows/*.yml
package.json
Dockerfile
docker-compose.yml
.env.example
It produces Markdown and JSON reports with:
finding title
severity
file and line evidence
confidence
whether the finding appears to add a new capability
whether it appears to expand permissions
suggested review steps
Suppose a PR adds this MCP config:
{
"mcpServers": {
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_TOKEN": "${GITHUB_TOKEN}"
}
}
}
}
ScopeDiff can report things like:
MCP server added
credential-like env var referenced
unpinned remote package
executable command introduced
If the same PR also changes a workflow from pull_request to pull_request_target and expands contents to write, ScopeDiff reports those changes too.
The point is not to block the PR automatically. The point is to give the reviewer a concise checklist:
Is this server needed?
Should the package version be pinned?
Does this token need write access?
Is this safe for PRs from forks?
Should this run in CI, or only in a trusted workflow?
You can try the published package with:
npx scopediff@latest scan
npx scopediff@latest diff --base main
npx scopediff@latest report --format markdown
In CI:
name: ScopeDiff
on:
pull_request:
permissions:
contents: read
jobs:
scopediff:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- run: npx scopediff@0.1.0 ci --fail-on high
By default, the CI mode writes to the GitHub Step Summary. It does not comment on PRs.
For v0.1.0, ScopeDiff is intentionally conservative:
local-first
read-only scanning
no telemetry
no code upload
no hidden network requests
no .env reading by default
no PR comments by default
no package reputation lookup
no attempt to execute detected commands
The report should help a maintainer decide what to review, not replace human judgment.
ScopeDiff is not:
a complete security audit
a vulnerability scanner
an MCP firewall
a package reputation service
a sandbox
a guarantee that a PR is safe
It can miss things. It can also produce false positives. That is why the report includes evidence and suggested review actions instead of pretending every finding is an exploit.
The most useful feedback right now is practical:
MCP config shapes ScopeDiff misses
Cursor/Claude/Codex instruction patterns worth detecting
GitHub Actions permission expansion cases that should be covered
noisy findings that should be lower severity
report wording that would help maintainers review faster
Repo: https://github.com/xiwuqi/scopediff
npm: https://www.npmjs.com/package/scopediff
If ScopeDiff helps you review agent/tooling changes, feedback is welcome. If it is useful, a star helps other maintainers find it.
Disclosure: I used an AI coding assistant to help draft and edit this post, then reviewed and approved the content before publishing.