信頼できない自律ワークロード:AIコーディングエージェントが隔離の使命をどう変えるか

今年の初め、Claude Codeを使ってブログをAstroに大量移行しました。投稿146。6、024 画像。標準的なURL、JSON-LDマークアップ、サイトマップ生成、全スタックです。私は何時間もかけてスキルファイルを書き、エージェントにブログのアーキテクチャやデプロイの仕組み、触れてはいけないことを教えました。そして、それはうまくいった。Claude Codeはコンポーネントを書き換え、数百ページにわたるトレーリングスラッシュの不一致を修正し、数百のルートにBreadcrumbListの構造化データを追加しました。Lighthouseのスコアはパフォーマンス面で 97 を得ています。ブログはこれまでで最も良く見えました。

問題は、自分のコードベースを理解しきれなくなっていたことです。

完全には。ファイルはまだ読めた。しかし「前回の修正で生じたエラーを修正する」という3回目のラウンドあたりで、スタックの痕跡をClaudeにコピー&ペーストして戻ってきて、返ってくるものを信じている自分に気づきました。担当者が変更をし、別の何かが壊れてしまい、それも直してもらい、数サイクル後にはブログがまた動作しました。PostCSSの設定に何が入っているのか、なぜGA4 統合があのような配線になっているのか、私には説明できませんでした。うまくいった。とても素晴らしかったです。その下にあるものへの自信は静かに消えてしまった。

その感覚(うまくいくのはありがたい、触れないでおこう)は、自律的なエージェントにコードベースへの本当のアクセスを与えたという感覚だ。これらのツールを使うすべての開発者はそれを知っています。ベンダーのブログ記事で書く人はいません。そして、ドキュメントを読む以上に深いレベルで、なぜDockerがサンドボックスを作らなければならなかったのかを理解させてくれました。

なぜなら、私が考えていなかったのは、Claude Codeが私のAstroコンポーネントを書き直し、数百のファイルにわたり画像CLSを修正している間、実行 npm install すべてが私のノートパソコン上で行われていたことです。変更したファイルやプルしたパッケージも同様です。ユーザー権限は、境界が見えません。もしエージェントがGitフックを修正したりCIのワークフローを書き換えたりしていたら、私は気づかなかったでしょう。その時点では個々のファイル変更を見直していませんでした。結果を見直していました。変更を省略しながら結果を見直すことはセキュリティモデルではありません。祈りだ。

Docker Sandboxはそのギャップを埋めるために存在します。

コンテナモデルと、なぜここでは適用されないのか

コンテナは決して間違った抽象概念ではなかった。それらは、その中に何が入っているかを知る世界にふさわしい理想的な抽象概念だった。12年間、その世界は続きました。コードを書き、レビューし、Dockerfileに入れ、コンテナがクリーンルームで動作させてくれました。共有カーネルは問題ありませんでした。なぜなら脅威モデルは自社ソフトウェアのバグであり、招待したテナントからの驚きではなかったからです。

AIのコーディングエージェントは合いません。それらはあなたのソフトウェアのバグではありません。なぜなら、それらはあなたのソフトウェアではないからです。彼らは新しいタイプのテナントであり、自律的で特権的な存在であり、どんなセキュリティエンジニアでも不安になるほどです。エージェントはあなたが選んでいないパッケージをインストールし、スクリプトしていないコマンドを実行します。依存関係ツリーに属しているとは知らなかったエンドポイントに対して、予想もしなかったネットワークコールを発信します。信頼プロファイルは今まさにコードであり、許可を求めるために一時停止しない何かによって書かれています。コンテナは異なる種類のコードのために作られました。

これは仮定の話ではありません。2026年3月19日、攻撃者たちはaquasecurity/trivy-actionで77バージョンタグの76を強制的に押し出し、悪意のあるTrivy v0を公開しました。69。4バイナリからGitHubリリースへの変換。露光時間は約 12 時間でした。侵害されたコードはCIランナーのメモリをスクレイピングし、秘密情報、クラウド認証情報、SSHキー、Kubernetesトークンを取得し、誤字検出ドメインに流出させました。そのウィンドウ中にバージョンタグごとにトリビアクションを参照するすべてのパイプラインは、受信側の誰もレビューしていないコードを実行していました。

