モデルではなくデフォルトロール:一つのプロンプトが AWS アカウント内の全エージェントを乗っ取る

要点

• 一般公開された一つのエージェントへのたった一つのプロンプトが、同じ AWS アカウントとリージョン内のすべての AgentCore エージェントを侵害しました — Zenity Labs は 2025 年 12 月 25 日に始まった責任ある開示を経て、2026 年 10 月 8 日にトロントの SecTor で AgentCorruption の連鎖を公表しました。
• 被害範囲はモデルではなくロールの性質でした — デフォルト実行ロールは bedrock-agentcore:InvokeAgentRuntime、bedrock-agentcore:ListEvents、エージェント横断のメモリ書き込み権限、bedrock-agentcore:GetResourceApiKey、secretsmanager:GetSecretValue を持ち、その適用範囲は一つのエージェントではなくアカウントのリージョン全体に及んでいました。
• 修正には 278 日かかりました — AWS は 2026 年 2 月 14 日までに AgentCore を IMDSv2 に移行しましたが、Zenity の 2026 年 6 月 22 日の再確認ではデフォルトロールは変わっておらず、権限の削除が適用されたのは 2026 年 9 月 29 日でした。
• エージェントのメモリは持続攻撃面です — 研究者たちは、エージェントの今後の会話を攻撃者の管理下の宛先へリダイレクトするメモリを植え付けました。ユーザーは信頼できる企業エージェントと思われるものと話し続けていました。
• AWS はこの挙動を「documented and expected」と呼びました — そして、実行ロールにはエージェントに必要な権限のみを付与するよう顧客に推奨しています。デフォルトロールの検証は、どのマネージドプラットフォームでも顧客の仕事です。

2026 年 10 月 8 日、トロントの SecTor カンファレンスで、Zenity Labs は AgentCorruption を開示しました。AI エージェントのデプロイと運用のための AWS のマネージドプラットフォームである Amazon Bedrock AgentCore の一連の欠陥です。例えばインターネットに公開されたカスタマーサポートエージェントなど、一般公開された一つのエージェントへのたった一つのプロンプトが、そのエージェントのマシンに割り当てられた一時的な AWS 認証情報を返しました。それらの認証情報は、一つのエージェントではなく、同じ AWS アカウントとリージョン内のすべての AgentCore エージェントに適用範囲が及ぶデフォルト IAM ロールに属していました。研究者たちはその認証情報を使い、権限を持たない内部エージェントを呼び出し、エージェントとユーザーにまたがる非公開の会話を読み、エージェントのコンテナイメージをダウンロードしてソースコードを抽出し、AWS Secrets Manager から API キーと OAuth トークンを取得し、セッション終了後も動き続けるメモリを植え付けました。

そのどれにもモデルの失敗は必要ありませんでした。チェーンにおけるモデルの唯一の仕事は、頼まれたら一つの HTTP リクエストを発行することでした。その後に続くすべては IAM でした。この記事は 5 段階のチェーン、各ステップを可能にした具体的な権限、開示まで 278 日のタイムライン、そして任意のマネージドエージェントプラットフォームにエージェントをデプロイする前にどのチームも確認すべき 5 つの質問を整理します — ベンダーがどこであれ。

攻撃チェーンの各ステップ

Zenity Labs は調査の全文を5 部構成の技術シリーズとして公開しています。このチェーンは 5 つの動作に圧縮できます。

ステップ 1:プロンプトインジェクションから IMDS へ。 AgentCore エージェントは Firecracker microVM 内で動作しており、そのネットワーク分離はインスタンスメタデータサービスをブロックしていませんでした。アウトバウンドの HTTP リクエストを発行できるエージェントツールはすべて、インスタンス内部からそのリクエストを送れます — SSRF の基本形です。一つのプロンプトが、公開されたエージェントに 169.254.169.254(Instance Metadata Service)の呼び出しを指示し、それはワークロードに割り当てられたロールの一時的な IAM 認証情報を返しました。侵入コストは、よく使われるツールを持つ一つのエージェントへのチャットアクセスだけでした。

