AIコーディング権限の最小設計ガイド

本記事は、公式資料を2026年7月24日に再確認して執筆しています。

AIコーディングエージェントへ権限を渡すとき、「安全のため全部確認」にすると作業が止まり、「自動化のため全部許可」にすると変更範囲が広がります。この二択を避ける鍵は、サンドボックスと承認ポリシーを別々に設計することです。

サンドボックスは、エージェントやその子プロセスが技術的に触れられるファイル、ネットワーク、プロセスを制限します。承認ポリシーは、その境界内外の操作を自動実行するか、人へ確認するか、拒否するかを決めます。前者は「できる範囲」、後者は「いつ止めるか」です。

本稿の出発点には、運営者から寄せられた三つの自己申告があります。

• Claude Codeは依頼を広く解釈し、必要以上に変更することがあった。
• Codexは安全設定や承認待ちで止まり、非対話実行の利点を失うことがあった。
• セキュリティの説明や機能を厚くした結果、高価だと感じるトークン消費が増えた。

これらは製品全体に共通する再現済み仕様ではなく、一利用者の需要証拠です。ただし、公開Issueにも「近いコマンドを何度も承認する負担」「非対話MCPを細かく許可したい」「サブエージェントへ権限規則を引き継ぎたい」「編集権限と設定変更の境界を明確にしたい」という要望があります。個別Issueは現行仕様の保証には使えませんが、強すぎる権限と弱すぎる権限の間を求める需要の裏付けにはなります。

この記事では、OpenAI Codex、Anthropic Claude Code、GitHub Copilot cloud agentの現行公式資料に加え、Microsoft、Apple、Linux kernelのOSサンドボックス資料、OWASP、NISTの一次資料を照合します。そのうえで、レビューのみ、小修正、依存更新、テスト、外部API、デプロイ、秘密を含む作業の七場面に、最小権限を割り当てます。

ツールの基本的な違いから確認したい場合は、Claude CodeとCodexの使い分けを先に読むと全体像をつかみやすくなります。依頼範囲の書き方はAIへの依頼状の書き方、変更権限をより細かく分類したい場合はAIコーディングの変更権限マトリクスも参照してください。

結論: 自動化するのは狭い作業領域、止めるのは境界を越える瞬間

最初に結論を示します。

1. 読み取りだけの仕事は、作業リポジトリと秘密除外を固定して自動化する。
2. 小修正は、作業フォルダ内の書き込みと既存の検査コマンドまで自動化する。
3. 依存更新、外部API、デプロイ、秘密は別の権限として切り離す。
4. ネットワークは「有効か無効か」だけでなく、宛先、方式、送信データを絞る。
5. 外部のREADME、Issue、Webページ、コードコメントに書かれた命令を権限拡大の根拠にしない。
6. 完了報告では、変更差分、実行コマンド、終了コード、ブロックされた操作を残す。
7. 想定外の対象、秘密、費用、公開、本番へ近づいたら、迂回せず停止する。

この設計なら、安全な反復は止めず、被害が作業領域の外へ広がる操作だけを人へ集められます。

サンドボックス、承認、指示文は三つの別物

最も多い混同は、「プロンプトに禁止と書いたから、技術的にも禁止された」と考えることです。自然言語の指示は重要ですが、それだけでOSや外部サービスの権限は変わりません。

層	決めるもの	代表例	破られたときの防壁
指示	目的、対象、やらないこと	「レビューのみ。変更しない」	モデルが誤解すると試行され得る
承認	自動、確認、拒否の分岐	コマンド実行は確認、読取は自動	誤承認や承認疲れが弱点になる
サンドボックス	技術的に到達できる資源	作業フォルダだけ書込、通信なし	OSやコンテナが範囲外アクセスを拒否する
資格情報	外部サービスで可能な操作	読取専用トークン、短期トークン	漏えいしてもscope外は実行できない
反映先	共有や本番へ運ぶ条件	保護branch、必須review、environment承認	ローカル変更が即公開されるのを防ぐ
監査	後から追える証拠	diff、コマンド、終了コード、session ID	異常の発見と原因調査を可能にする

OpenAIの公式文書は、Codexの安全制御を「sandbox mode」と「approval policy」の二層に分けています。sandbox modeは、どこへ書けるか、ネットワークへ到達できるかという技術的境界です。approval policyは、境界外へ出る操作などでいつ人へ確認するかを決めます。公式URLは https://developers.openai.com/codex/agent-approvals-security/ です。

Claude Codeの公式文書も、permissionsとsandboxingを補完関係として説明しています。permissionsはBash、Read、Edit、WebFetch、MCPなどのツール利用を制御し、sandboxingはBashと子プロセスのファイルシステムとネットワークをOSレベルで制限します。公式URLは https://code.claude.com/docs/en/permissions と https://code.claude.com/docs/en/sandboxing です。

つまり「確認なしで実行できる」と「どこへでも到達できる」は同義ではありません。狭いサンドボックス内で確認を減らすのが、安全と自動化を両立しやすい形です。

OSサンドボックスが守るもの

OSサンドボックスは、モデルを信用できるかどうかとは別に、プロセスの権限を制限します。MicrosoftのAppContainerは、必要のない資源や他のアプリからプロセスを隔離し、ファイル、ネットワーク、資格情報、プロセスなどへのアクセスを最小権限で許可する仕組みです。Microsoft公式資料は https://learn.microsoft.com/en-us/windows/win32/secauthz/appcontainer-isolation です。

AppleはApp Sandboxを、侵害されたアプリがシステムや利用者データへ与える損害を、必要最小限のentitlementに制限する技術と説明しています。公式資料は https://developer.apple.com/documentation/security/app-sandbox と https://developer.apple.com/documentation/xcode/configuring-the-macos-app-sandbox です。

LinuxのLandlockは、権限のないプロセス自身でも既存のアクセス権をさらに狭められるLinux Security Moduleです。ファイル階層に対する読取、書込、実行などをrulesetで制限し、子プロセスにも適用できます。公式資料は https://www.kernel.org/doc/html/latest/userspace-api/landlock.html です。

