FlawOpen

flawopen.com/AI Security/agentcorruption-bedrock-agentcore-metadata-role-scope-october-2026

● FlawOpenの対応付け： CWE-918 · 編集上の深刻度： 中
セキュリティ研究 · FlawOpen

AgentCorruption：AgentCoreのメタデータとIAMのリスク

Zenityの2026年10月の調査によると、モデルの影響を受けたツールからAgentCoreランタイムのメタデータに到達でき、過去のデフォルトロールの権限がアクセス範囲を広げていました。AWSは、ランタイム自身のロール認証情報へのアクセスを想定された動作とし、最小権限を推奨しています。Zenityの調査はCVE識別子を挙げておらず、顧客侵害も立証していません。[1], [4]

💡 わかりやすい解説 (ELI5)

作業場で働くエージェントに、許可された作業用の入館証が渡されると考えてください。Zenityによると、モデルに誘導されたツールが内部の窓口にその証を求めることができ、以前の証の権限では必要以上の部屋まで開けました。AWSは、作業場の中でエージェントが自身のロール認証情報を受け取るのは想定された動作だと説明しています。実際の対策は、証が開ける扉を絞り、内部リクエストを送れるツールを管理することです。[1], [4]

主要な概念と専門用語

AgentCorruption
Amazon Bedrock AgentCoreに対する制御された調査チェーンについて、Zenity Labsが付けた名称です。ZenityはCVE識別子を挙げておらず、顧客侵害も調査で立証していません。[1], [7]
MMDSと実行ロールの認証情報
AWSの文書によると、AgentCore microVM内のコードはMMDSを介して、そのランタイムの実行ロールに対する一時認証情報を取得できます。AWSはこれを想定された動作とし、認証情報で許可される操作はロールの権限で決まります。[4], [5]
権限の影響範囲
実行ロールは、エージェントのコードがアクセスできるAWSの操作とリソースを定めます。Zenityは、過去のデフォルト権限が同一アカウント・リージョン内で広範だったと報告しています。AWSは最小権限を推奨しており、認可は操作ごとに適用されるアイデンティティポリシーとリソースポリシーに従います。AWSは特に、アカウント間アクセスではロールと対象リソースの両方に明示的な許可が必要だとしています。[3], [1], [6]
CWE-918 — 編集上の分類
このページでは、エージェントツールが内部メタデータサービスへ送るリクエストを説明する編集上の分類としてCWE-918を使用します。AWSがこのCWEを割り当てたわけではなく、メタデータへのアクセスは文書化された動作です。[8], [4], [1]

フレームワーク対応

  • FlawOpenによるMITRE CWEへの概念上の対応付けです。ベンダーやCVEレコードがこの研究デモに弱点IDを割り当てたものではありません。 CWE-918

ステップ・バイ・ステップの攻撃フロー

ステップ 1

公開エージェントに外向きツールがある

Zenityは、外部からアクセスでき、外向きリクエストを送るツールを持つAgentCoreエージェントをテストしました。この状況には、到達可能なエージェントとモデルの影響を受けるツール経路が必要であり、すべての構成に当てはまるわけではありません。[2], [1]

ステップ 2

モデルの影響がメタデータに届く

Zenityは、テスト用エージェントを誘導してローカルのメタデータサービスへリクエストさせられたと報告しています。AWSはmicroVM内のコードによるMMDS認証情報へのアクセスを文書化しています。論点は、モデルからツールへの信頼経路と認証情報の権限であり、ランタイム自身の認証情報が存在するかどうかではありません。[2], [1], [4]

ステップ 3

応答にはエージェントロールが反映される

AWSによると、MMDSは設定済み実行ロールの一時認証情報を提供します。この認証情報だけで全リソースへアクセスできるわけではなく、適用されるIAMとリソースポリシーが許可操作を決めます。アカウント間アクセスには、ロールと対象リソースの両方に明示的な許可が必要だとAWSは説明しています。[4], [6], [1]

ステップ 4

過去の権限が影響を拡大した

