AIエージェントのセキュリティ：モデルがツールや認証情報を取得すると、何が変化するのか

AIエージェントのセキュリティとは、単に回答するだけでなく、行動をとることができるAIシステムを保護する取り組みのことです。エージェントはツール、認証情報、メモリを保持しているため、そのセキュリティを確保するには、モデルが示す内容ではなく、エージェントが何を呼び出すことが許可されているか、どのようなIDを保持しているか、実行時にどのような動作を行うかを管理する必要があります。

この違いが、影響範囲を決定づけます。質問に答えるだけのモデルは、誤った回答をする可能性があります。一方、APIトークン、メールボックス、シェルを保持するエージェントは、誤った判断を下し、その権限が許す範囲内でそれに基づいて行動してしまう可能性があります。このページでは、エージェント特有の脅威表面について解説します。具体的には、MITRE ATLASのエージェント技術ファミリー、ツールの改ざん、エージェントの識別とインベントリ、記録されたインシデント、および実行時の検知について取り上げます。 メモリポイズニングやエージェント型アプリケーション向けのOWASP Top 10など、自律システムの周辺アーキテクチャ、ライフサイクル、ガバナンスについては、エージェント型AIセキュリティに関するガイドをご覧ください。

AIエージェントのセキュリティとは何ですか？

AIエージェントとは、行動するように設計された言語モデルです。AIエージェントは、計画を立て、ツールを起動し、メモリの読み書きを行い、認証情報を保持し、さらには他のエージェントとの連携もますます密接になっています。これらの機能はどれも有用ですが、そのすべてが、攻撃者がアクセス可能なインターフェースでもあります。これこそがAIエージェントのセキュリティリスクのすべてです。つまり、モデル自体がより危険になったわけではなく、モデルに「手」が備わったのです。

この境界線について最も明確に述べているのは、ベンダーではなく標準化団体である。OWASPの「LLMアプリケーション向けトップ10 2026」は、その適用範囲を「モデル・アズ・コンポーネント」のケース、つまりアプリケーション内に組み込まれ、回答を行うモデルに限定している。 一方、モデルが主体となり、ツールを使用し、セッション間でメモリを保持し、下流に結果をもたらすようになった場合、OWASPはそれを「エージェンシー」のリストに分類します。これは、本ページが論じている境界線を、標準化団体が正確に定めていることを示しています。公式のリポジトリによると、この版は2026年8月4日付けであり、境界線がどれほど移動したかがわかります。「Excessive Agency（過剰な主体性）」は、2025年のリストでは6位でしたが、現在はLLM03に位置づけられています。

実際の問題として、AIエージェントのセキュリティは、モデル自体の問題というよりも、権限設定やツールの問題であると言えます。モデルを堅牢化しても、エージェントが引き続き呼び出すことが許可されているツールの影響範囲は縮小されません。この点が、エージェントのセキュリティがより広範なAIセキュリティの分野とは一線を画す所以であり、エージェントが読み取った情報に基づいて行動できるようになると、間接的なprompt injection がはるかに重要になる理由でもあります。

タイミングこそが、答えのもう半分です。ガートナーは、2025年には5%未満だった企業向けアプリケーションのうち、2026年までに最大40%がタスク特化型エージェントを統合するようになると予測しています。2025年に353組織を対象に行った調査では、80%が自社のAIエージェントが意図しない行動をとったことがあると回答しました。 また、GoogleによるCommon Crawlのスナップショット分析では、2025年11月から2026年2月にかけて、悪意のあるコンテンツの割合が32％増加したと報告されており、エージェントが読み込む信頼できないコンテンツそのものの質が悪化していることを意味しています。導入がセキュリティ対策の整備を先取りしている状況は、このリストに挙げられたあらゆるAIエージェントのセキュリティ課題に共通して見られる傾向です。

エージェントが攻撃を受ける可能性のある5つの場所

このテーマに関する最近の論考の多くは、AIエージェントの攻撃対象領域に関する同じ5層モデルに収束しており、その収束ぶりは、このモデルが妥当であることを示す確かな兆候である。これは差別化要因というよりは当然の前提であるため、一度言及しておき、その後は先に進むのがよいだろう。

‍

表1：AIエージェントの攻撃対象領域を構成する5つの層と、各層がもたらす不具合。

このページの残りの部分では、そのモデルでは扱われていない点、すなわち具体的な技術識別子、ツールの境界、識別子レジストリ、および実行時シグナルについて解説します。

エージェントによる攻撃とMITRE ATLASとの対応関係