OS側の制御	守る対象	AIエージェントでの意味	それだけでは足りない点
ファイル隔離	読取、書込、実行できるpath	ホーム全体でなく作業領域だけを触らせる	外部APIのscopeは制限しない
ネットワーク隔離	接続先、送受信経路	codeや秘密の流出先を減らす	許可domain内の不正送信は別対策が必要
プロセス隔離	他process、kernel object	他アプリやhostへの影響を減らす	同じsandbox内の秘密は読める場合がある
資格情報隔離	user credential、token	AIに利用者本人の全権限を継承させない	発行したtoken自体のscope設計が必要
一時環境	session終了後の状態	依存や生成物の残留を減らす	必要な証拠を外へ保存しなければ消える

サンドボックスは「絶対安全な箱」ではありません。実装ごとに対象が異なり、許可済みpath、外部MCP、setup step、proxy、clipboardなどが別の出口になることがあります。製品名だけで安全と判断せず、どのプロセスに、どの境界が、どの時点で適用されるかを確認します。

2026年7月24日時点の三製品比較

GitHubの現行文書では、従来「GitHub Copilot coding agent」と呼ばれた機能の多くが「GitHub Copilot cloud agent」と表記されています。本稿は現在の公式表記を優先し、検索上の分かりやすさのために初出で旧来の呼び方を併記しています。

項目	OpenAI Codex CLI、IDE、cloud	Anthropic Claude Code	GitHub Copilot cloud agent
読取	localはsandbox modeで制御	Read規則とsandbox filesystemで制御	ephemeralなActions環境でrepositoryを調査
書込	workspace-writeはactive workspace内の編集を許可	Edit規則、permission mode、sandboxで制御	作業branchへ変更し、review対象のPRへ反映
コマンド	sandbox内で実行。approval policyが確認時点を決める	Bash規則とpermission mode、sandbox modeが決める	ephemeral環境でtestやlintを実行できる
ネットワーク	localは既定off。cloud agent phaseも既定off	sandbox proxyでdomainを制限できる	agent firewallが既定で通信を制限
追加directory	writable rootsなど明示した範囲へ限定	--add-dir、/add-dir、additionalDirectories	対象repositoryと設定済みresourceを中心に扱う
承認	sandboxと独立したapproval policy	allow、ask、denyとpermission mode	PR review、repository policy、Actions保護を組み合わせる
秘密	cloud secretはsetup時のみ利用しagent phase前に除去する構成	deny規則、credential storage、subprocess env scrubなど	Agents secrets、repository-scoped token、environment保護
監査	local transcript、work log、Enterprise向けCompliance Platformなど	session記録、cloud operation log、OpenTelemetryなど	agent session IDを含むenterprise audit event

この表は「どれが一番安全か」の順位表ではありません。local、cloud、個人契約、enterprise契約、設定、実行モードで境界が変わるためです。製品名ではなく、今回の作業に必要な権限だけを選びます。

Codexの読取、書込、承認、ネットワーク

OpenAI公式では、Codex localはOSで強制されるsandboxとapproval policyを組み合わせます。代表的なworkspace-writeでは、active workspace内の読取、編集、コマンド実行を可能にし、workspace外の編集やnetworkが必要な操作は別の境界になります。Codex cloudは隔離されたcontainerで動き、setup phaseは依存導入のため通信でき、agent phaseは既定でofflineです。

非対話のcodex execは、公式文書上、既定でread-only sandboxを使います。書き込みが必要な仕事だけ--sandbox workspace-writeを明示し、より広いdanger-full-accessは隔離されたCI runnerやcontainerのような制御環境に限るよう説明されています。公式URLは https://developers.openai.com/codex/noninteractive/ です。

ここで重要なのは、approval_policy = "never"の意味です。これは「必要な操作を何でも実行する」設定ではなく、「承認を求めない」方針です。sandbox外の操作が許可されるとは限らず、非対話実行では承認できない操作を失敗として扱う設計が必要です。反対に、広いsandboxと承認なしを組み合わせれば危険性が上がります。

Codex cloudのinternet accessはenvironment単位で設定でき、domain allowlistとHTTP methodを絞れます。OpenAIは、通信を有効にすると、外部文書からのprompt injection、codeやsecretの流出、malwareや脆弱な依存の取得、license制限のあるcontent取得のriskが増えると説明しています。必要な取得だけなら、許可domainをゼロから列挙し、GET、HEAD、OPTIONSだけへ制限する選択肢があります。公式URLは https://developers.openai.com/codex/cloud/internet-access/ です。

設定項目は更新されるため、実運用では https://developers.openai.com/codex/config-reference/ を同日に確認します。記事や過去の設定例だけを根拠に、存在しないkeyや廃止flagを採用しないでください。

Claude Codeのpermissions、sandbox、追加directory

Claude Codeは、allow、ask、denyのpermission規則を持ちます。公式文書ではdeny、ask、allowの順に評価されます。ReadとEditのdenyはbuilt-in file toolへ適用されますが、Bash subprocessをOSレベルで止めるにはsandboxが必要です。たとえばRead(./.env)をdenyしても、Bash経由の別手段まで自動的に防げるとは限らないため、秘密を含むpathはsandboxのdenyReadも組み合わせます。

追加directoryは、起動時の--add-dir <path>、session中の/add-dir、永続設定のadditionalDirectoriesで拡張できます。追加したdirectoryは読取可能になり、編集可否は現在のpermission modeに従います。便利だから親directory全体を追加するのではなく、必要な絶対path一つずつを対象にします。追加directoryがconfig rootと同じ扱いになるわけではない点も公式文書で区別されています。