Trivyで気になるのは、武器化されたツールが脆弱性スキャナーだったことです。組織が悪意のあるコードを見つけるために展開したものが、悪意のあるコードそのものになりました。管理者は悪いバイナリを書いたわけではありません。アクセスが多すぎて封じ込めが不足した侵害されたCIワークフローがそれを成し遂げました。「侵害されたCIワークフロー」を「許容モードのAIエージェント」に置き換えれば、同じ脅威モデルがすべての開発者マシンで一日中稼働することになります。

コンテナは「このコードを信頼している、クリーンに実行したい」という正解でした。「このコードを完全には信用していないし、本当の仕事を与えたい」という答えには決して適していませんでした。それがmicroVMが埋めるギャップです。

Dockerは何を作ったのか、そしてそれぞれのパーツがなぜ存在しているのか

第一選択:コンテナはパッチを貼らないことです。私たちの業界には、馴染みのある抽象化にフラグを加えて新しい問題を扱うという長い伝統があります。特権モード、能力低下、seccompプロファイル、runcの前にgVisorを置く。それらすべてにそれぞれの役割があります。しかし、自律エージェントが独自のDockerデーモンを必要とするという具体的な問題は解決していません。Docker-in-Dockerは、隔離性(特権モード、ホストソケットマウント)を損なうか、ネストされた複雑性を生み出し、それが独自の攻撃面となります。Dockerのドキュメントはこれについて率直に述べています。コンテナはホストカーネルを共有し、「独自のDockerデーモンが必要なものを安全に分離できない」と言われています。

それを受け入れると、結局はVMにたどり着きます。重いものではなく(毎回のコーディングセッションごとにUbuntu Serverを起動するのは無理です)、microVMです。数秒で起動できるほど軽量で、エージェントのコンテナを動かすのに十分なカーネル容量があります。

Docker SandboxはFirecrackerではなくカスタムVMMを使っています。もしFirecrackerの仕様を読んでいて「 125msで起動し、オーバーヘッドは 5MB未満」と考えているなら、それはFirecrackerの数字であってDockerのものではありません。異なるmicroVMの実装は異なるコストプロファイルを持っています。プラットフォームの詳細:macOSではHypervisor.framework、WindowsではWindows Hypervisorプラットフォーム、LinuxではKVM。

キャプション:サンドボックスアーキテクチャ。各microVMは独自のカーネルとDockerエンジンを実行します。認証情報はVMの境界を越えることはありません。

各microVM内で、サンドボックスは完全なDockerエンジンを実行します。エージェントが docker buildを実行すると、そのコマンドはホストコンテナの存在を知らないプライベートデーモンに送られます。イメージを引くと、そのイメージはサンドボックスVM内に存在します。サンドボックスを削除すると、画像キャッシュ全体も一緒に消えます。複数のサンドボックスはレイヤーを共有しません。無駄遣いだ。それだけの価値はある。

初めて実行中のサンドボックスの中を見たとき、エージェントはrootとして実行され、VM内では完全なDocker Engineアクセス権を持っていました。反射的に、これは間違っているに違いないと思いました。信頼できないコードにはroot権限を与えません。しかし設計は正しく、アイソレーションモデルは境界内でエージェントの行動を制約しません。それは結果の行き先を制約します。仮想マシン内では、エージェントは好きなことができます。外で?何も。VM内でキャパビリティドロップをしてエージェントをロックしようとすると、間違った問題を解決することになります。エージェントはパッケージをインストールして docker buildを実行する必要があります。必要ないのは、それらがノートパソコンに触れることです。

キャプション:ホストより、サンドボックスはコンテナではないため、 docker ps には表示されません。 sbx ls 、そのように見えます。

ネットワーク層が面白いところで、認証情報の境界としても機能します。

