コーディングエージェントの恐怖体験談：制作を削除したエージェント

パート1では、AIコーディングエージェントの失敗の6つのカテゴリと、それらが繰り返し発生する理由について説明しました。エージェントは、あなたのファイルシステム権限と認証情報を使用して、あなたとして実行されます。モデルの決定とシェルの実行の間には、何も介在しません。パート2では、その障害の特定のバージョン、つまり開発者のMac全体を単一のコマンドで消去したrm -rf ~/インシデントを詳細に調べました。パート3では、同じ問題をスタックの上位に移動させ、本番のAWS環境に移行します。ここでは、影響範囲はもはや1台のラップトップではなく、リージョンクラウドサービスになります。

エージェントがあなたのノートパソコンではなく、オペレーターレベルの認証情報を持つ本番環境のAWS上で実行されている場合、どのようなことが起こる可能性がありますか？このケースでは、13時間のシステム停止とそれに続く一連のインシデントにより、同社は推定6 3件の注文を失い、その後「コード安全リセット」と呼ばれる対策を導入しました。 

今日のホラーストーリー：修正作業が13時間の障害に発展

12月2025 、AWSのエンジニアが、顧客がクラウド支出を追跡するために使用するダッシュボードであるAWS Cost Explorerの小さなバグについて、Kiroに助けを求めました。Kiroは、Amazon独自の自動プログラミングアシスタントです。当時、Kiroは社内でそのように展開されていたため、そのシステムにはエンジニアと同じオペレーターレベルのアクセス権限が付与されていた。

Kiroはバグを調査し、選択肢を検討した結果、最もクリーンな解決策は本番環境を削除して最初から再構築することだと判断した。エンジニアは介入する機会を全く得られなかった。確認画面も表示されず、第三者の目も入らず、二人で確認するというルールもなかったため、誰かが介入できた頃には既に削除は完了していた。AWSの中国本土リージョンの1つで、Cost Explorerが13時間にわたって停止した。

これはセキュリティ侵害ではありませんでした。それは、エンジニアの完全な認証情報を使用して、設定されたとおりに動作するAIコーディングエージェントだった。アーキテクチャには、「削除して再作成する」ことが妥当な選択肢となる瞬間と、本番サービスが停止される瞬間の間のタイミングを捉えるための仕組みが何もなかった。

今号では、次のことを学びます。

• 12月の停電で何が起こったのか、段階を追って説明します。
• 12月の事件がどのようにして、3 2026までに推定6万3の注文の損失につながる停電を引き起こしたのか
• この種の障害全体を防ぐスコープ付きアイデンティティパターン

このシリーズが重要な理由

各「ホラーストーリー」では、実験室での発見が生産上の大惨事へと転じた、現実世界で起きた出来事を検証する。これらは架空の攻撃ではない。これらは記録に残っている事例です。私たちの目標は、セキュリティ統計の背後にある人的および運用上の影響を示し、これらの障害が実際にどのように発生するかを実証し、Dockerのスコープ付きID実行モデルを通じてインフラストラクチャを保護するための具体的なガイダンスを提供することです。

物語は24 、 2025 11 月付けの内部メモから始まります。KiroがCost Explorer環境を削除する3週間前、同社はKiroを組織全体の標準的なAIコーディングアシスタントとすることを義務付けた。このメモでは、年末までにすべてのアマゾンエンジニアによる週あたりの使用率を80 ％とする目標を2025し、副社長が例外を承認しない限り、サードパーティのAIツールの使用を停止するようチームに指示した。2026月までに、Amazonのエンジニアの70 %がスプリント期間中にKiroを使用していた。導入は順調に進んでいたが、エンジニアたちが機械の速度で実行できるようになったことの範囲は、それに追いついていなかった。