Zenityによると、当時のデフォルトロールは同一アカウント・リージョン内の他のAgentCoreリソースに対する操作を許可しており、ランタイム呼び出し、セッションやイベントへのアクセス、メモリ操作、シークレットへのアクセスが含まれていました。Zenityは、AWSが2026年9月29日までにデフォルトロールを大幅に制限したと報告しています。顧客管理ロールが自動で変更されたことを示すものではありません。[3], [1], [6]

ステップ 5

現在の制御は異なる境界を守る

Zenityによると、新規エージェントは2026年2月14日からMMDSv2を使用していました。AWSの現行文書では、2026年6月30日以降、ランタイム呼び出しにMMDSv2の有効化が必要です。AWSは現在もmicroVM内コードによるロール認証情報へのアクセスを説明しているため、MMDSv2は最小権限IAMやモデル影響下のツール管理に代わるものではありません。この制御の分離は情報源に基づく防御上の推論です。[5], [4], [1]

根拠と現在の範囲

境界根拠防御策
メタデータアクセスZenityはテストでのアクセスを報告し、AWSはmicroVM内コードに対するMMDS認証情報を文書化しています。エージェントのコードとモデルの影響を受けるツールを、実行ロールの認証情報を扱う主体として考えてください。
ロール権限Zenityは過去のデフォルト権限が広範だったと報告しています。AWSによると、アカウント間アクセスにはロールと対象リソースの明示的な許可が必要で、その他の操作には該当するIAM・リソースポリシーが適用されます。デプロイ済みロールとリソースポリシーを確認し、操作ごとの適用ポリシーを検証してください。プロンプトやサービスのデフォルト値から認可範囲を推測しないでください。
デフォルトロールの変更ZenityはAWSが2026年9月29日にデフォルトロールを制限したと報告しています。顧客管理ロールが自動変更されたとは述べておらず、調査はCVE識別子を挙げず、顧客侵害も立証していません。各アカウント・リージョンで実効ロールを確認し、顧客管理ロールが変更済みと仮定しないでください。
MMDSv2Zenityは新規エージェントでのMMDSv2利用を2026年2月14日としています。AWSの現行文書では、同年6月30日以降のランタイム呼び出しに有効化が必要です。AWSは引き続きVM内からの認証情報アクセスを文書化しています。MMDSv2を有効にしたうえで、ロールの操作・リソース・呼び出し元を別途制限してください。

根本原因の分析 (Root Cause)

二つの境界を分けて評価します。モデルの影響を受けるツールはランタイム内からリクエストを送ることができ、実行ロールはそのリクエストの権限を決めます。AWSはランタイム自身の認証情報へのアクセスを想定された動作とし、Zenityが報告した他エージェントへの影響は過去のロール権限範囲に依存していました。MMDSv2を有効にしてもIAM権限は狭まりませんし、ロールを制限してもモデルが誘導する内部リクエスト自体は防げません。ツールの外向き通信とIAM認可を個別に見直してください。ネットワークの外向き通信制限だけでは、microVM内のコードがMMDSへアクセスできないことの証明にはなりません。[1], [3], [4], [5]

ソースコード比較：脆弱 vs 堅牢化

説明用のIAMポリシー例であり、AWSの過去のポリシーやその後のデフォルトロール変更を示すものではありません。AWSは、ランタイム権限を具体的なリソースARNに限定し、ワイルドカードを避けるよう推奨しています。最初の記述は広いリソース指定を示し、次の記述はその権限が必要な場合に呼び出し先を承認済みランタイム一つに限定します。不要なら権限を削除してください。実際のデプロイでアクションとリソースの対応、および関連するリソースポリシーを確認してください。完全なデプロイ可能ポリシーではありません。[3], [6], [5]

脆弱な実装
{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/*"
}
堅牢化されたセキュアパッチ
{
  "Effect": "Allow",
  "Action": "bedrock-agentcore:InvokeAgentRuntime",
  "Resource": "arn:aws:bedrock-agentcore:REGION:ACCOUNT:runtime/APPROVED_RUNTIME_ID"
}

エンジニアリング＆システム堅牢化チェックリスト

参考資料

← AI Security Directory →