送信HTTP/HTTPSトラフィックはホスト上のプロキシを経由し、VM内部からアクセス可能です host.docker.internal:3128。UDPとICMPはネットワーク層でブロックされており、ポリシーによって許可されません。非HTTP TCP(SSHなど)には明確なIP+ポートルールが必要です。DNSの解決はプロキシ経由で行われます。リクエストがプロキシを通れなければ、その要求は出ません。プロキシはTLSを終了し、ホストヘッダーを検査し、ポリシーを適用し、サンドボックスが信頼する自身の証明書局で再暗号化します。設計上、中間的な男。Dockerはドキュメントでまさにそのフレーミングを使用しています。

MITMこそが認証注入を機能させる要素です。エージェントにはAPIキーが必要です。AIプロバイダー用、レジストリ用、時にはクラウドアカウント用です。単純な答えとしては、その認証情報を環境変数として渡し、VM内に置いてどこへでも追跡することです。Dockerはホスト上の認証情報をOSのキーチェーンに保持し、プロキシがそれをアウトバウンドリクエストに透過的に注入させます。エージェントは動作するリクエストを見ていて、そもそもVMには秘密情報がなかったのです。ドキュメントはこれに注意を払っていません。認証情報の値はVM内に保存されることはありません。侵害されたサンドボックスはAPIキーを外すことはできません。なぜならAPIキーはそこに存在しなかったからです。

Dockerは何がうまくいかないか教えてくれます

サンドボックスのドキュメントにはセキュリティアーキテクチャのドキュメントでは珍しい特徴があります。システムが何から守っていないかを教えてくれるのです。これらの文書の多くは、製品を強力に見せるために書かれています。Dockerのドキュメントは限界を明らかにしています。そのうち二つは重要な。

最初の問題はネットワークポリシーに関するものだ。

最初にSBXログイン時に、3つのデフォルトポリシーのいずれかを選択します。OpenはブロックされたCIDR範囲(プライベートネットワーク、リンクローカルアドレス、クラウドメタデータエンドポイント)以外のすべてを許可します。バランス型はデフォルトでは拒否しますが、共通の開発ドメインは事前許可されています。ロックダウンは、明確に許可するまですべてを拒否します。ロックダウンは最も厳しい選択肢で、もし被害妄想なら望む「デフォルト拒否」モードです。しかし、Locked Downやキュレーションされた許可リストを使っても、プロキシはコンテンツではなくドメインでフィルタリングします。

文書の正確な文言はこうです。 github.com のような広範なドメインを許可すると、そのドメイン内のあらゆるコンテンツへのアクセスが許され、「エージェントはこれらをデータ流出のチャネルとして使うことができる」とされています。セキュリティベンダーは通常、自社製品についてこう言いません。github.com が許可リストに入っている場合(ほぼ間違いなく入っています。エージェントはリポジトリをクローンする必要があるため)、プロキシはリクエストが github.com されることを知っています。エージェントがドキュメントを読んでいるのか、リポジトリをクローンしているのか、それともあなたの内容でパブリックギストを作成しているのかは分かりません .envファイル。これら3つともドメインレベルではほぼ同じに見えます。ユーザー生成コンテンツを含むすべての許可リストエントリーも同様です:Discordのウェブフック、Notionのページ。「ドメインは許可されている」というのは「安全なコンテンツだけがそこに存在している」という意味ではありません。

キャプション:拒否ポリシーの下で、許可されていないドメインはブロックされます。許可リストされたドメインは成功しており、任意のユーザー生成コンテンツをホストするドメインも含まれます。

ドキュメントはまた、ドメインフロントングがHTTPSプロキシの本質的な制限であることを認めています。プロキシはリクエストがどのドメインに向かっているかを認識します。許可されたCDNを通じてリクエストが他の場所にルーティングされるのを必ずしも防ぐことはできません。

microVM境界が主要な隔離です。ネットワークプロキシは、特に内部ネットワークへの誤ってアクセスをブロックするのに役立つ追加制御手段です。これは密閉シールではなく、Dockerもそれをそう主張していません。「エージェントは拒否ポリシーに入っている」と「エージェントはどこにもデータを送れない」とは違います。

作業スペースは常に共有されています

ネットワークポリシーは、より小さな正直な限度額です。ワークスペース共有が大きな問題です。

microVMの境界は、意図的に横切る一つの経路、すなわちワークスペースディレクトリを除いて、どこでも強固です。

