Back to list
dev_to 2026年4月25日

マージ前に 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.