Zenity AgentCorruptionがAWS AgentCoreのアカウント全体を乗っ取る経路を露呈
Zenity AgentCorruptionの研究者は、悪意ある1つのプロンプトによって、公開到達可能なAmazon Bedrock AgentCoreエージェントから一時的なAWS認証情報を露出させられることを発見した。これらの認証情報により、脆弱なアカウント、リージョン、そして広範な権限を持つデフォルトロールを共有するすべてのAgentCoreランタイムへ侵入する経路が開かれたとされる。この発見は、よく知られたプロンプトインジェクションの問題を、アカウント全体に及ぶクラウドセキュリティ上の障害へと変えた。
この攻撃は、基盤モデルを破ること、無関係なAWS顧客の環境へ脱出すること、あるいは管理者パスワードを盗むことには依存していなかった。エージェントのHTTPリクエスト能力に、メタデータ認証情報と過剰なIdentity and Access Management権限を組み合わせたものだ。Zenityによれば、この連鎖はプライベートエージェント、ソースコード、会話履歴、保存済みのシークレット、長期メモリに到達した。
重要なのは、プロンプトが1つだったという見出し上の数字よりも、この組み合わせである。AWSはAgentCoreを、アイデンティティ、メモリ、ツール、可観測性、隔離されたランタイムを含め、本番エージェントを安全に運用するためのマネージドインフラとして販売していた。AgentCorruptionは、認可境界が広すぎる場合、こうした接続されたサービスが侵害された1つのエージェントをいかに増幅し得るかを示した。
ただし、重要な留保がある。Zenityは、2026年10月8日に研究を公開する数か月前に問題を開示していた。研究者らによれば、AWSは公開前にデフォルト実行ロールを制限した。一方、AWSのドキュメントは現在、より強力なメタデータ制御を求め、本番環境で広範なCLI生成ポリシーを使わないよう警告している。
この結果は、現在のすべてのAgentCoreデプロイメントが依然として完全な攻撃チェーンにさらされている証拠ではない。マネージドなエージェントインフラを最小権限の代替物として扱えないことを示す証拠である。エージェントセキュリティは今や、言語モデルの挙動、ランタイム認証情報、クラウド権限、メモリの完全性、横展開を一体として扱う必要がある。
Zenity AgentCorruptionはいかにして1つのプロンプトをAWS認証情報へ変えたのか
最初の失敗は、信頼できない言語入力と信頼されたクラウドアイデンティティの境界を越えた。
ZenityのAgentCorruption researchによると、露出したAgentCoreエージェントは、ローカルのメタデータエンドポイントへリクエストするよう指示するプロンプトを受け入れた。リクエストの対象は、AWSコンピューティング環境がワークロードメタデータと一時的なロール認証情報を提供するために使用するリンクローカルアドレス、169.254.169.254だった。
関連するサービスはInstance Metadata Serviceで、一般にIMDSと略される。AgentCoreのFirecracker microVM環境では、関連するMicroVM Metadata Service（MMDS）が、実行ロールの認証情報をワークロード内で利用可能にする。
この認証情報配布の仕組みには正当な目的がある。エージェントは、承認済みのS3オブジェクトの読み取り、別のAWSサービスの呼び出し、または業務タスクの実行に一時的な認可を必要とする場合がある。一時的な認証情報は、恒久的なアクセスキーをコードやコンテナイメージに埋め込むことも避けられる。
問題は、信頼できないプロンプトがツールにメタデータエンドポイントへ接続させられる場合に生じる。Zenityによれば、HTTP対応ツールがmicroVM内部からリクエストを送信したため、メタデータサービスはこれをローカルワークロードからのリクエストとして扱った。応答により、エージェントランタイムの一時アクセスキー、シークレットキー、セッショントークンが露出した。
これは通常SSRFと呼ばれる、サーバーサイドリクエストフォージェリのパターンである。攻撃者が直接到達できない宛先に対し、サーバー側コンポーネントからリクエストを送らせる手法だ。ここでは、エージェントのツールが外向きのHTTPリクエストを実行できたため、エージェント自体がリクエスト元になったとされる。
プロンプトインジェクションが意図を与え、HTTPツールが能力を与えた。そしてメタデータサービスがクラウドアイデンティティを提供した。これらの要素のいずれか単独では、報告された影響範囲には至らなかった。
単に安全でないテキストを生成するモデルだけでは、認証情報を盗めなかっただろう。エージェントのツールから保護されたメタデータエンドポイントであれば、この経路を止められたはずだ。実行ロールが狭い範囲に限定されていれば、認証情報窃取後であっても影響を封じ込められたはずである。
AWSは現在、この認証情報露出の特性を明示的に文書化している。credential guidanceでは、microVM内のコードやアクターがメタデータエンドポイントを呼び出し、利用可能な認証情報へアクセスできると説明している。そのためAWSは、実行ロールを各ワークロードに必要な権限のみに制限するよう顧客へ求めている。
Zenityは当初、2025年12月25日にメタデータ問題をAWSへ報告した。研究者らによると、AWSは2026年4月12日にこの報告を情報提供としてクローズした。AWSは、2026年2月14日以降に新規デプロイされたエージェントではIMDSv2を使用していたと伝えた。
IMDSv2では、クライアントがメタデータを取得する前にセッショントークンを要求する必要がある。この設計は、攻撃者が事前のトークンリクエストやそのヘッダーを常に制御できるわけではないため、多くの従来型SSRF攻撃を阻止する。
自律エージェントは、この前提を変える。エージェントが十分に柔軟なリクエストを実行できれば、トークンを取得してから認証情報を取得できる可能性がある。Zenityは、IMDSv2の要件は障壁を高めたものの、根底にある信頼の問題を解消しなかったと主張している。
AWSは後に、任意導入を超える対応へ移った。現在のランタイムガイダンスでは、MMDSv2が有効化されていないAgentCoreランタイムは、2026年6月30日以降拒否されているとされる。この制御はベースラインを改善するが、正当なランタイムコードが依然アクセスできる認証情報に過剰な権限を付与することを正当化するものではない。
本質的な教訓はアーキテクチャにある。エージェントが自然言語の指示を特権的なネットワークおよびアイデンティティ操作へ変換できるとき、プロンプトインジェクションはクラウド侵害になる。悪意ある文をフィルタリングするだけでは、その経路の一層にしか対処できない。
デフォルトロールが1つのエージェントを全員の問題にした
盗まれた認証情報がアカウント全体に及ぶ足掛かりとなったのは、検証された実行ロールが、同じリージョン内の他のエージェントに対する広範なアクセスを1つのエージェントに委ねていたためである。
Zenityは2026年1月12日、初期侵害の背後にある権限に焦点を当てた2件目の報告を提出した。研究者らによれば、デフォルトロールは、それを引き受けたランタイムに限定されていなかった。複数の権限が、同じAWSアカウントおよびリージョン全体のAgentCoreリソースに適用されていた。
最初の拡張段階ではCloudWatch Logsが使われた。Zenityによると、logs:DescribeLogGroupsにより、侵害されたアイデンティティはリージョン内のロググループ名を列挙できた。AgentCoreの命名規則により、ランタイムおよびメモリリソースの識別子がそれらの名前に露出していた。
攻撃者は、既存のプライベートエージェント一覧を必要としなかった。ロールからすでに見えていた運用メタデータから、ランタイム識別子を導出できたとされる。探索により、盗まれたアイデンティティはローカルな足掛かりから、近隣リソースの地図へと変わった。
このロールには、Amazon Elastic Container Registryに対するリージョン全体の権限も含まれていた。Zenityは、予測可能なリポジトリ命名により、研究者がAgentCoreランタイムとコンテナイメージを関連付けられたとしている。これらのイメージを取得すると、アプリケーションコードと、デプロイ済みアーティファクトに埋め込まれている可能性のある機密設定が露出した。
この発見は、マネージドランタイムに関する一般的な前提に疑問を投げかける。microVMは実行中の1セッションを別のセッションから隔離できる一方で、IAMはそのセッションに無関係なリソースの取得を依然として認可し得る。コンピューティングの隔離と認可の隔離は、異なる問題を解決する。
次に登場したのがbedrock-agentcore:InvokeAgentRuntimeだった。Zenityのrole analysisによると、検証されたポリシーはリージョン内のワイルドカード指定されたランタイムリソースを対象としていた。そのため盗まれた認証情報は、外部ユーザーが到達することを意図されていなかったプライベートエージェントを呼び出すことができた。
公開されたサポートボットは、ツールが限定され、データが慎重にフィルタリングされていたかもしれない。プライベートな請求エージェントは、財務ファイル、内部API、または取引システムへアクセスできる可能性がある。リージョン全体に及ぶ呼び出し権限は、露出した入口を、より機密性の高いエージェントへと接続した。
Zenityは、テスト用の請求エージェントに対してこの経路を実証した。研究者らはそのツールを列挙し、billing.jsonというファイルを特定し、エージェントにその内容を返すよう指示した。このシナリオは、2つ目のソフトウェア脆弱性ではなく、正規のAgentCore APIを通じた横展開を示した。
会話メモリは、被害をさらに拡大した。AgentCore Memoryは、メモリリソース、アクター、セッションごとに短期イベントを保存する。長期戦略では、抽出された事実、好み、要約、将来のやり取りに向けた教訓を保持できる。
Zenityによれば、侵害されたロールはアクターとセッションを列挙し、その後ListEventsを呼び出して会話内容を取得できた。これらの権限はワイルドカードのメモリリソースを対象としていたため、研究者らは他のエージェントやユーザーに属する会話へアクセスしたとされる。
露出した情報には、個人情報、ソースコード、内部計画、顧客記録、またはトラブルシューティング中に貼り付けられた認証情報が含まれ得る。会話に入力されたシークレットが本来そこに存在すべきだったかを、プラットフォーム側で判断することはできない。無関係なワークロードがそもそもセッションを読めないよう、認可によって防ぐ必要がある。
書き込み権限は、別の完全性リスクを生んだ。Zenityは、このロールがメモリイベントを作成および削除できることを発見した。攻撃者は、アクティブなセッションに偽のコンテキストを注入したり、ツール結果を削除したり、エージェントが起きたと信じる出来事に影響を与えたりできる。
このリスクは、通常のデータ窃取とは異なる。操作されたエージェントは、攻撃者が与えたコンテキストに基づいて行動しながら、信頼された企業サービスとして振る舞い続けられる。敵対的な指示は、利用者に見えるプロンプトではなく保存済みセッション状態の中にあるため、ユーザーには見えない可能性がある。
AWSは2月25日、根本的な問題に対処しているとZenityへ伝えた。研究者らは6月22日に再確認し、デフォルトロールは変更されていなかったと報告した。このタイムラインにより、広範なロールは数か月にわたり未解決の攻撃チェーンの中心に残った。
9月29日の最終レビューで、Zenityは大幅な制限を確認した。研究者らによれば、AWSはランタイム間の呼び出し、プライベート会話へのアクセス、Secrets Managerの取得を可能にする権限を削除していた。その他の権限も狭められた。
この修正は、現在のリスク評価を大きく変える。公開された攻撃チェーンは、研究者らが以前のデフォルト設定に対して達成した内容を記録したものであり、同一の権限が現在も付与されている証明ではない。既存の顧客作成ロール、複製されたポリシー、古いデプロイメントについては、依然として直接のレビューが必要である。
マネージドな隔離と過剰権限の現実が衝突した
AgentCorruptionは、AgentCoreの隔離の約束と、個々の隔離されたランタイムを取り囲む共有認可経路との間にある対立を露呈した。
AWSは2025年10月、エージェントを安全に大規模運用するためのインフラとしてAgentCoreを一般提供開始した。プラットフォームは、ランタイム隔離に、アイデンティティ、メモリ、ゲートウェイ、ブラウザ自動化、コード実行、可観測性を組み合わせた。
各機能は実際のデプロイメント課題に対応する。エージェントには会話をまたぐ状態、接続先サービスの認証情報、統制されたツールアクセス、予測不能な行動を追跡するためのトレーシングが必要だ。これらすべてのコンポーネントを独自に構築すれば、コストと複雑性が増す。
しかし、統合はセキュリティ上の依存関係も生み出す。ランタイム自体は計算上分離されていても、その実行ロールは別のランタイムを呼び出せる場合がある。トークン保管庫がシークレットをアプリケーションコードから隔離していても、権限が過剰に広いIDはそれらのシークレットを要求できてしまう。
これがZenityのAgentCorruptionにおける中心的な逆説だ。マネージドプラットフォームの連携された制御機能は、安全な本番利用を支援する目的で設計された。テストされたデフォルト設定では、同じ接続がサービス境界をまたいで侵害を拡大させたと報告されている。
AWSの最新のランタイムセキュリティプラクティスでは、この区別がより直接的に認められている。ドキュメントは、CLIで生成した開発用ポリシーを本番環境で使用しないよう顧客に警告している。ワイルドカードのリソース指定ではなく、特定のランタイムARNを推奨している。
このガイダンスでは、実行ロールの権限は、そのロールの呼び出しを許可されたプリンシパルと同等以下であるべきだとも述べている。このルールは、公開エージェントを評価する有用な方法となる。匿名ユーザーがランタイムを呼び出せるなら、ランタイムは匿名ユーザーには与えられていない権限を継承すべきではない。
公開到達可能であることが、直ちにエージェントを危険にするわけではない。しかし、モデルに届くあらゆる指示の信頼レベルは変化する。実行ロールは、受け入れられた入力の一部が悪意あるもの、誤解を招くもの、あるいはツールの操作を狙ったものであることを前提にしなければならない。
認証は呼び出し元の特定に役立つが、プロンプトインジェクションを排除するものではない。正規の顧客アカウントでも、敵対的な指示を送信できる。ユーザーが要約をエージェントに依頼した後は、侵害された文書やWebページから間接的なプロンプトインジェクションが配信される可能性もある。
ゲートウェイ制御は、リクエストがランタイムに到達する前に検証することで露出を減らせる。ガードレールは既知の攻撃パターンを検出でき、インターセプターはIDとコンテキストに基づいて操作を制限できる。ただし、呼び出し元がゲートウェイを迂回してランタイムを直接呼び出せない場合にのみ、これらの制御は機能する。
AgentCoreのセキュリティガイダンスは現在、ゲートウェイが意図されたエントリーポイントである場合、ランタイムの呼び出しをゲートウェイの実行ロールに限定するよう推奨している。このアプローチでは、認可をモデルの意思決定ループの外側に移す。エージェントはIAMによる拒否を言葉で回避できない。
IAMリソースのスコープ設定は、より強力な封じ込め境界であり続ける。カスタマーサポートエージェントに、すべてのランタイムを呼び出すワイルドカード権限を与えるべきではない。メモリ書き込み権限では、サービスがその精度をサポートする場合、特定のメモリリソース、アクターのスコープ、ビジネス上の必要性を指定すべきである。
同じ考え方はコンテナリポジトリやログにも当てはまる。運用メタデータは、アプリケーションデータほど機密性が高くないように見えることが多い。しかし、名前、識別子、エンドポイント、リポジトリパターンは、ラテラルムーブメントのための発見システムになり得る。
組織には信頼レベルごとの分離も必要だ。セットアップツールによって設定が容易だからという理由だけで、公開エージェントと内部エージェントが実行ロールを共有すべきではない。アカウントレベルの制御がより明確な分離を提供できる場合は、機微な機能をAWSアカウントまたはリージョン間で分割できる。
どのプロンプトフィルターも、モデルがあらゆる悪意ある変種を拒否することを保証できない。モデルは有限のコマンド文法を強制するのではなく、意味を解釈する。攻撃者は要求を言い換えたり、取得データ内に指示を隠したり、システムコンテキストとユーザーコンテキストの競合を悪用したりできる。
この制約は、エージェントの導入を非現実的にするものではない。むしろ、防御側がどこに信頼を置くべきかを変える。モデルレベルの防御は操作の成功を減らせる一方、決定論的なクラウド制御は、操作されたモデルが実行できることを制限する。
チームはプロンプトを信頼できない入力として、ツールを特権インターフェースとして扱うべきだ。すべてのツール呼び出しには、認証済みユーザー、要求されたリソース、許可された操作に基づく認可判断が必要となる。モデルがツールを呼び出すという選択自体を、認可として扱ってはならない。
こうした判断を文書化する組織では、検索可能なエンジニアリングナレッジベースが、ランタイムの所有者、IAMポリシー、脅威モデル、インシデント対応手順を結び付ける助けになる。複数のチームが共有クラウドアカウントを通じてエージェントを導入する場合、この記録は重要になる。
メモリポイズニングが侵害を永続的な支配へと変えた
この連鎖で最も重大だったのは認証情報の窃取ではなく、信頼されたエージェントが後に記憶する内容を改ざんできたことだった。
AgentCore Memoryは、短期状態と長期状態をサポートしている。短期メモリは、セッション内でターンごとのイベントを記録する。長期メモリは再利用可能な情報を抽出し、エージェントが設定、事実、要約、過去の教訓を思い出せるようにする。
この永続性は使いやすさを向上させる。サポートエージェントは未解決のケースを記憶でき、職場向けアシスタントは書式設定の好みを保持できる。一方で、将来の意思決定に影響し得る永続的な入力チャネルも生み出す。
Zenityのメモリポイズニングに関する研究によると、窃取されたロールはCloudWatchログを通じてメモリ識別子を発見できた。続いて、アクター、セッション、設定済みのメモリ戦略を列挙できたという。
研究者らはCreateEventを使用し、他のエージェントの会話に敵対的なコンテンツを追加した。メモリ抽出はそれらのイベントを処理し、その内容を長期記録へと変換した。将来のセッションでは、それらの記録が信頼されたコンテキストとして取得される可能性があった。
したがって攻撃者は、すべてのやり取りで元のプロンプトインジェクションを繰り返す必要がなかった。埋め込まれた指示は侵害されたセッションを超えて残存し、後の会話に影響を及ぼす可能性があった。表示上のインターフェースは、依然として組織の公式エージェントに見える。
Zenityはこれを永続的なコマンド・アンド・コントロールと表現している。この表現は、研究者らのテスト環境に関する評価として読むべきである。実際の挙動は、メモリ設定、取得ロジック、モデルの挙動、ツール、認可制御に左右される。
それでも、実証されたプリミティブは深刻である。偽の設定情報によって、エージェントが攻撃者の管理するアドレスへデータを送信するよう誘導される可能性がある。捏造された事実はワークフローを逸らし、汚染された要約は顧客による過去の承認を誤って表現しかねない。
短期履歴の操作には即時的なリスクもある。挿入されたアシスタントイベントは、モデルにとって、それまでに自身が下した判断のように見える可能性がある。削除されたツール結果は、本来であれば危険な操作を止める証拠を取り除いてしまう。
従来のアプリケーションセキュリティでは、ログと履歴をインシデント後の証拠として扱うことが多い。エージェントシステムでは、保存された履歴が将来の意思決定に積極的に再投入される可能性がある。したがって、そのデータの完全性の失敗は、調査を妨げるだけでなく、実行そのものを変え得る。
メモリは復旧も複雑にする。盗まれた認証情報をローテーションすれば継続的なAPIアクセスは停止できるが、汚染されたすべての記録が自動的に削除されるわけではない。対応担当者は、侵害されたIDが触れたセッション、イベント、要約、抽出済みメモリを特定しなければならない。
AWSの最新のメモリガイダンスは、入力検証、永続化前のガードレール、定期的なプロンプトインジェクションテストを推奨している。また、メモリリソースに対する最小権限ポリシーも強調している。
これらの制御はプロベナンスと組み合わせるべきだ。長期記録には、どのユーザー、エージェント、セッション、抽出プロセスが作成したのかを示すのに十分なメタデータを保持させる必要がある。セキュリティチームには、侵害されたIDに関連するメモリを効率的に隔離する手段が必要となる。
高リスクの操作は、想起されたコンテキストを認可の証拠として扱うべきではない。エージェントは、ユーザーが特定の銀行口座を好むことを記憶しているかもしれないが、送金には依然として現在時点で独立して検証された承認が必要だ。メモリはワークフローを導けるが、それ自体が認可するわけではない。
組織は影響度に応じてデータ型を分離すべきでもある。文体に関する設定は、支払い指示、アクセス権の付与、宛先アドレスよりもリスクが低い。機微なメモリには、より厳格な作成ルール、より短い保持期間、より強力なレビューが必要だ。
監視は読み取りだけでなく、書き込みも対象にしなければならない。異常なCreateEventの急増、エージェント間のメモリアクセス、多数のアクターに影響する変更は、不正利用の兆候となり得る。CloudTrail、アプリケーションログ、AgentCoreの可観測性データは、予想されるワークロードの挙動に結び付いたアラートへ取り込むべきだ。
ここでインシデントはAWSの範囲を超える。永続的なメモリとツールを組み合わせるあらゆるエージェントプラットフォームは、同様の完全性の問題に直面する。実装の詳細は異なっても、信頼に関する問いは変わらない。
エージェントはどの情報を記憶してよいのか、誰がそれを書き込めるのか、そして後にどの判断がそれに依存できるのか。AgentCorruptionは、不完全な回答が一時的な足掛かりを継続的な影響力に変え得ることを示している。
AgentCoreの顧客が今確認すべきこと
公開前に、過去の完全な攻撃連鎖は絞り込まれたが、各デプロイメントに残る露出は顧客が定義した権限と古い設定によって決まる。
最初に確認すべきなのは、すべてのAgentCoreランタイムにアタッチされた実行ロールだ。チームは許可されたアクションとリソースを一覧化し、ランタイムの文書化された機能に関係しない権限を削除すべきである。ワイルドカードには、慣例的な受け入れではなく、具体的な正当化が必要だ。
本番ロールがプロトタイプ用に生成されたポリシーを継承すべきではない。AWSは現在、CLI生成権限を開発時の便宜として位置付け、顧客に対して狭くスコープした代替策を作成するよう助言している。テストデプロイメントの成功は、そのロールが本番環境に属する証拠ではない。
2番目の確認事項はMMDSv2の強制だ。現在のランタイムでは、メタデータ設定でrequireMMDSV2をtrueに設定すべきである。チームは、プラットフォーム更新によって過去のすべてのランタイムが正しく変更されたと仮定せず、デプロイ済み設定を確認すべきだ。
MMDSv2も依然として1つのレイヤーとして扱うべきである。エージェントが柔軟なHTTPクライアント、シェル、コードインタープリターを正当に制御している場合、単純なSSRF防御が攻撃者には構築できないと想定していたリクエストを実行できる可能性がある。ネットワークポリシーは、メタデータエンドポイントへの不要なアクセスを遮断すべきだ。
3番目の確認事項はインバウンド到達可能性だ。チームは、直接のパブリック呼び出し、IAM、JWTベースの呼び出しを受け入れるランタイムを特定すべきである。公開エージェントの入力は最も信頼度の低い対象から来るため、最小のロールが必要となる。
AgentCore Gatewayがポリシー強制を提供する場合、ランタイムへの直接呼び出しは制限すべきだ。そうしなければ、攻撃者はゲートウェイのガードレールを迂回し、別の認可済み経路を通じてランタイムエンドポイントを呼び出す可能性がある。認証とユーザー識別子は、検証済みのプリンシパルから導出されなければならない。
4番目の確認事項はラテラルムーブメントを扱う。ランタイムは、無関係なエージェントを呼び出したり、リージョン内のロググループを列挙したり、無関係なECRイメージを取得したり、メモリリソースを列挙したりすべきではない。これらの権限は、ランタイムARNとビジネス機能ごとに分離すべきである。
5番目の確認事項は会話の機密性だ。セキュリティチームは、あるランタイムIDが別のワークロードに属するアクター、セッション、イベントを列挙できるかをテストすべきである。また、リソースポリシーとIDポリシーが組み合わさって意図した拒否を生成するかも検証すべきだ。
6番目の確認事項はメモリの完全性である。チームは、CreateEvent、DeleteEvent、長期メモリアクセスを持つプリンシパルを棚卸しすべきだ。アラートでは、通常のユーザーセッション書き込みと、エージェント間または大量の変更を区別すべきである。
7番目の確認事項は保存された認証情報に関するものだ。AgentCore Identityは第三者トークンをアプリケーションコードの外部に保持できるが、IAMは依然として誰がそれらを取得できるかを制御する。ランタイムロールには、APIキーやSecrets Managerの値への広範なアクセス権を与えるべきではない。
過去の露出可能性を調査する担当者には、現在のポリシーのスナップショットだけでは不十分です。該当期間中のCloudTrailイベント、ランタイム呼び出しログ、メタデータ関連のアクティビティ、ECRイメージのプル、メモリAPI呼び出し、Secrets Managerへのアクセスを確認する必要があります。
一時的な認証情報は失効しますが、その影響は残り続ける可能性があります。攻撃者は失効前にソースコードをコピーしたり、取得したシークレットを保持したり、セッション履歴を改変したり、長期メモリを仕込んだりできるかもしれません。対応計画には、認証情報のローテーションと状態の検証を含めるべきです。
依然として2つの不確実性が重要です。Zenityの調査結果は研究者が管理するデプロイ環境に基づくものであり、ここで引用した公開情報には、顧客環境で広範な悪用が行われたことを示す証拠はありません。AWSは、AgentCorruptionの完全な攻撃チェーンを説明する専用のセキュリティ情報を公開していません。
この不在は、主張を誇張しない理由にはなるべきですが、研究を軽視する理由にはなりません。Zenityは詳細な権限の例、悪用経路、開示日を公開しています。AWSの更新済みドキュメントも、ランタイムコードがメタデータ認証情報にアクセス可能であること、そして広範な開発用ポリシーが本番環境には適さないことを独立して確認しています。
最初に注視すべきシグナルは、AWSが正式なアドバイザリ、回顧的な報告、または追加のポリシー移行ガイダンスを発行するかどうかです。こうしたドキュメントにより、影響を受ける構成や、顧客が古いロールを手作業で修正する必要があるかどうかが明確になります。
2つ目のシグナルは、エージェント制御下のツールからのメタデータアクセスがさらに制限されることです。ランタイムワークロードが認証情報エンドポイントへ到達するのを阻止する制御は、モデルの挙動への依存を減らします。きめ細かなエグレスポリシーは、他のSSRF経路の封じ込めにも役立つ可能性があります。
3つ目のシグナルは、顧客から見えるメモリ保護機能です。より優れたプロベナンス、スコープを限定した書き込み認可、整合性アラート、一括隔離ツールがあれば、メモリ汚染の検知と復旧は容易になります。長期メモリがビジネスクリティカルなワークフローに組み込まれる限り、こうした機能は重要です。
Zenity AgentCorruptionは最終的に、エンタープライズエージェントの根底にある、より広範な前提を試しています。マネージドインフラストラクチャは運用の複雑さを軽減できますが、アイデンティティ、メモリ、ツールアクセスを、広く信頼された1つのロールへ安全に集約できるわけではありません。
開発者は今、デプロイ済みのすべてのエージェントに対して具体的な問いを投げかけるべきです。モデルが受け取り得る最悪の指示に従った後、何が起きるのか。そこから発生するツール呼び出し、認証情報、権限、到達可能なエージェント、書き込み可能なメモリを追跡してください。
その答えが当該エージェントの限定的なタスクの範囲を超えるなら、そのスコープを現行のセキュリティ欠陥として扱うべきです。ロールを見直し、公開ランタイムを分離し、メモリ境界をテストし、現在のAWSデフォルトを直接確認してください。最も安全なエージェントとは、常に操作を拒否するエージェントではありません。操作された応答がアカウント全体のインシデントへ発展するのを、クラウド権限によって防げるエージェントです。