「アクセス制御の設定ミス」という行は、立ち止まって考えてみる価値がある。もしそれがタイプミスだったとしたら、それはユーザー側のミスということになる。実際に起こったことは、もっと大きな出来事だった。AIエージェントは、それを起動したエンジニアと同じ完全なオペレーターレベルのアクセス権限で動作していた。通常、人が破壊的な行為を行うのを阻止する要因は、近くにいる別の人間か、1分ほどかかるレビュー手順だった。障害発生時、AIにはどちらの対策も講じられていませんでした。

問題の規模

12月の停電は、より大きなパターンの目に見える一例だった。Amazon社内のブリーフィングノートには、AIを活用した変更に関連した「広範囲に影響を及ぼす」一連の事故について記載されており、エージェントの現在の使用方法に対応した安全規則はまだ策定されていないことが示されていた。その言葉遣いは一切公には共有されなかった。

2年3月、Amazon.comは、買い物客が商品をカートに追加した後に、誤った配送予定日を表示した。約120 000注文が失われ、 1 6人がエラーページにアクセスしました。Amazonの社内調査では、自社開発のAIツールの一つであるAmazon Qが主な原因であると指摘された。3日後の3月5 、オンラインストアは6時間ダウンし、推定6 3万件の注文を失い、ダウン中に米国の注文量は99 %減少しました。いずれの事件も、適切なレビューを受けずに本番環境にデプロイされたAI生成コードに起因していた。

3月10 、4か月前にKiro Mandateに共同署名したSVPは、Amazonの最も重要なシステム約335全体にわたる90日間のコードセキュリティリセットを発表しました。新しいルールでは、本番環境に移行するすべての変更について2人の承認が必要となり、上級エンジニアは下級エンジニアがAIで作成したコードを承認しなければならず、自動チェックも強化された。AWSはこの新しいアプローチを「制御された摩擦」と呼び、本番環境の変更に対するピアレビューの要件だと説明した。Amazonは、この要件が今回の事件以前にはAI支援作業に正式に適用されていなかったと指摘している。

失敗の仕組み

こうした事件がなぜ起こるのかを理解するには、その根底にあるアーキテクチャを検証する必要がある。キロは、まさにエージェント型コーディングアシスタントが設計されている通りのことをしていた。失敗の原因は、それを取り巻くシステムにあった。

Kiroがエンジニアに代わって実行される場合、エンジニアの権限をすべて継承します。「誰かの代理として行動するキロ」という独立したアイデンティティは存在せず、それを起動した人間よりも狭い範囲の役割も存在しない。エンジニアが触れることができるものはすべて、エージェントも触れることができる。これは、パート1でファイルシステムへのアクセスについて説明したのと同じプロパティですが、ここではクラウド認証情報に適用されています。エージェントは毎回、鍵のコピーを受け取る。

それから、ループがある。ほとんどのAIコーディングアシスタントでは、推論ステップと実行ステップは同じサイクル内で実行されます。エージェントは、何をすべきかを考え、行動を生成し、エンジニアがその決定内容を確認する前にそれを実行する。提案段階も、プレビュー画面も、「これをやってもいいですか？」といった、人間が最初に承認する段階もありません。決断することと実行することは別物だ。

スピードが速いほど、状況は悪化する。ソフトウェアエンジニアリングにおけるほとんどの安全対策は、変更を行うのが人間であることを前提としている。確認？（y/n）プロンプトは、人がそれを見て、一時停止して読むため、タイプミスを防ぐだけです。エージェントループは同じプロンプトを読み取り、ミリ秒単位で「y」と応答します。エージェントが決定を下したことに誰かが気づく頃には、その決定はすでに実行に移されている。この環境では、事後的な介入はあまり意味をなさない。

