1つのプロンプト、1つのエージェント、AWSアカウント全体：Amazon Bedrock AgentCoreにおけるAgentCorruptionの内幕

2026年10月8日、Zenity LabsはAgentCorruptionを開示した。これはAmazon Bedrock AgentCore（AIエージェントのデプロイと実行のためのAWSのマネージドプラットフォーム）に存在する一連の脆弱性であり、公開された1つのエージェントに対する単一の自然言語プロンプトによって、同一のAWSアカウントおよびリージョン内のすべてのAgentCoreエージェントを掌握できてしまうというものだった。この研究は、SecTor 2026（トロントで開催）での講演と併せて公開され、Zenityのセキュリティ研究部門ディレクターであるTamir Ishay Sharbatがこれを発表した（Dark Reading、2026年10月8日）。Sharbat、Lana Salameh、Dmitry Lozovoy、João Donato の名でクレジットされたZenity自身の解説記事は、そのメカニズムの説明から始まっている。すなわち、外向きのリクエストを行えるツールを1つでも持つAgentCoreエージェントは、次のものを呼び出すよう誘導され得る：AWS Instance Metadata Service (IMDS)（リンクローカルアドレス169.254.169.254）。これは、そのエージェント自身の実行ロールの一時的な認証情報を返す。Zenityはこれらの認証情報を自社のマシンにエクスポートし、そこからでも問題なく機能することを確認したと述べている。CVE識別子は割り当てられなかった。

アーカイブでは、これは脆弱性として記録されている。つまり、発見されたものであり、必ずしも悪用されたわけではない。深刻度は高で、確度はA、実際の被害の記録はなく、AIの関与が確認されている。事実関係では当事者間で一致しているものの、その位置づけをめぐっては見解が分かれている。AWSはDark Readingに対し、この研究は「想定済みで文書化された動作を脆弱性として不正確に表現している」と述べた。

チェーンが実際に何だったのか

AgentCore は各エージェントをコンテナとしてパッケージ化し、セッションごとの Firecracker MicroVMで実行します。Zenity のシリーズ最初の投稿は、Strands SDK（AWS のオープンソースエージェントフレームワークで、組み込みの HTTP リクエストツールとシェルツールを備えています）で構築されたテストエージェントへの平易な言葉のリクエストによって、足がかり全体を再現しています。microVM はメタデータサービスへのトラフィックを制限していなかったため、リクエストはインスタンス内部から発信され、IMDS が応答しました。その後、研究者たちはエンドポイントを辿りました。IAM ロール名、一時的な STS 認証情報そのもの、ユーザーデータエンドポイント — これはアカウント ID、完全な ARN、ランタイム URL、そしてエージェントの Amazon Elastic Container Registry (ECR) イメージ URI — そしてインスタンスタグには、mTLS 証明書チェーン、秘密鍵、内部ストレージへの事前署名済み URL が含まれていました。Zenity によれば、シェルツールを通じても同じ結果が得られました。なぜなら、分離の失敗はプラットフォームレベルにあり、特定のツールにあるのではないからです。

その一連の流れの中には、つい読み飛ばしてしまいやすい細部が二つある。認証情報はサンドボックス内にとどまっていなかった。ZenityはそれらをAgentCoreの外へ持ち出し、AWSのID呼び出しを実行したところ、エージェントが引き受けたロールとして返ってきた。そして盗まれたロールはコンテナイメージを取得でき、それによってエージェントのソースコードが読めるようになった。Zenityの投稿は、イメージにはハードコードされたキー、残存トークン、本来焼き込まれるべきではなかった設定が日常的に含まれていること、そして取得されたイメージは基盤となるビジネスロジックの地図であると指摘している。

デフォルトロールは、足掛かりがアカウントになるところです

