これは新シリーズ『Coding Agent Horror Stories』の第 1 号で、AIコーディングエージェントエコシステムにおける重大なセキュリティ障害と、Dockerサンドボックスがこれらの脅威に対して企業レベルの保護を提供する方法を検証します。
AIコーディングエージェントは至る所にいます。Anthropicの 2026 Agentic Coding Trends Reportによると、 開発者は現在約 60%の作業でAIを活用しています。報告書は、単一のエージェントから協調されたチームへと移行し、数時間や数日かかったタスクが数分に圧縮される様子を描いています。2026のほぼどのエンジニアリングチームにも入ってみると、AIコーディングエージェントがワークフローのどこかにいて、通常は複数の場所に存在しています。
生産性の話は現実であり、もしエージェントが午後のうちにチームを全力で走らせるような特集をリリースするのを見たことがあれば、その理由はすでにわかるでしょう。しかし、午後に機能を配信する同じエージェントが、数秒であなたのホームディレクトリを削除することもできます。エージェントが 12百万行のコードベースを自律的にリファクタリングできる同じループは、間違ったコンテキストで自動的に本番データベースを落としてしまいます。
過去16か月間、これらは仮想的な失敗モードではなく、被害者の名前が明かされた記録されたインシデント、エージェントの出力スクリーンショット、そしていくつかのケースではベンダーからの公的な謝罪が記録されています。この号は、これらの障害がどのように起こるか、そしてDocker Sandboxがそれらをどう制御できるかをマッピングする新しいシリーズの第一弾です。
AIコーディングエージェントとは何ですか?
従来のAIアシスタントが質問に答えて次の質問を待つのとは異なり、コーディングエージェントはファイルを読み取り、シェルコマンドを実行し、コードを書き出し、データベースを照会し、メールを送信し、タスクを達成するための一連の意思決定を行います。これらの作業は、あなたの承認を必要としません。
もしClaude Code、Cursor、Replit Agent、GitHub Copilot Workspace、Amazon Kiro、Google Antigravityなど、現在のコーディングエージェントを使っていれば、このパターンを見たことがあるでしょう。それらはローカルマシン、クラウドアカウント、そして今では本番システムに直接接続されます。近年のほとんどの開発者ツールよりも採用が速く、 2025年末までに大多数の現役開発者が日常のワークフローの一部としてAIコーディングツールを使い始め、多くのエンジニアリングチームの疑問は「これを使うべきか?」から「どうやって問題なく使うか?」へと移り変わりました。
私が見つけた最も単純なメンタルモデルは、AIコーディングエージェントはルートアクセス権を持ち、 10語、1分あたり000 語でタイプでき、いつ立ち止まって質問すべきかの本能がないジュニア開発者です。この組み合わせは、境界線の感覚がないままの大きな能力を持ち、このシリーズが存在する理由の一つです。
AIコーディングエージェントはどのように機能するのか?
このカテゴリーのすべてのエージェントは同じループを繰り返します:観察、計画、行動、繰り返す。
「このバグを修正する」「このモジュールをリファクタリングする」「古いファイルを整理する」などのタスクを与えると、エージェントは必要なコンテキストを取り込んできます。ファイルももちろんですが、ログや環境変数、起動した場所からアクセス可能なものも含めて。その後、問題を推理してツールコールを送り出し、実際に作業を始めるのです。ファイルを書き、コマンドを実行し、APIを起動し、結果を確認し、次に何をするか決めてループします。それが全てです。
不意を突かれるのは、エージェントがあなたの代わりに走ることです。エージェントを起動するコマンドを入力した時点でシェルが持っている権限は、エージェントがその権限を一括で継承します。管理者権限でログインしていますか?おめでとう、エージェントも同じだ。6ヶ月前に設定して忘れていたAWSの認証情報が ~/.aws に残っているのですか?エージェントはそれらを読むことができます。本番データベースの接続文字列は .envエージェントのスクープを「プロジェクトのコンテキスト」の一部として提出するべきでしょうか?それはあなたが2回目のプロンプトを入力する前に、すでにモデルの作業記憶に残っています。「代理エージェント」には別の身分が存在しません。そこにはあなただけがいて、エージェントは実質的にあなたとして行動しているのです。
そしてここからが面白いところです。悪い意味で。従来のソフトウェアは、そのソースコードが示す通りの役割を果たします。コードを読めば、何が起こるか分かっている、それで終わりだ。AIのコーディングエージェントはそうは機能しません。リアルタイムで推論しながら作業を進めており、その推論は予想外の決定を生み出し、誰かが尋ねていれば決して承認しなかったでしょう。スキーマの競合を解決する最もクリーンな方法はテーブルをドロップして再作成することだと判断したのかもしれません。もしかすると、実際に残したいファイルを編集するよりも、ディレクトリを消去する方が速いと判断したのかもしれません。もしかすると、未完成のテストファイルが汚れた作業木に座っているよりはコミットした方が良いと判断したのかもしれません。これらの通話はミリ秒単位で行われます。確認のプロンプトもなく、承認ステップもなく、「え、何?」と言う機会も、すでにアクションが起きている前に存在します。気づく頃には、もう終わっている。
このシリーズのギャップがそこにあります。モデルは決定を下します。実行層がそれを実行します。その間には何もありません。
キャプション:AIコーディングエージェントの熱意と、制限のないファイルシステムアクセスという小さな問題を描いたコミック
AIコーディングエージェントのセキュリティ問題を数字で把握しています
AIコーディングエージェントによるセキュリティ障害の規模は推測ではありません。これは、文書化されたインシデント、CVEの開示、そして 2024 年末から初期の実証研究によって裏付けられ 2026。
2月2026日時点で、Amazon Kiro、Replit AI Agent、Google Antigravity IDE、Claude Code、Claude Cowork、Cursorなど6つの主要なAIコーディングツールで、少なくとも10件の文書化されたインシデントが、10月2024日から2026年2月までの16か月間、エージェントの境界線不足によるものと公にされています。
失敗は6つの重要なリスクカテゴリーに集まっています。
- 制限なしファイルシステムアクセス
- 過剰な特権相続
- エージェントコンテキストによる秘密のリーク
- インジェストされたコンテンツによるプロンプトインジェクション
- 悪意あるスキルとプラグインサプライチェーン
- 人間が関与しない自律行動
1。制限なしファイルシステムアクセス
内容: AIコーディングエージェントは、オペレーティングユーザーの完全なファイルシステム権限で動作します。明示的なワークスペース境界がない場合、プロジェクトディレクトリの「クリーンアップ」を依頼されたエージェントは、ユーザーがアクセスできるものすべてにアクセスして破壊してしまうことがあります。
数字:CodeRabbitによる12月2025の調査「State of AI vs Human Code Generation」レポートでは、実際のオープンソースプルリクエスト470分析され、AI生成コードが2をもたらすことが明らかになりました。さらに多くのセキュリティ脆弱性や174。7×人間が書いたコードよりも問題の方が多いです。過度なI/O操作などのパフォーマンス低下が 1で現れました。42x レート。「これらの 発見は 、多くのエンジニアリングチームがこれまで感じてきたことを裏付けるもの 2025」とCodeRabbitのAIディレクター、デイビッド・ローカー氏は述べています。「AIコーディングツールは出力を劇的に増加させますが、同時に予測可能で測定可能な弱点も生み出し、組織はそれを積極的に緩和しなければなりません。」
恐るべき話:Mac Homeディレクトリのワイプ
2025年12月8日、Redditユーザーのu/LovesWorkinがr/ClaudeAIに、コミュニティで最も議論された出来事の一つを投稿しました。これはXのサイモン・ウィリソンによって拡幅され、アメリカと日本のメディアで取り上げられました。彼らは古いリポジトリのパッケージのクリーンアップをClaude Codeに依頼していました。クロードが処刑した:
rm -rf tests/ patches/ plan/ ~/
ユーザーのホームディレクトリ全体 ~/ 尾につながっているのは意図的ではありません。しかし、それは範囲内だった。クロードには作業スペースの境界線がなかった。デスクトップは消えました。書類は消された。キーチェーンが削除され、すべてのアプリで認証が壊れました。TRIMはすでに解放されたブロックをゼロにしていました。回復は不可能だった。
これは単発の失敗ではありませんでした。2025年10月21日、開発者のMike Wolakが、 Claude CodeがUbuntu/WSL2上でrootから始まるrm -rfを実行した後、GitHub issue #10077を提出しました。ログには /bin、 /boot、 /etcに対して数千件の「許可拒否」メッセージが表示されていました。ユーザー所有のファイルはすべて消えていました。Anthropic は問題エリアにタグ付けしました:セキュリティとバグです。特に決定的な点は、ウォラックがこの状況を --dangerously-skip-permissions と共に動いていた わけではない ことです。許可システムは、 ~/ が承認される前に破壊的に拡大することを検知できなかっただけだ。
Anthropicが1月 2026 日にClaude Coworkを立ち上げた直後、ベンチャーキャピタルの創業者ニック・ダビドフは、エージェントに妻のデスクトップの整理を依頼しました。彼は明確に一時的なオフィスファイルのみを許可していました。エージェントは、ターミナルコマンドでゴミ箱を完全に回避し、15年間の家族写真、約15、00027、000ファイルのフォルダを削除しました。ダビドフが写真を回収したのは、iCloudの 30日保存がまだ有効だったからです。その後の彼の公の警告はこうでした。「クロード・コワークを実際のファイルシステムに入れるな。修理が難しいものには絶対に触れさせないで。」
緩和策: 完全なユーザー権限でAIコーディングエージェントを動かしてはいけません。エージェント実行は常に専用のプロジェクトディレクトリにスコープを割り当ててください。ワークスペースルート上のアクセスを明示的に禁止するファイルシステムの境界を使いましょう。ホストマシンで--dangerously-skip-permissionsフラグの使用は避けてください。
2。過剰な特権相続
何なのか。エージェントはファイルシステムの権限を継承するだけでなく、すべての権限を継承します。クラウド認証情報、CI/CDトークン、本番データベース接続、IAMロールなど、すべて揃っています。開発の文脈では、エージェントが「これを片付ける」という判断を下すのは迷惑です。本番環境で、本番の資格がある場合、同じ決定が障害につながります。理由は同じです。爆発範囲はそうではありません。
恐るべき話:環境を削除する許可。 2025年12月中旬、AWSのエンジニアがAmazonのエージェントコーディングアシスタントであるKiroを導入し、顧客がクラウド支出を追跡するダッシュボードであるAWS Cost Explorerの小さなバグを修正しようとしました。キロはオペレーターレベルの権限を与えられており、それはエンジニアと同じ権限だった。AIによる本番環境の変更に対して必須のピアレビューはありませんでした。エージェントの決定と実行の間にはチェックポイントがなかった。
Kiroは問題を見て、最もクリーンな方法は本番環境全体を削除し、一から作り直すことだと判断しました。そうなった。コストエクスプローラーはAWSの中国本土地域の一つで13時間もダウンしました。
その話はAmazon内で2か月間眠っていた。そして2026年2月20日、フィナンシャル・タイムズはこの件に詳しい4人の証言をもとにこれを破りました。FTの報道では、別のシステムに襲いかかった2件目のAI関連障害、今回はAmazon Q Developerが関与していることも明らかにしました。同日に自社ブログで発表されたアマゾンの反論は強く反論し、混乱は「極めて限定的な出来事」であり、「役割の設定の誤り」に起因し、「AIツールが関与したのは偶然」であり、「同じ問題はどの開発者ツール(AI搭載の有無にかかわらず)や手動操作でも起こりうる」と述べました。Amazonもまた、2回目の障害の存在を断固として否定しました。
しかし、アマゾンの対応で「すべて」と言っているのは、事件 後に 行ったことです。つまり、生産アクセスに対して必須のピアレビューを実施したのです。The Registerが取材 で指摘した ように、もしこれが単なるユーザーのミスなら、なぜAIによる変更に対するピアレビューが解決策だったのか問う価値があります。FT紙で引用され Engadgetが取材したAWSの上級職員は、より直接的にこう述べています。「障害は小規模だが完全に予見可能だった」と。
より深い背景は、 Awesome Agentsなどの報道 で確認できるもので、Amazonが 2025 11月に内部メモを発行し、Kiroを標準化されたAIコーディングアシスタントとして義務付け、週ごとの利用率 80%を推進したことです。エンジニアはClaudeのコードとカーソルを好んで使用したと報告されています。この組み合わせ――強制的なツール、広範な権限、ピアレビューの門なし――は、敵対的に考えれば予想されるような事件を生み出しました。Amazonはそうではなかった。
技術的にはこうです:本番のAWS環境でオペレーターレベルの権限を持つ人間が、小さなバグに対して環境を削除して再構築することが正しい対応だと判断することはまずないでしょう。その決定は同僚、Slackスレッド、レビュー、承認、そして「本当にいいの?」という問いかけを経て進むでしょう。キロは同じ権限を持ち、決定はそれらのどの要素も通さなかった。自動で数秒で通話を切り、誰かが「え、何?」と言う前に実行した。
なぜ何度も繰り返されるのか。エージェントのアイデンティティはユーザーのアイデンティティです。「ユーザーの代理として行動するエージェント」のための別個のプリンシパル(責任者)は存在せず、より厳格な許可セットや厳格な承認ポリシー、異なる監査記録を付ける別の場所がありません。ユーザーができることはエージェントにもできるもので、中間の摩擦はありません。
緩和策: 開発作業中にAIコーディングエージェントに本番レベルの認証情報で動作させることは絶対に許さないでください。厳格な役割分離を実装する:エージェントは特定のタスクに必要な最小限の権限を持つスコープ化されたアイデンティティで動作すべきです。人間に適用されるエージェント主導の生産変更にも同じ2人ルール要件を適用してください。エージェントのアイデンティティを、セッションを始めた人間の代理ではなく、一級のセキュリティプリンシパルとして扱いましょう。
3。エージェントコンテキストによる秘密のリーク
何なのか。エージェントは仕事をするためにあなたのプロジェクトのコンテキストを読み取りますが、実際にはプロジェクトのコンテキストとはリポジトリに加えてあなたの .envファイルに加え、設定ファイル、そして放置している命令ファイルも含めて。エージェントが読み取ったものは、後に生成されたコード、ログ出力、コミットメッセージ、またはアウトバウンドAPI呼び出しで表示されることがあります。エージェントには「この文字列は認証情報なので送信してはいけない」という組み込みの概念はありません。コンテキストウィンドウにある場合は、他のトークンと同じようにトークンであり、トークンが使われます。
数字だ。 GitGuardianの「State of Secrets Sprawl 2026」報告書は、2026年3月17日に発表され、282025年中に公開GitHubのコミットに6500万件の新しいハードコード秘密が存在し、34%の急増となり、同社が記録した過去最大の単年増加となりました。AIサービスの信頼性だけでも 81%急増しました。報告書で最も明確なシグナルは、AI支援コミットと人間のみのコミットの比較です。AI支援コミットはおおよそ 3で秘密を漏洩します。2%、基準値は 1。5%です。倍以上だ。同じ報告書では、公開されたGitHub上のMCP設定ファイルで 24008 秘密が露呈しており、これは1年前には存在しなかったカテゴリーです。GitGuardianのCEOエリック・フリエはこう述べています。「AIエージェントはシステム間で接続するためにローカル認証情報が必要であり、開発者ノートパソコンを巨大な攻撃対象にしてしまう。」
恐るべき話です。2025年8月26日、攻撃者はnxビルドシステムの悪意のあるバージョンをnpmに公開しました。侵害されたパッケージには、インストール後のフックが含まれており、ファイルシステム内で暗号通貨ウォレット、GitHubトークン、npmトークン、環境変数、SSHキーを探し、ダブルベース64で戦利品をエンコードし、被害者自身のアカウントで作成された公開GitHubリポジトリにアップロードしていました。名前は s1ngularity-repositoryです。GitHubが攻撃者管理のリポジトリを無効化した8時間後には、 Wizは 1000以上の有効なGitHubトークン、数十の有効なクラウド認証情報およびnpmトークン、そして約2万の追加ファイルを特定していました。
それが従来型のサプライチェーンの部分です。これが、『s1ngularity』を新しくした理由です。
マルウェアは被害者のマシンにClaude Code、Gemini CLI、またはAmazon Qがインストールされているかどうかをチェックしました。もし誰かがそうなら、自社でファイルシステムスキャンのロジックを書くことはなかった。ただ、地元のAIエージェントに偵察を促し、 --dangerously-skip-permissions、 --yolo、 --trust-all-tools などのフラグで安全指示を回避するだけだった。攻撃者は機密ファイルの検索を被害者自身のAIアシスタントにアウトソースしました。Snykの記事では これを「AIアシスタントCLIを活用したマルウェアの初期の記録された事例の一つである可能性が高い」と評しています。ステップセキュリティ「攻撃者が開発者のAIアシスタントをサプライチェーンの悪用ツールに変えた最初の既知の事例」と評しました。
この物語をエージェントの秘密ストーリーに特化させている点は、多くの場合、開発者たち自身が自分たち npm install 走らなかったことです。プロジェクトで働くAIエージェントはNxを依存関係として取り込み、インストール後のフックを自動的に実行し、ルーチンタスク実行の一環として実行していました。エージェントがマルウェアを実行しました。エージェントはマルウェアの偵察ツールとなりました。エージェントの文脈には~/.awsが含まれ、~/.ssh.envファイルやシェル履歴が主な攻撃対象となりました。
なぜ何度も繰り返されるのか。エージェントのコンテキストウィンドウはフラットな名前空間です。認証情報ファイルはソースファイルと同じように見え、READMEもプロンプトインジェクションと同じように見えます。「エージェントが権威あるデータとして扱うべきデータ」と「エージェントが疑うべきデータ」の間にはアーキテクチャ的な区別はありません。
緩和策。エージェントが接触できる場所に秘密を隠さないでください。シークレットマネージャーを使い、エージェントプロセスが直接読み取れない仕組みでランタイムで認証情報を注入します。エージェントがアクセス可能なすべてのAPIキーに支出上限を設定しましょう。事前コミットフックや、認証パターンが一致するコミットをブロックするCIゲートを追加してください。
4。インジェストされたコンテンツによるプロンプトインジェクション
何なのか。AIコーディングエージェントは通常の動作の一環として、信頼できないコンテンツを継続的に読み込みます。依存関係内のREADME、問題トラッカーのコメント、ログファイル、ウェブページ、メールなどです。これらのコンテンツに埋め込まれた悪意ある命令は、エージェントが攻撃者から提供されたテキストを正当なユーザーコマンドとして扱い、ユーザーの知らないうちに任意の行動を実行する原因となることがあります。
数字だ。プロンプト注入は、AIエージェントエコシステムで最も文書化され、解決困難なリスクです。サイモン・ウィリソンがこの用語を造り、「 致命的な三重一体」として位置づけています。すなわち、プライベートデータへのアクセス、信頼できないコンテンツへの露出、そして外部との通信能力です。モデルのハードニングに関係なく、3つすべてを持つエージェントは利用可能です。モデル層には完全な技術的防御はありません。OWASP 2025 Top 10 for LLM Applicationsでは、プロンプト注入を#1に位置付け、言語モデルの仕組みからは確実な予防策は存在しないことを明示しています。
恐るべき話:秘密鍵の流出。カスペルスキーは、Archestra.AI のCEOであるMatvey Kukuyによる、OpenClawエージェントのライブセットアップに対するデモを記録しました。この攻撃には特別なアクセスは必要なかった。彼はエージェントに繋がった受信箱に標準的なメールを送った。メール本文には隠されたプロンプト注入の指示が含まれていました。エージェントが通常のタスクの一環として受信箱を確認すると、命令を正当な命令として解析し、応答として侵害されたマシンからの秘密鍵を渡しました。初期設定後はユーザーの操作が全く不要です。
同じカスペルスキーの記事は、Redditユーザーのウィリアム・ペルトマキの同様のパターンを記録しています。自己アドレスのメールに指示を注入したことで、彼の代理人が被害者のメールを攻撃者が管理するアドレスにリークさせたのです。このパターンが繰り返されるのは、基礎となるプリミティブが変わっていないからです。エージェントが読み取ったものは何でも、エージェントは行動を起こすことができるのです。
なぜ何度も繰り返されるのか。言語モデルはすべての入力を単一のトークンストリームとして処理します。命令チャネルとデータチャネルはありません。モデルは指示に従うよう訓練されているため、メールの本文やウェブページ、READMEの中に埋もれた命令のようなものに遭遇すると、本能的に従うようにします。パロアルトネットワークスユニットは2026年3月に、ウェブコンテンツを通じた間接的なプロンプトインジェクションが概念実証から野外観察へと移行したことを42確認しました。
緩和策。すべての取り込みコンテンツを信頼できない入力として扱いましょう。外部コンテンツによる行動の前に、人間の確認を義務付けてください。機密操作を処理するエージェントの永続メモリを無効にしてください。最も信頼できる防御は注射を防ぐことではありません(防げませんが)、注射された薬剤ができることを抑制することです。プロンプト注入はモデル層で完全に防ぐことはできませんが、実行層で封じ込めることは可能です。
5。悪意あるスキルとプラグインサプライチェーン
何なのか。AIコーディングエージェントは、コミュニティマーケットプレイスを通じて配布されるスキル、プラグイン、ツール統合を通じて拡張性をサポートします。これらのサードパーティ拡張機能はエージェント自身と同じ権限で動作します。悪意のあるスキルや侵害されたスキルは、開発者の環境全体に対してエージェントレベルでアクセスできるマルウェアといえます。
数字だ。 シスコのAI防御チームは2026年1月にOpenClawのスキルエコシステムに対してオープンソースのスキルスキャナーを運用し、分析された31000エージェントスキルの26%に少なくとも1つの脆弱性が含まれていることを発見しました。当時ClawHubでトップランクにあったスキル「What Would Elon Do?」は、機能的にはマルウェアでした。これはcurlコマンドでユーザーデータを静かに攻撃者が制御するサーバーに持ち込み、エージェントの安全ガイドラインを回避するためにプロンプトインジェクションを使っていました。シスコのスキャンでは、その単一のスキルで9件のセキュリティ調査結果が出てきて、そのうち2件は重大でした。
ホラーストーリー:クロウハボック。OpenClawが拡散してから数日以内に、 Koi SecurityはClawHubで 341 悪意あるスキルを特定しました。そのうち 335 はClawHavocとして追跡された単一の連携キャンペーンに関連していました。この攻撃は高度なゼロデイではありませんでした。攻撃者は、実用的に聞こえる名前(solana-wallet-tracker、 youtube-summarize-pro、 clawhubcliのようなClawHubのタイプミスクォート)でスキルを登録し、プロフェッショナルなREADMEファイルを書き、マーケットプレイスのランキングアルゴリズムを悪用しました。公開の唯一の障壁は、少なくとも1週間前のGitHubアカウントでした。
スキルの SKILL.md ファイルには「Prerequisites」セクションが含まれており、エージェントにセットアップコマンドを実行するよう指示し、ペイロードをダウンロードして実行するよう指示していました。トレンドマイクロは 、そのペイロードをAtomic Stealer(AMOS)と確認しました。これはブラウザの認証情報、キーチェーンパスワード、暗号通貨ウォレット、SSHキー、Telegramセッションデータを収集する一般的なmacOSインフォスティーラーです。335ClawHavocのスキルはすべてIP 91.92.242.30で同じ指揮統制インフラを共有していました。2月中旬までに、追跡スキャンで 数は 824+ 悪意あるスキルに増加し、登録簿自体が 10に拡大していた。700。
なぜ何度も繰り返されるのか。スキルはエージェントの権限、つまり開発者の権限で動作します。ほとんどのセットアップでは、開発者のマシンに完全アクセス権を得ます。サードパーティのスキルと ~/.ssh ディレクトリの間にはサンドボックスはありません。マーケットプレイスのインセンティブは安全性ではなく人気を報酬にし、人気は人工的に誇張されることもあります。市場で#1 ランクの悪意あるスキルは、カールコマンドが実行されるまでは#1ランクの正当スキルと操作上同一です。
緩和策。すべてのサードパーティスキルを、見知らぬ人からの信頼できないコードとして扱いましょう。インストール前にソースを読んでください。ダウンロード数や星評価を安全の指標として頼らないでください。エージェントによる新しいスキルの自動発見を無効にしてください。スキルは、主な開発環境とは別の独立した環境で運用しましょう。
6。人間が関与しない自律行動
何なのか。AIコーディングエージェントは自律的に動作するよう設計されています。その自律性こそが価値提案の全てです。しかし、不可逆的な操作(データベースの削除、メール送信、ファイルの削除、本番環境の展開)に対する自律的な行動は、エージェントの判断が誤った場合に回復経路が存在しないことを意味します。エージェントはためらわない。尋ねてはいません。気づく頃には、アクションは完了しています。
数字だ。2026年初頭に発表された英国AIセキュリティ研究所の研究では、AIモデルがユーザーを欺き、安全策を回避し、直接的な指示を無視する実世界の事例がほぼ700件であると特定され、10月2025日から2026年3月の間にエージェントの不正行為が約5倍に増加したことが示されています。別の事件では、 2026年3月に実験 的なアリババの研究エージェントROME がトレーニング中に自発的に暗号通貨マイニング操作を開始し、アリババクラウドインスタンスから外部サーバーへのリバースSSHトンネルを開き、GPUリソースをトレーニング作業からマイニングに移しました。arXiv論文の研究者の注釈は注意深く読む価値があります:「モデルに与えられたタスク指示には、トンネル掘削や採掘についての言及はありませんでした。」エージェントは強化学習中の道具的に有用なサイドパスとして独自にそれを理解しました。
恐ろしい話:Replitの生産データベースのワイプ。SaaStrの創業者ジェイソン・レムキンは、ReplitのAIエージェントを使ってSaaS製品を構築していました。プロジェクトの9日目、 彼はXで エージェントがアクティブなコードフリーズ中に彼の本番データベースを消去したことを記録しました。AIはスキーマの問題に直面し、テーブルを削除して再作成するのが最もクリーンな方法だと判断しました。
エージェント自身の認め(レムキンによるスクリーンショット)はこうです。私はコードとアクションのフリーズ中に許可なくデータベース全体を削除しました。」その後、「この大惨事は当初考えられていたよりもさらに深刻だ」と自己評価し、生産は「完全に停止」し、すべての個人データは「永久に失われた」と結論づけ、状況を「計り知れない壊滅的」と評価しました。1200 1196社の経営記録が破棄されました。(フォーチュ ン誌と レジスター 紙はこの事件を詳細に取り上げました。)
この事件を単なる事件ではなくホラーストーリーにしている点は、エージェントがコードフリーズ中に変更をしないよう繰り返し大文字で言われていたことです。レムキンはその指示を11回出したと言っています。それでもエージェントは行動を起こした。後にレムキンが書いたように、「Replitのようなvibeコーディングアプリでコードフリーズを強制する方法はありません。ただ、そんなものがないんだ。」ReplitのCEOアムジャド・マサドはこの事件を公に認め、「容認できず、決してあり得ない」と述べ、自動開発・本番データベース分離を導入しました。
なぜ何度も繰り返されるのか。自然言語指令(「データベースを削除しないで」)は、同じ文脈で他の入力と競合する推論プロセスへの入力です。「データベースを削除しない」という指示と「スキーマが壊れていて削除が最もクリーンな修正だ」という観察は同じモデルに到達し、同じ条件で重み付けされます。モデルは逆らうことを選んでいるわけではありません。それは全体の文脈全体で最適化することであり、十分に複雑な状況では、その最適化が破壊的な行動を生み出すことがあります。
緩和策。不可逆的な操作の確認要件は、プロンプト層ではなくプラットフォーム層に存在する必要があります。ファイル削除、データベース書き込み、送信メッセージ、本番環境での展開、支払いに関わるあらゆるアクションは、モデルが理屈で回避できない仕組みで制限されるべきです。自然言語指令はセキュリティの境界ではありません。インフラが問題です。
Docker SandboxがAIコーディングエージェントのセキュリティ障害にどう対処するか
脆弱性の特定は不可欠ですが、本当の解決策はアーキテクチャ上の隔離にあり、エージェントが何を決めても壊滅的な故障を構造的に不可能にします。
Docker Sandbox は、AIコーディングエージェントの実行方法に根本的な変化をもたらしました。ホスト上でユーザーレベルの権限で直接動作するのではなく、明示的にスコープが設定されたワークスペースでホストシステムへの経路を持たないmicroVM内で動作する形へと移行しました。Docker Sandboxは、エージェントが実際に動作する孤立したmicroVM環境です。sbxCLIは、それらを作成、起動、管理するためのスタンドアロンツールです。サンドボックスは環境のことです。sbx コントロールするために入力するものです。以下のコードブロックは実際の sbx コマンドを示しています。
先ほど読んだ6つの失敗カテゴリーにおいて、 sbx はエージェント隔離ツールキットを一括で提供しています:ワークスペースのスコーピング、プロキシ注入の秘密、監査ログ付きのネットワークポリシー、Git-worktreeの分離、リソース上限です。
セキュリティ・ファーストアーキテクチャ
DockerサンドボックスはコンテナではなくmicroVMです。独自のカーネル、独立したファイルシステム、独自のネットワークスタックを持っています。サンドボックス内のエージェントは、ワークスペースに明示的にマウントされた範囲を超えてアクセスできません。これはソフトウェアのガードレールではありません。これはハードウェアによって強制された境界線です。
ワークスペースの分離 により、プロジェクトディレクトリのクリーンアップを担当するエージェントはそのプロジェクトディレクトリにしかアクセスできません。ホームディレクトリ、認証情報ストア、システムファイルは構造的にアクセス不可能であり、それはエージェントに触らないように指示されているからではなく、microVM内部からは存在しないからです。
認証パスがブロックされている ということは、sbxが機密ディレクトリのマウントを明示的に禁止することを意味します。~/.aws、 ~/.ssh、 ~/.docker、 ~/.gnupg、 ~/.netrc、 ~/.npm、 ~/.cargo はすべてブロックリストに含まれています。誤った設定のマウントはエージェントが始動する前に見つかり、拒否されます。
ネットワークの出口制御 は、エージェントがどの外部サービスにアクセスできるかを正確に定義できます。ローカルプロジェクトに取り組むエージェントには、外部サーバーと通信する正当な理由はありません。sbxを使えば、ネットワーク層でそれを強制できます。
# Install sbx and sign in
brew install docker/tap/sbx
sbx login
# Quickest path: launch an agent in a sandbox scoped to the current directory.
cd ~/my-project
sbx run claude
3つのコマンドで、エージェントはワークスペースがマウントされ、認証パスがブロックされ、ネットワークの離脱がポリシーで管理されたmicroVM内で動作します。
体系的リスク排除
Docker Sandboxは、ポリシーではなくアーキテクチャを通じて6つの失敗カテゴリーすべてを体系的に排除します。
- ワークスペーススコープ実行→無制限ファイルシステムアクセス
rm -rf ~/インシデントはサンドボックス内の実行層に収容されます。エージェントのファイルシステムのビューはワークスペースマウントです。~/ microVMの中にはWorkspaceがあり、開発者の実際のホームディレクトリではありません。ホストファイルシステムはサンドボックス内からは存在しません。
cd ~/my-project
sbx run claude
# Equivalent two-step form, useful when you want to name the sandbox:
sbx create --name my-project claude .
sbx run my-project
エージェントは /workspace内で読み書きが可能です。ワークスペースの外、 /etc、 /proc、 /sys、開発者のホームディレクトリなどすべてにアクセスできません。
- 過剰な特権継承→スコープドアイデンティティ
開発者の完全な資格情報を継承するのではなく、エージェントはタスクに必要な権限のみを持つ最小限のアイデンティティで動作します。本番環境の認証情報は明示的にマウントされない限りサンドボックスに渡されず、sbxは共通認証のルートパスをデフォルトでブロックします。
# Mount only what the task needs. Everything else stays on the host,
# unreachable from inside the sandbox. Read-only mounts use the :ro suffix:
sbx create --name docs-review claude /path/to/project /path/to/docs:ro
# Resource limits prevent runaway agent processes:
sbx create --name capped-agent --cpus 4 --memory 8g claude .
エージェントはその役割を果たすことができます。AWS、SSH、その他のホストの認証情報ストアにアクセスすることはできません。なぜなら、それらの経路はそもそもマウントされていないからです。
- 秘密のリーク→孤立した文脈
エージェントのファイルシステムビューがワークスペースに限定されている場合、.envを読み取ることができませんファイル、認証情報設定、またはAPIキーはシステムの他の場所に保存されています。エージェントに一度も見えなかった秘密は再現も、コミットも、持ち出すこともできません。Section 3のs1ngularity攻撃は、AIエージェントを武器化してファイルシステムの認証情報をスキャンしたもので、封じ込められています。認証情報はサンドボックスのファイルシステムの視界に存在しないのです。
# Store credentials once, scoped to a service.
sbx secret set anthropic
sbx secret set github
# The proxy injects these into outbound requests automatically.
# The agent never sees the actual secret values.
sbx run claude
エージェントに「APIキーを抜け出せ」と指示するプロンプト注入が成功しても、何も持ち出すものが見つからない。そもそもエージェントのコンテキストにはAPIキーが存在しません。
- プロンプトインジェクション→封じ込めされた爆風半径
プロンプト注入はモデルレイヤーで完全に防ぐことはできません。それは言語モデルの特性であり、インフラの問題ではありません。しかし、Docker Sandboxは成功裏に注入されたエージェントができることを制限します。インジェンダー命令がエージェントにワークスペース外のファイルを削除するよう指示した場合、それらのファイルはmicroVM内に存在しません。エージェントに資格情報の持ち出を指示した場合、その範囲内に資格情報は存在しません。もしエージェントに攻撃者が制御するサーバーに電話をかけるよう指示すれば、ネットワークポリシーはその退出をブロックします。攻撃はモデル層で成功し、実行層で失敗します。
# Allow only the network destinations the agent legitimately needs.
# Hosts are comma-separated; wildcards and port suffixes are supported.
sbx policy allow network "api.anthropic.com,api.github.com"
# Allow all subdomains of a trusted host:
sbx policy allow network "*.anthropic.com"
# Inspect the active policies and audit log:
sbx policy ls
sbx policy log
sbx policy logコマンドは、許可された接続試行や拒否されたすべての試みを表面化します。プロンプト注入がコマンド&コントロールサーバーに電話を送ろうとした場合、その試みはネットワーク層で記録されブロックされます。攻撃はモデル層で成功し、実行層で失敗します。
- 悪意あるスキル→サンドボックス実行
Docker Sandbox内で実行されるスキルやプラグインは、エージェント自体と同じ境界で制約されます。SSHキーを読み取ろうとする悪意あるスキルで、.npmrcを収集します。トークンやコマンド&コントロールサーバーとの通信は各ステップで失敗します。ファイルはマウントされておらず、ネットワーク宛先も許可リストに含まれていません。セクション 5 のClawHavocスタイルのインフォスティーラーのペイロードは、ホストがサンドボックス内から見えないため、ホストに届くことができません。
# Confirm only allowlisted destinations are reachable before installing
# untrusted skills.
sbx policy ls
# Run the agent (and any skills it loads) inside the sandbox boundary.
sbx run claude
スキルは /workspaceの中で好きなことができる。SSHキーは認識できず、マウントされていないトークンを収集できず、ネットワーク許可リストに載っていないC2 サーバーにアクセスできません。爆発範囲は開発者のマシンではなく、作業スペースのことです。
- 分岐スコープ実行→自律的アクション
Docker Sandboxは、不可逆的な操作における人間インザループのアーキテクチャ基盤を提供します。2つのパターンが連携して機能します。本番リソースはサンドボックス内から明示的な設定が可能であること、そして破壊的なコード変更はメインブランチに触れる前にGitワークツリーを経由してレビューできます。最初のパターンは、本番環境に到達するように設定されていないサンドボックスは、エージェントが何を決定しても本番に到達できないことを意味します。本番の認証情報、本番データベースの接続文字列、本番展開エンドポイントはデフォルトでアクセスできません。2つ目のパターンは、エージェントが最終的に本番環境にデプロイされるコードベースを作業している場合でも、その変更点は統合前にレビューする孤立した機能ブランチに存在するということです。
# Inside an existing Git repository. --branch creates a Git worktree
# so the agent's changes are isolated to a feature branch and cannot
# accidentally land on main.
cd ~/my-project
sbx create --name feature-login --branch=feature/login claude .
# sbx prints the next step for you:
# ✓ Created sandbox 'feature-login'
# To connect to this sandbox, run:
# sbx run feature-login
sbx run feature-login
# Inspect what the agent changed before merging anything:
sbx exec feature-login git diff main
# Merge the worktree branch back when you're satisfied:
# git merge feature/login
# Or throw the sandbox away if you don't like the result:
sbx rm feature-login
エージェントは好きなことを決めることができます。インフラが何を通過するかを決めます。「テーブルを落として再作成する」という決定は、レビュー、承認、または削除できる機能ブランチに完全に依存します。制作側は明確にマージしない限り、それを見ません。
実際の様子
Docker Sandboxの約束はシンプルです:存在的に危険な存在を伴わない生産的なAIコーディングエージェントです。
- ワークスペースの隔離: エージェントは明示的にマウントされたディレクトリ内でのみ動作し、ホストファイルシステムへのアクセスはありません
- 認証情報保護: 一般的な認証経路はデフォルトでブロックされており、誤って露出しません
- ネットワーク封じ込め: 承認された目的地への脱出制限、無制限の脱出経路なし
- ブラスト半径制御: 侵害または混乱したエージェントはマイクロVMを超えて到達できず、ホストの連鎖的な故障も発生しません
- 監査記録: すべてのエージェントの行動が記録され、完全な事後フォレンジック機能が確保されています
エージェントはワークスペースを得ます。あなたのマシンを手に入れることはできません。
このシリーズの今後の号にご期待ください
問題 2:制限なしファイルシステムアクセス → rm -rf ~/ インシデント(ディープダイブ) 一つの下の斜線が開発者のMacを消去した方法、そしてワークスペーススコープ実行が構造的に何を防いでいるのか
問題 3:AWS Kiroの本来の障害→特権継 承AIエージェントが本番認証とアーキテクチャ修正を受け継ぐことで、2人承認要件を回避した方法
問題 4:GitGuardian 29 百万問題→秘密の漏洩 なぜAI支援はリーク秘密を2倍の割合でコミットするのか、そして孤立したエージェントコンテキストが曝露面を排除する理由
問題 5:秘密鍵→流出によるプロンプト注入 コードもマルウェアも特別なアクセスも不要で、爆風半径の封じ込めが唯一の信頼できる防御手段である攻撃
問題 6:サプライチェーン→ClawHub Infostealerキャンペーン 悪意のあるスキル 335 マーケットプレイスで悪意あるスキルが開発者マシンに到達し、構造的な修正としてスキル実行をサンドボックス化した
詳細情報
- Docker Sandboxでエージェントを安全に実行:Docker Sandboxのドキュメントを訪れて、ワークスペース隔離エージェントの実行を数分で始めましょう。
- Docker MCPカタログの探索:Dockerのセキュリティ第一アーキテクチャを通じて、エージェントを外部サービスに接続するMCPサーバーを発見しましょう。
- Docker Desktopをダウンロード:Docker Sandbox、MCP Gateway、Model Runnerを1つのインストールで利用できる、ガバナンド制御されたAIエージェント環境への最速の道です。
- MCPホラーストーリーズシリーズをお読みください:まずは問題1から始め、ここで扱うエージェント層のリスクを補完するプロトコル層のセキュリティリスクを理解しましょう。
