2026年10月8日、セキュリティ企業Zenityの研究チーム（Zenity Labs）が、AWSのAIエージェント基盤「Amazon Bedrock AgentCore」についての研究報告「AgentCorruption」を公開しました。
最初に大事なことを書いておくと、Zenity Labsは報告の中で「ブログで説明したセキュリティ上の問題は、すべてAWSのセキュリティチームによって修正済み」と書いています。つまり、今まさに対策がないまま放置されている問題ではありません。
ただし、修正前に作ったエージェントや、権限を広めに設定した実行ロールを使い続けている場合は、自分の設定を見直すきっかけになります。この記事では、AgentCoreのかんたんな説明と、報告の概要、そして開発者が確認しておきたいポイントをまとめます。
Amazon Bedrock AgentCoreとは
Amazon Bedrock AgentCoreは、AIエージェントをAWS上で動かし、運用するためのマネージドサービスです。エージェントの実行環境（AgentCore Runtime）、外部ツールとつなぐしくみ（Gateway）、認証情報の管理（Identity）、会話の記憶（Memory）などがまとまっています。
AgentCore Runtimeで動くエージェントは、microVM（小さな仮想マシン）の中で動きます。エージェントがS3などのAWSのサービスを使うときは、「実行ロール」というIAMロールの一時的な認証情報を使います。
実行ロールとメタデータサービス（MMDS）
AWSの公式ドキュメント「Credentials Management」によると、AgentCoreの実行環境は、EC2でいうIMDS（インスタンスメタデータサービス）に似た「MMDS（MicroVM Metadata Service）」から認証情報を受け取ります。
同じドキュメントでは、重要な注意として「VMの中で動くコードや実行者は、メタデータのエンドポイントを呼ぶことでこの認証情報にアクセスできる」と書かれています。つまり、エージェントの中で動くものは、実行ロールの権限をそのまま使える、ということです。
AgentCorruptionの報告の概要
Zenity Labsの報告は、おおまかに次の2点を指摘したものです。
1. プロンプトから認証情報を取り出せた
HTTPリクエストを送れるツールを持ったエージェントに対して、プロンプトインジェクション（AIへの指示文で、本来させたくない動作をさせる手口）を使い、エージェント自身にメタデータのエンドポイントへアクセスさせることで、実行ロールの一時的な認証情報を取り出せた、という内容です。
2. 既定の実行ロールの権限が広かった
当時AgentCoreが既定で用意していた実行ロールは、そのエージェント専用に絞られておらず、同じアカウント・リージョン内のAgentCoreのリソースに広く権限を持っていた、と報告されています。報告では、ほかのエージェントの呼び出し、会話履歴の読み取り、メモリーの作成、Secrets Managerのシークレット取得などの権限が含まれていたとされています。
AWSの対応と、修正済みの内容
Zenity Labsの公開した経緯によると、次のような対応がとられています。
- 2026年2月14日時点で、AgentCoreはIMDSv2のみを使うように更新され、新しくデプロイされるエージェントはIMDSv2で起動するようになった（AWSからの回答として報告に記載）
- 2026年9月29日の公開前の確認で、既定の実行ロールから、エージェントの広い呼び出し、会話の読み取り、Secrets Managerのシークレット取得の権限が外され、ほかの権限も大きく絞られていたことを確認
また、AWSの公式ドキュメント「Security best practices for AgentCore Runtime」には、2026年6月30日以降、エージェントのランタイムはMMDSv2を有効にしている必要があり、有効でないランタイムは呼び出せない（ValidationExceptionになる）と書かれています。
AWSの見解
AWSは声明で、「説明されている動作はドキュメント化された想定どおりのもの」であり、エージェントは自分の実行ロールの認証情報にメタデータサービス経由でアクセスできる、としています。そのうえで、実行ロールにはエージェントに必要な権限だけを与えることをベストプラクティスとして推奨しています。
つまり、「エージェントが自分の認証情報を使えること」自体は仕様で、守るカギは「その認証情報にどれだけの権限を持たせるか」だということです。
開発者が見直したい古い設定
修正済みとはいえ、以前に作ったまま見直していない環境では、次の点を確認しておくと安心です。
MMDSv2が有効になっているか
公式ドキュメントでは、UpdateAgentRuntime を呼び出し、metadataConfiguration の requireMMDSV2 を true にすることで有効にできると案内されています。呼び出し時に「This runtime is not MMDSv2-enabled」というエラーが出る場合は、この設定が必要です。
実行ロールの権限を最小限にしているか
以前の既定ロールをそのまま使っていたり、作成時に広い権限（* のようなワイルドカード）をつけたりしていないかを確認しましょう。公式ドキュメントでは、次のような考え方が示されています。
- 最小権限の原則にしたがい、意図した権限だけを与える。とくにLLMは任意のコードを生成しうるので重要
- 実行ロールの権限は、そのエージェントを呼び出せるユーザーの権限と同じか、それより少なくする
- 各AgentCoreのサービスごとに、必要な権限にロールを絞る
コマンド実行の権限をしぼっているか
ベストプラクティスのドキュメントでは、InvokeAgentRuntimeCommand などのコマンド実行APIを呼べる人をIAMポリシーで限定するよう書かれています。エージェントを呼び出せる人が、全員コマンドまで実行できる必要はありません。
エージェントに持たせるツールを見直す
外部へHTTPリクエストを送れるツールやシェルを実行できるツールは便利ですが、プロンプトインジェクションと組み合わさると想定外の動きにつながります。本当に必要なツールだけを持たせ、アクセス先を制限できる場合は制限しましょう。
A2B攻撃との共通点
この報告は、以前紹介したA2B攻撃とも考え方が似ています。A2B攻撃では「公開アプリは解析されるもの」と考えてサーバー側で守ることが大事でした。AIエージェントでも、「エージェントへの入力は信用できない」と考えて、エージェントが持つ権限そのものを小さくしておくことが大事です。
ほかのセキュリティ対策については、ランサムウェア対策の記事やパスキーとは？もあわせて読んでみてください。
まとめ
- AgentCorruptionは、Zenity LabsがAmazon Bedrock AgentCoreについて公開した研究報告
- 報告された問題は、Zenity Labsによると修正済み。IMDSv2のみへの更新や、既定の実行ロールの権限の見直しがおこなわれた
- AWSは、エージェントが自分の実行ロールの認証情報を使えるのは想定どおりとし、最小権限を推奨している
- 以前に作ったエージェントは、MMDSv2の有効化と実行ロールの権限を見直しておくと安心
コメント