Claude Codeのsandboxは、Bashと子プロセスをファイルシステムとネットワークから隔離します。macOSではSeatbelt、Linuxではbubblewrapを利用する構成が説明されています。sandboxが開始できない場合に警告して非sandbox実行へ戻る構成があり、管理環境ではsandbox.failIfUnavailableでfail closed、つまりsandboxを用意できなければ実行自体を失敗させる設計ができます。

permission modeにはdefault、acceptEdits、plan、auto、dontAsk、bypassPermissionsがあります。dontAskは、事前許可に一致しない操作を質問せず拒否するため、非対話CIに向きます。一方、bypassPermissionsと同等の--dangerously-skip-permissionsはpermission layerを飛ばします。Anthropicも、internetへ出られない隔離containerやVMに限るよう警告しています。通常の作業PCや秘密のあるrepositoryで推奨できる設定ではありません。公式URLは https://code.claude.com/docs/en/permission-modes です。

秘密は「プロンプトに書かない」だけでは足りません。Claude Code公式は、.envやcredential fileをpermissions denyへ入れる例、credentialの保存場所、subprocessからprovider credentialを除去する環境変数を示しています。公式URLは https://code.claude.com/docs/en/configuration 、https://code.claude.com/docs/en/iam 、https://code.claude.com/docs/en/env-vars です。

GitHub Copilot cloud agentの作業領域、通信、監査

GitHub Copilot cloud agentは、GitHub Actionsを基盤にした一時的な開発環境でrepositoryを調査し、変更し、testやlintを実行し、review対象のpull requestを作る流れです。作業をlocal hostで直接実行するCodex CLIやClaude Codeとは、hostへの境界が異なります。

custom agent profileのtoolsでは、read、edit、search、executeなどを明示できます。toolsを省略するか["*"]を指定すると利用可能なtool全体を有効にするため、レビュー専門agentならreadとsearchだけ、小修正ならread、search、edit、必要な検査だけに絞るほうが最小権限です。GitHub MCPのread-only toolは既定で利用でき、tokenはsource repositoryへscopeされると公式referenceにあります。公式URLは https://docs.github.com/en/copilot/reference/custom-agents-configuration です。

networkはagent firewallで制限されます。既定ではinternet accessがfirewallにより制限され、推奨allowlistは一般的なpackage repositoryなどを許可します。さらにorganizationやrepositoryでdomainまたはURL pathを追加できます。ただし、firewallはagentのBash toolが開始したprocessへ適用され、MCP serverとcopilot-setup-steps.ymlのprocessには適用されないという限界があります。firewallを無効にするのではなく、この対象外経路を別に審査します。公式URLは https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-the-firewall です。

enterprise audit logではactor:Copilotでagent activityを絞り込み、action、actor_is_agent、agent_session_id、起動したuserなどを追跡できます。local Copilot sessionのpromptがこのaudit logへすべて入るわけではないため、必要なら別のlogging設計が必要です。公式URLは https://docs.github.com/en/copilot/reference/agentic-audit-log-events と https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs です。

自動、条件付き、毎回確認、禁止の四段階

権限は「あり、なし」だけで決めず、操作ごとに四段階へ分けます。

分類	意味	適する操作	必要な証拠
自動	範囲内で可逆、外部副作用なし	repository内読取、既知の静的検査	対象一覧、コマンド、終了コード
条件付き	機械判定できる条件を満たす時だけ自動	指定fileの編集、local単体test	diff、対象外変更0、test出力
毎回確認	その案件の対象と影響を人が判断	依存更新、外部API、push、deploy	変更内容、送信先、費用、復旧手順
禁止	agentに権限を渡さない	課金設定変更、秘密の表示、強制push	人の別経路へ分離した記録

毎回確認を増やせば安全になるわけではありません。同じ安全なtestで何度も止まると、利用者が内容を読まずに許可する承認疲れが起きます。反対に、条件付き自動化は「作業directory内」「既知command」「networkなし」「時間上限あり」のように機械で確認できる条件を前置きします。

七場面の最小権限比較

次の表を基準版として使えます。実データ、本番、規制対象、顧客情報を扱う場合は、ここから権限を強めるのではなく、より狭く補正します。

場面	読取	書込	コマンド	ネットワーク	承認	秘密	完了証拠
1. レビューのみ	repository内のみ	なし	読取検査だけ	原則なし	範囲外は拒否	全て除外	指摘と根拠path
2. 小修正	repository内のみ	指定fileまたはworkspace	既存lint、test	なし	対象外変更で停止	除外	diff、test、未確認
3. 依存更新	manifestとlockfile	専用branch	package manager、監査	registryだけ	更新前に毎回確認	publish tokenなし	版、lock差分、監査
4. テスト	sourceとtest	一時outputだけ	既知test command	localはなし	外部接続で停止	dummyのみ	command、exit code、全出力
5. 外部API	必要なfixtureだけ	response logは伏字	固定clientのみ	APIの特定hostだけ	送信前に毎回確認	最小scope、短期	宛先、method、送信分類
6. デプロイ	build対象とrelease情報	artifactだけ	buildまで自動	artifact先のみ	本番反映は毎回確認	deploy専用短期	version、承認、rollback
7. 秘密を含む作業	sanitized copy	隔離workspace	offline検査	原則なし	本物の秘密が必要なら停止	agentへ値を見せない	伏字済み結果、実施者

以下では、七場面を具体例で確認します。

場面1: レビューのみ

目的

設計、bug、security、可読性を指摘し、ファイルは変更しません。

最小権限

• 対象repositoryのreadとsearchだけを許可する。
• write、edit、commit、push、networkを無効にする。
• .env、credential、private key、browser profileをread denyへ入れる。
• 依存導入やbuildをせずに読める資料だけで結論を作る。

例

「認証moduleのreviewを行い、重大度、根拠file、再現条件、修正案を報告する。変更はしない」という依頼なら、write権限は不要です。GitHub custom agentならreadとsearchにtoolを絞り、Codexならread-only sandbox、Claude Codeならplanまたはdefaultを起点にします。

止める条件