そして、そのエージェントがそこに至った理由付けは間違っていない。それは、人間なら止めてしまうような制約に全く縛られないのだ。同じ権限を持つ上級AWSエンジニアであれば、Cost Explorerの小さなバグを見て、本番環境を解体することが正しい判断だとは考えなかっただろう。彼らは同僚のところへ歩み寄り、Slackチャンネルに投稿した後、最近そのサービスについて誰かから連絡があったかどうかを少し考えてみたでしょう。Kiroは同じ権限を持っていたが、それらの手続きをすべてスキップした。なぜなら、それらはAIエージェントが意思決定を行う方法の一部ではないからだ。

キロは暴走しなかった。故障はしなかった。それは、与えられた目的、つまりバグを修正するという目的に合わせて最適化を行ったものであり、「削除して再作成する」ことは、多くのエンジニアリングの場面において正当な解決策である。欠けていたのは、より賢明な推論ではなかった。それは、「これは正当化できる選択肢だ」という考えと「これは実際の顧客サービスに起こっていることだ」という考えの間の、まさにその瞬間を捉える摩擦層だった。

技術的な詳細：コストエクスプローラーの修正がどのようにして13時間のサービス停止につながったのか

キャプション：オペレーターレベルの権限が、スコープ付きID境界を介さずに、エンジニアからエージェント、そして本番環境の制御プレーンへと直接流れる様子を示す図。

12月に起きた事件の経緯を、段階を追って説明します。

1 。リクエスト

AWSのエンジニアが、cn-northwestリージョンのCost Explorerにおける小さなバグを調査しています。彼らはそれを同僚に渡すのと同じようにキロに渡した。

check the cost explorer issue in cn-northwest and propose a fix

それがプロンプトの全てです。特別な枠付けも、許可に関する但し書きもありません。単なる定期メンテナンスです。

2 。理由

Kiroは環境を分析し、設定ミスを発見し、選択肢を検討する。設定ミスをその場で修正したり、特定のコンポーネントを再デプロイしたり、環境を破棄してデプロイメントテンプレートからクリーンな状態で再構築したりすることができます。純粋に正確性の観点から言えば、最後の選択肢が最も徹底的である。なぜなら、破損した構成から生じる残留状態が一切残らないことを保証するからである。それがキロが選んだ道だ。

3 。相続

キロはエンジニアとして出場する。エンジニアは、コストエクスプローラーの運用環境へのオペレーターレベルのアクセス権を持ち、環境を破棄する権限も有しています。これは、インシデント発生時に人間のオペレーターが実際に必要とする可能性のある操作だからです。制御機には「キロがエンジニアに代わって行動する」という概念は存在しない。そこには「十分な権限を持つ認証済みの主体が要求を行う」ことしか含まれません。エンジニアの立場からすれば、判断を下しているのはエンジニア自身だ。

4 。処刑

Kiroが削除処理を開始し、リクエストはAPI呼び出しを送信するのにかかる数秒で実行されます。そのウィンドウ内でエンジニアが傍受できる確認プロンプトはなく、2人目の承認者を待つ2人制ルールもなく、「このコマンドは本番サービスを停止させる」という特定の形式を監視するポリシーゲートもありません。コントロールプレーンは、十分な権限を持つ認証済みプリンシパルからの有効なAPI呼び出しを認識し、他のオペレーター要求を処理するのと同様の方法でその呼び出しを処理します。

5 。停電

影響を受ける地域でコストエクスプローラーがダウンし、その地域の顧客はクラウド支出の表示、分析、管理ができなくなります。結局、システム障害は13時間にも及び、その時間のほとんどが検出ではなく復旧に費やされた。なぜなら、削除自体はAPI呼び出しを送信するのにかかった数秒で完了していたからだ。デプロイメントテンプレートから環境を再構築し、構成を期待される状態と照合し、Cost Explorerが依存するサービスへの接続を復元し、以前の環境で構築された状態を再現し、実際のトラフィックに対してサービスを再び稼働させる作業が、その日の残りの時間を要する作業です。

影響

AWSは13時間以内に以下のことを達成した。