MITRE ATLASは、AIシステムに対する実世界の攻撃者の行動に関するMITREのナレッジベースであり、この問題に対するエージェントネイティブなフレームワークです。現在のリリースはv2026.07で、2026年8月7日にGitHubに公開されました。リリース本文には、その内容が正確に記されています。「このバージョンのATLASデータには、1つのマトリックス、16の戦術、101の手法、77のサブ手法、37の対策、および68のケーススタディが含まれています。」つまり、合計178の手法定義があります。

その178人のうち、 29件のエントリはエージェント固有のものとなっています: 13の親テクニックと16のサブテクニック。それらと並んで、 7つのエージェントによる緩和策 そして 4つの主要なエージェント事例. 集計基準が重要ですので、以下に示します。エントリは、その完全なATLAS表示名に「AI Agent」または「Agent」が含まれている場合に条件を満たし、さらに AML.0034.002 コストハーベスティング：エージェントによるリソース消費。これは明らかにエージェントに関連する概念であるが、「Agent」という単語の厳密な語境判定には合格しない。以下の識別子はすべて、公開されたリリースアセットから読み取られる。 ATLASデータリポジトリ.

その影響範囲はさらに広範です。v2026.07全体では、178件のテクニック定義のうち48件（27.0%）が名称や説明文に「エージェント」という用語を含んでおり、68件のケーススタディのうち19件（27.9%）、37件の緩和策のうち14件でも同様です。現在、ATLASコーパスの約4分の1が、何らかの形でエージェントに関連しています。

ここで、曖昧な表現ではなく、正確に述べられた差別化要因を提示します。「ATLASをエージェントにマッピングした人が誰もいない」というのは事実ではありません。事実なのは、公開されている試みはすべて、すでに廃止されたATLASのバージョンに基づいており、現在の29のエージェントエントリのうち、せいぜい2つしか網羅していないということです。そのような公開マッピングは2つ存在しますが、いずれもこのトピックで検索順位上位に表示されるページではありません。そのため、ランキング対象のコーパス自体にはATLAS識別子が1つも含まれていないのです。2つのうち1つはATLAS v5.4.0を引用し、7つの手法識別子を挙げています。もう1つは、その後廃止された手法を引用しています。フレームワークの概要については、MITRE ATLASフレームワークに関する解説記事をご覧ください。以下では、エージェント固有の側面について解説します。

もう一つのMITREフレームワークに関する注記：ATT&CKは、この文脈では適切な主要な分析枠組みとは言えません。これは、エージェントの認証情報やホストが従来の足掛かりとして悪用されるような、侵害後の段階では重要ですが、エージェント固有の手法ファミリーは含まれていません。現在のリリースはATT&CK v19.2で、2026年8月6日に公開されました。これらの手法を用いたエージェントに対する攻撃テストは、 AIレッドチーム活動, また、ATLAS v2026.07でもこれが正式に規定され、さらに以下が追加されました。 AML.M0035 リスク軽減策としてのAIレッドチーム。

表2：MITRE ATLAS v2026.07に含まれる29件のエージェント固有の手法エントリを、親手法ごとに分類したものである。識別子と名称はリリース資料から引用したものであり、「実践」欄はATLASの説明文ではなく、当方が平易な言葉で解説したものである。

表3：MITRE ATLAS v2026.07における7つのエージェント固有の緩和策。

ツールの汚染とツールの境界

ツール定義は設定ではありません。それはモデルが読み取り、それに従うテキストであり、それゆえに指示面となります。「ツールポイズニング」とは、この事実に起因する攻撃であり、MITRE ATLASではこれを次のように追跡しています。 AML.0110 AIエージェントのツールポイズニング。

よく混同されがちな3つの概念を、明確に区別しておきましょう。Prompt injection は攻撃の伝達手段です。Memory poisoningはエージェントの記憶を改ざんするもので、これについては「エージェント型AIのセキュリティ」ガイドで詳しく解説しています。Tool poisoningはツールそのものを改ざんするもので、 prompt injection これが攻撃の媒介として頻繁に利用されます。

ツールが汚染される可能性のある3つの場所

ATLAS v2026.07 では、以下の項目に 3 つのサブテクニックが追加されました。 AML.0110、そしてこれらが有用なのは、まさに3つの異なる防御上の問題を区別しているからに他なりません。親となるテクニックはこのリリースより前から存在していましたが、今回のリリースで更新されました。3つの子テクニックは新たに追加されたものです。

‍

表4：MITRE ATLAS v2026.07におけるAIエージェントのツールポイズニングの3つのサブ手法。

