エージェントへの権限は「機能・範囲・承認」の3つで絞る：Claude CodeとCodexの公式文書で確かめる

3行でいうと

OWASPは、危険の根を「機能が多い・権限が多い・人の確認なしに動ける」の3つに分け、どれも絞るよう勧めています。
Claude Codeの権限ルールは、モデルではなくアプリが強制します。評価の順は拒否、確認、許可で、拒否が常に勝ちます。
許可の確認とサンドボックス（OS側の隔離）は別の層です。公式は両方を重ねる前提で書いています。

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。

先に結論

権限の設計は、どの道具を持たせるか（機能）、その道具が何に触れるか（範囲）、いつ人が止めるか（承認）、失敗しても被害を閉じ込める壁があるか（隔離）の4つに分けると整理しやすいです（見立てです）。
「プロンプトに『これはしないで』と書く」ことは、権限の設計ではありません。Claude Codeの文書は、権限ルールを強制するのはモデルではなくClaude Code自身で、プロンプトやCLAUDE.mdの指示は、許可される範囲を変えないと書いています。
承認は便利さとの綱引きです。確認が多すぎると人は流して許可し、確認が意味を失います。そこで各社は、サンドボックスの内側は確認なしで動かし、境界を越えるときだけ人に聞く、という形に寄せています。

前提：用語を先にそろえる

エージェント：AIがツール（検索、ファイル編集、コマンド実行など）を自分で選んで使い、複数の手順をこなす仕組みです。仕組みの型は別の記事「ワークフローとエージェントの違い」にあります。
最小権限：仕事に必要な最小の権限だけを渡す原則です。
承認（approval）：AIが何かを実行する前に、人が「はい」と答える仕組みです。
サンドボックス：プログラムが触れるファイルや通信先を、OSの仕組みで囲い込む隔離です。
プロンプトインジェクション：AIが読む文章（ウェブページ、メール、課題票）に紛れた指示で、AIを操る攻撃です。権限を絞る最大の理由が、これが起きても被害を小さくするためです。

考え方：OWASPの整理

OWASP（Webなどの安全に関する非営利の団体）の「LLMアプリ向けTop 10（2025年版）」のLLM06 Excessive Agency（過剰な裁量）は、AIが誤った出力や操作された出力に従って、害のある行動をとってしまう脆弱性です。原因は、幻覚（もっともらしい誤り）、性能の低さ、直接・間接のプロンプトインジェクションなど、何でも含まれます。

危険の根は3つに分けられています。

根	意味	対策の例（OWASPの記載）
過剰な機能	その仕事に要らない機能が付いている	道具の数を絞る。各道具の機能を絞る。シェルやURL取得のような何でもできる道具を避け、細かく分けた道具にする
過剰な権限	下流のシステムに必要以上の権限がある	利用者本人の最小権限で動かす（範囲を限ったOAuthなど）。下流の側でも許可を確かめる（AIの判断に頼らない）
過剰な自律性	影響の大きな行動を、独立に確認・承認せずに実行する	影響の大きな操作は人が承認する

ログ、監視、速度制限は、被害を抑えるものであって、過剰な裁量を防ぐものではない、とも書かれています。

OWASPの「Top 10 for Agentic Applications 2026」（2025年12月の版。公式PDFで確認）は、10項目のリストです。ツールの悪用、ID・権限の悪用、予期しないコード実行、カスケード障害などが並びます。文書は「Least-Agency（最小の裁量）」という言い方で、必要のない自律性を持たせないよう勧めています。権限はタスクの範囲で、期限を切って渡すこと（task-scoped, time-bound）、というのが、IDと権限の項目の対策の一つです。

Claude Codeの設計

Anthropicの開発者向けAIアプリ、Claude Codeの公式文書から、権限の仕組みを読みます。

権限ルールとモード

ルールは3種類。許可（allow）は確認なしで使える、確認（ask）は毎回聞く、拒否（deny）は使えない。
評価の順は拒否、確認、許可で、最初に合ったものが結果を決めます。範囲の狭い許可ルールで、広い拒否ルールを例外にすることはできません（例：Bash(aws *)を拒否していれば、Bash(aws s3 ls)を許可しても通りません）。
設定は、ユーザー、プロジェクト、管理（組織）の層で重なり、どこかで拒否されたものは、他の層で許可できません。管理設定は最上位で、コマンドライン引数でも上書きできません。
「手動（Manual）」モードは、読み取りだけを確認なしで許可し、ファイル変更やコマンド実行は聞きます。作業ディレクトリの外へのアクセスも聞きます。どのモードで始まるかは、使う画面やプランで変わると文書にあり、セキュリティの頁には、対話の端末ではautoが組み込みの開始モードだと書かれています。
モードは複数あります。acceptEdits（作業ディレクトリ内の編集と一部のファイル操作を自動承認）、plan（読むだけ）、auto（別の分類モデルが各操作を検査して、危ないと判断したものを止める）、dontAsk（聞くはずのものを自動で拒否）、bypassPermissions（確認を飛ばす）。
bypassPermissionsについて、文書は警告を出しています。確認を飛ばすモードなので、コンテナやVMのような隔離環境でだけ使うこと、とあります。このモードやautoを禁止する設定もあり、管理設定に置くと利用者が上書きできません。

