AIエージェントを組織で使い始めると、最初は慎重に権限を絞ります。けれど、数週間たつと「このリポジトリだけ」「このMCP serverだけ」「このautomationだけ」という例外が増えます。最初は妥当だった allow、長めに入れた token、調査のために開けた internet access、急ぎで許可した MCP write scope が、そのまま残ります。
この記事では、AIエージェントの 権限棚卸し を permission review として整理します。実行直前の承認は AIエージェント承認フロー設計ガイド、tool の危険度分類は AIエージェント tool risk tier 設計ガイド、ルールを配布する source-of-truth は AIエージェント policy as code 設計ガイド、MCP server 台帳は MCP サーバーカタログ設計ガイド に分けています。
今回の論点は、一度許可した権限を、いつ、何を見て、縮小・失効・継続するかです。
先に結論: 権限は設定ではなく期限付きの貸与にする
AIエージェントの権限を「設定ファイルに書いたら終わり」と扱うと、確実に広がります。便利な作業ほど、次も使うかもしれないという理由で残るからです。
私なら、AIエージェント向けの権限は次の5項目を持つ貸与として扱います。
| 項目 | 例 | ないと起きること |
|---|---|---|
owner | platform team / repo owner | 誰も失効判断しない |
purpose | weekly PR review / docs research | 別用途へ流用される |
scope | repo、MCP server、domain、tool | 許可範囲が説明できない |
expires_at | 2026-08-16 | 例外が恒久化する |
review_evidence | audit log、usage、失敗理由 | 感覚で継続される |
権限棚卸しは、AIエージェントを疑うための儀式ではありません。運用が進んだあとも、最小権限へ戻せる状態を保つための設計です。
既存記事との役割分担
このテーマは既存記事と近く見えますが、責務を分けます。
| 記事 | 扱うこと | 扱わないこと |
|---|---|---|
| 承認フロー | sensitive tool call の直前に approve / reject する | 許可済みルールを月次で見直す |
| tool risk tier | tool を read / write / external action へ分類する | 実際に使われた権限を失効させる |
| policy as code | ルールを AGENTS.md、settings、eval、監視へ配る | 例外が残ってよいか判断する |
| MCP server catalog | server、owner、scope、review date を台帳化する | Claude Code / Codex / automation 全体の権限を横断棚卸しする |
| permission review | 許可済み権限、例外、secrets、network、MCP scope を定期的に縮小する | 実行直前の yes / no 承認 |
つまり permission review は、運用後の掃除です。最初にきれいなルールを作っても、例外が増える現場では棚卸しがないと安全側へ戻れません。
棚卸し対象を5つに分ける
権限棚卸しで見る対象は、tool の許可だけでは足りません。最低でも次の5つに分けます。
| 対象 | 見るもの | 判断 |
|---|---|---|
| permission rule | allow / ask / deny、sandbox rule | 広すぎる allow を ask / deny へ戻す |
| MCP scope | server、tool、OAuth scope、token owner | 未使用 server と write scope を外す |
| network | domain allowlist、HTTP method、proxy log | 調査用 domain を閉じる |
| secret / env | setup secret、agent phase env、API token | agent phase から外す、短命化する |
| automation lane | scheduled task、background run、review queue | 無人実行に残す権限を絞る |
ここで重要なのは、設定ファイルだけを見ないことです。設定上は狭く見えても、実際には環境変数、MCP token、connector、network allowlist、plugin、automation が別の面で広がっていることがあります。
Claude Code では managed settings と sandbox を別々に見る
Claude Code では、権限の面が複数あります。公式 docs では managed scope が最上位で、組織横断の security policy や compliance requirement に使うものとして説明されています。allowedMcpServers、allowManagedMcpServersOnly、allowManagedPermissionRulesOnly、strictKnownMarketplaces、strictPluginOnlyCustomization のような設定もあります。
棚卸しでは、次の順で見ます。
claude_code_permission_review:
managed_settings:
- allowedMcpServers
- deniedMcpServers
- allowManagedMcpServersOnly
- allowManagedPermissionRulesOnly
- strictKnownMarketplaces
- strictPluginOnlyCustomization
project_settings:
- permissions.allow
- permissions.ask
- permissions.deny
- hooks
sandbox:
- filesystem.allowWrite
- filesystem.denyRead
- network.allowedDomains
- network.deniedDomains
evidence:
- claude doctor
- audit log
- MCP usage log
- denied / approved tool callsたとえば .env の read を deny していても、別の shell command や MCP server から同等の情報へ到達できるなら、実質的には守れていません。Claude Code の sandbox は subprocess にも効く境界として扱えるため、permission rule だけでなく OS-level の filesystem / network 境界も一緒に棚卸しします。
Codex では environment と agent phase を分ける
Codex cloud では environment 設計が重要です。公式 docs では、environment variables は task 全体、つまり setup script と agent phase の両方に設定されます。一方で secrets は追加の暗号化で保存され、task execution のために復号されますが、setup scripts だけで使われ、security reasons により agent phase 前に削除されると説明されています。
これは permission review の基準として使えます。
| 置き場所 | 棚卸し判断 |
|---|---|
| setup script secret | package install や private registry に必要なら残す。ただし owner と expiry を持つ |
| environment variable | agent phase から見えてよい通常設定だけにする |
| production secret | agent phase には原則置かない |
| staging token | 短命 token にし、work log review 前提で使う |
Codex の agent internet access も同じです。公式 docs では agent phase の internet access は default off で、必要時に environment 単位で有効化します。リスクとして prompt injection、code / secret exfiltration、malware、license restriction が挙げられています。
棚卸しでは、domain allowlist を「今も必要か」で見ます。
codex_environment_review:
environment: docs-research
agent_internet_access:
mode: allowlist
domains:
- developers.openai.com
- docs.anthropic.com
- modelcontextprotocol.io
methods:
- GET
- HEAD
- OPTIONS
remove:
- registry.npmjs.org # setup script onlyで十分
- api.github.com # 今回のdocs調査には不要
evidence:
last_used_at: "2026-07-12"
work_log_checked: true調査のために開けた domain は、調査が終わったら閉じます。package install のために必要な通信は setup script に寄せ、agent phase には残さない方が棚卸ししやすいです。
MCP は server ではなく scope と token で見る
MCP では、server を許可して終わりにしない方がよいです。MCP Security Best Practices は token passthrough を anti-pattern として扱い、監査や trust boundary を壊すリスクを説明しています。
permission review では、MCP server ごとに次を見ます。
| 項目 | 確認 |
|---|---|
server_id | まだ使っているか |
owner | 障害時と棚卸し時の責任者がいるか |
tools | read tool と write tool が混ざっていないか |
oauth_scope | downstream API に対して広すぎないか |
token_audience | MCP server 向け token か |
last_used_at | 直近で必要だったか |
review_after | 次回棚卸し日があるか |
kill_switch | 止め方が分かるか |
特に write tool を持つ MCP server は、server allowlist だけでは粗すぎます。GitHub MCP なら read-only の issue 取得と comment 投稿は別物です。Notion や Slack でも、検索と投稿、draft 作成と公開は分けて見ます。
例外は必ず期限付きにする
AIエージェント運用で一番残りやすいのは例外です。
- 今週だけ外部 docs を広く読ませたい
- この repository だけ write を許可したい
- この MCP server だけ beta のまま使いたい
- この automation だけ夜間に PR を作らせたい
こういう例外は、禁止するより期限を持たせた方が現実的です。
permission_exception:
id: ex-20260716-codex-docs-research
owner: platform-team
reason: "Codex cloud environment docs refresh"
scope:
environment: docs-research
network_domains:
- learn.chatgpt.com
- code.claude.com
- modelcontextprotocol.io
allowed_until: "2026-07-30"
review_evidence:
- "work log has no secret exposure"
- "no POST / PUT / PATCH / DELETE network requests"
after_expiry: "remove domains unless renewed by owner"例外に after_expiry がないと、期限が来ても誰も何をすればよいか分かりません。継続、縮小、削除のどれかまで書きます。
月次レビューで見る指標
最初から重い GRC workflow にしなくても、月次レビューはできます。私なら、まずこの8項目だけ見ます。
| 指標 | 見る理由 |
|---|---|
| allow rule count | 便利さで広がっていないか |
| deny / block count | ルールが現実に合っているか |
| approval override count | 承認が多すぎる権限を分類し直す |
| unused MCP server | 使われていない接続を外す |
| write tool usage | 外部副作用が増えていないか |
| agent internet domains | 調査後に閉じ忘れていないか |
| secret exposure event | agent phase に残っていないか |
| expired exception | 期限切れ例外が残っていないか |
大事なのは、棚卸しを「全部読む会」にしないことです。監査ログ、MCP catalog、environment 設定、Claude Code managed settings、Codex work log から差分だけ見ます。
permission review record を残す
棚卸し結果は、長い議事録ではなく短い record にします。
permission_review:
review_id: pr-20260716-agent-permissions
period: "2026-06-16..2026-07-16"
reviewer: platform-team
scope:
- claude_code_managed_settings
- codex_cloud_environments
- mcp_server_catalog
- scheduled_automations
decisions:
- target: "codex environment docs-research"
decision: "shrink_network_allowlist"
reason: "npm registry was setup-only; agent phase did not need it"
- target: "github MCP write tools"
decision: "keep_with_approval"
reason: "used by PR review automation; all writes had approval IDs"
- target: "temporary slack webhook"
decision: "revoke"
reason: "expired exception and no usage in 30 days"
follow_up:
- "update managed settings"
- "rotate revoked webhook token"
- "add eval for denied secret read"この record は、監査ログほど細かくなくてよいです。ただし、何を継続し、何を縮小し、何を失効したかは残します。次回レビューで「なぜこの allow が残っているのか」を掘り返さなくて済むからです。
よくある失敗
1. 使われた権限だけを正当化する
使われたから必要、とは限りません。agent が楽をするために広い権限を使っただけかもしれません。棚卸しでは、同じ成果が narrower scope でできないかを見ます。
2. deny を増やして安心する
deny は必要ですが、deny だけで全体の安全性は決まりません。sandbox、MCP scope、network、secrets、automation lane を合わせて見ます。
3. MCP server を一括許可する
server を許可すると、その中の tool がまとめて安全になるわけではありません。read、draft、write、external action を分けます。
4. 例外をチケットだけで管理する
チケットに例外理由があっても、実際の設定に expires_at や owner がなければ残ります。設定と catalog の両方に期限を持たせます。
5. レビュー結果を policy に戻さない
棚卸しで「これは危ない」と分かっても、managed settings、AGENTS.md、MCP catalog、eval、monitoring に戻さなければ次回も同じです。
導入手順
最初の permission review は、次の順で十分です。
- Claude Code / Codex / MCP / automation の権限面を1枚に並べる
- write / external action / secret / internet access だけを優先して見る
- すべての例外に owner、purpose、expires_at を付ける
- 30日使われていない MCP server と network domain を削る
- 継続する例外には review_evidence を残す
- 棚卸し結果を managed settings、environment、MCP catalog、eval へ戻す
最初から完璧な台帳を作る必要はありません。まず、広い権限が放置されない状態を作る方が大事です。
参考にした一次情報
- Claude Code settings
- Codex cloud environments
- Codex agent internet access
- MCP Security Best Practices
- NIST AI RMF Core
まとめ
AIエージェントの権限管理は、最初に厳しいルールを書くことだけでは足りません。運用が進めば、例外、MCP scope、network allowlist、secrets、automation lane が少しずつ広がります。
permission review は、その広がりを定期的に戻すための仕組みです。owner、purpose、scope、expires_at、review_evidence を持たせ、使われていない権限は消し、必要な権限も狭くする。ここまでやって初めて、AIエージェントの便利さを組織で維持できます。