「実装」の欄には、実例が記載されています。2025年9月、エージェント向けのメール送信ツールを提供する、広く利用されていたnpmパッケージにバックドアが仕込まれていました。 Koi Securityによる「postmark-mcp」バックドアの公表 その経緯は次のように明快に記録されている。「15バージョン、そう、15バージョンにわたって、このツールは完璧に動作していた」。しかし、バージョン1.0.16で、すべてのメッセージのBCCが密かに攻撃者のアドレスに追加されるようになった。 頻繁に引用される「影響を受けた組織は約300」という数字は、実測値ではありません。これは、週あたり1,500件のダウンロードというベースラインに対し、「おそらく20％が実際に使用されている」という仮定を適用した、研究者自身の推定値に過ぎません。著者たちもそう扱っているのですから、これもあくまで仮定として捉えるべきです。ATLASはこのインシデントをケーススタディとして掲載しています。 AML.CS0053.

攻撃対象領域としてのMCP

モデルコンテキストプロトコル（MCP）は、ツールをエージェントに公開するための主要な手段であり、そのためMCPサーバーは、生成権限を持つサプライチェーン上の依存要素となります。ガートナーの分析も同様の見解を示しており、MCPは「相互運用性、使いやすさ、柔軟性を最優先に設計されたため、エージェント型AIに対して継続的な監視が行われない場合、セキュリティ上のミスが顕在化する可能性がある」と指摘しています。 同予測では、2025年の9％から増加し、2028年までに企業の生成AIアプリケーションの25％が、年間少なくとも5件の軽微なセキュリティインシデントを経験すると見込まれている。

Model Context Protocol（MCP）仕様書の2026年7月28日付けリリース版には、正確に引用する価値のある規範的要件が記載されています。「MCPサーバーは、そのMCPサーバーに対して明示的に発行されていないトークンを一切受け入れてはならない（MUST NOT）。」この文は、仕様書のセキュリティベストプラクティス文書における「トークンパススルー」の対策項目に記載されており、同文書では11の攻撃および対策のサブセクションが挙げられています： 「Confused Deputy Problem」、「トークン・パススルー」、「サーバーサイド・リクエスト・フォージェリ」、「ステート・ハンドル・ハイジャック」、「ローカルMCPサーバーの侵害」、「OAuth認証URLの検証」、「プロキシシナリオにおけるstdioトランスポートのセキュリティ」、「ミックスアップ攻撃」、「ローカルホストリダイレクトURIのなりすまし」、「CIMD信頼ポリシー」、および「スコープの最小化」。

2つの訂正を挙げておく価値があります。なぜなら、どちらの誤りもよくあるものだからです。まず、「ツールポイズニング」、「ラインジャンピング」、「ツールシャドウイング」、「ラグプル」は、MCP仕様の概念ではありません。これらはOWASPやコミュニティの研究に由来するものです。 「MCP仕様のツールポイズニングのセクション」を引用している人は、実際には存在しないものを説明していることになります。次に、「セッションハイジャック」は「ステートハンドルハイジャック」に置き換えられました。MCPは現在、プロトコルレベルのセッションを持たないステートレス方式となっているため、MCPのセッションハイジャックを現在の仕様セクションとして引用しているコンテンツは、廃止された改訂版に基づいて作成されたものです。

OWASPは、「OWASP MCP Top 10」において、ツールポイズニングに独自の番号「MCP03:2025」を割り当てました。ここではステータスの区分が重要です。これはv0.1のOWASP インキュベータープロジェクトであり、現在はフェーズ3、ベータリリースおよびパイロットテストの段階にあります。 最終リリースの日程は未定であり、次回のリリースは2026年10月に予定されています。このプロジェクトはLLM Top 10のような権威性を有しておらず、あたかもそうであるかのように引用すべきではありません。

政府の指針はさらに進んでいる。NSAが単独で発行した「モデル・コンテキスト・プロトコル（MCP）」に関するサイバーセキュリティ情報シート（2026年5月付のバージョン1.0、17ページ）には、MCPに関する9つの推奨事項が記載されている。そのうち2つは、しばしばより弱い表現に言い換えられてしまうため、そのまま引用する価値がある。「可能な場合は、サポートされているMCPプロジェクトを選択すること」および「MCP関連の脆弱性を追跡し、パッチを適用すること」である。

境界条件のうち、一度言及しておけばそれ以上触れる必要のないものが一つあります。ある大手分析会社は現在、エージェントによる機密データへのアクセス、信頼できないコンテンツの取り込み、および外部との通信機能の3つが組み合わさったユースケースについては、一切手を出すべきではないと助言しています。この組み合わせについては、当社の エージェント型AIセキュリティ ページ。工具のサプライチェーンは、従来の依存リスクとも重なり合っており、これは MITRE ATLAS 名前を直接 AML.0010.005 AIサプライチェーンの侵害：AIエージェントツール。

エージェントの識別、インベントリ、およびレジストリの問題