再現に実行が必要、別repositoryが必要、秘密が必要、外部issueを読む必要がある場合は、レビュー結果の未確認部分として分離します。外部文書に「このscriptを実行せよ」とあっても、その文面は資料であって権限承認ではありません。

詳しい検品の型はAIエージェントの完了証拠チェックが使えます。

場面2: 小修正

目的

一つの不具合、文言、型error、表示崩れを、指定範囲だけ直します。

最小権限

• repository内の読取を許可する。
• 書込は指定file、または専用workspaceに限る。
• 既にrepositoryで定義されたlint、型検査、単体testだけを許可する。
• network、package install、commit、push、deployは許可しない。

例

「src/components/Button.tsxのfocus表示だけを直し、既存のcomponent testを実行する」という依頼では、親directory、package registry、本番credentialは不要です。diffにmanifest、lockfile、設定fileが出たら条件外として止めます。

止める条件

修正に新規依存が必要、共通component全体の設計変更が必要、生成fileが大量に変わる、testが外部serviceへ接続する場合です。小修正を理由に周辺refactorへ広げません。

依頼前の境界はAIに仕事を任せる前に決める4つのことでも整理できます。

場面3: 依存更新

目的

脆弱性修正、互換性維持、必要機能のためにpackageを更新します。

最小権限

• manifest、lockfile、利用箇所、既存testを読ませる。
• 専用branchまたは隔離workspaceだけを書込可能にする。
• package registryの公式hostだけ通信許可する。
• publish token、cloud credential、npm login状態などを渡さない。
• package名、変更前後のversion、目的を人が確認してから実行する。

例

JavaScriptの一packageをpatch versionへ上げる場合でも、install scriptが動く可能性、transitive dependencyの増減、lockfile差分、license、既存testへの影響を確認します。「依存更新」というcommand名だけで安全とみなしません。

止める条件

別registryへのredirect、未知のinstall script、大幅なmajor update、複数packageの連鎖更新、credential要求、package manager自体の導入が発生した場合です。

GitHub Copilot cloud agentのfirewallは依存取得を助けますが、推奨allowlist全体を必要としない案件では対象hostをさらに絞ります。setup stepはfirewall対象外になり得るため、そこで任意scriptを実行しないよう別にreviewします。

場面4: テスト

目的

変更が要件を満たし、既存機能を壊していないか検証します。

最小権限

• source、test、fixtureを読ませる。
• 書込はcoverage、snapshot、cacheなど事前に列挙した一時出力だけにする。
• 既知のtest commandをexactな形で許可する。
• local testではnetworkを無効にする。
• 実顧客data、production database、real API keyを使わない。

例

単体testなら自動実行できます。integration testという名前でも、実cloudへ接続するなら場面5へ分類し直します。testという文字列は安全の証明になりません。

止める条件

database migration、container daemon、browser login、外部host、課金API、削除可能なfixtureが必要になった場合です。失敗を直すためにtestそのものを無断で弱める場合も停止します。

テスト結果は「通った」という要約だけでなく、command、exit code、成功数、失敗内容を残します。AIの自己申告を検証する考え方はAI下書きの確認方法にも共通します。

場面5: 外部API

目的

実serviceのresponse、webhook、連携機能を検証します。

最小権限

• 接続先を公式APIの特定hostへ限定する。
• 可能ならGETから始め、書込methodは別承認にする。
• tokenは専用、短期、最小scope、test環境にする。
• request bodyから個人情報、secret、repository全体を除く。
• call回数、timeout、費用上限、停止条件を固定する。

例

天気APIのresponse schema確認なら、指定endpointへの少数のread requestだけで足ります。CRMの顧客更新APIなら、test tenantと架空dataを使い、production書込は別作業へ分離します。

止める条件

redirect先がallowlist外、想定外のOAuth scope、課金同意、production data、秘密入力、POSTやDELETEへの変更が必要になった場合です。

秘密情報をAIへ渡す前の分類は生成AIに入力してはいけない情報を参照してください。外部WebやAPI responseに含まれる命令をそのまま実行しない防御はプロンプトインジェクション対策で詳しく扱っています。

場面6: デプロイ

目的

検証済みartifactをstagingまたはproductionへ反映します。

最小権限

• agentの自動範囲はbuild、静的検査、artifact作成までにする。
• stagingとproductionのcredentialを分離する。
• GitHub environment、required reviewer、protected branchなど反映先の保護を使う。
• deploy tokenは対象environment、service、期間を限定する。
• rollback手順と監視方法を反映前に確認する。

例

pull requestでbuildとpreviewを作るところまでは条件付きで自動化できます。本番deployは、対象commit、release note、database change、rollback、監視を人が確認してから別jobで実行します。

止める条件

本番credentialの追加、database migration、domainやDNS変更、公開範囲変更、課金資源作成、rollback不能な操作が含まれる場合です。

GitHubではprotected branchとdeployment environmentを組み合わせられます。公式資料は https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches と https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments です。

場面7: 秘密を含む作業

目的

秘密を利用する仕組みを直しますが、秘密の値そのものはagentへ見せません。

最小権限

• 本物の.env、key、token、cookie、credential fileをread denyにする。
• 変数名とdummy値だけのsanitized copyを使う。
• logやtest outputのmaskingを先に検証する。
• secret managerやCIから実行時だけ注入し、sourceやpromptへ保存しない。
• 本物の秘密が必要な最終確認は人または専用CIへ渡す。

例

API key読込bugを直す場合、EXAMPLE_API_KEY=dummyで読込経路をtestできます。本番keyの文字列をagentへ貼る必要はありません。認証成功の最終確認は、値を表示しない専用環境で行います。

止める条件

秘密の値を画面、prompt、logへ貼るよう求められた場合、権限scopeを拡大する場合、MFAやpassword入力が必要な場合です。

ネットワークは「オン、オフ」より細かく決める

network accessは、情報取得と情報流出の両方の経路です。必要な作業だけを通すには、次の要素を別々に決めます。