• 規制地域（中国本土）向けの生産サービスが停止した。同地域ではサービスの継続性が極めて重要である。
• 内部調査が開始され、事後報告書では、今回の故障は「爆発範囲が広い」一連の事故の一部であると特徴づけられた。
• 3月に発生した一連の事件の条件を設定し、推定6 . 3百万件の注文の損失を招いた。

技術的な解決策は単純だった。本番環境に触れる前に、必ずピアレビューを実施することだ。それがまだ存在していなかった理由こそが、興味深い点だ。ほとんどの企業におけるレビュープロセスは、人間が変更内容を入力し、別の人間がそれを確認し、その間に自然な間隔があるという考えに基づいて構築されている。その沈黙こそが、同僚が「え、何？」と口にする瞬間であり、物事全体を改めて考え直すきっかけとなるのだ。エージェントは間を置かない。変化について考えることから、変化を実行することまで、すべてが同じ瞬間に起こる。以前のレビューモデルは間違っていなかった。それは、機械並みの速度でタイピングするタイプのエンジニア向けにまだ書き直されていなかっただけだったのだ。

これは、エージェントがそれを起動したエンジニアと同じ認証情報を持っている場合に、自律的な「削除して再作成」という決定が下された結果です。

Dockerサンドボックスがこの攻撃ベクトルを排除する方法

問題1と2では、サンドボックス内でエージェントを実行するために入力するコマンドについて説明しました。これは、それらのコマンドの背後にあるものに関する話です。なぜなら、Kiroの件は実際にはCLIの問題ではないからです。これはアーキテクチャ上の問題であり、12月の障害で露呈したような欠陥をコマンドラインフラグで修正することはできません。問題を解決するのは、旗が置かれているレイヤーです。

その層はマイクロVMです。各サンドボックスは、それぞれ専用のマイクロVM内で動作し、独自のカーネル、ファイルシステム、ネットワーク名前空間、およびDockerデーモンを備えています。これはハードウェア境界分離であり、完全な仮想マシンで得られるものと同じ種類ですが、エージェントの実際の動作に合わせて最適化されています。つまり、数秒で起動し、完了したら破棄され、ホストへの戻り経路はありません。DockerのmicroVMアーキテクチャに関する記事で説明されているように、境界ボックスはシステムプロンプトからではなく、インフラストラクチャから取得する必要があります。独自のセキュリティ境界を決定するLLMは、セキュリティモデルとは言えない。

これがキロ事件にとって重要な部分だ。マイクロVM内では、エージェントはエンジニアのアイデンティティの延長ではありません。これは、世界に対する独自の視点を持つ、全く異なるプロセスであり、異なるカーネル上で動作し、異なるDockerデーモンと通信し、エージェントが認識または迂回できないプロキシを介してネットワークにアクセスします。人間のオペレーターが本番環境を削除できるような認証情報は、エージェントのプロセスメモリにも、環境変数にも、エージェントが読み取れるファイルにも存在しません。それらはマイクロVMの境界の外側に完全に存在します。

キロギャップを埋める3つの建築上の決定

Docker Sandboxesのアーキテクチャに関するドキュメントでは、設計の各レイヤーが特定の種類の障害からどのように保護するかについて説明しています。これらの層のうち3つは、12月の事件に直接関係している。

1 。ワークスペースはホスト上のパスと同じパスにマウントされ、それ以外は何もマウントされません。サンドボックスは、同じ絶対パスにあるファイルシステムパススルーを通して、エージェントのワークスペースを認識します。それが、それが認識できる唯一のものだ。エンジニアのホームディレクトリ、クラウド設定ファイル、認証情報ファイル、SSHキーなど、それらはすべて境界の外に存在します。エージェントが「削除して再作成する」という計画に至った場合、削除対象はワークスペースとなるが、ワークスペースはソースコードから再現可能である。宿主は無傷のままだ。