従来のIDおよびアクセス管理では、予測可能なアクセスパターンを持ち、人間が所有し、合理的に推測可能なセッションを持つプリンシパルを前提としています。 エージェントはこれら3つの前提すべてを覆します。モデルが何を呼び出すかを決定するため、そのアクセスパターンは非決定論的です。その権限はログインではなく、委任チェーンを通じて付与されます。そして構造的には「混乱した代理人（confused deputy）」であり、行動を要請する者よりも多くの権限を保持しています。この最後の点は単なる理論的な枠組みではありません。「混乱した代理人」の問題は、MCP仕様書のセキュリティ文書において最初に名指しされた攻撃なのです。

したがって、最初の制御は、そもそも制御とは呼べない。それは単なる棚卸しである。この市場における3つの独立したページは、エージェントの発見が重要であると主張しているが、その手法について説明しているものは一つもない。その手法とは、観測された挙動と照合されたレジストリである。レジストリに記載されていないツールを実行するものはすべて「シャドウエージェント」であり、この照合こそが、エージェントの拡散を測定する唯一の信頼できる方法である。

表5：エージェント登録レコードに含まれるべき項目、および各項目を省略した場合の影響。

用語に関して言えば、2つの用語が本質的に同じものを指しています。「マシン・アイデンティティ」と「非人間アイデンティティ（NHI）」は、いずれも、人間ではないが認証情報と権限を持つ主体を意味し、サービスアカウント、APIキー、ワークロード、そして現在ではエージェントもこれに含まれます。 率直に言えば、これらの用語の違いは、市場における用語上の真の隔たりである可能性もあれば、単に市場が「非人間アイデンティティ」という表現に落ち着いただけである可能性もあります。現時点の証拠では、その区別はつきません。エージェント・アイデンティティが、いかなる非人間プリンシパルによる悪用検出とも重なる部分については、その領域はアイデンティティ脅威の検出および対応に属します。

ポータブル標準レイヤーは弱点であり、この点については率直に指摘しておく価値がある。 暗号ワークロードのIDを発行するためのCNCFプロジェクトであるSPIFFEとSPIREは、2022年9月20日にGraduated（卒業）済みであるため、これらを「新興」と表現する人は4年も時代遅れだ。その上のレイヤーについては、活発な活動状況が示唆するほど実態は充実していない。AIエージェントのIDや認証に関するアクティブなIETFドラフトは165件ある。これら165件はすべて個別の提案である。 ワーキンググループで採択されたものはゼロです。エージェントIDの標準化レイヤーは、標準化レイヤーというよりは提案が爆発的に増えている状態に過ぎません。2つの反例を挙げておく価値があります。OAuthクライアントIDメタデータ文書は、MCP仕様が直接参照している正真正銘のワーキンググループ文書であり、OpenID AuthZENワーキンググループはMCPへのバインディング認証に関するドラフトを保有しており、AuthZENアクセス要求および承認プロファイルは2026年8月20日にDraft 1に達しています。 一方、WIMSEワーキンググループは、設立から約33ヶ月間で6つのアクティブな文書を作成したものの、RFCはゼロである。また、RFC 8693は依然として「提案標準（Proposed Standard）」のままであり、その120の関連行すべてにおいて更新も廃止も一切行われていない。つまり、エージェントの委任に関して、これを置き換えるものは何もないということだ。上記の出典はIETFデータトラッカーにある。

実用的な観点から言えば、現時点ではポータブルなエージェントIDを購入することはできないため、実際に利用可能な制御手段は「スコープ」「スポンサー」「有効期限」に限られます。エージェント型AIの導入に関するNCSCのガイダンスも、ガバナンスの観点から同様の結論に達しています。「Zero trust 」の原則はエージェントにもそのまま適用できますが、1点だけ調整が必要です。すなわち、継続的に検証される「プリンシパル」は人間ではないため、検証のシグナルはログインイベントではなく、行動から得られなければなりません。

AIエージェントに関する記録された事例が示すもの

実際に発生した事象は、予測よりも有用です。なぜなら、それぞれの事象が、境界が実際にどこで機能しなくなったかを示しているからです。

表6：記録されているAIエージェントのセキュリティインシデントの一覧。主な情報源および、存在する場合はATLASのケーススタディ識別子を記載している。

Amazon Q Developer。悪意のあるコードが、リリースされた拡張機能に混入していました。AWSセキュリティ情報 AWS-2025-015には、その結果が次のように明確に記されています。「AWSセキュリティチームがコードを調査した結果、悪意のあるコードが拡張機能とともに配布されていたものの、構文エラーのために実行には至らなかったことが判明しました。」 破壊的な命令は完全に構成されていました。それを阻止したのは、単なるタイプミスでした。CVE-2025-8217 については、CVSS v4.0 の 5.1（MEDIUM）および v3.1 の 4.0（MEDIUM）の両スコアが「Secondary」に分類されており、AWS が CNA として割り当てました。NVD は独自の「Primary」スコアを公表しておらず、レコードのステータスは「Deferred」となっています。