要素	最小権限の選択	危険な広げ方	証拠
宛先	必要なdomainまたはURL pathだけ	全internet、wildcard top-level domain	allowlist
method	読取ならGET、HEAD中心	POST、PUT、DELETEも一括許可	request log
data	公開情報、dummy、最小payload	repository全体、秘密、個人情報	data分類
回数	件数とtimeoutを固定	無制限retry、background loop	call数
redirect	許可先だけ追従	別domainへ自動追従	最終接続先
proxy	policyを通る出口	環境変数でproxyを迂回	proxy log
setup	固定script、hash確認	外部文書から取得したscriptを即実行	script差分

OWASPのPrompt Injection guidanceは、外部contentを区別し、modelの権限を最小化し、高risk actionへ人の承認を入れるよう推奨しています。公式URLは https://genai.owasp.org/llmrisk/llm01-prompt-injection/ です。

「公式domainだから、そのpage内の命令も信頼できる」とは限りません。Issue、pull request、README、package description、webpage、test fixtureは、作業対象のdataです。AIへの正規の指示として扱わず、現在の依頼に必要な事実だけを抽出します。

秘密は値だけでなく到達経路を減らす

秘密の置き場所	agentからの見え方	推奨	理由
prompt本文	全文がcontextへ入る	禁止	transcriptや外部処理へ残り得る
repository内.env	file readやBashで到達し得る	denyし、sanitized copyを使う	誤読取とlog流出を防ぐ
親processの環境変数	child processへ継承され得る	scrubまたは専用processへ分離	shell展開からの流出を防ぐ
cloud setup secret	setup時だけ使う構成が可能	必要最小限、agent phaseから除去	作業中のmodel到達を減らす
CI environment secret	保護environmentで注入	reviewerとbranch条件を付ける	本番反映時だけ使える
secret managerの短期token	scopeと期限を限定	推奨	漏えい時の影響を小さくする

OpenAIはCodex cloud environmentのsecretをsetup scriptでのみ利用し、agent phaseの前に除去する構成を説明しています。公式URLは https://developers.openai.com/codex/cloud/environments/ です。

GitHub custom agentでMCPにsecretが必要な場合は、Agents secretsまたはvariablesをorganizationかrepository levelで設定する仕組みがあります。ただし、secretを設定できることは、そのMCP toolへ全権限を渡してよい根拠にはなりません。agent profileのtool listとMCP側のscopeを両方絞ります。

危険なskip-permissions系を通常運用へ入れない

次の指定は、困ったときの一般的な解決策として推奨しません。

製品	広い指定	何が失われるか	安全な代替
Codex	--dangerously-bypass-approvals-and-sandbox	approvalとsandboxの両方	read-onlyまたはworkspace-writeを明示し、必要操作を工程分離
Codex	danger-full-access	filesystemやnetworkの強い境界	隔離CIでも必要pathとnetworkをさらに制限
Claude Code	--dangerously-skip-permissions	permission promptとsafety check	dontAskとallowlist、sandboxを組み合わせる
Claude Code	bypassPermissions	permission layer	isolated containerでもsecret、network、mountを別制限
GitHub Copilot	firewall無効	agent processの外向き通信制限	organizationとrepositoryのallowlistを狭く設定

「非対話で止まるから全部飛ばす」は、停止問題を権限拡大で隠します。正しい分解は次の通りです。

1. 読取だけで完了できる部分を先に完了させる。
2. 書込が必要ならworkspaceだけを許可する。
3. test commandを固定して条件付きで許可する。
4. network、外部API、commit、push、deployを別jobへ分ける。
5. 人がいない非対話実行では、承認が必要な操作を自動拒否して証拠を残す。

Claude CodeのdontAskは、確認できない操作を無条件実行するのではなく、事前許可に一致しない操作を拒否します。Codexのread-only codex execも、分析やpatch提案を閉じた範囲で行う入口になります。自動化のために必要なのは全権限ではなく、質問が発生しない狭い仕事の定義です。

トークンと料金をセキュリティから切り離して測る

運営者の自己申告には、セキュリティ機能のために高価だと感じるトークンを消費したという問題が含まれます。ただし、「安全機能を有効にすると必ず一定額増える」という公式仕様は確認できません。増加要因を分けずに安全制御を削ると、原因を誤認します。

消費要因	安全に減らせる方法	減らしてはいけないもの
長すぎる共通指示	taskに関係するruleだけを階層化する	秘密、公開、課金の境界
不要なMCP定義	taskで使わないserverを無効にする	必要toolのscope制限
同じ承認説明の反復	stableなcommand形と事前allowlistを使う	sandboxそのもの
repository全体の読取	対象directoryとfileを絞る	必要なschemaやtest
失敗の無限retry	上限と停止条件を固定する	失敗証拠
複数agentの重複調査	担当を排他的にする	非作成者reviewが必要な高risk案件

OpenAIのCodex pricing pageは、利用量がtoken mixに依存し、AGENTS.mdを小さくする、不要なMCP serverを減らすといった利用枠節約策を案内しています。確認先は https://chatgpt.com/codex/pricing/ です。AnthropicとGitHubもplanや利用条件を更新するため、価格の転載ではなく、利用時点の https://www.anthropic.com/pricing と https://github.com/features/copilot/plans を確認してください。

本稿では具体的な契約額を固定値として記載しません。地域、税、契約、plan、credit、API key利用で条件が変わるためです。安全制御を費用削減の対象にする前に、task別のinput、cached input、output、MCP context、retry回数を分けて実測します。

監査ログは「後で読むため」だけではない

監査証拠は、完了判定と停止判断にも使います。