サンドボックスでエージェントを動かす目的は、エージェントが実際のコードベースで実際の作業を行うことです。Dockerはホストとサンドボックスの間で同じ絶対パスでワークスペースを共有しています。エージェントがサンドボックス内でファイルを編集すると、そのファイルはホスト上で変更されます。ホストに新しいコミットを引くと、エージェントはそれを確認します。これが設計図です。まさに開発者ツールに求めるものです。

また、エージェントが正当な書き込みアクセス権を持つ秘密のチャネルでもあります。

Dockerのセキュリティドキュメントには「同じファイル」が何を含むかが明記されており、重要なのは通常開発中に暗黙的に実行されるファイルです。ギットフック。CI構成。IDEタスクの定義。メイクファイルのターゲット。package.json 台本。事前コミット設定。「道具を使っている」ような感じの動きをしているときに動くものなら何でもいいです。

攻撃の最も単純なバージョンは、サンドボックス内のエージェントが.git/hooks/post-commitに悪意のあるpost-commitフックを書き込むことです。git diffにはギットフックは登場しません。彼らは .git/に住んでいます。ほとんどの開発者は開かない。次にホストでコミットするときは、フックはユーザー権限でホスト上で実行されます。サンドボックスの境界は重要ではありません。なぜなら境界はワークスペースで終わっており、ワークスペースは常に共有されていたからです。

それが私自身のアストロ移行を思い出させましたが、居心地の悪さを感じました。私はClaude Codeでブログの何百ものファイルを書き換えてもらうでしょう。結果(Lighthouseスコア、外観、ビルド成功度)は確認しましたが、触れたすべてのファイルを監査したわけではありません。.git/hooks/を確認していなかった。私はそのディレクトリを一度も開いたことがなかった。npm installを出す前にすべてのpackage.json脚本を読んだわけではありません。ドキュメントで警告されている通り、エージェントの出力をレビュー済みコードとして扱っていましたが、実際には自分のマシン上で実行しようとしている未検証コードでした。

これを「サンドボックスは壊れている」と読み取るのは簡単です。そういう意味じゃない。microVMはまさにmicroVMが本来やるべきことを行います。つまり、ハードウェアの境界の向こう側で任意のコード実行の結果を含みます。エージェントができないのは、ワークスペースの内容を安全にすることです。なぜなら、ワークスペースの内容こそがエージェントの仕事のやり方だからです。エージェントはファイルを書ける必要があります。読めることが大事です。共有地域が必要であり、共有地域こそが脅威モデルの興味深い部分です。

緩和策はさらなる隔離ではありません。microVMはちゃんと役割を果たしています。緩和とは規律です:ワークスペースの内容を、まだ知らない貢献者からのプルリクエストを扱うように扱うのです。違い .git/hooks/エージェント・セッションズの後だ。npm installする前にpackage.json脚本を読んでください。--branchフラグを使うと、エージェントが独立したブランチで動作し、マージ前にレビューできるGitワークツリーが作成されます。これらは何も珍しいものではありません。これは単に自律エージェントの出力を信頼できるコードとして扱わない慣習です。なぜなら、そうではないからです。

ここだけのスペースを使っているのは、多くの人が間違える部分だからです。ハイパーバイザーの境界線は安心感を与えますが、実際はそうではありません。完全には。製品が動作するためには両方の要素が同時に成立していなければならず、Dockerチームは意図的にそう設計しました。優れたセキュリティアーキテクチャはそのギャップを記録し、ユーザーが何にサインアップしているのかを確実に理解させます。

実際の費用はどうか

ハイパーバイザーの隔離は無料ではなく、そうでないふりもできません。私はこれを、冒頭で挙げたAstroブログの自分の本番コードベースでテストしました。サンドボックス化されたエージェントワークロードの合成ベンチマークではあまり多くを語れないからです。本当の仕事をする感覚を知りたいのです。

キャプション:同じ docker build --no-cache 、同じAstroコードベース。司会者: 1:44。62。サンドボックスmicroVM: 1:28。58。アイソレーション境界はワークロードには見えません。このランでは、サンドボックスの方が早く終わった。