サンドボックス（Bashの隔離）

Claude CodeのBashサンドボックスは、シェルのコマンドと、その子プロセスに対して、OSが強制する境界を作ります。macOSでは組み込みのSeatbelt、LinuxとWSL2ではbubblewrapとsocatを使います。ネイティブのWindowsでは、サンドボックスなしで実行される、と書かれています。

既定の境界は、公式の表では次のとおりです。

項目	既定
書き込み	作業ディレクトリ、利用者ごとの一時ディレクトリ、追加したディレクトリ。保護された場所は書き込み不可
読み取り	マシンの大部分。`~/.ssh`や`~/.aws/credentials`のような認証情報のファイルも含む
ネットワーク	直接の出口なし。自分のマシン上のプロキシを通り、許可ドメイン（最初は空）にある宛先だけ
環境変数	Claude Codeから引き継ぐ。環境にある秘密情報も含む

読み取りが広いこと、環境変数が引き継がれることは、見落としやすい点です。文書は、認証情報を守る設定（denyReadやcredentials）を別に用意しています。

サンドボックスの外で動くものもあります。

ファイルの読み書きやウェブ取得の組み込みツール（これらは権限ルールの管轄）
フック、ローカルのMCPサーバー、LSPサーバーなど、Claude Codeが起動する他のプロセス
利用者が!で直接打つコマンドの多く
除外コマンド（excludedCommands）に当てはまるもの
Claudeが「サンドボックスなしで再試行」を求めた場合（dangerouslyDisableSandbox）

つまり、サンドボックスは「シェルコマンドの囲い」であって、エージェント全体の囲いではありません。全体を囲むには、Claude Code自体をコンテナ、VM、サンドボックスランタイムの中で動かす、と文書が案内しています。

許可の確認とサンドボックスの関係

公式は「許可（どの道具を使えるか）」と「サンドボックス（OSが強制する、ファイルとネットワークの制限）」を補い合う層としています。プロンプトインジェクションでAIの判断が崩れても、サンドボックスの制限は残る、というのが重ねる理由です。サンドボックスの内側のコマンドは、既定で確認なしに実行される設定があり、境界が確認の代わりになります。

サンドボックスの限界（公式文書の記載）

サンドボックスの頁は、「リスクを減らすが、完全な隔離の境界ではない」と明記しています。主な限界は次のとおりです。

ネットワークのフィルタ：既定のプロキシは暗号化された通信の中身を見ません。許可ドメインにgithub.comのような広いものを入れると、データ持ち出しの道ができうる、と警告されています。ドメイン・フロンティングのような手法で許可外に出られる可能性も書かれています。より強い保証が必要なら、TLSを終端して検査する独自のプロキシを使う、とあります。
Unixソケット：allowUnixSocketsで/var/run/docker.sockなどを許すと、実質ホストへの道が開く。
ファイルの書き込みを広く許すこと：$PATH上の実行ファイルのあるディレクトリや、.bashrcなどへの書き込みを許すと、別の文脈でコードが実行される。
Linuxの弱い入れ子モード：enableWeakerNestedSandboxはDocker内で動かすための設定で、安全性を大きく下げる。ほかの隔離がある場合だけ使うこと。
macOSのApple Events：許可すると、サンドボックス内のコマンドが、他のアプリを制限なしに起動できる。
公式の警告：「ファイルの隔離とネットワークの隔離の両方が要る」。ネットワークがなければ、侵害されたエージェントが秘密鍵を持ち出せる。ファイルの隔離がなければ、システム資源に細工してネットワークへの道を作れる。

Codexの設計

OpenAIのコーディングエージェントCodexの公式文書（Agent approvals & security、Sandboxing）から読みます。サンドボックスと承認が、別の設定として分かれています。

設定	値	意味（文書の記載）
サンドボックスのモード	`read-only`	読むだけ
	`workspace-write`	作業場所で編集とコマンド実行ができる。既定ではネットワークは切れている
	`danger-full-access`	サンドボックスなし
承認の方針	`on-request`	サンドボックスを出る、またはネットワークを使うときに聞く
	`never`	聞かない。選んだサンドボックスの中で動く
	granular	一部の種類だけ聞き、他は自動で拒否
	`untrusted`	廃止。指定すると起動に失敗することがある