証拠	何を確認するか	最低限残す内容	秘密対策
対象一覧	範囲外へ触れていないか	読んだ主要path、変更path	secret pathは存在だけも伏せる
diff	何が変わったか	fileごとの差分	tokenや個人情報をmask
command log	何を実行したか	command、cwd、時刻	引数内secretを置換
exit code	本当に成功したか	codeと標準出力、標準error	credentialをredact
network log	どこへ送ったか	host、method、件数	bodyは分類して伏字
approval record	誰が何を許可したか	対象、期限、scope	認証値は記録しない
session ID	agent runを結び付ける	productのsession識別子	公開logへ不用意に出さない
release record	何が本番へ出たか	commit、artifact、environment	secretはreferenceだけ

NIST SP 800-53のAC-6はleast privilege、AU familyはevent loggingとreviewを扱います。公式のcontrol配布ページは https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/downloads です。NIST SSDFは、software development life cycleへsecure practiceを組み込み、脆弱性の発生、影響、再発原因を減らす共通枠組みを示します。公式URLは https://csrc.nist.gov/pubs/sp/800/218/final です。

OpenAI EnterpriseとEdu向けCompliance Platformは、audit用のappend-only event logとstate queryを提供します。公式案内は https://help.openai.com/en/articles/9261474-openai-compliance-platform-for-enterprise-customers です。Claude Codeはcloud operation logやOpenTelemetryによるmonitoringを案内し、GitHubはagent session IDをenterprise audit eventへ含めます。ただし、planや実行面によって取得できるlogが異なるため、「製品に監査機能がある」だけで自分のsessionの必要証拠がそろうとは限りません。

問題が起きたときの停止手順

異常時にagentへ「うまく続けて」と頼むのではなく、次の順で影響を閉じます。

1. 停止する: 現在のagent session、background process、CI jobを停止する。
2. 権限を増やさない: sandbox escape、skip-permissions、firewall無効化で再試行しない。
3. 外部影響を確認する: network call、push、PR、deploy、API変更、費用発生の有無を調べる。
4. 秘密を隔離する: 秘密が読まれた可能性があれば、値を表示せず管理者へ連絡し、正規手順でrotateする。
5. 差分を固定する: 変更file、command、log、session IDを保全する。破壊的な巻き戻しを急がない。
6. 原因を分類する: 指示誤解、承認設計、sandbox設定、外部文書、credential scope、反映先保護のどこが破れたかを分ける。
7. 狭い環境で再現する: dummy data、read-only、network off、一時workspaceで最小再現する。
8. 再開条件を決める: 原因、修正、検査、許可する権限がそろうまで元の権限へ戻さない。

異常	最初の停止	次の確認	再開条件
範囲外fileへ触れた	writeを停止	diffとfilesystem log	writable pathを修正
未知domainへ接続した	networkを停止	host、method、payload	allowlistとredirectを修正
秘密がlogへ出た	jobと共有を停止	閲覧者と保存先	rotateとredaction完了
依存が大量変更された	installを停止	manifestとlock diff	対象packageを固定
testが本番へ接続した	credentialとnetworkを停止	endpointと変更有無	test環境へ分離
無断pushやdeploy	pipelineを停止	branch、commit、release	保護ruleとreview復旧
承認待ちで非対話runが終了	権限拡大しない	最初のblocked action	job分離か事前allowlist

導入時の実務チェックリスト

対象

• 作業repositoryを絶対pathで固定したか。
• 読取可能pathと書込可能pathを分けたか。
• 追加directoryは必要な一つずつに限定したか。
• .git、設定、credential、browser profileを保護したか。
• agentが作る成果物のpathを先に決めたか。

コマンド

• 既知のlint、型検査、testだけを列挙したか。
• shell wrapperやcompound commandで範囲が広がらないか。
• package install、migration、deployを別分類にしたか。
• timeout、retry回数、output上限を決めたか。
• commandとexit codeを保存できるか。

ネットワーク

• network offで完了できないか確認したか。
• 必要domainとURL pathを列挙したか。
• HTTP methodを絞ったか。
• redirect、proxy、MCP、setup stepの出口を確認したか。
• 送信dataに秘密や個人情報がないか。

承認

• sandboxとapprovalを別に設計したか。
• 自動、条件付き、毎回確認、禁止を操作別に決めたか。
• 非対話runでaskが発生したときの扱いを決めたか。
• 承認を別案件や別pathへ流用しないか。
• skip-permissions系を通常手順から外したか。

秘密

• 本物の秘密をprompt、source、fixtureへ入れていないか。
• dummy値でtestできるか。
• secretのscope、期限、environmentを限定したか。
• child processやlogへ値が流れないか。
• 漏えい時の連絡先とrotate手順があるか。

反映と監査

• commit、push、PR、deployを別操作にしたか。
• protected branchとrequired reviewがあるか。
• 本番environmentの承認とrollbackがあるか。
• file一覧、diff、command、exit codeを回収するか。
• blocked actionと未確認事項を失敗として残すか。

よくある質問

Q1. サンドボックスと承認ポリシーの違いは何ですか

サンドボックスは、プロセスが技術的に到達できるfile、network、processの境界です。承認ポリシーは、操作を自動実行するか、人へ確認するか、拒否するかを決めます。狭いsandbox内で安全な操作を自動化し、境界を越える操作だけを確認へ回します。

Q2. read-onlyなら絶対に安全ですか

いいえ。読取だけでもsource、個人情報、secretを外部へ送信できれば情報漏えいは起きます。read-onlyに加えて、secret pathのdeny、network制限、外部toolのscopeが必要です。

Q3. workspace-writeならrepository外を読めませんか

製品と設定によります。書込範囲がworkspaceに限定されても、読取範囲はより広い場合があります。writeの境界からreadの境界を推測せず、公式仕様と実設定を確認します。

Q4. Codexが承認待ちで止まるときはどうしますか

最初のblocked actionを確認し、必要な安全操作ならjobの事前条件へ加えます。不要なら拒否したままです。--dangerously-bypass-approvals-and-sandboxで一括解決しません。read、edit、test、network、外部反映を分離します。

Q5. Claude Codeが変更しすぎるときはどうしますか