postmark-mcp。前述の通り、ここにも該当します。なぜなら、ポイズンド・エージェント・ツールは、エージェントの生産権限を継承する依存関係だからです。あらゆるサプライチェーン攻撃に当てはまる論理がここにも適用されますが、結果に至るまでの経路ははるかに短くなります。

Claude Code GitHub Action。 サンドボックス化されていない単一のツールが攻撃経路のすべてであり、通常のGitHubのイシューからアクセス可能だった。 GMO Flatt Securityの技術レポート ベンダーによりCVSS v4.0スコア7.8が割り当てられており、報奨金は4,800ドルで、中核となるバイパス脆弱性は claude-code-action v1.0.94. エージェントの部分的なサンドボックス化は、完全な回避策となる。

2026年7月のエージェント主導型侵入事件。あるAIプラットフォームプロバイダーは、自律型エージェントフレームワークが同社の内部システムに対してエンドツーエンドの侵入を引き起こしたことを明らかにした。その技術的なタイムラインは、以下のフォレンジック記録の通りである。 「当社のフォレンジック再構築では、2026年7月9日 02:28 UTC から 2026年7月13日 14:14 UTC までの間に、回収できた約17,600件の攻撃者の行動を、約6,280のクラスターに分類して記録しています。」この約6,280件は、コンピューティング・クラスターではなくアクティビティ・クラスターであり、その期間はおよそ4日半に及びます。 同文書には、「エージェントが、136個の鍵を保持する本番用オブジェクトを含む、クラスターのシークレットオブジェクトを読み取った」と記録されています。プロバイダーのインシデント開示報告書では、「限られた内部データセットおよび複数の認証情報への不正アクセス」について説明されており、パートナーおよび顧客への影響評価は依然として進行中であると述べられています。報告書では相手方の名称は明記されておらず、その概要においても同様に明記すべきではありません。

注目すべきは検知の詳細部分です。シグナルは確かに検知されていました。プロバイダー自身の説明によると、「当社のAIベースのセキュリティエージェントスタックによって相関分析が行われ、一貫性のある攻撃シグナルとして特定されました。しかし、アラートの重要度を正しく引き上げ、オンコールチームを起動させることに失敗したため、対応に貴重な時間を費やすこととなりました。」

EchoLeak。Microsoft 365 Copilot の実稼働環境において、個人データへのアクセス、信頼できないコンテンツの取り込み、および外部への通信経路が確認された。 両方のスコアを正確に提示します。CNA（中央評価機関）として機能するMicrosoftによるCVE-2025-32711のCVSSスコアは9.3（CRITICAL）ですが、NVDによる独立したNIST分析では、CWE-74に基づき7.5（HIGH）と評価されています。一部の報道で流布している9.8という数値は、いずれの情報源にも根拠がありません。EchoLeakおよび関連するエージェント型インシデントについては、当社のエージェント型AIセキュリティページで取り上げています。

サイバー評価におけるインシデント。あるモデルプロバイダーは、「Claudeがインターネットにアクセスできた可能性のある141,006件の評価実行を検証した結果」、セキュリティテスト中に同社のモデルが第三者組織に到達した3件のインシデントを特定したと明らかにした。3つの組織のうち2つには、その後連絡が取れている。 141,006件のうち3件という数字は基本発生率ではなく、決してパーセンテージとして表現してはならない。この開示は調査結果を記述したものであり、発生率の測定結果ではないからだ。同社自身の根本原因に関する説明こそが、このページの主張を最も明確に示している。「我々は、これらの事象はモデルのアラインメントの失敗というよりは、ハーネスおよび運用上の失敗に近いものと見なしている。」

配送エージェント製品に関する2件の2026年のCVEが、この状況を締めくくっています。Azure SREAgentのCVE-2026-62830は、CWE-862に該当し、CVSS v3.1で9.9（CRITICAL）と評価されています。また、Copilot CoworkのCVE-2026-59118は、CWE-285に該当し、9.3（CRITICAL）と評価されています。 いずれも2026年8月6日に公開されており、両方のスコアはCNAによって割り当てられたもので、独立したNVDによる分析は行われていません。このパターンはAIエージェント製品において例外ではなくむしろ一般的であるため、このトピックに関するCVE一覧表では、どの機関によるスコアを表示しているかを明記する必要があります。いずれもCISAの「悪用された脆弱性カタログ」には掲載されていないため、悪用されたものとして記述すべきではありません。