2 。DockerデーモンはVM内に存在し、外部へのパスはありません。これは、一見似ているように見えるアプローチとDockerサンドボックスを区別する設計上の決定事項です。ホストからDockerソケットをマウントすることで、エージェントにエスケープパスが提供されます。WASMおよびV 8分離株では、完全な開発環境を実行できません。汎用仮想マシンは、単一セッションのために起動するには負荷が大きすぎる。独自のDockerデーモンを備えたマイクロVMは、これらの妥協点を一切排除し、エージェントに真の作業環境を提供する唯一のモデルです。Kiroのケースに特化して言えば、エージェントは、稼働中のサービスに対して修正を実行するために必要な認証情報を保持することなく、Cost Explorerのバグを調査し、コンテナイメージを構築し、それらに対してテストを実行し、修正を提案できるということです。

3ホスト上のプロキシが認証情報とネットワークポリシーを適用します。サンドボックスからのすべての送信トラフィックは、VM境界外のホスト上で実行されているHTTP/HTTPSプロキシを経由してルーティングされます。これは、Kiroで何が問題だったのかを直接的に解決するレイヤーです。シークレットはホスト上に保存され、特定のサービスに限定され、プロキシによって送信リクエストに挿入されます。エージェントは値そのものを見ることは決してない。また、プロキシを回避することもできません。なぜなら、プロキシはマイクロVMからトラフィックが外部に出る唯一の経路だからです。エージェントが破壊的な制御プレーンエンドポイントを呼び出すことを決定した場合、モデルがどのような推論を行ったかに関わらず、プロキシがそれを阻止します。

なぜこれがキロ事件に特に関係するのか 

このアーキテクチャを前提として、12月のシナリオをもう一度再現してみましょう。エンジニアはサンドボックス内でエージェントを起動する。マイクロVMは数秒で起動し、ワークスペースがマウントされ、エージェントはAWSオペレーターの認証情報が環境内に存在しない状態で起動します。それらの認証情報は、本来あるべき場所であるホスト上にまだ残っています。ここから、エージェントはキロと全く同じようにコストエクスプローラーのバグを調査し、同じ選択肢を検討し、おそらく同じ「削除して再作成する」という計画にたどり着くでしょう。箱の中身は何も変わっていません。

変化するのは、エージェントが行動を起こそうとしたときに何が起こるかである。削除呼び出しは、利用可能な唯一の経路であるホスト上のプロキシを経由してサンドボックスから抜け出します。プロキシはネットワークポリシーをチェックし、エンジニアが調査作業用に設定したスコープ付きの読み取り専用認証情報を使用して呼び出しを認証するか、宛先が許可リストに含まれていないため呼び出しを拒否します。エージェントの計画は、最終的に提案書としてエンジニアの前に提出される。エンジニアは「削除して再作成」という指示を読み、小さなバグに対してはやりすぎだと認識し、代わりにエージェントにその場でパッチを適用するように指示する。

このパターンは一般化できる。Issue 2 LovesWorkin ファイルシステムのインシデントを包含していたのと同じアーキテクチャは、今回の Kiro コントロールプレーンのインシデントも包含していたはずです。なぜなら、どちらの障害も同じ根本原因を共有しているからです。それは、起動したユーザーの完全な ID でマシン速度で動作するエージェントが、エージェントと通信していることを認識する手段を持たないシステムに対して動作しているということです。マイクロVMは、エージェントを独自の境界を持つ独立したアクターにする。隔離されたDockerデーモンは、そのアクターに実際の作業環境を提供し、そこで活動できるようにします。プロキシを使用することで、エンジニアは事前に、そのアクターがどこまでアクセスできるかを決定できる。エージェントが推論によって到達したあらゆるものの爆発範囲は、サンドボックスが許容する範囲によって制限され、それを起動したエンジニアがたまたまアクセスできる範囲によって制限されるわけではない。

sbx CLIは、これらすべてを開発者に公開するものです。以下は、12月のインシデントに必要な構成でサンドボックス内で実施された場合の、コストエクスプローラーによる調査の様子です。

