単一プロンプトで横展開──Bedrock AgentCoreの設計連鎖が開けた「同一アカウント内ハイジャック」のリアリティです

今日の深掘りポイント

• 事象の核心は、HTTP/シェル系ツールを持つAIエージェントが、メタデータに触れられる設計と過剰な実行ロールが直結していた点です。プロンプト1発で一時クレデンシャルを引き出し、同一アカウント・同一リージョンで横展開できる導線が露出していました。
• 被害は会話ログの露出や「メモリ」汚染、さらに接続サービスの認証情報窃取まで及ぶため、生成AIの利用境界がクラウド・コントロールプレーンに食い込む構造リスクが現実化しています。
• 研究者報告では新規デプロイでIMDSv2のみの動作が導入とされますが、過剰権限のロールが温存される限り、根の深い問題は解けません。権限分離とロールの粒度最適化が決定打です。
• 現場対応は、最小権限の再設計（エージェント単位の実行ロールとABAC）、SCPの明示的Denyでの横展開封じ、旧エージェントの再デプロイ、会話・メモリのデータ境界再確認、CloudTrailの行動分析強化が軸です。
• メトリクス上は即応性・実務適用性が高い一方、状況の楽観余地は乏しいシグナルです。CISOには「早く、小さく、確実に権限を絞る」ガバナンス判断が求められます。

はじめに

生成AIの俊敏さは、いまやアプリケーション境界の外側──クラウドの制御平面にまで拡張されつつあります。今回の事案は、プロンプトという一見“アプリ内の入力”が、実はAWSの認可境界にまで波及することを示唆する出来事です。モデルの賢さより、ツールの持ち物検査とIAMの切れ味がセキュリティの決定因になる、という当たり前でいて忘れがちな原則が改めて突きつけられたと言えます。

研究者の報告によれば、AWS BedrockのAgentCoreにおける設計連鎖により、HTTPやシェル実行ツールを備えたエージェントがローカルメタデータエンドポイントに誘導され、一時クレデンシャルを抽出。これを足掛かりに、同一アカウント・同一リージョン内の他エージェントや接続サービスへ横展開が可能だったとされます。会話ログの露出、メモリ（永続ストア）の汚染、接続先の認証情報窃取までつながる点が特に深刻です。新規デプロイではIMDSv2が必須化されたとの指摘もありますが、これは扉の堅牢化に過ぎず、扉の向こうに広がる権限の倉庫が過積載であれば、依然として被害半径は大きいままです。

出典は研究者の一次報告とされる記事のみのため、ベンダー公式アドバイザリ等の追加確認は引き続き必要です。現段階では、クラウドIAMの運用知とAIエージェントの機能制御をどう融合させるかが実務の焦点になります。

参考: AWS Bedrock AgentCore flaw allowed attackers to hijack AI agents within same account and region（GBHackers）

深掘り詳細

事実整理（研究者報告に基づくポイント）

• 攻撃の起点は、エージェントに備わるHTTP/シェル実行ツールです。単一の悪意あるプロンプトで、ローカルメタデータエンドポイント（IMDS）へのアクセスを実行し、エージェントの実行ロールに紐づく一時クレデンシャルを取得できたと報告されています。
• この一時クレデンシャルに過剰な権限が付与されている場合、同一アカウント・同一リージョン内の他エージェントや、当該エージェントが連携するAWSサービス（S3、DynamoDB、Secrets Manager等が典型）へ横展開が可能になります。
• 影響は、(1) 会話履歴・実行履歴の露出、(2) エージェントメモリの汚染（将来の応答歪み）、(3) 連携先の認証情報窃取やデータ持ち出しに及ぶと指摘されています。
• 研究者記事は、新規にデプロイされたエージェントではIMDSv2のみの動作が導入された旨にも言及しています。ただし、既存エージェントやロール設計の過剰権限に手当がなければ、根源的なリスクは残存します。

出典: GBHackersの報道

編集部のインサイト（仮説と実務視点）