これらに共通しているのは、そのいずれもがモデルの誤りに起因するものではないという点だ。ほぼすべてが、間接的なprompt injection がツールに到達したこと、あるいはタスクに必要な範囲を超える権限が与えられていたことに起因している。2026年7月の事例は、被害者ではなく攻撃者がエージェントであったという点で、示唆に富む例外である。AIエージェント・コミュニティと「無害であるという錯覚」に関する我々の研究も、エージェント間という観点から同様の結論に達している。

侵害されたAIエージェントの検知と封じ込め

まず率直な説明から始めましょう。それが要件を明確にするからです。文書化されている故障モードは2つあり、それらは異なる問題です。

第一に、沈黙です。ZombieAgentの事例では、従来のどの制御手段もデータ流出を検知しませんでした。セキュアWebゲートウェイも、エンドポイントツールも、ファイアウォールも検知できず、ユーザーにアラートが届くこともありませんでした。OECDの「AIインシデントおよびハザードモニター」の記録は、この件に関する中立的な登録情報となっています。 研究者たちはこれを「ゼロクリック型の間接的なprompt injection 」と表現している。これは研究者たちの定義によるものであり、ペイロードが実行されるにはユーザーが通常通りアシスタントとやり取りする必要があるため、この定義に従って記述する価値がある。

2つ目は、ノイズの判定ミスです。2026年7月の侵入事件では、複数の層から同時に信号が発射され、それらが相関して一貫性のある攻撃信号となりました。その結果、システムは警報の重要度を引き上げることができませんでした。沈黙と重要度の誤判定は、どちらも同じ結果を招くものであり、より優れたモデルを導入したとしても、いずれも解決されることはありません。

検出機能の構築において注目すべきランタイムシグナルは5つあります：

1. 指示遵守における異常：課題との妥当な関連性が見られない行動。
2. 想定されるワークフローのトポロジーを崩すツール呼び出しシーケンス。
3. エージェントが正当に保有する低帯域幅の通信経路を介した情報流出。
4. 現在のタスクの範囲外での認証情報およびシークレットへのアクセス。
5. セッションをまたいで休眠状態の命令が残ってしまうメモリ書き込みの異常。

シグナル　テレメトリ上での表示　ATLAS手法　緩和策の制約　指示遵守の異常　親タスクやユーザーのリクエストがないツール呼び出しAML.T0080AML.M0030ツール呼び出しのトポロジーの断絶：ワークフローの境界をまたぐ呼び出しシーケンスAML.T0053AML.M0028低帯域幅による情報漏洩　許可されたツールを介して行われる、少量かつ繰り返しのアウトバウンド書き込みAML.T0086AML.M0033対象範囲外の認証情報へのアクセス：実行中のタスクとは無関係なSecretが読み取られるAML.T0098AML.M0026メモリ書き込みの異常：ユーザートーン外での永続メモリへの書き込みAML.T0080.000AML.M0029

表7：侵害されたAIエージェントに関する5つの実行時検知シグナルと、各シグナルが観測するATLAS手法、およびそれを抑制する対策との対応関係。

製品機能ではなく、リスク軽減策に焦点を当てる。なぜなら、リスク軽減策は1年後も有効であり続けるからだ。 AML.M0033 AIエージェントコンポーネントの入出力検証および AML.M0030 「信頼できないデータに対する AI エージェントツールの呼び出しを制限する」という 2 つの項目が、検出に関連するテレメトリを最も多く生成しています。なお、ここでは「ヒューマン・イン・ザ・ループ」は単なる推奨事項ではなく、 AML.M0029 AIエージェントの行動における「ヒューマン・イン・ザ・ループ」という名前の緩和策は、以下の文献の専用セクションでも言及されている。 OWASP AIエージェントセキュリティ・チートシート および「ヒューマン・イン・ザ・ループ」に関する小節が 政府合同ガイド.

測定方法として、ある研究機関が、これまでに公表された中で唯一の「エージェント固有」の指標セットを提案していますが、これを採用したベンダーは1社もありません。その指標とは、「カバレッジ（監視対象となるトラフィックの割合）」「リコール（不適切な動作の検出率）」「応答時間」です。 同研究では、信頼できないAIエージェントを潜在的な「内部脅威」として扱うべきであると主張しており、これは正しい姿勢である。これら3つの指標を採用することで、アラートの件数とは異なる報告項目が得られる。真のエージェント実行時の可観測性、すなわちプロンプトをテキストとして記録するのではなく、ツールの呼び出しを第一級のイベントとして記録することこそが前提条件であり、それはセキュリティ可観測性というより広範な実践と並行して存在している。