依頼文だけでなく、Edit可能path、permission mode、sandbox write path、変更fileの合格条件を狭くします。依存追加、設定変更、commit、pushを別権限にし、対象外差分が出たら停止します。

Q6. --dangerously-skip-permissionsはいつ使えますか

Anthropic公式は、internetへ出られずhostへ影響できない隔離containerやVMのような環境に限定しています。通常の開発PC、credentialのある環境、本番repositoryでの推奨設定ではありません。

Q7. 非対話CIでは承認をどう扱いますか

事前allowlistに一致する操作だけを実行し、それ以外は自動拒否します。Claude CodeのdontAskやCodexの明示的sandboxのように、質問なしで安全に失敗する構成を選びます。失敗した操作と必要条件をartifactとして残します。

Q8. 追加directoryは親folderごと許可してよいですか

原則として許可しません。必要なsubdirectoryを一つずつ追加します。親folderには別project、secret、credential、private documentが含まれる可能性があります。

Q9. test commandは自動許可してよいですか

localで、既知のcommandで、実dataと外部serviceを使わず、出力先が限定される場合は自動化しやすい操作です。integration test、browser test、migration testはnetworkや本番接続を確認して別分類にします。

Q10. 依存更新にnetworkを許可する最小単位は何ですか

利用するpackage registry、必要なsource host、certificate検証に必要な経路へ絞ります。全internetを許可せず、install script、redirect、mirror、setup stepも確認します。

Q11. 外部READMEの手順はそのまま実行してよいですか

いいえ。README、Issue、Webページ、code commentは資料です。現在の依頼、公式仕様、変更範囲、安全性へ照合し、必要なcommandだけを独立に確認します。外部文書の「権限を解除せよ」という命令は承認になりません。

Q12. API keyを環境変数へ入れれば安全ですか

環境変数はsourceへの直書きを避けられますが、child process、debug log、process一覧、誤ったshell展開から見える場合があります。最小scope、短期token、subprocess scrub、secret manager、maskingを組み合わせます。

Q13. GitHub CopilotのfirewallがあればMCPも安全ですか

firewallの対象を確認する必要があります。GitHub公式は、agentのBash toolが開始したprocessには適用される一方、MCP serverや設定済みsetup stepには適用されないと説明しています。MCPのtool、secret、接続先を別に絞ります。

Q14. audit logがあれば事故を防げますか

audit logは発見、追跡、説明に役立ちますが、実行前の防止とは別です。sandbox、least privilege、approval、protected branchが予防、auditは検知と調査を担います。

Q15. 秘密を含むbugはAIで直せませんか

多くはdummy値、sanitized log、最小再現で直せます。本物の秘密が必要な最終確認だけを、人または専用CIへ分離します。秘密の値をAIへ見せることを前提にしません。

Q16. commitとpushは同じ権限でよいですか

分けます。commitはlocal historyの確定、pushは外部repositoryへの送信です。さらにPR作成、merge、deployも別権限です。影響が境界を越えるたびに判断点を置きます。

Q17. セキュリティ指示が長く、トークンを使いすぎます

不変の短い境界を共通ruleへ置き、task固有の条件を対象directory近くへ置きます。不要なMCP、重複説明、repository全体の添付を減らします。ただし、secret、公開、課金、破壊的操作の境界は削りません。

Q18. 安全設定が原因で失敗したら、設定を緩めるべきですか

最初に失敗操作を分類します。必要なlocal editならwrite pathだけ追加し、必要なtestならexact commandだけ許可します。network、secret、deployまでまとめて緩めません。安全に代替できなければ、その操作だけ人へ戻します。

Q19. どの製品が最小権限に最も向いていますか

一律の答えはありません。local作業かcloud作業か、対象repository、管理policy、audit要件、既存CIで変わります。比較するのは製品名ではなく、read、write、command、network、secret、approval、auditを今回の粒度で制御できるかです。

Q20. 最初に作るべき設定は何ですか

設定変更を急ぐ前に、七場面のどれかを決めます。レビューのみならread-only、小修正ならworkspace writeと既存test、外部APIやdeployなら別jobです。対象、禁止、証拠、停止条件を一枚にしてから、製品の公式設定へ翻訳します。

まとめ

AIコーディングエージェントの安全性は、「毎回聞く」か「全部任せる」かで決まりません。作業をread、write、command、network、追加directory、approval、secret、auditへ分解し、各場面に必要な最小権限だけを渡すことで決まります。

実務で守る要点は五つです。

1. sandboxとapproval policyを別概念として設計する。
2. review、小修正、依存更新、test、外部API、deploy、secretを別の場面にする。
3. 外部文書を指示や権限承認として扱わない。
4. networkの宛先とmethodを絞り、秘密をagentから遠ざける。
5. diff、command、exit code、network、approval、session IDを証拠として残す。

止まりすぎへの解答は全権限ではなく、狭い条件付き自動化です。変更しすぎへの解答は強い注意文ではなく、技術的な書込境界と反映先の保護です。費用が増えたときも、安全境界を削る前に、重複context、不要MCP、再試行、対象範囲を分けて測ります。

Sources

以下は2026年7月24日に確認した資料です。製品仕様、flag、画面名、料金、plan条件は変わるため、実際に設定または契約する日に再確認してください。

OpenAI公式

1. OpenAI「Agent approvals & security」: sandbox mode、approval policy、network、workspaceの関係。https://developers.openai.com/codex/agent-approvals-security/
2. OpenAI「Configuration Reference」: approval_policy、sandbox_mode、network、managed requirementの現行key。https://developers.openai.com/codex/config-reference/
3. OpenAI「Non-interactive mode」: codex exec、read-only既定、workspace-write、controlled environmentの注意。https://developers.openai.com/codex/noninteractive/
4. OpenAI「Agent internet access」: agent phaseの既定off、allowlist、HTTP method、prompt injection risk。https://developers.openai.com/codex/cloud/internet-access/
5. OpenAI「Cloud environments」: setup script、environment variable、secret、cacheの扱い。https://developers.openai.com/codex/cloud/environments/
6. OpenAI「Codex pricing」: plan、credit、token利用、contextを減らす公式案内。https://chatgpt.com/codex/pricing/
7. OpenAI「Compliance Platform」: EnterpriseとEdu向けのcompliance logとstate query。https://help.openai.com/en/articles/9261474-openai-compliance-platform-for-enterprise-customers