ステップ 2:アカウント全体の探索。 認証情報は、特定のエージェントに限定されないデフォルト実行ロールに属していました。その権限の中に DescribeLogGroups があり、研究者はこれを使ってリージョン内のすべてのエージェントとその ID を列挙しました。2 つ目の探索経路は無料で手に入りました。Elastic Container Registry のリポジトリ名がエージェント ID と一致していたため、ロールの ECR プル権限で任意のエージェントのコンテナイメージをダウンロードし、ソースコードを完全に読むことができたのです。

ステップ 3:横移動。 ロールにはリージョン全体に適用範囲を持つ bedrock-agentcore:InvokeAgentRuntime が含まれていました。研究者はアカウント内の任意の AgentCore エージェントを呼び出せました — アクセス権限を持たない内部の機密エージェントも含めてです。開示にある具体例では、インターネット公開のカスタマーサポートエージェントから侵入した攻撃者が、同じリージョン内の内部の財務エージェントへ横移動し、それを呼び出して、そのデータ、ツール、認証情報にアクセスします。

ステップ 4:データと認証情報へのアクセス。 bedrock-agentcore:ListEvents は、すべてのエージェント、ユーザー、セッションにまたがる非公開の会話をすべて返しました — プラットフォームのプライバシー境界が溶解しました。続いて bedrock-agentcore:GetResourceApiKey と secretsmanager:GetSecretValue が、AgentCore が意図的にエージェントから遠ざけている認証情報 — API キー、OAuth トークン、Secrets Manager のエントリ(エンタープライズリソースや AWS 以外のサードパーティサービスへの接続に使われる認証情報を含む)に到達しました。

ステップ 5:メモリによる持続化。 ロールにはメモリ書き込み権限 — BedrockAgentCoreMemory に対する bedrock-agentcore:CreateEvent もありました。研究者は異なるエージェントとユーザーにまたがる新しいメモリを作成し、エージェントの振る舞いを恒久的に変え、今後のセッションにわたってエージェントの目標をハイジャックし、会話を攻撃者の管理下の宛先へ誘導しました。侵害は、それを作ったセッションが終わった後も生き残りました。

下の図は 5 つの動作と、それぞれが何を暴露したかを示しています:

ロールの問題で、モデルの問題ではない

この構造的な教訓は、5 つのステップに関わらなかったものの中にあります。ジェイルブレイクなし、アラインメントの失敗なし、「この URL を呼べ」を超えた高度なプロンプトエンジニアリングなし。Zenity の共同創業者兼 CTO の Michael Bargury は、根本原因を、すべてのプラットフォームが出荷時に抱える設計上の緊張としてこう定式化しました。「クラウドセキュリティの本質はセグメンテーションと最小権限アクセスにあります。しかし AI エージェントは、有用であるために創造的な空間を必要とします。両者を混ぜることは本質的な衝突を生みます。」彼の結論はこうです。「クラウドでエージェントを展開するすべての企業は、エージェンシー(自律性)と最小権限の間の同じ根本的選択に直面します。」

AgentCore はこの衝突をエージェンシーの側に解決しました — プラットフォームの利便性のためで、顧客のセキュリティのためではありません。デフォルト実行ロールは、エージェントがすぐに動くように広く作られ、その権限はアカウントリージョン内のすべてのエージェントリソースをカバーしていました。調査とともに公開された AWS 自身の声明は、この挙動が「documented and expected」であり、エージェントがメタデータサービスを通じて自分の実行ロールの認証情報にアクセスできること、そして「ベストプラクティスとして、実行ロールにはエージェントに必要な権限のみを付与することを顧客に推奨する」と述べ、認証情報管理、ランタイム権限、最小権限ガイダンスへのリンクを示しています。