実行時検出を支持する最も有力な根拠は、エクスプロイトデータである。2026年8月24日に公開されたカタログバージョン2026.08.24時点で、CISAの「既知の悪用済み脆弱性カタログ」には1,675件のエントリが収録されており、そのうち11件がAIおよびエージェントスタックに関連している。内訳は、Langflowが6件、LiteLLMが2件、MLflow、n8n、Rayがそれぞれ1件ずつである。 11件のうち6件が単一のエージェント・ワークフロー・プラットフォームに集中していること自体が注目に値する。さらに有用なのは、その発生時期のばらつきである。RayのエントリであるCVE-2025-62593は、2025年11月26日にNVDで公開され、2026年8月17日にカタログに追加された。この間には264日間の間隔がある。 対照的に、MLflowのCVE-2026-64849は2026年8月17日に公開され、2026年8月19日にカタログに追加され、是正措置の期限は2026年9月2日とされており、2日間のタイムラグが生じています。 エージェントスタックに既知の悪用されている脆弱性が存在し、それが悪用されていると誰かに指摘されるまで9ヶ月も放置されるような状況では、パッチ適用頻度だけでは不十分です。その間の挙動を監視する仕組みが必要です。

Volumeも同様の見解を示しています。OWASP独自の追跡調査（2026年4月時点の監視対象GitHubリポジトリのスナップショットに基づく）によると、n8nが57件、Claude Codeが22件、AutoGPTが15件、Difyが13件、Roo-Codeが11件のアドバイザリが記録されています。これらは監視対象のリポジトリごとの件数であり、エージェント型プロジェクトの総数ではありません。 独自のエージェントに対する敵対的テストはAIレッドチーム活動の一環であり、問題のモデル層に関する部分はGenAIのセキュリティの範疇となります。

フレームワーク、政府の指針、および規制

現在、エージェント固有の制御カタログが作成されている最中であり、これにより、各フレームワークへの参照を正確に日付付けすることは、単なる細かすぎるこだわりではなく、品質を示す明確な指標となっている。

表8：AIエージェントのセキュリティに関する枠組みおよび規制の対応表（各文書の版および日付を含む）。

「エージェント型AIサービスの慎重な導入に関する共同ガイダンス」は、これまでに公表されたエージェントに特化した管理ガイダンスの中で最も詳細なものである。 全29ページにわたる本ガイドラインでは、問題を5つのリスクカテゴリーに分類しており、報道で流布している要約ではなく、ガイドライン自体の表現を用いる価値がある。すなわち、特権リスク（7ページ）、設計・構成リスク（9ページ）、挙動リスク（9ページ）、構造的リスク（11ページ）、および説明責任リスク（12ページ）である。 ベストプラクティスの内容は、セキュアなエージェントの設計、開発、導入、運用を網羅する4段階のライフサイクルとして構成されています。5カ国にわたる6つの機関が共同で作成しました。オーストラリア信号局（ASD）傘下のACSC、CISA、NSA、カナダ・サイバーセキュリティセンター、NCSC-NZ、およびNCSC-UKです。

規制に関しては、日程が変更されたものの、公表済みのガイダンスの多くはそれに追いついていない。規則（EU）2026/1744は2026年7月8日に採択され、2026年7月24日に官報に掲載され、2026年7月27日に発効した。同規則は、2027年12月2日から附属書IIIに規定される独立した高リスク義務を、2028年8月2日から附属書Iに規定される組み込まれた高リスク義務を適用する。 2026年8月2日から適用されたのは、第50条に基づく透明性義務のみである。附属書IIIの領域において意思決定を行う、または意思決定に実質的な影響を与える企業向けエージェントは高リスクAIシステムに該当するため、2027年12月が実質的な計画期間となる。一方、第50条に基づく開示義務は、顧客向けエージェントに対してはすでに適用されている。

今後展開される動きは注目に値するが、過大評価すべきではない。NISTがAIシステムのセキュリティ確保のために策定している制御オーバーレイには、「AIエージェントシステムの活用（AIエージェント）－単一エージェント」および「AIエージェントシステムの活用（AIエージェント）－マルチエージェント」という2つのエージェント活用事例が含まれている。いずれも計画段階にあり、草案は作成されていない。現時点では、予測AIの活用事例に関するコンセプトペーパーと注釈付き概要のみが存在する。 これとは別に、2026年2月17日に発表されたNISTのAIエージェント標準化イニシアチブでは、エージェントのセキュリティおよびアイデンティティに関する研究を含む3つの柱が掲げられている。