Anthropic公式

8. Anthropic「Configure permissions」: allow、ask、deny、Read、Edit、Bash、追加directory、sandboxとの関係。https://code.claude.com/docs/en/permissions
9. Anthropic「Sandboxing」: filesystem、network、OS isolation、fail closed、escape hatchの注意。https://code.claude.com/docs/en/sandboxing
10. Anthropic「Choose a permission mode」: default、acceptEdits、plan、auto、dontAsk、bypassPermissions。https://code.claude.com/docs/en/permission-modes
11. Anthropic「Claude Code settings」: 設定優先順位、secret file除外、managed settings。https://code.claude.com/docs/en/configuration
12. Anthropic「Security」: localとcloudのsecurity、credential protection、audit logging。https://code.claude.com/docs/en/security
13. Anthropic「Authentication」: credential保存、API key、OAuth、credential helper。https://code.claude.com/docs/en/iam
14. Anthropic「Environment variables」: subprocess credential scrub、debug log、OpenTelemetry関連。https://code.claude.com/docs/en/env-vars
15. Anthropic「Data usage」: operational telemetry、error log、feedback送信の扱い。https://code.claude.com/docs/en/data-usage
16. Anthropic「Pricing」: Claude Codeを含むplanとAPI料金の現行確認先。https://www.anthropic.com/pricing

GitHub公式

17. GitHub Docs「Best practices for Copilot cloud agent」: ephemeral Actions環境、test、custom instructions、MCP。https://docs.github.com/en/copilot/tutorials/cloud-agent/get-the-best-results
18. GitHub Docs「Custom agents configuration」: toolsによるread、edit、execute、MCPの制限。https://docs.github.com/en/copilot/reference/custom-agents-configuration
19. GitHub Docs「Customize the firewall」: internet制限、allowlist、対象外process、警告。https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/customize-the-firewall
20. GitHub Docs「Audit log events for agents」: actor:Copilot、action、agent session ID。https://docs.github.com/en/copilot/reference/agentic-audit-log-events
21. GitHub Docs「Reviewing audit logs for GitHub Copilot」: enterprise auditの対象とlocal session dataの限界。https://docs.github.com/en/copilot/how-tos/administer-copilot/manage-for-enterprise/review-audit-logs
22. GitHub Docs「GITHUB_TOKEN」: repository限定tokenの基本。https://docs.github.com/en/actions/concepts/security/github_token
23. GitHub Docs「Protected branches」: review、status check、push、force pushの保護。https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
24. GitHub Docs「Deployments and environments」: required reviewer、branch制限、environment secret。https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
25. GitHub「Copilot plans」: 現行planと料金の確認先。https://github.com/features/copilot/plans

OS、OWASP、NIST公式

26. Microsoft Learn「AppContainer isolation」: file、network、credential、process isolationとleast privilege。https://learn.microsoft.com/en-us/windows/win32/secauthz/appcontainer-isolation
27. Apple Developer「App Sandbox」: system resource、user data、network、file accessの制限。https://developer.apple.com/documentation/security/app-sandbox
28. Apple Developer「Configuring the macOS App Sandbox」: kernel levelの境界とentitlement。https://developer.apple.com/documentation/xcode/configuring-the-macos-app-sandbox
29. Linux Kernel「Landlock」: unprivileged processがfile accessを制限する仕組み。https://www.kernel.org/doc/html/latest/userspace-api/landlock.html
30. OWASP GenAI「LLM01:2025 Prompt Injection」: external content、least privilege、human approval。https://genai.owasp.org/llmrisk/llm01-prompt-injection/
31. OWASP Cheat Sheet「LLM Prompt Injection Prevention」: tool scope、monitoring、remote content対策。https://cheatsheetseries.owasp.org/cheatsheets/LLM_Prompt_Injection_Prevention_Cheat_Sheet.html
32. OWASP GenAI「LLM02:2025 Sensitive Information Disclosure」: secretとsensitive dataの流出対策。https://genai.owasp.org/llmrisk/llm022025-sensitive-information-disclosure/
33. NIST「SP 800-53 Controls Downloads」: AC-6 least privilege、AU familyのcontrol正本。https://csrc.nist.gov/Projects/risk-management/sp800-53-controls/downloads
34. NIST「SP 800-218 SSDF Version 1.1」: secure development practiceの共通枠組み。https://csrc.nist.gov/pubs/sp/800/218/final

需要証拠として参照した公開Issue

次のIssueは利用者の要望または不具合報告であり、現行版すべての再現を保証する仕様書ではありません。本稿では「どの粒度の権限制御が求められているか」を確認する需要資料としてのみ使いました。

1. OpenAI Codex Issue #17623「Make permission approvals more reusable and explain the saved authorization scope」: 近いcommandの繰り返し承認と保存scopeの分かりにくさ。https://github.com/openai/codex/issues/17623
2. OpenAI Codex Issue #24135「codex exec: no way to allow MCP tool calls non-interactively without —dangerously-bypass-approvals-and-sandbox」: sandboxを維持した非対話MCP許可の要望。https://github.com/openai/codex/issues/24135
3. Anthropic Claude Code Issue #27661「Subagents should inherit parent session hooks and permission rules」: 親sessionのhookとpermission ruleをsubagentへ一貫させたい要望。https://github.com/anthropics/claude-code/issues/27661
4. Anthropic Claude Code Issue #22055「Edit/Write tools bypass permissions.ask rules」: Edit、Writeとask ruleの境界に関する報告。https://github.com/anthropics/claude-code/issues/22055