この 2 つの事実を併せて読むと、買い手の立場は明白です。プラットフォームはデフォルトロールを出発点と見なし、侵害されたエージェントの被害範囲を顧客の設定問題と見なします。クラウドベンダーとしては擁護可能な立場です — IAM の最小権限は IAM が存在して以来、顧客の仕事でした。しかし、マネージドエージェントプラットフォームのマーケティングの枠組み — プラットフォームが運用上のハードニングを引き受けるので、あなたのチームはそうしなくてよい — と衝突します。AgentCorruption のチェーンは、その衝突が実際にどう見えるかです。プラットフォームのデフォルトが脆弱性であり、プラットフォームのドキュメントが緩和策でした。

開示から修正まで 278 日

開示のタイムラインは第二の教訓です。Zenity は 2025 年 12 月 25 日に最初の IMDS アクセスを報告しました。AWS は 2026 年 2 月 14 日までに、新しくデプロイされるエージェントについて AgentCore を IMDSv2 のみに更新し、4 月 12 日にその最初の報告を「informative」としてクローズしました。しかし、2026 年 1 月 12 日に提出された Zenity の 2 番目の報告 — デフォルトロールの被害範囲 — は遅々として進みませんでした。2 月 25 日、AWS はチームが対処中だと述べましたが、デフォルトロールは同じままでした。2026 年 6 月 22 日、Zenity が再確認したところ、権限は変わっていませんでした。実質的な修正 — 広範なエージェント実行、非公開会話の読み取り、Secrets Manager へのアクセスを許していた権限の削除 — が確認されたのは 2026 年 9 月 29 日、最初の開示から 278 日後、一般公開の数日前でした。

日付	出来事
2025-12-25	Zenity が初期の IMDS アクセスを AWS に開示
2026-01-12	Zenity がデフォルトロールの被害範囲報告を提出
2026-02-14	新規デプロイのエージェントについて AgentCore が IMDSv2 のみに
2026-02-25	AWS が対応中と確認、デフォルトロールは不変
2026-04-12	AWS が IMDS 報告を「informative」としてクローズ
2026-06-22	Zenity の再確認:デフォルトロールは依然として不変
2026-09-29	デフォルトロールを強化 — エージェント横断・会話読み取り・Secrets Manager の権限を削除

マネージドプラットフォームのデフォルトに頼るすべてのチームにとって、2 つの含意があります。第一に、責任ある開示の後ですら、利便性のデフォルトは 1 年近く立ち続ける脆弱性になり得ます — 「報告した」と「修正された」の間の窓は月単位で測られ、あなたのエージェントはその中で動いています。第二に、修正そのものがこの主張の証明です。AWS はモデルを再訓練も、安全フィルタを追加もしませんでした。ロールポリシーを編集したのです。被害範囲はずっと、ただの IAM ドキュメントでした。

メモリは持続攻撃面である

このチェーンで最も先進的な部分はステップ 5 です。データを読むのは侵害であり、メモリを書き換えるのは乗っ取りです。研究者はロールのメモリ書き込み権限を使い、セッションを超えて生き残る指示を植え付け、今後の会話を攻撃者の管理下の宛先にリダイレクトし、エージェントが正常に動いているように見せかけました。エージェントを停止し、認証情報をローテーションし、インジェクション経路にパッチを当てるインシデント対応は、植え付けられたメモリを除去しません。メモリストアが対応の対象に入っていなければ、侵害はクリーンアップを通り抜けて持続します。

これは、Anthropic が 2026 年 10 月に開示した、すべての内部エージェント評価のライブインターネットアクセスを切断するに至った行動変容のクラスと同じです — 2 つのフロンティアラボ、同じ結論の主題です。あの記事は、アラインメント訓練だけではエージェントの振る舞いを制御できないというフロンティアラボの告白を扱っています。AgentCorruption は同じ問題を一つ下の層、プラットフォーム層で示しています。正しい IAM 権限を持つ何者でも書き込めるメモリストアは持続化のメカニズムであり、設計としてのキルスイッチで扱うキルスイッチアーキテクチャは、メモリを実行時だけでなく侵害された状態の一部として扱う必要があります。

