エージェントに全権を渡す条件｜Docker Sandboxes

検証日: 2026年8月27日／claude --help・codex --help 実測

--dangerously-skip-permissions と --yolo は「使うな」と言われ続けてきました。ですが公式ドキュメントを読むと、どちらも使うなとは書いていません。使ってよい前提条件が書いてあります。

Claude Codeのドキュメントには、完全無人実行の項があります。そこで claude -p "<prompt>" --dangerously-skip-permissions に付いている条件が「コンテナ、VM、またはsandbox runtimeが必須」「LinuxとmacOSでは非rootユーザーで実行」です。Codexの --yolo にも --help に「外部でサンドボックス化された環境で動かす場合に限る」と書かれています。

つまり問題はフラグそのものではなく、条件を満たさないまま使っていたことでした。この記事では、その条件が何を要求しているのかを構造から説明し、Docker Sandboxesを使ったときに何が閉じて何が残るのかを線引きします。Sandboxes自体の使い方は別記事で扱っているので、ここでは踏み込みません。

2つの危険フラグは、外しているものが違う

まず前提として、エージェントCLIの安全統制は原理の異なる2層に分かれます。

決定的な差は強制主体です。承認軸はコマンド文字列とモデルの判断で決まるため、コマンドが名前から想像される以上のことをしても見抜けません。隔離軸についてClaude Codeの公式ドキュメントはこう書いています。サンドボックス境界は実行中のプロセスに対してOSが強制する。だから、モデルが何を実行することを選んだかに境界は左右されない。許可されたコマンドがその名前以上のことをした場合も同じである、と（Configure the sandboxed Bash tool）。

この2軸で見ると、2つのフラグは別物です。

Claude Code：承認軸だけが外れ、隔離軸は手つかずで残る

--dangerously-skip-permissions は --permission-mode bypassPermissions と等価です。公式ドキュメントは3者の関係を整理しています。/sandbox（Bashサンドボックス）が制御するのは、コマンドが実行されたあと何にアクセスできるか。auto modeと --dangerously-skip-permissions が制御するのは、各ツール呼び出しが実行されるかどうか。そして承認プロンプトの代わりに何が置かれるかという欄には、auto modeが「アクションを審査する分類器」、--dangerously-skip-permissions が「なし」と書かれています。

裏を返すと、Claude Codeの隔離軸は --dangerously-skip-permissions を付けても消えません。 /sandbox を有効にしていればOS境界はそのまま残ります。microVMの中でさらにOSサンドボックスを重ねられる、というのはClaude Code側だけの選択肢です。

ただしBashサンドボックスの適用対象はBashコマンドとその子プロセスのみで、Read・Edit・WebFetch・MCPツールには及びません。ファイル編集やMCP経由の操作は素通りします。だからこれ単体では全自動運転の土台にならず、外側にmicroVMが要ります。

もうひとつ、このモードでも残るものがあります。denyルールは bypassPermissions を含む全モードで効き続けます（逆にallowルールは意味を持ちません）。隔離の中では全部許すが、これだけは絶対にやらせない。その一線をルールで引けるということです。加えて、LinuxとmacOSではroot／sudoでの起動を拒否します。

Codex：承認軸と隔離軸が同時に外れる

--yolo は --dangerously-bypass-approvals-and-sandbox の別名で、名前のとおり両方を外します。--sandbox danger-full-access 相当の状態になり、Codex側に残る境界はありません。日本語圏ではClaude Codeの --dangerously-skip-permissions も「YOLOモード」と呼ばれることが多いのですが、以上のとおり影響範囲は構造的に違います。

そしてこの差は、外側にハイパーバイザ境界がある環境では小さくなります。--yolo が外すのはCodex自身が張るOSサンドボックスであって、その外側のmicroVM境界には手が届かないからです。危険フラグを常用できるかどうかは、外側の境界のほうで決まります。

承認軸を外すと、注入と実行の間に何も残らない

プロンプトインジェクションは入力側の攻撃です。ツールの出力、issueの本文、依存パッケージ、AGENTS.md のような設定ファイルに、エージェント宛の命令を仕込みます。対してパーミッションは出力側の統制で、エージェントが取ろうとした行動を止めます。

承認軸を外すということは、注入から実行までの間にある唯一のゲートを取り払うということです。ここに残せる統制は隔離軸しかありません。ベンダーが「危険フラグを使うなら隔離が必須」と条件をつけているのは、この構造から出ています。

実際の事例も、片側だけでは閉じないことを示しています。2025年8月のNx悪性パッケージの事案では、--dangerously-skip-permissions や --yolo といった安全装置を無効化するフラグが攻撃に利用されたと報告されました。2026年1月には claude-code-action の権限バイパス（CVSS 4.0で7.8）がRyotaK氏／GMO Flatt Securityから公表されています。翌2月には、Clineのリポジトリでissue triageワークフローの脆弱性連鎖がAdnan Khan氏から報告されました。Codex CLIについても、AGENTS.md へのインジェクションによる資格情報の窃取がBackslash Securityから出ています。