• これは「LLMが騙された」話ではなく、「ツールとIAMが結び付いた瞬間に、プロンプトが制御平面へ伸びる」設計問題です。プロンプトはトリガーに過ぎず、本丸は“その先に何ができる権限を握らせていたか”です。
• 多くの現場では、複数エージェントで実行ロールを共有しがちです。そこにbedrockや横断的なデータサービスへの広い許可が紛れ込むと、同一アカウント内の“水平感染”が現実になります。権限の共有は、運用効率のためのショートカットでありつつ、攻撃者にとっては最短ルートです。
• IMDSv2は確かに改善ですが、IMDS自体が悪いのではなく、IMDSが露出している実行環境に“過大な権限”を与えることが問題です。Hop limitやトークン要求で偶発的な踏み台化は抑えられても、適用外の既存環境や設計上の権限過多は残ります。
• 検知の難所は、メタデータ呼び出し自体がCloudTrailに載らない点です。その後のAPI行動（列挙、横展開、データ取得）で“振る舞い”を捉える以外にありません。ロール単位の行動ベースベースラインと、想定外サービス呼び出しの即時検知が肝心です。
• 会話・メモリは“個人データや商業秘密の集積所”になりやすく、AI規制や業界監督（内部統制・監査）との整合が問われます。生成AIの安全運用能力は、各国規制対応力と事業継続性の評価指標になりつつあります。セキュリティは単なるコストではなく、競争力の基盤です。

脅威シナリオと影響

以下は、MITRE ATT&CKフレームに沿った仮説シナリオです。実際の挙動は各環境で異なるため、あくまで防御設計の叩き台としてご覧ください。

• シナリオA：プロンプト誘導によるメタデータ経由の横展開

  1. 初期侵入（仮説）: ユーザ入力や外部コンテンツに仕込んだ指示で、エージェントのHTTP/シェルツールを起動させる
  2. 資格情報取得: IMDSから一時クレデンシャルを抽出
     • 対応ATT&CK: T1552.005（Cloud Instance Metadata API）
  3. 認証済み横移動: 取得したクレデンシャルで同一アカウント内の他エージェントやサービスへアクセス
     • 対応ATT&CK: T1078（Valid Accounts）、T1526（Cloud Service Discovery）
  4. 収集と持ち出し: 会話ログやメモリ、接続先データを列挙・取得し、外部へ持ち出し
     • 対応ATT&CK: T1567（Exfiltration Over Web Service）

• シナリオB：ツール連携を踏み台にした権限拡大

  1. エージェントが接続するツール（関数呼び出し、HTTPクライアント）を悪用
  2. 過剰権限のロールでbedrockやデータ系サービスの列挙・設定読み取り
     • 対応ATT&CK: T1526（Cloud Service Discovery）
  3. アカウント操作の試行（権限があれば）
     • 対応ATT&CK: T1098（Account Manipulation）

• シナリオC：メモリ汚染による持続的影響

  1. メモリストアに悪性データを混入
  2. 後続の会話で誤誘導やデータ漏えいを誘発（持続的な影響）
     • ATT&CK上の明確な一技法へは直結しにくいものの、Collection/Impactの境界で評価対象です（仮説）。

参考（MITRE ATT&CK）:

• T1552.005 Cloud Instance Metadata API
• T1078 Valid Accounts
• T1526 Cloud Service Discovery
• T1098 Account Manipulation
• T1567 Exfiltration Over Web Service

影響評価の勘所は三つです。第一に、横展開の半径は“アカウント境界の中でどこまで共有権限が伸びているか”で決まります。第二に、被害の深刻さは“会話とメモリの機微度”に依存します。第三に、検知難易度は“ロールごとの通常行動をどれだけ精緻に学習・監視できているか”で変わります。メトリクスが示す通り、いま取れる現実的な対処は多く、優先度は高い一方で、全体感としては楽観できない局面です。素早い権限削減と分離設計への舵切りが、組織のレジリエンスを左右します。

セキュリティ担当者のアクション

今日から着手できる現実解を、優先度順にまとめます。