同じDockerfileとコードベースで、ホスト側とサンドボックス内で1回ずつ docker build --no-cache 実行しました。ホストは4 1でゴールしました:44。62。サンドボックスは 1年に終了しました:28。58、実際には、ランのノイズの中でも速くなっています。サンドボックス内のDocker Engineは、ホストから完全に隔離された独自のカーネルとブロックデバイス上で動作しており、ビルドは気にしません。microVMは実際のビルドにほぼオーバーヘッドを加えません。

Apple Siliconでこれを実行している現実的な注意点として、私のAstroパイプラインのjemallocは 4Kページサイズを前提に出荷されており、サンドボックス型のVM(16Kページ)では失敗します。組み立て自体は正しく完了しました。すべてのページ 354 レンダリングされ、ディスト生成されましたが、分解ステップはゼロでない段階から出てしまいました。修正は、Dockerファイル内に有効なビルド出力を確認する一行のガードを導入することでした。追跡するのに 30 分かかった。Apple Siliconでサンドボックス対応のDockerファイルを出荷する前に知っておく価値があります。なぜなら、実際には成功しているのに、症状はビルド失敗のように見えるからです。

結論:セッションベースのエージェント作業(プロジェクトに数時間かかる)では、オーバーヘッドは消えます。高頻度のサンドボックス作成(短時間タスクで毎分数十回)では、コールドスタートコストが積み重なります。Sandboxが設計されている作業負荷、つまりエージェントに実際のセッションのための環境を提供するという点では、この取引は妥当です。

孤立と信頼のマッチング

コンテナとVMの議論ではバイナリとして扱われますが、それは間違った枠組みです。私が役立つ枠組みは、自分自身の仕事でも、エンジニアリングリーダーたちと「本当にmicroVMが必要なのか?」と問いかける会話でも、スペクトラムです。

キャプション:信頼スペクトラム。隔離の強さをワークロードの信頼プロファイルにマッチさせます。

一方には自分で書いたコードがあります。チームがレビューし、CIがテストし、本番が実行します。標準的な容器が正解です。カーネルは共有され、デーモンも共有されますが、それらは重要ではありません。なぜならワークロードは既知だからです。

さらに一歩先に、チームのコードを動かすCI/CDパイプラインや、主に信頼するレジストリからの依存関係があります。ほとんどは知られているが、入力はより多様だ。セキュリティコンププロファイルを追加したり、機能をドロップしたり、ネットワークポリシーを作成したりします。

さらに進むと、監督付きAIエージェント:開発者が各ステップをレビューしながらコードを提案するツールです。人間がループに関わるので、厳格なポリシーを持つハードコンテナでも機能します。

その端には自律型AIエージェントがいます。誰も各コマンドを確認していません。あなたの代わりに意思決定を行うエージェントたちが、それぞれが前回とは異なる可能性があります。信頼プロファイルは「このコードを信頼している」というものではありません。なぜなら、信頼すべき固定されたコードは存在しないからです。「監視なしでシステム上で何かを動かしているので、故障モードは『ノートパソコン上』ではなく『使い捨ての仮想マシンに限定』したい」というものです。そのワークロードはmicroVMが必要です。

これはコンテナが時代遅れだと宣言するものではありません。むしろ逆です。コンテナは、そのスペクトラムの左側にあるすべての問題に対する正解であり、現在稼働しているもののほとんどがその部分です。MicroVMはスペクトルを右に広げ、コンテナが適切なツールになることは決してなかった。サンドボックスの4つの分離層(ハイパーバイザー、ネットワーク、Docker Engine、認証プロキシ)は加算的です。容器を置き換えるのではなく、追加の保護として包んでいます。すべてのサンドボックスの中には、コンテナを実行するマイクロVMがあります。コンテナはどこにも行っていません。信頼の積み重ねの中で一段階踏み込んでしまっただけです。

「AIエージェント用のマイクロVM、その他すべてはコンテナ」という表現はあまりにも粗雑です。「隔離をワークロードの信頼プロファイルに合わせる」というのが今も通用します。

なぜみんながここに集まるのか

Dockerだけがこの答えに至ったわけではなく、この融合は何かを教えてくれます。

