IMDSとは何か、なぜその認証情報を得ることが深刻なのか？
IMDS（Instance Metadata Service）は、クラウドのインスタンスが自分自身の情報を問い合わせる内部アドレスで、インスタンスに付与された実行ロールの一時認証情報も含む。インスタンスに169.254.169.254へリクエストさせ結果を持ち出せれば、そのロールの権限を手にしたも同然で、この認証情報はインスタンスの外でも使える。
IMDSv2はリクエストごとにセッショントークンを要求して最も単純なSSRF経路を塞ぐが、認証情報自体の権限の大きさは変えない。被害を最終的に決めるのは、そのロールに何が与えられていたかだ。
AWSは「想定された動作」と言い、Zenityはなぜ脆弱性だと主張し続けるのか？
AWSの立場は、権限モデルは設計上開発者が制御するもので、エージェントが他のリソースに届くには実行ロールと対象リソースの両側で明示的な許可が必要というものだ。Zenityの立場は、デフォルトで付くロールがすでにリージョン内のAgentCoreリソース全体に及び、多くの開発者はデフォルトを変えないので、デフォルトが実質的な安全水準だというものだ。
どちらにも筋があり、争点は「デフォルトの責任は誰にあるか」だ。開発者にとっての実用的な結論は1つで、デフォルトロールが最小権限だと思い込まないことだ。
メモリインジェクションのバックドアは、一回限りのプロンプトインジェクションよりなぜ危険なのか？
一回限りのプロンプトインジェクションは、その会話にしか影響しない。この事例では、研究者が偽造イベントを恒久的なユーザー指示として保存させ、内容は「毎回の回答前に特定のページを訪れてその内容に従う」だった。指示が外部ページを指すため、攻撃者は後でページを書き換えるだけで、エージェントのメモリに触れずに挙動を変えられる。
防御の焦点は長期メモリへの書き込みの管理だ。どの出所から、どんな検査を経れば、将来の全回答を左右する指示として保存してよいのかを決める。
AgentCoreを使っていないが、気にするべきか？
すべきだ。このチェーンの核心はAgentCore固有の機能ではなく、3つの一般的な条件が同時に成り立つことだ。エージェントがネットワークリクエストを送れるツールを持つこと、実行環境がメタデータアドレスを遮断しないこと、実行ロールの権限が広すぎること。この3つが揃うクラウドや自前環境なら、同様のリスクがある。Zenityも他のクラウドを評価中だと述べている。
最も安い自己点検は、各エージェントのツール一覧とロール権限を並べ、「外向きリクエストを送れる」と「ロールが多くを読める」の組み合わせがないか探すことだ。
2026年10月8日、Zenity LabsはSecTor 2026でAWS Bedrock AgentCoreに対する脆弱性チェーン「AgentCorruption」を公開した。Zenityの主張は、公開されたAgentCoreエージェントに1つのプロンプトを送るだけで、同じAWSアカウント・リージョン内の他のエージェントまで到達できるというものだ。AWSの反応は、「想定された文書化済みの動作」を脆弱性として描いているというものだった。このチェーンの各段階は、開発者が自分のエージェント展開で繰り返している可能性があるため、両方の主張を読む価値がある。
第1段階、入口は普通の公開エージェント。研究者はStrands SDKで構築し、組み込みのhttp_requestまたはshellツールを有効にしたエージェントを使った。攻撃者は自然言語で特定のアドレスへのリクエストを頼むだけだ。ZenityはこれをSSRFと位置づけ、「隔離の失敗はツール層ではなくプラットフォーム層にある」と強調する。外向き通信を生成できるツールなら結果は同じになる。
第2段階、IMDSへの到達。エージェント実行のたびにFirecracker microVMが起動するが、microVMはメタデータサービス（169.254.169.254）への通信を遮断しない。エージェントは実行ロールの一時STS認証情報（アクセスキー、シークレットキー、セッショントークン）を返し、研究者はAgentCoreの外でそれを使い、sts get-caller-identityで有効性を確認した。
第3段階、デフォルト実行ロールの過剰な権限。ZenityはAgentCoreがデフォルトで付与するロールを「ひどく過剰権限」だと指摘する。logs:DescribeLogGroupsでリージョン内の全エージェントのIDと名前が列挙でき、ECRイメージアクセスのリソースがrepository/*のため、アカウント・リージョン内の任意のイメージを取得できる。ソースコード、依存パッケージ、残存するハードコードされた鍵が含まれうる。
第4段階、他エージェントの読み取りと呼び出し。The Next Webのまとめによれば、同じロールで研究者は全エージェントの一覧取得、各エージェントのコンテナイメージとソースのダウンロード、到達すべきでない内部エージェントの呼び出し、ユーザーとエージェントの非公開会話の読み取り、Secrets ManagerのAPIキー（AWS外のサービス用の認証情報を含む）の取得ができた。
第5段階、メモリインジェクションによるバックドア。研究者はエージェントの長期メモリに書き込み、偽造した会話イベントを恒久的なユーザー指示として保存させた。毎回の回答前に攻撃者が管理するウェブページを訪れ、その内容に従えという指示だ。以後はそのページを書き換えるだけで、新たなメモリなしにいつでも挙動を変えられる。Zenityのデモでは、ユーザーは普通にチャットしているのに会話が研究者のサーバーに送られた。ただし、このメモリインジェクションが他のエージェントへ自動的に広がることは公開情報では確認されておらず、Zenityも修正前に実際の悪用の証拠は見つからなかったと述べている。
AWSの声明は「想定された文書化済みの動作を脆弱性として不正確に描いている」というもので、エージェントが他のリソースにアクセスできるのは、開発者が実行ロールと対象リソースの両側で明示的に許可した場合のみだとし、エージェントが必要とする権限だけを実行ロールに与えるよう勧めている。Zenityはデフォルトロールの範囲そのものが問題だと主張する。時系列では、Zenityは2025年12月末にIMDSの問題を、2026年1月にデフォルトロールの過剰権限を報告。AWSは2026年2月14日から新規デプロイのAgentCoreエージェントはIMDSv2のみで起動すると述べ、4月に最初の報告を「informative」でクローズした。Zenityは6月時点でデフォルトロールは未変更だったとし、9月29日の公開前最終確認で権限が縮小され、エージェント間呼び出し、非公開会話の読み取り、Secrets Managerへのアクセスが削除されていたと述べる。既存エージェントがIMDSv2に移行済みかどうかは公開報道では不明だ。
Zenityの研究者Tamir Ishay Sharbatは2019年のCapital One侵害を例に挙げた。これもEC2のIMDSに対するSSRFで認証情報を得たもので、根本原因は最小権限の欠如だった。彼の言葉では、誰かがIMDSに到達しても影響範囲ははるかに小さくなる。クラウドでエージェントを動かす誰にとってもこのチェーンが参考になるのは、エージェントのツールが「外向きリクエストの送信」を自然言語で駆動できるものにし、SSRFの入口をエージェントと会話できる誰にでも渡してしまうからだ。
AgentCoreや他のマネージドクラウド上で公開エージェントを運用しているなら、ベンダーの次のパッチを待つより実践的な対応がある。各エージェントの実行ロールを点検し、repository/*のようなワイルドカードのリソースを明示的なものに置き換え、ログ・ECR・Secrets Managerの権限が本当に必要か確認する。既存エージェント（新規デプロイだけでなく）にIMDSv2が強制され、169.254.169.254への外向き通信が制限されているか確認する。公開エージェントではshellや任意のHTTPリクエストツールを有効にしない。鍵や.envファイルをコンテナイメージの外に出す。長期メモリへの書き込み経路を見直し、1つの会話イベントが恒久的な指示にならないようにする。攻撃者はいずれIMDSに到達すると想定し、認証情報を得ても何もできないに近い状態を目指すべきだ。