• インベントリと棚卸し（48時間以内）

  • すべてのBedrockエージェントと実行ロール、接続ツール（HTTP/シェル、外部コネクタ）を洗い出します。共有ロールの有無、bedrock系APIやデータ系サービスへの広範許可を特定します。
  • 研究者報告にあるとおり、新規デプロイでIMDSv2限定が導入されている可能性があります。既存エージェントは再デプロイ（ローリング）を計画し、同時にロール最小化を適用します（仮説を明示します）。
  • 会話ログ、メモリ（永続ストア）の保管先とアクセス制御を確認し、プロジェクト／エージェント単位で境界が分かれているかを点検します。

• 最小権限の再設計（1〜2週間）

  • エージェント単位で一意の実行ロールを割り当て、bedrockやデータストアの権限はリソースレベルで限定します。タグベース（ABAC）でエージェントIDや環境タグによりアクセスを縛ることを推奨します。
  • 組織単位ではSCPで明示的Denyを活用し、bedrockの列挙・他エージェント参照、不要なiam:PassRole、過度な*通し権限をブロックします。sts:AssumeRoleはSourceArn/SourceAccount/CalledVia条件で厳格化します。
  • 可能ならHTTP/シェル系ツールは原則無効化し、必要最小の許可先のみを通すプロキシ（エグレス制御）で囲い込みます。169.254.169.254宛の到達は環境次第で遮断困難ですが、少なくとも自社管理のツール実行環境（例：LambdaやECSで実装するアクショングルー）ではIMDS不要を徹底します。

• ログと検知の強化（即時〜継続）

  • CloudTrailで「エージェント実行ロール」を主体にした行動基準線を作り、以下の逸脱を高優先度検知にします。
    • bedrock系APIの列挙・他エージェント参照の試行
    • データ系（S3/DynamoDB/Secrets Manager等）への想定外のアクセスパターン
    • IAM/STS周りの列挙・AssumeRoleの試行や成功
  • メタデータ呼び出し自体は記録されないため、後続APIの“連続性”と“広がり”で兆候を掴みます。GetCallerIdentity→横断的List/Get→データ取得→外部送信というシーケンスをルール化します。
  • 役割の異なる環境（開発・検証・本番）間でのロール誤用を異常として扱い、アラート疲れを回避しつつ高優先度化します。

• 会話とメモリのデータガバナンス（並行）

  • 会話ログとメモリは機微情報として分類し、保存期間・暗号化・アクセスレビューを厳格化します。エージェント間でのメモリ共有は廃し、必ず境界を切ります。
  • 既存のメモリ汚染の可能性をゼロトラストで評価し、検体抽出・検証・クリーンリビルドを計画します。

• レジリエンスと運用（1ヶ月以内）

  • インシデント対応手順に「エージェント横展開」を追加し、(a) 実行ロールの即時境界縮小・分離、(b) 影響範囲（他エージェント・接続サービス）の機械的列挙、(c) メモリ／会話の一時凍結と検証、を自動化します。
  • レッドチーム／パープルチームで“プロンプト→IMDS→クラウドAPI”の疑似攻撃シナリオを回し、防御線（権限・検知・運用）の穴を測定します。モデルガードレールは補助輪であり、最後はIAMとネットワーク境界が決め手です。

• 経営・法務・調達への橋渡し（継続）

  • 生成AIの安全運用は、規制・監査・顧客信頼の要です。AI導入の採算評価には、エージェント分離と権限最小化の運用コストを初期から内数化します。
  • ベンダー側の更新（IMDSv2化や権限テンプレート修正等）は継続監視し、既存環境の再デプロイ判断をためらわない文化を育てます。

最後にひと言です。今回の教訓はシンプルで、だからこそ難しいです。“賢いAI”を“安全なAI”にするのは、モデルの才覚ではなく、我々の権限設計と分離の根気です。地味なひと手間の積み重ねが、最悪の一手（単一プロンプトの横展開）を無力化します。次の四半期レビューで、エージェント単位ロールの完全分離をKPIに上げてください。その一歩が、事業の足腰を確かにします。