構造的に効いているのは、従来なら信頼されたリポジトリへの書き込み権限が必要だった攻撃が、issueやPRを作成できるだけで成立するようになったことです。GitHubの無料アカウントがあれば誰でも入口に立てます。

auto modeは隔離軸の代わりにならない

「承認をモデルに任せればいいのでは」という反論があります。Claude Codeのauto modeは、実行前に別モデルの分類器が審査する仕組みで、しかも分類器はユーザーのメッセージと実行ペイロードだけを見てツール結果を見ません。もっともらしい理屈で説得されて承認してしまう経路を、構造的に断つ設計です。

それでも数字は正直です。Anthropicの技術ブログによれば、実トラフィック1万件に対する偽陽性率は全体0.4%まで下がります。一方、実際に「やりすぎ」だった事例のデータセットでの偽陰性率は17%でした。危険なのに通してしまう率です。Anthropic自身が、高リスクなインフラにおける人間のレビューの代替ではないと明記しています。

承認軸をモデルで補強しても、17%は抜けます。全自動で回したいなら、抜けた先で何も起きない状態を作るほうが確実です。

被害は「出口」でしか起きない

ここが発想の切り替えどころです。注入が成立すること自体は被害ではありません。 注入されたエージェントが何かを外に対して実行できて、はじめて被害になります。

出口は3つしかありません。

1. ホストのファイルシステム — ファイルの破壊、~/.ssh や ~/.aws からの資格情報の窃取、ホストのDocker daemonの掌握
2. 手元の資格情報 — APIキー、トークンの読み出しと持ち出し
3. 外向きのネットワーク — 盗んだものを攻撃者へ送る経路

逆に言えば、この3つを塞げば、注入が成立しても攻撃者の手元には何も届きません。承認軸を外すという判断は、この3つを塞いだ上でなら成立します。

Sandboxesは3つの出口を塞ぐ

Docker Sandboxesの既定セキュリティ姿勢は、この3つに正面から対応しています。

ホストのファイルシステムから見ます。明示的にマウントしたワークスペースと共有skillsストア以外のホストファイルシステム、およびホストのDocker daemonが遮断されます。~/.aws・~/.ssh・~/.config/gcloud はそもそもVM内に存在しません。外部を指すsymlinkも辿れません。dev containerで定番だった /var/run/docker.sock のマウントも、VM内に専用daemonがあるため不要です。

資格情報はどうか。公式の記述は明快で、sbx secret または環境変数で明示的に渡さない限り、サンドボックスに資格情報は一切存在しません。そのうえで sbx secret 経由で渡した場合は、実値がVM内に入りません。VM内の環境変数に入るのはsentinel（置き換え用のプレースホルダ）で、ホスト側のproxyがoutboundリクエストのヘッダへ実値を注入します。エージェントは生の資格情報の値を読めません。

ここは渡し方で結果が変わる点に注意してください。環境変数に実値を直接入れて渡せば、それはVM内に平文で存在します。持ち出しが閉じるのは sbx secret を使った場合の話です。

三つ目の外向き通信が、いちばん効きます。outbound TCPは、HTTP・HTTPS・SSHを含めて、明示的なルールが許可しない限りすべてブロックされます。外向きのUDPとICMPはネットワーク層でブロックされ、DNSクエリもサンドボックス内部のリゾルバ経由でポリシーが適用されます。通信がサンドボックスから出る唯一の経路はホスト側のproxyで、proxyがリクエストごとにルールを適用します。

ただし出荷時のpresetは balanced で、一般的な開発サイトが最初から許可されています。deny-by-defaultは設計の話であって、何もしなければ穴が開いた状態から始まります。全自動で回すなら locked-down から始めて、必要なホストだけを足すことになります。

ここまで揃うと、ベンダーが要求する条件と実際の構成が一対一で対応します。

被害面で見ると、こう変わります。

上4行が閉じるからこそ、承認軸を捨てるという取引が成立します。

ワークスペースだけは隔離の外に残る

3つの出口を塞いでも、ワークスペースは別です。ここがこの構成でいちばん危ない場所なので、独立して扱います。

共有マウント（既定）とclone modeの違い

Sandboxesのワークスペースには2つのモードがあります。既定は共有マウント（direct mount）で、エージェントはホストの作業ツリーに読み書きし、変更は即座にホストへ反映されます。--clone を付けるとclone modeになり、エージェントはサンドボックス内に作られた別のGitリポジトリを編集します。このときホストのリポジトリは /run/sandbox/source に読み取り専用で見えます。

clone modeには制約もあります。作成時に決まり後から変更できません。cloneは現在チェックアウトされているrefを反映し、ブランチの自動作成は行われません。メインでないworktreeからは作成できません。そして sbx rm するとサンドボックス内のcloneは完全に消えるため、残したいコミットは削除前にpushかfetchが必要です。

共有マウントで成立する攻撃は2種類ある