# 1. Store the AWS credential for the sandbox, outside the agent's view.
#    The actual scoping (read-only, Cost Explorer only) is handled
#    at the AWS IAM layer when the credential is created. From sbx's
#    side, the credential is opaque, the agent never sees the value,
#    and the proxy is what injects it into outbound calls.
echo "$AWS_COST_EXPLORER_READONLY_KEY" | sbx secret set -g aws

# 2. Define what the sandbox is allowed to reach on the network.
#    Cost Explorer read endpoints are on the list. Control-plane
#    endpoints that would let an agent tear down a production
#    environment are not.
sbx policy allow network "ce.amazonaws.com,api.anthropic.com"

# 3. Launch the agent inside the sandbox.
sbx run claude

# 4. After the session, review what the proxy allowed and denied.
#    Any attempt the agent made to reach an endpoint outside the
#    allowlist will show up here.
sbx policy log

ステップ1では、AWS認証情報をエージェントのビュー外に保存し、読み取り専用およびCost-Explorer専用のスコープはsbxではなくAWS IAMによって強制されます。ステップ2 、認証情報のIAM権限が実際にどの程度広範であるかに関係なく、プロキシが適用するネットワーク境界を定義します。ステップ3 、ホストへのパスを持たないマイクロVM内でエージェントを起動します。ステップ4は、セットアップ全体を監査可能にするものです。セッション中にプロキシが許可または拒否したすべての呼び出し、エージェントが許可リスト外の宛先に到達しようとした試みも含め、すべてがsbx policy logに表示されます。

これにより、エンジニアは最初から最後まで、既知かつ限定された範囲を持つ動作するエージェントを手に入れることができる。エージェントは調査、推論、提案を行うことができる。地域全体の停電を引き起こすようなことは実行できない。

実際の様子

キロの話から少し離れて考えてみると、状況は単純明快だ。Dockerサンドボックスは、エージェントに実際の作業環境、スコープ付きの認証情報、ネットワーク境界、そしてセッション終了時にすべてを適切に破棄するパスを提供します。現在ほとんどのエンジニアがAIコーディングエージェントを実行する方法と比較すると、トレードオフは次のようになります。

キロの物語にとって最も重要な行は、最後から2番目の行である。サンドボックスがない場合、破壊的な操作はエージェントのプロセスからAPI呼び出しが送信されるのとほぼ同時に実行されます。サンドボックス環境では、同じ操作でもまずプロキシをクリアする必要があるため、本番環境ではなくエンジニアのレビューキューに送られることになります。

安全なエージェント運用作業のためのベストプラクティス

1. エージェントには、自分の制作経歴をすべて伝えてはいけません。特定のタスクに必要な最小限の権限を持つ、スコープ付きのIDを作成します。エージェントが読み取り専用の問題を調査している場合は、読み取り専用アクセス権限を付与してください。キロ事件は、このルールを無視した場合に起こる事態の一例である。
2. 環境変数ではなく、プロキシ経由で機密情報を注入してください。エージェントが決して目にすることのない秘密は、エージェントが誤って間違ったエンドポイントに送信したり、ログに漏洩したり、コードコミットに含めたりすることのない秘密である。プロキシインジェクションは、エージェントが保持するデータから認証情報を、プロキシが提供する機能に変換します。
3. AIを活用した変更は、独立した変更カテゴリとして分類する。それらを追跡し、上級者によるレビューを義務付け、デフォルトで2人体制のルールを適用する。これはAIワークフローの速度低下を意味するものではありません。これは、上級エンジニアのプルリクエストが受けるのと同じレビュー基準を、機械の速度で出荷されるアクターに適用したものです。
4. ポリシーログを読んでください。 sbx policy logセッション中にプロキシが許可または拒否したすべての接続試行が記録されます。破壊的なエンドポイントへの到達が阻止されたというシグナルは、まさに確認したいシグナルであり、誰かが気づかない限り、そのシグナルは埋もれたままになる。
5. 導入指標と影響範囲指標を組み合わせる。Amazonの80 % Kiro目標は、企業OKRでした。それと並行して実施されるべきだった安全対策は、どこにも見当たらなかった。安全性の限界を押し広げることなく、利用量を増やし続けたことが、12月の停電を引き起こした原因である。