作業場所には、現在のディレクトリと/tmpのような一時ディレクトリが含まれます。workspace-writeでは、.gitと、ディレクトリとして存在する場合の.agents、.codex、.awsは、中身も含めて読み取り専用に保護されます。
「Auto」という初期の設定は、--sandbox workspace-write --ask-for-approval on-requestと同じです。作業場所の中では聞かずに編集・実行し、外への編集やネットワークの前に聞きます。バージョン管理されたフォルダーはこれ、そうでないフォルダーはread-onlyで始まります。
ネットワークを使うには、network_access = trueを設定します。ドメインで絞るプロキシ（features.network_proxy）は、それ自体ではアクセスを許さず、許可リストが先で、denyがallowに勝ちます。内部のアドレスは、許可しない限り遮断されます。
--dangerously-bypass-approvals-and-sandbox（別名--yolo）は、サンドボックスと承認の両方を外します。文書は「推奨しない」としています。
ウェブ検索は、既定ではcached（OpenAIが保持する索引）で、これが「プロンプトインジェクションへの露出を減らす」と書かれています。liveにすると（--yoloでは既定がliveになる、とも書かれています）、ウェブの内容を直接取るので、信頼できない指示に従わされる可能性があり、検索結果は信頼しない扱いにする、とされています。
推奨として、機能用のブランチで作業する、作業前にgit statusをきれいにしておく、差分をPRと同じように見る、が挙がっています。コンテナの中でdanger-full-accessを使うのは、信頼できるリポジトリに限る、とあります（悪意あるプロジェクトが、コンテナ内の認証情報を持ち出せるため）。

設計の手順：4つの問い

見立てです。ここまでの文書を並べると、エージェントを導入するときの問いは、次の順になると思います。

機能：この仕事に、本当に要る道具は何か。シェルやURL取得のような「何でも」の道具は、必要になるまで外す。
範囲：各道具は何に触れられるか。読み取り専用で足りないか。1つのリポジトリ、1つのフォルダー、1つのドメインに限れないか。認証情報の置き場所は、読めない場所にあるか。
承認：取り消せない操作（削除、送信、支払い、本番への反映）だけは人を挟めるか。承認が多すぎて流していないか。サンドボックスの内側は確認なし、外へ出るときだけ確認、という形にできないか。
隔離と記録：失敗しても被害が囲い込まれるか。コンテナやVMの中か。呼び出しの記録は残るか。

承認を人が押すだけでは足りない理由も、文書から読み取れます。Googleの文書（別の記事で紹介）は、人が承認を誤る問題を挙げています。見立てです。だから、承認を残しつつ、それとは別に、権限の範囲そのものを絞っておく二重の構えが要ると思います。

よくある失敗・つまずき

見立てです。公式文書の警告から、起きやすいと思う点を挙げます。

確認を避けるために、確認を飛ばすモード（bypassPermissions、--yolo）を、隔離のない自分のマシンで使う。
「許可」を足していくうちに、広い許可ルールが積もる。Bash(curl *)のような許可が、サンドボックスなしの再試行も承認してしまう、と文書にあります。
サンドボックスを入れたから安心だと考える。サンドボックスの外で動くもの（ローカルのMCPサーバー、フックなど）や、広すぎる許可ドメインが穴になります。
認証情報が読める場所に置かれている。Claude Codeのサンドボックスは、読み取りの既定が広いです。
非対話の実行（自動化、CI）で、対話時の承認画面が出ないことを忘れる。
AIへの指示（「秘密は読まないで」）だけで済ませる。ルールの強制は、モデルでなくアプリ側の仕事です。

気をつけること

この記事は、実際に使って確かめた記録ではありません。公式文書を読んでまとめたものです。
設定名、既定値、モードの種類は、製品の更新で変わります。この記事は2026年10月8日に読み、10月23日に公式文書を読み直した版です。Codexのuntrustedのように、廃止された値もあります。
ClaudeとCodexの設計を比べて優劣を述べてはいません。表は、文書の記載を並べただけです。
OWASPのAgentic Applicationsのリストは、公式PDFの1か所で確かめました。項目名は意訳です。
CodexのSandboxingのページは、ネットワークの既定を明記していませんでした。ネットワークが既定で切れている、という記載は、Agent approvals & securityのページのものです。
ここで紹介したのは製品の機能の紹介で、特定の環境が安全であることの保証ではありません。業務で使う場合は、社内のセキュリティ担当などに相談してください。
権限を絞っても、プロンプトインジェクションが起きる可能性はゼロになりません。公式文書も、完全に防げるとは言っていません。

出典

更新履歴

2026年10月25日 書き方を直しました。
- 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した
2026年10月23日 公式の資料を読み直して、次の点を直しました。
- 前：Codexで読み取り専用に守られるのは.git、.agents、.codex → いま：.awsも加わり、中身も含めて守られる（ディレクトリとして存在する場合）
- 前：Codexのウェブ検索liveの説明のみ → いま：--yoloでは既定がliveになる、との説明を追加
一部の出典は読めなかったため、その部分は前のままです。