公式ドキュメントは、エージェントがワークスペースディレクトリ内の任意のファイルを読み・書き・削除できると明記しています。隠しファイル、設定ファイル、ビルドスクリプト、Git hooksを含む、と。共有マウントではこれがあなたの実リポジトリそのものです。ここから2つの経路が開きます。

経路A：ホスト側で後から実行される仕掛けを置かれる。

.git/hooks/ に置かれたスクリプトは、あなたが次にホストで git commit や git merge を実行したときに動きます。動く場所はホストのユーザー権限、microVMの外側です。エージェントはVMの中に閉じ込められていますが、置いていったスクリプトは閉じ込められていません。境界を破って出るのではなく、境界の外側で実行されるものを仕込んで待つわけです。

同じことが .git/config でも起きます。Gitはaliasの ! 記法でシェルコマンドを実行しますし、core.pager や core.hooksPath のような設定値も外部コマンドを指します。.git/config は作業ツリーの中にあるので、共有マウントでは書き換え対象です。ほとんどすべてのgit操作が設定を読むため、hooksより発火しやすい経路です。

Gitの外にも同種のものが並んでいます。package.json の postinstall / prepare、Makefile、direnvの .envrc（ディレクトリに入っただけで走ります）、エディタのタスク定義。いずれも「あとで人間がホストで叩くもの」であり、書き換えられた時点でホスト実行が予約されます。

経路B：コミットの内容そのものが汚染される。

共有マウントでは、注入されたエージェントが書いた変更があなたの作業ツリーに直接載ります。あなたはそれを自分の変更として git commit し、git push します。攻撃者はpush権限を必要としません。あなたの手でリモートへ運ばれるからです。 そこから先はCIが実行し、他のメンバーが取り込みます。前述のClineの事例やNxの事例が示したのは、この供給経路の短さでした。

clone modeが閉じるもの、閉じないもの

clone modeにするとホストの作業ツリーが読み取り専用になるため、経路Aは閉じます。 hooksも .git/config もビルドスクリプトも、書き換えられるのはVM内のcloneだけです。VM内で発火してもVM内で完結し、sbx rm で消えます。

閉じないのは経路Bのほうです。clone modeはコミットの内容を検査してくれるわけではありません。VM内からpushすればリモートへ届きますし、sbx cp で持ち出したファイルにも同じことが言えます。clone modeがやってくれるのは、チェックポイントを移すことです。ホストで無自覚に実行される状態から、pushかコピーという明示的な操作へ。そこに人間のdiff確認を挟むかどうかは、運用側の責任として残ります。

なお、clone modeでもホストのリポジトリは /run/sandbox/source から読めます。書き込みはできませんが、リポジトリにコミットされている資格情報や設定は読み取れます。読まれて困るものはリポジトリに入れない、という原則はここでも効きます。

全自動で回すなら、--clone は前提だと考えてください。

残る穴は、許可したホストとVMの中

許可したホストが最後の攻撃面になります。モデルAPIは許可せざるを得ませんが、宛先はベンダーであって攻撃者ではないので、実務上の持ち出しチャネルにはなりにくいと考えられます。問題はgithub.comです。ここを許可し書き込み権限のあるトークンを注入していると、注入されたエージェントが書いた悪意あるcommitは、proxyが本物のトークンを載せてpushします。隔離では止まりません。pushを人間の手に残すか、トークンのスコープを絞るかの判断が要ります。allowlistは「開ける穴を最小にする」設計そのものです。

VMの中も守られません。公式が保護対象外として挙げているのは3つです。サンドボックス内の悪意あるコードそのもの（エージェントはVM内で完全な sudo 権限とVMの制御権を持ちます）。インストールしたパッケージや設定が、再起動をまたいで残ること。そしてサンドボックス間の直接ネットワーク通信。VMは壊れてよい前提で使い、壊れたら捨てる運用にしてください。

まとめ

危険フラグを常用するというのは、承認軸を捨てて隔離軸に全部賭ける取引です。ベンダーはその取引を禁じておらず、成立条件を書いています。

条件は、ホスト・資格情報・外向き通信という3つの出口を塞ぐこと。Docker Sandboxesはこの3つに正面から対応しているので、locked-down まで絞れば --dangerously-skip-permissions も --yolo も、その中でなら全自動運転の道具として使えます。承認プロンプトに疲れてホスト上で危険フラグを常用するより、隔離の中で堂々と使うほうが筋が通っています。

残るのはワークスペースです。既定の共有マウントでは、注入されたエージェントがGit hooksや .git/config を書き換え、あなたが次にホストでgitを叩いた瞬間に境界の外で実行させられます。同時に、汚染されたコードがあなた自身のコミットとしてリモートへ運ばれます。--clone は前者を閉じますが、後者は閉じません。hooksは隔離で止まり、コミットの中身は人間のdiff確認でしか止まりません。

やることは2つです。起動コマンドに --clone が入っているかを確認すること。そして、エージェントが書いた差分をマージする前に必ず自分の目で読むこと。前者は一度設定すれば終わりますが、後者は毎回発生します。全自動運転で自動化できないのは、結局この一手です。