10月10日、Eswarが「AWS Bedrock AgentCore Flaw Allowed Attackers to Hijack AI Agents Using a Single Prompt」と題した記事を公開した。同記事が伝えるのは、AWS Bedrock AgentCoreにおいてデフォルト設定のまま運用されているエージェントが1つ侵害されると、同一AWSアカウント内の全エージェントに被害が連鎖する攻撃チェーン「AgentCorruption」だ。追加の脆弱性は不要で、必要なのはプロンプト1つだけ——AIエージェントセキュリティ専門のセキュリティ企業Zenityの研究者たちがこの事実を実証した。
攻撃の起点：たった1つのプロンプトから始まる
AIエージェント基盤の普及に伴い、エージェント自体を攻撃対象とするセキュリティリスクが現実のものになりつつある。今回のリサーチはZenity（AIエージェントおよびノーコード/ローコードプラットフォームのセキュリティを専門とするセキュリティ企業）によるものであり、その危うさを実証的に示した事例だ。
Amazon Bedrock AgentCoreはエージェントをFirecracker製マイクロVM（軽量な仮想マシン）上のコンテナとして実行する。研究者たちが着目したのは、HTTPツールやシェルツールを持つエージェントに対して、VM内部のメタデータエンドポイント（169.254.169.254）へアクセスするよう指示できるという点だ。
このリクエストはワークロード内部から発生するため、実質的にSSRF（サーバーサイドリクエストフォージェリ）の経路が生まれる。エンドポイントはエージェントの実行ロールに紐付いた一時的なAWS認証情報（アクセスキーID・シークレットアクセスキー・セッショントークン）を返す。研究者はこれを自身のマシンにエクスポートし、AWS STS（Security Token Service）で正規のID権限として確認した。
AWSのドキュメントはこの仕組みを「MMDS（MicroVM Metadata Service）」として公式に説明しており、VM内のあらゆるコードやアクターが実行ロールの認証情報を取得できると明記している。MMDSはFirecracker特有のメタデータサービスで、AWS EC2で広く知られる「IMDS（Instance Metadata Service）」に相当するものだ。
ここで補足しておくと、AWS EC2ではIMDSv2（トークンベースの認証を要求するバージョン）への移行が標準的な防御策として推奨されている。IMDSv2ではメタデータ取得の前にPUTリクエストでセッショントークンを発行する必要があり、単純なSSRFによる認証情報の窃取を困難にする。AgentCoreにおいても2026年2月14日以前は、IMDSv1相当の動作（トークンなしでの直接アクセス）が可能な状態だったとZenityは指摘している。つまり今回の問題はゼロデイではなく、設計上「想定内」とされていた動作が招いた権限過剰の帰結だ。
横展開：1エージェント侵害が全体に波及する仕組み
ここからが本題の攻撃チェーンだ。デフォルトの実行ロールには、侵害されたエージェントの範囲を超えた権限が含まれていた。
logs:DescribeLogGroupsを使って他のエージェントの識別子を特定bedrock-agentcore:InvokeAgentRuntimeで他のエージェントランタイムを直接呼び出し- Amazon ECR（コンテナレジストリ）の広範な権限により、他エージェントのコンテナイメージを取得。アプリケーションコードや埋め込みシークレットが露出するリスクがあった
さらにメモリ関連の権限も影響を広げた。
bedrock-agentcore:ListEventsでエージェントの会話履歴を列挙・閲覧- 書き込み・削除権限によるセッション改ざん。攻撃者が制御するコンテンツをエージェントの以降の判断に混入させることが可能
- 長期メモリへの書き込みによるメモリポイズニング（記憶汚染）の永続化
加えて、**bedrock-agentcore:GetResourceApiKey** および secretsmanager:GetSecretValue を用いて、接続ツール向けの認証情報まで取得できた。
AWSの対応と現在の状況
AWSは段階的に対策を講じている。
- 2026年2月14日：新規デプロイのエージェントに対してIMDSv2専用の動作を導入
- 2026年9月29日：実行ロールの権限を大幅に絞り込み。広範なエージェント呼び出し、会話アクセス、Secrets Manager取得などの権限を削除
AWSはメタデータへのアクセス自体は「ドキュメントに記載された想定内の動作」と位置づけており、クロスアカウントアクセスには明示的な認可が必要であることを強調している。一方でZenityは、「想定内の動作」であるにもかかわらずデフォルト設定が過剰な権限を付与していた点こそが問題の本質だと指摘しており、タイトルで「設計上の盲点」と表現される所以はそこにある。AWSはその上で、最小権限の原則に基づいた実行ロール設計を推奨している。
エンジニアへの示唆
AgentCorruptionが示したのは、プロンプト経由のツール実行がクラウドの権限を継承するという構造的な問題だ。AIエージェントにHTTPアクセスやシェル実行の能力を持たせる場合、その実行ロールに付与するIAMポリシーの設計が直接的なセキュリティ境界になる。
エージェントが侵害された際の「爆発半径」を最小化するために、以下のような対策が有効だ。
- IMDSv2の強制：EC2やFirecrackerベースの環境では、IMDSv2をデフォルトで有効化し、トークンなしでのメタデータアクセスを遮断する。
HttpTokens: requiredの設定がこれに相当する - エージェントごとの専用IAMロール分離：複数エージェントで実行ロールを共有すると、1つの侵害が即座に横展開の踏み台になる。各エージェントに専用ロールを割り当て、他エージェントへの
InvokeAgentRuntimeやListEventsといった権限を付与しないことが基本だ - IAMポリシーのスコープ絞り込み：
bedrock-agentcore:*のようなワイルドカード指定ではなく、当該エージェントが実際に使うアクションのみを列挙したポリシーを作成する。secretsmanager:GetSecretValueはアクセスを必要とするシークレットのARNをResourceで明示的に限定すべきだ - ログモニタリングとアラート：
logs:DescribeLogGroupsやecr:GetDownloadUrlForLayerなど、エージェントの通常業務では発生しにくい操作をAWS CloudTrailで監視し、異常なAPI呼び出しを早期に検知する体制を整えることも重要だ
AgentCorruptionのケースでは、AWSが2026年9月に権限を大幅に絞り込んだことで既存の攻撃チェーンの再現は困難になっている。しかし根本的な教訓——デフォルト設定を信頼せず、最小権限を自ら設計する——はAgentCoreに限らず、あらゆるIAM権限設計に通じる原則だ。
詳細はAWS Bedrock AgentCore Flaw Allowed Attackers to Hijack AI Agents Using a Single Promptを参照していただきたい。