別途報告された2つ目の欠陥は、AgentCoreがデフォルトでエージェントに付与した実行ロールが単一のエージェントにスコープされていなかったことです。Zenityは、権限がアカウントおよびリージョン内のすべてのAgentCoreリソースに及んでいると説明しており、その対象にはbedrock-agentcore:InvokeAgentRuntime、bedrock-agentcore:ListEvents、bedrock-agentcore:CreateEvent、bedrock-agentcore:DeleteEvent、そして認証情報チェーンの末端ではbedrock-agentcore:GetResourceApiKeyとsecretsmanager:GetSecretValueが含まれます。

列挙可能性は、それらのワイルドカードをターゲットリストへと変えた。Zenityはロールの logs:DescribeLogGroups 権限を利用した。AgentCoreは各エージェントのCloudWatchロググループを /aws/bedrock-agentcore/runtimes/{AGENT_ID}-{ENDPOINT_NAME} と命名しており、それらのロググループ名からエージェントIDを導き出せたからだ。ECRリポジトリ名は研究者たちが観察した命名規則 — bedrock-agentcore-<agent_name> — に従っていたため、そのリージョン内のあらゆるエージェントのイメージをプルできた。メモリリソースも同じ方法で、ロググループのパターン /aws/vendedlogs/bedrock-agentcore/memory/APPLICATION_LOGS/{MEMORY_ID} から特定され、ロールの ListActors、ListSessions、ListEvents 権限によって、会話内容を読み取るのに必要なアクター識別子とセッション識別子が得られた。

Zenityの記事は、具体的な横方向の移動のデモンストレーションを示している。公開向けエージェントを通じて侵入し、あるエージェントのツールを発見する：billing_agentは同じリージョンにあり、ファイルを見つけ、そのファイルの名前はbilling.jsonで、ファイル読み取りツールを通じてそれを持ち出す。プレスリリースは同じシナリオを一般的な言葉で述べている — インターネットに面したカスタマーサービスエージェントを通じて侵入した攻撃者は、同じリージョンにデプロイされた内部の財務エージェントに移動し、それを呼び出し、そのデータ、ツール、関連する資格情報、プライベートな会話に到達できる可能性がある。

記憶は、プロンプトより長く生き残った部分だった

AgentCore Memory は会話自体を短期メモリとして保持し、抽出されたレコードを長期メモリとして保存します。その際に使用するストラテジーは SEMANTIC、USER_PREFERENCE、SUMMARIZATION と EPISODICです。Zenity は CreateEvent を使用して、会話イベントを他のエージェントのメモリリソースに書き込みました。その投稿では、このプリミティブにできることとできないことについて注意深く述べています。CreateEvent では、呼び出し元が長期名前空間を選択したり、レコードを直接上書きしたりすることはできません — 抽出される内容とその保存先は、対象メモリに設定されたストラテジーによって決まります。Zenity はまた、DeleteEvent が、ツール結果イベントを削除してエージェントが欠落データから誤った結論を導くようにするため、およびメモリを植え付けたイベントを削除して痕跡を消すために使用されることについても述べています。

書き込みプリミティブが生み出したのは永続性だった。Zenityのデモンストレーションでは、エージェントが回答する前に研究者が管理するページを取得し、そのページの内容に従うようリクエストを植え付けた。それはcommand-and-controlエンドポイントであり、別のメモリを植え付けることなく指示を変更できるものだった。同じチャネルはその後、会話内容を外部に持ち出した。記事は、エージェントがユーザーのメッセージと自身の返信を収集エンドポイントに送信したこと、そしてそのロールのメモリ権限が侵害されたエージェントだけではなくアカウントとリージョン全体に広がっていたことを述べている。研究とともに公開されたビデオでは、その内容が研究者のサーバーに到着する間もユーザーが会話を続けている様子が示されている。

AWS 以外の認証情報

