MCPの権限はどこまで許可する？AIエージェント連携を安全に始める最小権限ガイド
MCPでAIエージェントに外部ツールをつなぐ前に、読み取り、書き込み、削除、外部送信、認証情報アクセスを分けて最小権限から始める方法を整理します。
公開 2026.06.30 / 更新 2026.08.10
この記事のポイント
- MCPは外部データやツールをLLMアプリに接続する標準的な仕組み
- 読み取り、書き込み、削除、外部送信、認証情報アクセスは分けて許可する
- 出所不明のMCPサーバーや強い権限の初期許可を避ける
Work pluginsとProgrammatic Tool Callingも最小権限から始める
Workのplugin / connected appと、Responses APIでprogramから呼ぶMCP toolは、どちらも接続できることと許可してよいことを分けます。read / write / delete / external sendを分離し、allowed_callersとrequire_approvalを用途に合わせます。
MCPのtool許可とCodexのpermission profileは別に見る
MCPのtool policyは、接続したサーバーの検索・書き込み・削除・外部送信など、AIにどの道具を見せるかを決めます。一方、Codexのpermission profileは、Codexが実行するローカルコマンドのfilesystemとnetworkの境界を決めます。MCPを接続しただけでCodexのfilesystem権限が広がるわけでも、Codex側を安全なprofileにしただけでMCPのtoolが安全になるわけでもありません。
| 層 | 主に制御するもの | 最初の設計 |
|---|---|---|
| MCP tool policy | 接続サーバーのtoolと操作範囲 | read中心、tool allowlist、削除・送信は分離 |
| Codex permission profile | ローカルコマンドのfilesystem・network境界 | `:read-only`またはworkspaceを絞ったnamed profile |
| Sandbox mode | 技術的に何ができるか | workspace内のwrite、network offから確認 |
| Approval policy | いつ人間へ確認を求めるか | 外部workspace・network・副作用のある操作で止める |
Codexのpermission profileを最小権限で使う
公式ドキュメントでは、組み込みprofileとして`:read-only`、`:workspace`、`:danger-full-access`が案内されています。通常は`:read-only`から始め、書き込みが必要な作業だけworkspace rootを限定したnamed profileへ広げます。`default_permissions`と`[permissions]`を使う新しいpermission profilesと、旧`sandbox_mode`設定は同時に組み合わせず、既存のconfigに古い設定が残っていないか確認します。
- MCP側では、read・write・delete・external send・credential accessを別々に棚卸しする
- Codex側では、まず`:read-only`または対象workspaceだけを書けるnamed profileを選ぶ
- networkを有効にする理由がある場合だけdomain allowlistを作り、domain ruleではdenyがallowに優先する前提で確認する
- approvalは確認のタイミングであり、sandboxやpermission profileの代わりではない。副作用のあるMCP・app呼び出しも別にレビューする
- 会話だけ、または計画だけにしたいときは`/permissions`でread-onlyへ切り替える