ここでは、2つの出典に関する注記が実際の誤りを防いでいます。2026年のLLMリストは、インシデントデータに基づいて重み付けされた初版であり、その序文には7,714件の実在するインシデントからなるコーパスが記録されています。そのうち6,639件は分類に十分な詳細情報を含んでおり、重み付けはコミュニティの投票が4分の3、インシデントデータが残りの4分の1を占めています。 これらの数値や序数は、ランディングページではなく、ソースリポジトリから確認してください。同様に、OWASP『Agentic AI Threats and Mitigations v1.1』のバージョンは、ページの日付ではなくPDFの表紙に記載されているものを参照してください。また、CSA『AI Controls Matrix v1.1』には247の制御目標が含まれていますが、サフィックスのないURLでは依然として古い243のバージョンが提供されている点に注意してください。 これらすべてに対応するアプリケーション層の概念が「GenAIセキュリティ」であり、エージェント型アーキテクチャ層については、『OWASP Top 10 for Agentic Applications』で扱われています。

AIエージェントのセキュリティに関する最新のアプローチ

エンタープライズAIエージェントのセキュリティ向けツールは急速に普及しつつあり、現在では単一のカテゴリーではなく、6つのカテゴリーに分類されつつある。

• エージェントの検出とインベントリ。登録されていないエージェントを特定し、レジストリと照合する。
• エージェントごとのリスク評価。モデルではなく、そのエージェントが持つツールや認証情報の適用範囲に基づいて評価を行う。
• ツールおよびMCPへのアクセス制御。エージェントがどのツールを、どのような条件下で呼び出せるかを規定する。
• エージェントのアクション制御。実行時に特定のアクションを承認、制限、またはブロックすること。
• 実行時の動作検知。エージェントの実際の動作を監視し、逸脱があった場合にアラートを発する。
• 人間以外の主体に対する識別および委任制御。スコープ付き認証情報、委任チェーン、および失効。

AIエージェントのセキュリティソリューションにおいて、長期的に機能し続けるものとそうでないものを分けるのは、4つの質問です。登録していないエージェントも列挙するのか、それとも指定したエージェントのみを把握するのか？ ツールの起動も検知するのか、それともプロンプトのみなのか？ 検知結果を、監査可能な公開された手法分類体系にマッピングできるのか？ そして、エージェントを無効化することなく単一のツールの動作を制限できるのか？ これこそが、「制御」と「オフスイッチ」の違いなのです。

市場の行方はかなり明確です。エージェントのアイデンティティは、独立したカテゴリーとなるのではなく、既存のアイデンティティ・セキュリティのカテゴリーに組み込まれつつあり、制御カタログも成熟しているわけではなく、現在作成が進められている段階です。また、この分野で有力なベンダーのいくつかが2025年12月から2026年6月の間に経営権が移ったため、独立性は当然のこととして想定するのではなく、確認する必要があります。エージェントベースおよびエージェントレスの導入モデルについては、サイバーセキュリティソリューションの項目で扱われる、まったく別の問題です。

Vectra AIがAIエージェントのセキュリティをどのように捉えているか

AIエージェントは、他のすべてのものと同じネットワーク上で動作する新しい種類のアイデンティティであるため、これに対しても「侵害を前提とする」という同じ問いが当てはまります。もし、エージェントの認証情報を使って、そのエージェントが本来行うはずのない行動が行われた場合、環境内のどこかでそれを検知できるでしょうか？ Vectra AIの立場は、エージェントの挙動は、それを起動したプロンプトから推測するのではなく、エージェントが活動する場所――ネットワーク、ID、クラウドを横断して――で観察されなければならない、というものです。これは、侵害されたあらゆるプリンシパルに対して当社が適用している「Attack Signal Intelligence™」アプローチと同じです。つまり、「それが何であると主張しているか」ではなく、「実際に何をしているか」を監視するということです。AIセキュリティの全体像こそが、この立場の背景となっているのです。

結論

AIエージェントのセキュリティと一般的なAIセキュリティを区別する問いは、「そのモデルは安全か」ということではありません。それは、「このエージェントには何が許されているのか、そしてもしそれ以外の行動をとった場合、誰かがそれに気づくだろうか」ということです。これまでに報告されたすべてのインシデントは、前半の問いに対しては不十分な回答しか示しておらず、後半の問いに対してはさらに不十分な回答しか示していません。 ほとんどのセキュリティチームが直面している作業は、華やかさのない、段階的なものです。エージェントを列挙し、それぞれに担当者を割り当て、モデルそのものではなくツールの範囲を特定し、ツールの呼び出しを、検知が可能となるテレメトリに組み込むことです。MITRE ATLAS v2026.07では、その作業を公開された分類体系に結びつけるための29のテクニック識別子と7つの緩和策が提供されています。

周辺のアーキテクチャ、ライフサイクル、ガバナンスに関する課題に取り組んでいる場合は、このページの続きとして、当社の「エージェント型AIのセキュリティ」ガイドをご参照ください。

‍