シリーズ最後の記事では、接続されたツールについての話を締めくくります。AgentCore Identity と Outbound Auth は、ツールの認証情報をシークレットとして AWS Secrets Manager に保存します。その名前は、プロバイダー名と bedrock-agentcore-identity!default/apikey/{provider_name} のような固定パターンから組み立てられます。Zenity は、すでに ECR から取得していたエージェントのソースコードをスクレイピングしてプロバイダー名を回収し、その他の名前はブルートフォースで回収しました。同社によると、既定の5文字のサフィックスは数字と小文字からクライアント側で生成されるため、2種類のプロバイダー全体で 2 x (10+26)^5 = 120,932,352 通りの組み合わせになります。Secrets Manager に対して維持できたリクエストレートでは、完全な列挙に数時間かかると Zenity は述べており、これは STS 認証情報の有効期間よりも長いため、古い認証情報が期限切れになるたびにエージェントの IMDS エンドポイントへ再クエリして新しい認証情報を取得するループを組みました。さらに Zenity は、メタデータの user-data エンドポイントを通じて環境変数が読み取り可能で、すべての名前の先頭に CONTAINER_ENV_ が付いており、エージェントがモデルプロバイダーへの認証に使うキーも含まれていたこと、そして発見した各エージェントを適切なプロンプトで呼び出すことで、それらの値を大規模に収集できたことを付け加えています。

確立されたが、技術的な問題で異議が唱えられている

立証されているのは、限定的かつ具体的な点だ。AgentCore のエージェントは IMDS に到達し、自身の実行ロールの一時的な認証情報を受け取ることができた——AWS はこれを否定しておらず、声明で「文書化されており想定内」と述べている。デフォルトの実行ロールは、単一のエージェントではなくアカウントとリージョンにスコープされた権限を備えていた。AWS はその後これを変更し、Zenity は自社のテストでその縮小が確認されたと述べている。この研究は実証であり、観測された攻撃キャンペーンではない。Sharbat は Dark Reading に対し、修正前にこの欠陥が実際に悪用された証拠は Zenity では見られなかったと語り、その一因として、どの組織が AgentCore 上でエージェントを実行しているかを特定する難しさを挙げ、さらに「それをやる方法があることは100%確信している」と付け加えた。

争点となっているのは、そのいずれかを脆弱性と呼ぶべきかどうかである。Dark ReadingとThe Next Webに寄せられたAWSの声明は次の通りだ。「AWSは、Amazon Bedrock AgentCoreに関して公表された研究を把握している。それは、想定され文書化された挙動を脆弱性として不正確に描き出している。エージェントが別のAWSアカウント内のリソースにアクセスできるのは、開発者がエージェントの実行ロールと対象リソースの双方で権限を明示的に付与した場合に限られる」。Zenity自身の投稿に引用されたAWSの声明は、最初の文の趣旨——「記述されている挙動は文書化されており想定内である」——を保ったうえで、顧客は実行ロールにエージェントが必要とする権限のみを付与すべきだと付け加えている。この見解の相違の背景には二つの点がある。AWSは境界を別のAWSアカウント内のリソースへのアクセスという観点で捉えているのに対し、Zenityの発見は単一のAWSアカウントおよびリージョン内のエージェントに関するものであること。そして、Zenityが説明するロールは、顧客が手作業でポリシーを書いたものではなく、プラットフォームのデフォルトに由来するものだということである。

The Next Webが自社記事に加えた訂正は記録に値する。なぜなら、研究者以外の誰かによってその主張がより厳密なものにされたことを示しているからだ。同メディアは当初、研究者があるリージョン内のすべてのAgentCoreエージェントを乗っ取ったとする見出しを報じ、後に訂正した。訂正版では、調査が単一のAWSアカウントとリージョン内のエージェントを対象としていたと述べられ、以前の見出しが研究者の主張を事実として記していたことも指摘されている。

開示タイムライン