FirecrackerはAWS LambdaとFly.ioのmicroVMプラットフォームを駆動しています。gVisorはユーザースペースカーネル内のシスコールを傍受します。Kata Containersは、コンテナ互換インターフェースの背後でVMの分離を提供します。ModalはgVisor上でサーバーレスエージェントのワークロードを実行します。E2Bは、Firecrackerベースのサンドボックスをマネージドクラウドサービスとして提供しています。ノースフランクは本番AIワークロード向けに型ベースのアイソレーションを出荷します。同じ理由で、すべて同時に養子にされた。アーキテクチャはどこでも同じように見えます。内部にコンテナ(開発者の考え方だから)、外部にVM(境界がそこにある必要があるため)です。

Docker Sandboxesはローカルファーストのバージョンです。ほとんどの代替手段はクラウドサービスで、実行ごとに料金を支払い、自分のコードが他人のマシン上で動作します。Dockerは開発者のノートパソコンに同じアーキテクチャを適用しました。CLIはネイティブで8つのエージェント(Claude Code、Codex、Copilot、Gemini CLI、Kiro、OpenCode、Docker Agent、Droid)をサポートし、カスタムツール用のシェルモードも備えています。スタンドアロンのSBX CLIはDocker Desktopを使わずに動作するため、アーキテクチャは商用製品に縛られていません。MicroVMレイヤーにはHTTP APIがあり、オープンソースコミュニティはすでにその基盤を築き始めています。

それがランタイムです。そしてDockerは、10年前にマイクロサービスの標準的な運用方法となった docker run のと同様に、自律コーディングエージェントの標準的な運用方法として位置づけています。

もう一つ。ハードンドイメージとサンドボックスは同じ問題の異なる層に対処します。例えば、サプライチェーン(バイナリの発生源)のためのハードドイメージ、ランタイム分離(バイナリが触れる範囲)のためのサンドボックスです。どちらも「信頼できるパブリッシャーのコードは安全だ」という前提が信頼できなくなったために存在しています。

振り返り、未来を見つめて

私は20年間で業界が信頼モデルを再構築するのを3回見てきました。

複数のワークロードを同じハードウェアに安全に配置する必要があったため、ベアメタルから仮想マシンへの変換です。

仮想マシンからコンテナへ。なぜなら、より速い立ち上げ、低コスト、そして開発者が実際にコードを配信する方法に合ったパッケージングモデルが必要だったからです。

しかし今は、ワークロードが変わりカーネル名前空間が不十分になったため、コンテナは別の種類の仮想マシンに移されました。コンテナが間違っていたわけではなく、新しいテナントがもっと必要としており、それがまたハイパーバイザーのように見えるからです。

これらの転換点は、振り返れば明らかで、当時は議論の的となっていました。コンテナが本当にマルチテナントワークロードに十分安全かどうかの議論を覚えています。(ほとんどはそうではなかったため、最終的に名前スペース付きのクラスタやテナントごとのVM、gVisor、そして今ではエージェント用のmicroVMを使うようになりました。)microVMの議論も同じ流れをたどると予想しています。約1年間争われ、3年以内に明らかになるのです。

私のAstro移行は、システムに本格的にアクセスできる自律的なエージェントと共に働く感覚を教えてくれました。手作業よりも生産的で、どれだけ追跡をやめていたかに気づいたときの不安も予想以上に不安でした。サンドボックスがエージェントを信用できるものにはしません。エージェントが予期せぬ行動を取ったとき、そのダメージは捨てられる箱の中に留まるだけです。ワークスペースは依然としてあなたの注意を必要とします。君の懐疑心。この組み合わせ(強制可能な強い境界線、できないところは規律あるレビュー)が自律的なコードのモデルであり、しばらくはそのまま続くでしょう。

もし許可のプロンプトや誤ったファイル変更、あるいは全体の配置に何かが安全でないと感じてためらっていたなら、その感覚は正しかったです。コンテナはこの作業量には合っていませんでした。サンドボックスが最適です。本当に興味のあるプロジェクトで試してみてください。それが唯一重要なテストです。

Docker Sandboxesを始めましょう→