エージェントは認証情報を明かすよう何度もだまされており、一つの攻撃経路にパッチを当てても、ほかの経路は開いたままになっています。
Palo Alto NetworksのUnit 42とZenity Labsのサイバーセキュリティ研究者によると、Amazon Web Services（AWS）は今年、自律型エージェントのセキュリティ上の欠陥に繰り返しパッチを適用する事態に追い込まれています。しかも、修正した欠陥は、少し形を変えて再び現れています。
ただし、問題の根源はAWSにあるわけではありません。AWSはセキュリティ報告に素早く対応しているようです。むしろ問題は、自律型AIエージェントの本質的な性質と、エージェントを制御することの難しさにあります。Amazonほどの膨大なリソースを持つハイパースケーラーでさえ、この問題に先手を打てていないという事実は、あらゆる企業のIT部門やサイバーセキュリティ部門の幹部にとってのエージェント型AIの課題を浮き彫りにしています。
AgentCoreの問題
たとえば2026年9月18日、Palo Alto NetworksのUnit 42のサイバーセキュリティ研究者らは、「AWS AgentCore Harnessのデフォルト設定を使うと、攻撃者がプロンプトインジェクションでエージェントの動作を操り、AgentCore Identityが管理する平文の認証情報を窃取できる可能性がある」という問題を報告しました。
報告書に記された問題の内容は、エージェント型AI特有の典型的な欠陥を示しています。エージェントが機能を果たすために必要なアクセス権そのものが、重大なセキュリティリスクにもなっているのです。
報告書は次のように説明しています。「Harness組み込みのシェルツールはデフォルトで有効になっており、認証情報が平文に解決されるのと同じメモリ空間に到達できます。組み込みツールは、Harnessが高い自律性と生産性を発揮できる大きな理由です。エージェントはファイルを書き込み、コードを実行して実際の作業をこなせます。しかし、組み込みツールを便利にしているその到達範囲こそが、意図せず有効のままにされたときに危険を生みます」
報告書はさらにこう続けています。「シェルツールはHarness内でrootとして動作することがわかりました。攻撃者がエージェントにコマンドを実行させた瞬間、そのコマンドは同じroot権限を引き継ぎます。これが起きるために、設定ミスは必要ありません。出荷時の初期状態がそのまま該当します」
Unit 42の報告書によると、Amazonの対応は、この穴を実際にふさいだのかどうかがはっきりしないものでした。報告書は「この発見をAWSに開示しました。AWSは報告を精査したうえで、AgentCoreの責任共有モデルに基づき『参考情報』として扱い、クローズしました」と記しています。
数か月前の4月7日にも、Unit 42は認証情報を窃取する別の経路についてAWSに警告していました。
この問題の説明によると、Unit 42は重大なセキュリティ上のリグレッション（退行）を発見しました。AgentCore Runtimeが、セッショントークンの強制を欠いたmicroVMメタデータサービス（MMDS）を使っていたのです。
Unit 42は当時、次のように書いています。「当社の開示とAWSによる修正が行われる前は、この構成を悪用されると、攻撃者がサーバサイドリクエストフォージェリ（SSRF）といった一般的なWeb脆弱性を突いて、機密性の高い認証情報を直接抜き取り、環境全体を危険にさらす恐れがありました」
Zenity Labsも本日、独自の報告書を公開しました。CSOはその事前コピーの提供を受けています。報告書には、AWSのエージェントが、要求した攻撃者に認証情報を渡してしまった経緯が詳しく記されています。
Zenityは、エージェントに一式の一時的なSTS認証情報を返させることに成功しました。アクセスキーID、シークレットアクセスキー、そしてエージェントの実行ロールに紐づくセッショントークンです。報告書は次のように述べています。「これらの認証情報はサンドボックス内に限定されていません。当社はこれらを自前のマシンにエクスポートしました。AgentCoreの外部です。そして、認証情報が有効であることを確認しました」
エージェントが渡したデータにはECRの読み取り権限が含まれていました。報告書によれば、「そこでレジストリに認証し、イメージを取得しました。その時点で、エージェントのソースコードや依存関係、開発者が組み込んだあらゆるものを、root権限で調べられる状態になりました」といいます。
Zenityは次のように指摘しています。「ここで『それなら、エージェントに生のHTTPツールを与えなければいい』と考えるのは自然な反応でしょう。しかし、それでは解決しません。分離の失敗はツールではなくプラットフォームのレベルで起きているため、外向きの通信を生成できるものであれば、どれでも同じようにIMDSに到達します。Strands組み込みのシェルツールなど、複数のツールで同じ結果を再現しました」
ただしZenityの報告書によると、このエージェントは、ほかのエージェントの認証情報も共有していました。
Zenityの報告書は次のように説明しています。「AgentCoreは各リポジトリにエージェント名を付けています（`bedrock-agentcore-<agent_name>`）。そのため、発見したすべてのエージェントに対して自動化ツールを実行したところ、数秒のうちに、そのリージョン内の全エージェントのソースコードをすべて入手できました」
報告書はこうも述べています。「このロールは、リージョン全体のさまざまなAgentCoreおよびAWSサービスに対するREAD、WRITE、DELETEの権限を持っていることがわかりました。これにより、ほかのエージェントを呼び出し、リージョン内で横展開（ラテラルムーブメント）することが可能でした。さらに、全ユーザー・全エージェントの非公開の会話をすべて読み取り、メモリを汚染して永続性を維持し、AWSの外へのアクセスまで可能にする認証情報やAPIキーを収集し、同じリージョン内で破壊的な操作を実行できました」
パッチの適用状況は不明
こうした露出が現在どの程度残っているのか、完全には明らかになっていません。Zenityが公表した時系列では、研究者らがこれらの問題の多くを発見したのは2025年後半で、詳細をAWSに報告したのは12月25日です。AWSは2026年2月にアップデートで対応しました。しかしZenityは、AWSが露出経路の一部を限定的にふさいだだけで、ほかの経路は攻撃を受けるまま残された可能性があるとしています。
Zenityは、10月8日の時点でAWS環境の権限が修正済みであり、同社が発見した攻撃経路にはもはや露出していないことを確認しました。
しかし、Zenityが示したより詳細な時系列からは、三つの点が見えてきます。一つ目は、エージェント型環境を保護することの複雑さです。二つ目は、穴を修正し、しかもその修正を維持し続けることの難しさです。三つ目は、穴が本当にふさがれたかどうかを見極める難しさです。
ZenityとPalo Altoの報告を受けて、AWSは2月に環境を更新し、問題を解決したと考えていました。しかし、Zenityのセキュリティ研究ディレクターであるTamir Ishay Sharbat氏が10月8日に送ってきたメールによると、2月の修正で欠陥が実際に解消されたわけではありませんでした。
同氏は次のように書いています。「当社の開示後、AWSは2026年2月14日にAgentCoreをIMDSv2のみを使うよう素早く更新しました。このアップデートにより、そもそも認証情報にアクセスできてしまった最初の侵入経路は修正されました」。しかし「6月22日にAgentCoreのデフォルトロールを確認したところ、権限は変更されていませんでした」といいます。
ただし同氏によると、その後のZenityの確認で、AWSが6月22日から9月29日の間に権限の問題を修正したことが確認されました。
報告書で取り上げられた問題についてCISOやCIOは何をすべきか。Zenity CTOのMichael Bargury氏はメールで、この問題は一筋縄ではいかないと答えました。強固な防御には強力なエージェントの分離が必要だからです。一方で同氏は、「エージェントが役に立つには、自律性と接続性が必要です。この研究が示すとおり、両者は相反します。企業はこの本質的な対立を意識し、それに応じてセキュリティ対策を計画すべきです」と指摘しました。
AWSはインタビューの依頼を断りましたが、短い声明をメールで送ってきました。声明では、エージェントは本来の想定どおりに動作したという点を改めて強調しています。Zenityの報告書についてもコメントを求めたところ、広報担当者は次のように答えました。「AWSは、Amazon Bedrock AgentCoreについて公表された研究を把握しています。この研究は、想定され文書化されている動作を、誤って脆弱性として描いています。エージェントが別のAWSアカウントのリソースにアクセスできるのは、開発者がエージェントの実行ロールと対象リソースの両方で明示的に権限を付与した場合に限られます。ベストプラクティスとして、お客様には、エージェントに必要な権限のみを実行ロールに付与するよう推奨しています」
アナリストやコンサルタントは、両報告書の内容を懸念すべきものと受け止めましたが、驚きはしなかったといいます。これまでにエージェント型AIの問題を数多く見てきたためです。それでも、公表された詳細のうち、一部の専門家にとって最も気がかりだったのはメモリの問題でした。
Dickson Researchの主席アナリストであるFrank Dickson氏は、「メモリの汚染が最も心配です。汚染されたメモリは、役に立つエージェントを『マンチュリアン・キャンディデート』（洗脳された刺客）に変えてしまいます。しかるべき会話が来るのを待ち、行くべきでない場所へエージェントを送り込むのです。盗まれた鍵はローテーションできますが、どのメモリを信頼してよいかを見極めるのははるかに困難です」と述べました。
Coalition for Secure AI（CoSAI）のメンバーで、ACMのAIセキュリティ（AISec）プログラム委員会にも名を連ねるNik Kale氏も、メモリの問題が最も深刻だと考えています。
Kale氏は次のように指摘しました。「盗まれた認証情報は数時間で失効しますが、汚染されたメモリはそうはいきません。すべての鍵をローテーションした後も、長きにわたって会話を誘導し続けます」
古い過ちが新しい形で表面化
Info-Tech Research Groupの主席リサーチディレクターであるFred Chagnon氏は、AWSのエージェント型AIをめぐる一連の問題を「過去のプラットフォーム設定ミスが、新しいプラットフォームに新しい形で再び現れることを示す教訓」だと見ています。
たとえば同氏によると、SSRFでメタデータサービスに到達し、ワークロードの認証情報を盗み出したAWSのセキュリティホールは、「本質的に2019年のCapital Oneの情報漏えいと同じパターンです。SSRF、盗まれたロール認証情報、そして過剰な権限を持つロールが組み合わさり、一つの足がかりがはるかに広範なアクセスへと変わりました」。
しかし今回の問題では、Chagnon氏は「引き金が異なります。シェルやHTTPツールを持つエージェントは、頼まれればURLを取得しにいくため、プロンプトそのものが攻撃になります」と語りました。
さらに同氏は「より大きな問題は被害範囲です。侵害された一つのエージェントが、アカウントとリージョン内のすべてのエージェント、会話、シークレットに到達しました」と付け加えました。
より難しいのは、企業のCISOやCIOがこの状況にどう対処すべきかです。IT分野で最も古くからある課題の一つが、権限、統制、アクセスが共有された環境をうまくやりくりすることです。初期のクラウド導入がそうだったように、ハイパースケーラーは最大級の企業テナントの知らないところで、あるいは許可を得ずに、一部の判断を下してしまいます。
Chagnon氏はこう説明します。「ここでの責任は共有されています。サンドボックスを分離し、プラットフォームの機密情報をインスタンスメタデータに置かないのはAWSの仕事であり、顧客には修正できません。一方、デフォルトの権限はクラウドエンジニアが置き換えられますし、置き換えるべきですが、ほとんどは置き換えないでしょう。ワイルドカードでアクセスを許可するデフォルトロールがリスクとして残ります。AWSは、エージェントごとに範囲を絞った最小権限のデフォルトを提供し、サンドボックスからのメタデータアクセスを制限できるはずです」
ただし同氏によれば、責任共有モデルでは、こうした統制を実施する責任は企業側にあります。CISOは独自の最小権限ルールを策定し、シェルツールとHTTPツールを高リスクとして扱うべきです。外向き通信を制限し、イメージにシークレットを含めず、エージェントごとのIDとツール利用のベースラインを設けて、異常が目立つようにする必要があります。
同氏は次のように述べています。「企業は、数多あるエンタープライズソフトウェアの欠陥を修正したり補ったりできないのと同様に、クラウドプラットフォームの欠陥も修正できません。しかし、侵害された一つのエージェントがどこまで被害を及ぼせるかは、自ら決定し、設計できます」
最大の問題：エージェントは設計どおりに動作した
Dickson氏は、AWSをめぐる一連の事例で大きな問題なのは、エージェントが誤作動したことではなく、設計されたとおりに動作したことだと付け加えました。
同氏は「エージェントは頼まれたことをそのまま実行しました。それが問題なのです」と語ります。「Zenity Labsが見つけたのは、一連の連鎖でした。ネットワークに到達できるエージェント、そのエージェント自身のクラウド認証情報を返したメタデータサービス、そして、どのエージェントにも必要のない過大な権限を持つデフォルトの実行ロールです。個々の要素は、いずれもよくある過ちです。それらを連鎖させると、一つの外部公開エージェントが、ビル内のあらゆる部屋を開けられるホテルのカードキーに化けてしまいます」
Kale氏も同意見です。
同氏は次のように語りました。「メタデータサービスから認証情報を引き出すのは、クラウドハッキングの基本中の基本です。新しいのは、研究者がそこに至るのにバグを見つける必要がなかった点です。ただ平易な英語でエージェントに頼んだだけでした。それが可能になった時点で、サンドボックスの壁がどれだけ頑丈かは、もはや重要な問いではなくなります。本当の境界は、エージェントが持つIDそのものです。そのIDがほかのエージェントにまで及ぶなら、一つの会話が環境全体に影響を与えかねません」
コンサルティング会社AcceligenceのCEOであるJustin Greis氏は、企業のCISOに強調したいのは、二次的なデータアクセスを制御することの重要性だと述べました。
同氏は次のように語ります。「ガバナンスが不十分なエージェントの被害範囲は、従来のアプリケーションに慣れたほとんどの組織が想定するよりも、はるかに大きくなり得ます。今回の研究で際立っているのは増幅効果です。問題は、単に一つのエージェントを操作できたことではありません。一つのエージェントが侵害されると、より広範な認証情報、ほかのエージェント、ソースコード、機密情報、さらには動作の持続的な操作へと至る経路が生まれかねないことが懸念されます。この点で、これは単なる技術的な脆弱性の一つではなく、経営層の問題になります」
同氏は、CIOやCISOが次のような重要な問いを投げかけ、その答えを必ず求めるよう提案しました。エージェントはどのIDで動作しているのか。何にアクセスできるのか。何を変更できるのか。何を記憶できるのか。ほかのどのエージェントやシステムに到達できるのか。
「そして」と同氏は言います。「最も重要なのは、侵害されたら何が起きるのか、ということです」