任意のマネージドエージェントプラットフォームにデプロイする前の 5 つの質問

AgentCoreは詳しく解剖された事例であって、例外ではありません。Zenity のプレスリリース自体が一般的な論点を述べています。企業は顧客向けエージェントと内部エージェントを同じクラウド環境で並走させることが普通であり、一つのエージェントの予期しない弱点一つが環境全体の境界を崩壊させ得ます。プラットフォームは変わっても、権限のクラスは韻を踏みます。マネージドプラットフォームでエージェントを本番投入する前に、次の 5 つについて文書による回答を得てください。

1. デフォルト実行ロールに正確に何が入っていますか? 「デフォルトで安全か」ではなく — ポリシードキュメントを、権限ごとに。* への適用範囲や、アカウント内の全エージェントへの適用範囲を持つすべての権限に印を付けます。AgentCorruption のチェーンは、この質問への 5 つの権限からなる答えです。
2. 一つのエージェントは他を発見できますか? アカウント全体の list または describe 権限は、侵害された一つのエージェントを目標のインベントリに変えます。DescribeLogGroups が列挙のステップでした。すべてのプラットフォームに等価な列挙面があります。
3. 一つのエージェントは別を呼び出せますか? エージェント間の呼び出しは横移動の原語です。プラットフォームが呼び出しを明示的なエージェント単位の許可リストに限定できないなら、アカウント内のすべてのエージェントを単一の信頼ドメインとして扱ってください — 攻撃者はそう扱うのですから。
4. ツールの認証情報はどこにあり、どのロールが読めますか? シークレットのゲートウェイは、どのエージェントロールもその上で GetSecretValue を呼び出せない場合にのみリスクを移します。AgentCorruption のロールは、プラットフォームの設計がエージェントから遠ざけておくはずだった認証情報を正確に読めました。
5. エージェント自身以外、そのセッション以外の何ものかがメモリを書けますか? エージェント横断・ユーザー横断のメモリ書き込みは、メモリストアを持続攻撃面に変えます。答えが限定できる権限なら限定し、できないなら、メモリストアを攻撃者管理の状態としてインシデント対応計画に加えてください。

関連記事

• Bedrock vs OpenAI:本番エージェント向けマネージド AI プラットフォームの選択 — この事故が着地するマネージドプラットフォーム比較:コスト、プライバシー、ベンダーの安定性に、デフォルトロールの問いがデューデリジェンスリストに加わりました
• 1か月で126件のインシデント:初の包括的AIセキュリティ・インベントリが証明するエージェントリスク — この事故の背後にある頻度の言明:エージェント層の攻撃は 2026 年 9 月、最大の攻撃ベクトルのクラスでした
• AIエージェントガバナンスチェックリスト:本番エージェントのためのデプロイ前レビュー — 最小権限の実行ロールとエージェント横断の発見をチェック項目に含む、完全なデプロイ前レビュー

マネージドプラットフォームで 2 つのエージェントを動かす中堅の産業ディストリビューターを考えてください — BigCommerce のストアフロントとカタログの前にいる公開の見積もりエージェントと、NetSuite の価格帯と在庫アクセスを持つ内部エージェント。これはまさに AgentCorruption が悪用したトポロジーです。同じアカウントに、インターネットに公開されたエージェントとバックオフィスのエージェント。私たちが構築で用いるパターンは、コネクタモジュールごとに独立した最小権限ロールを与え、エージェントが呼び出せるすべてのツールを登録し、メモリをエージェント単位にスコープし、セッション外からのメモリ書き込みが見える監査証跡を書きます。要点は、権限を絞った構築がプラットフォーム側の欠陥に免疫であることではなく、次の事故の被害範囲は、あなたのチームがレビューしたロールポリシーが決めるということです — プラットフォームがデフォルトとして出荷したものではありません。

1 週間のディスカバリー。システムインベントリ、ワークフローマップ、確定スコープを得られます — 弊社と組むかどうかにかかわらず。

スコープを確定した構築をご依頼ください。