Zenityは1件ではなく2件の報告を行い、それぞれ異なる回答を得た。IMDSアクセスに関する報告は2025年12月25日に提出され、AWSは2026年4月12日に「informative」としてこれをクローズし、AgentCoreがIMDSv2を使用していたのは2026年2月14日以降のみで、新たにデプロイされたエージェントはその方式で起動していると記した。この改訂は本研究の細部にとって重要である。なぜならIMDSv2はリクエストごとにセッショントークンを必要とし、研究者が認証情報を取得するために用いた単純な未認証フェッチを成立させなくするからだ。デフォルトロールとその影響範囲に関する2件目の報告は2026年1月12日に提出された。AWSは2026年2月25日にZenityに対し、チームが対応を進めている一方でロールはそのままの状態だと伝えた。Zenityは2026年6月22日にロールを再確認し、その権限が変わっていないことを発見した。2026年9月29日の最終確認ではロールが大幅に縮小されていることが判明し、Zenityのプレスリリースは、削除の対象が他のエージェントの呼び出し、プライベートな会話の読み取り、AWS Secrets Manager内のシークレットへのアクセスに及び、他の権限も同様に大幅に制限されたと述べている。Zenity自身の投稿は、AWSがその後AgentCoreのデプロイでIMDSv2をデフォルトにしたこと、そして両者がその過程を通じて協力したことを指摘している。

何が知られていないのか

Zenityは、2月のIMDSv2変更から9月下旬の範囲縮小までの期間に、何体のエージェントまたは何組織がデフォルトロールで稼働していたかを公表していない。また、引用された情報源のどこにも、研究者自身の環境の外に顧客データが露出したとは述べられていない。Zenityが報じたAWSによれば、IMDSv2の変更は2026年2月14日以降にデプロイされたエージェントに適用される。その日付より前にデプロイされたエージェントにとってそれが何を意味するかは、ここで検討した情報源には記載されていない。アーカイブには実際の害は記録されておらず、情報源は、デモンストレーションを描写し、AWSが自らインシデントを報告するのではなく脆弱性というレッテルに異議を唱えていることによって、その解釈を裏付けている。

Sharbat氏はDark Readingに対し、Zenityは現在、同様のメタデータアクセス問題がないか他のクラウドプラットフォームも調査しており、まだそれらの名前は明かしていないと語った。同氏が示した要点は、メタデータサービス単体ではなく権限に関するものだ。「たとえ誰かがIMDSに到達したとしても、影響範囲はかなり小さくなるだろう」という。

この記録が保存される理由

AgentCorruptionが注目に値するのは、メタデータエンドポイントが新しい着想だからではない。SharbatはSecTorの聴衆に2019年のCapital One侵害を挙げ、そこではSSRFがIMDSに到達して認証情報の窃取につながったと述べ、それを同種の最小権限の失敗として説明した。新しいのは、その取得を行った主体である。AWSのアイデンティティを生み出したリクエストを行ったのは、AIエージェントだった。それは、役に立てるように与えられたツールを通じて、平易な言葉で頼まれたとおりのことを行い、エージェントはその答えをそのまま返した。それをアカウント全体の問題に変えた2つの条件は、サンドボックスがブロックしなかったメタデータエンドポイントと、それを保持していたエージェントの権限よりも広いデフォルトロールだった。

5部構成の技術シリーズとデモンストレーション動画を含む完全な調査研究は、2026年10月8日付のZenityのプレスリリースからリンクされています。この記録は、AIインシデントアーカイブに記録されたエージェントインシデントの1件です。各エントリは独自の情報源、重大度、信頼度グレード、係争フラグを備えており、これらの項目によって、ここでのようにフレーミングをめぐるベンダーとの論争を、争いのある危害の認定と区別することが可能になります。

これは1件の記録であり、他者によって調査・報告され、ここではその出典として彼らに帰されている。他の文書化されたエージェント・インシデントは、それぞれ独自の情報源、深刻度、信頼度グレード、異議ありフラグを備えたうえで、AIインシデント・アーカイブに収められている——そうすれば、1つのプロンプトをアカウント全体の足掛かりに変えてしまうプラットフォームのデフォルト設定を、他の場所で実際に起きたことと並べて読むことができる。