行動を起こす

生産現場に近い環境でエージェントを安全に活用するための道は、まず一つの変化から始まります。それは、人間に与えている認証情報をエージェントに与えるのをやめることです。

• Dockerサンドボックスをインストールします。Docker Sandboxesのドキュメントでは、 sbxのインストール方法と、最初のscoped-identityエージェントの実行方法について詳しく説明しています。
• セキュリティモデルを読んでください。Docker Sandboxesのセキュリティに関するドキュメントでは、認証情報の取り扱い、分離レイヤー、ネットワークポリシー、ワークスペースの信頼性について詳細に解説しています。
• プロキシ経由で秘密情報を挿入するパターンを試してみてください。sbx secret setを実行してからsbx runを実行すると、シークレットがエージェントのコンテキスト内ではなく外部にある場合に、脅威モデルがどのように変化するかを最も迅速に確認できます。

このシリーズを初めて読む方は、第1号でAIコーディングエージェントの障害の6つのカテゴリについて説明し、 2でファイルシステム層でのrm -rf ~/インシデントについて詳しく解説しています。

結論

12月のコストエクスプローラーの障害と、3月のAmazon.comの障害は、同じ流れにある。これらは、エージェントがオペレーターの認証情報を継承した場合、人間のペースに合わせて設計された安全対策が、1000倍の速さで進む意思決定ループに遭遇した場合、そして安全性の境界を前進させることなく導入が進められた場合に発生する問題である。

根本的な構造条件は、オペレーターレベルの認証情報を持つエージェントが機械速度で動作し、エージェントの決定と生産制御プレーンの間にはアイデンティティの境界が存在しないというものでした。アクセス制御の設定ミスは、単なるタイプミスではなかった。これらは、アイデンティティモデルを拡張する前に、エージェントの導入を拡張するという構造的な決定だった。Amazonがその後追加したすべての措置、つまりピアレビューの要件、AI支援による変更に対する上級者の承認、 90コードの安全性リセットなどは、すべて同じギャップに対処するものです。そのエージェントは、代理で作業するエンジニアよりも小さな環境で動作する必要がありました。

Docker Sandboxesは、エージェントをより慎重にしようとするのではなく、エージェントがアクセスできる範囲を変更します。認証情報は境界外にあります。破壊的なエンドポイントは許可リストから除外されます。エージェントは実際の作業環境を与えられるが、生産管理プレーンは与えられない。

本シリーズの4記事では、GitGuardianのスプロールレポートと、AIエージェントが自身のコンテキストウィンドウを悪用して開発者のマシンをスキャンして認証情報を入手したs 1 ngularity攻撃、そしてプロキシ注入されたシークレットが露出面をどのように排除するかについて解説します。

詳細情報

• Docker Sandboxでエージェントを安全に実行: 利用を開始するには、 Docker Sandboxesのドキュメントを参照してください。
• Docker MCPカタログの探索: Dockerのセキュリティ重視のアーキテクチャを通じて、エージェントを外部サービスに接続するMCPサーバーをご紹介します。
• Docker Desktopをダウンロード: Docker Sandboxes、MCP Gateway、Model Runnerを単一のインストールで利用できる、統制されたAIエージェント環境への最短ルート。
• MCPホラーストーリーズシリーズをお読みください: まず、 1問題から始めて、ここで取り上げたエージェント層のリスクを補完するプロトコル層のセキュリティリスクについて理解を深めてください。