AIエージェントのセキュリティは、生成AIの対策と同じ枠組みでは足りません。文章を返すだけだった仕組みが、ツールを呼び、外部システムを操作するようになったためです。本記事では、OWASPが2025年12月に公開した10分類を軸に整理します。なお確認できた一次ソースだけを使います。
先にお断りします。本記事は法的助言でも製品推奨でもありません。また規格文書の日本語訳は当社によるもので、正式な訳ではありません。原文の該当箇所は出典から確認してください。
目次
AIエージェントのセキュリティが生成AI対策と別物になる理由
まず、何を「エージェント」と呼ぶかを揃えます。総務省と経済産業省の「AI事業者ガイドライン」第1.2版を見ます。同版は令和8年3月31日の公表です。定義は次のとおりです。
本ガイドラインにおけるAIエージェントとは、特定の目標を達成するために、環境を感知し自律的に行動するAIシステムとする
同ガイドラインの脚注では、高度な自律状態だけを指すのではないと補足されています。つまりある程度の自律性を持つものも含みます。
被害が出力ではなく実行として出る
従来のLLMは、誤った出力を返すところまでが被害でした。しかしエージェントは違います。誤った判断が、実際の処理として実行されます。
具体的には、返金の承認、外部APIの呼び出し、ファイルの削除といった操作です。したがって「出力を人が読んで判断する」という前提が崩れます。
入力を信頼できない構造は変わらない
OWASPの文書は、この構造的なリスクを次のように説明しています。すなわちエージェントは型のない自然言語入力を受け取ります。そのうえで、緩やかにしか統制されていないロジックで動作するという指摘です。
they cannot reliably distinguish legitimate instructions from attacker-controlled content
正当な指示と攻撃者が制御するコンテンツを、確実には区別できない。ここが出発点です。特にコンタクトセンターでは入力元が不特定多数のため、攻撃者も顧客と同じ窓口から入力できます。
OWASPが公開したAIエージェントのセキュリティ10分類
OWASP GenAI Security Projectが、エージェント専用のリスク一覧を公開しました。名称は「OWASP Top 10 for Agentic Applications」です。公開は2025年12月でした。なお公式サイトの掲載は12月9日、プレスリリースの配信は12月10日です。ライセンスはCC BY-SA 4.0です。
なお本記事の項目名は、公式PDF版の表記に従っています。OWASP自身のブログでは短縮形が使われている項目があるためです。
ASI01〜ASI05──目的・ツール・権限・供給網・コード実行
| 番号 | 項目名 | 要点 |
|---|---|---|
| ASI01 | Agent Goal Hijack | 入力や外部データの操作で、エージェントの目標や判断経路そのものが書き換えられる |
| ASI02 | Tool Misuse and Exploitation | 正規のツールが誤用され、データ流出や処理の乗っ取りにつながる |
| ASI03 | Identity and Privilege Abuse | 委任の連鎖や権限の継承を悪用され、アクセス範囲が広がる |
| ASI04 | Agentic Supply Chain Vulnerabilities | 第三者が提供するエージェント、ツール、成果物が改ざんされている |
| ASI05 | Unexpected Code Execution (RCE) | コード生成機能や組み込みツール経由で、任意のコード実行に至る |
実際にASI02では、「ツールポイズニング」が例に挙げられています。ツールの説明文（記述子）を汚染する手口です。つまりエージェントは説明文を読んでツールを選ぶため、説明文が攻撃面になります。
ASI06〜ASI10──記憶・通信・連鎖・信頼・逸脱
| 番号 | 項目名 | 要点 |
|---|---|---|
| ASI06 | Memory & Context Poisoning | 記憶や参照データが汚染され、以後の推論や計画が偏る |
| ASI07 | Insecure Inter-Agent Communication | エージェント間の通信を傍受・改ざん・なりすましされる |
| ASI08 | Cascading Failures | 一つの誤りが自律エージェント間で伝播し、システム全体の被害に膨らむ |
| ASI09 | Human-Agent Trust Exploitation | 人がエージェントに寄せる信頼が悪用され、危険な承認へ誘導される |
| ASI10 | Rogue Agents | 本来の機能や認可された範囲から逸脱したエージェントが動き続ける |
ASI10の定義は、他の項目との切り分けを明示しています。まず外部からの侵害は、逸脱の「きっかけ」にすぎません。そしてASI10が焦点を当てるのは、逸脱が始まったあとの挙動の整合性とガバナンスの喪失です。
また同文書は「Least-Agency」という考え方を提示しました。最小権限の発想を、自律性そのものに広げるものです。価値を生まない場所にエージェント的な挙動を置けば、攻撃対象が増えるだけだとしています。
プロンプトインジェクションとAIエージェントのセキュリティの関係を整理する
ここで、よくある誤解を1つ訂正します。「プロンプトインジェクションは独立項目でなくなった」という説明を見かけますが、正確ではありません。
まずLLM向けのリストを確認します。「OWASP Top 10 for LLM Applications」は、2026年7月時点で2025年版が最新です。そしてプロンプトインジェクションはLLM01:2025として、第1位に現存しています。廃止も降格もされていません。
次にAgentic版は初版です。したがって「以前は独立項目だった」という前身のリストが存在しません。
両者の違いは射程です。LLM01:2025は、単一のモデル応答の改変に焦点を当てています。一方でASI01は、操作された入力が目標・計画・多段階の行動そのものを方向転換させる点を捉えます。つまり2つは置き換えではありません。参照範囲の違いとして読むのが正確です。
実際に起きた4件──AIエージェントのセキュリティ事故を一次ソースで読む
分類だけでは実感が湧きません。そこで公式に記録が残っているものだけを挙げます。
開発ツールとMCP経由のコード実行
まずCVE-2025-54135です。コードエディタのCursorに対する脆弱性でした。具体的には、間接プロンプトインジェクションでMCPサーバー設定ファイルを承認なしに作成させます。そのうえで任意コマンド実行に至ります。対象は1.3.9未満で、公開日は2025年8月4日です。
加えてCVE-2025-49596があります。対象はMCPサーバーのテスト用ツール、MCP Inspectorです。すなわちクライアントとプロキシの間に認証がなく、リモートコード実行に至ります。CVSS v4.0で9.4、対象は0.14.1未満でした。
拡張機能への悪意あるコード混入
次にAWSの事例です。Amazon Q Developer for VS Code拡張機能のリポジトリに、悪意あるコードが混入しました。内容はAWSリソースとローカルファイルの削除を狙うものです。そのままv1.84.0として配布されています。公開は2025年7月23日、更新は7月25日です。
ここは表現を正確にする必要があります。AWSは「実害がなかった」とは述べていません。悪意あるコードは配布されたが、構文エラーにより実行に失敗した、という説明です。
the malicious code was distributed with the extension but was unsuccessful in executing due to a syntax error
つまり設計上の防御が効いたのではなく、攻撃側の不備で実行されなかったということです。修正版はv1.85.0で、関連するCVEはCVE-2025-8217です。
Microsoft 365 Copilotの情報開示
3件目はCVE-2025-32711で、公開日は2025年6月11日です。Microsoftの公式タイトルは「AI command injection in M365 Copilot allows an unauthorized attacker to disclose information over a network」でした。CVSS v3.1は7.5です。
ここで注目したいのがCVSSベクタです。UI:N、すなわちユーザー操作を必要としません。なお「EchoLeak」「ゼロクリック」という呼称は発見者側の表現であり、Microsoftの用語ではありません。
またMicrosoftは、顧客が影響を受ける前に修正できたとしています。実被害が出た事案ではない点を落とさないでください。
AIを使った攻撃キャンペーン
4件目はAnthropicが2025年11月13日に公表した報告です。攻撃者が同社のClaude Codeを悪用し、約30の標的に対して侵入を試みたとされています。
数値の性質には注意が必要です。まず成功したのは「ごく少数のケース（a small number of cases）」です。次に「作戦の80〜90%をAIが実行した」は同社の評価であり、実測値ではありません。人間の関与も「perhaps 4-6」と推定表現で書かれています。
さらに同社は限界も注記しました。Claudeが認証情報を幻覚したり、公開情報を機密情報と誤認した例があったという内容です。したがって「AIが完全に自律して侵入した」と読むのは行き過ぎです。
国内の公的文書はAIエージェントのセキュリティをどう扱うか
海外の規格だけでは、社内の説明資料になりません。そこで国内の一次文書を3つ確認します。
DS-920が要件にしたこと
デジタル社会推進標準ガイドラインDS-920を見ます。決定は2026年6月12日、主体はデジタル社会推進会議幹事会です。なお行政の生成AI調達・利活用に関する文書です。
注目すべきは、エージェントを名指しした規定がある点です。原文を引用します。
利用者が高度なタスクを実行できるAIエージェント等を作成できる生成AIシステムの場合には、出力結果の適切さの判断を行わずにタスクを実行するものの作成を制限するか、又は利用者がこれを作成したときには利用開始前に提供者又はAI統括責任者（CAIO）に報告を求める旨の利活用ルールを整備し、周知する
つまり「人の判断を挟まずに実行するもの」を、制限するか報告させるかの二択で扱えという設計です。加えて同文書はアクセス制御と、入出力およびアクセス履歴のログ取得・管理も求めています。
IPAの10大脅威に初めて入ったAIリスク
IPAは2026年1月29日に「情報セキュリティ10大脅威 2026」を公表しました。組織向けの3位に「AIの利用をめぐるサイバーリスク」が初めて選出されています。1位はランサム攻撃による被害、2位はサプライチェーンや委託先を狙った攻撃でした。
一方でJPCERT/CCからは、AIエージェントを対象とした注意喚起は出ていません。2026年7月時点の注意喚起一覧で確認した結果です。
国内企業のAIエージェントのセキュリティ実装は公表が薄い
企業側の公表事例も探しました。富士通は2024年12月12日に、マルチAIエージェントセキュリティ技術を「世界初」として発表しています。ただしこれは同社発表による表現で、根拠や比較範囲を示す注釈はありません。
技術の中身も公表されています。まず本番環境から検証用の仮想環境を自動構築し、シミュレーションを隔離実行します。加えて組織間の協働では、ポリシー制御とデータ秘匿を行うとしています。
もちろん他社も導入は進めています。しかし「人の承認・最小権限・監査ログ」を具体的に書いたプレスリリースは、今回の調査では見つかりませんでした。したがって現時点では、DS-920のような公的文書を社内基準の下敷きにするほうが確実です。
コンタクトセンターでAIエージェントのセキュリティを設計する4点
ここまでを実務に落とします。すべてを一度に満たす必要はありません。ただし次の4点は、規格側と国内文書の双方が共通して求めています。
| やること | 目的 | 対応する分類 |
|---|---|---|
| ツールごとに権限を絞る | 乗っ取られても実行できる範囲を限る | ASI02 / ASI03 |
| 取り消せない操作の前に人を挟む | 被害の確定を防ぐ | ASI09 / DS-920 |
| 監視をエージェントから独立させる | エージェント自身の報告に依存しない | ASI10 |
| 止めるスイッチを用意する | 異常時に人が停止できる | ASI08 / NIST |
ツール単位で権限を絞る
まず、エージェントに1つの強い権限を渡す設計をやめます。返金、解約、個人情報の参照は、それぞれ別のツールとして分けてください。
そのうえで各ツールに上限を設けます。金額、件数、対象範囲のいずれかで区切る方法が現実的です。
取り消せない操作の前に人を挟む
次に、取り消せる操作と取り消せない操作を分類します。送金、削除、外部送信は後者です。
DS-920が示した基準は、そのまま民間でも使えます。すなわち出力結果の適切さを人が判断してから実行する形にするか、事前に責任者へ報告させるかです。
監視をエージェントから独立させる
さらに、ログの取得主体を分けます。エージェント自身が書く実行ログだけでは、逸脱したときに信頼できないからです。
OWASPはASI10の緩和策を2つ挙げています。1つは改ざんできない署名付きの監査ログです。もう1つはピアの出力を検証する監視エージェントです。まずは前者から着手するのが現実的でしょう。
止めるスイッチを用意する
最後に停止手段です。NISTのAI リスクマネジメントフレームワーク1.0は、MANAGE 2.4で次を求めています。2023年1月26日の公表です。
Mechanisms are in place and applied, responsibilities are assigned and understood to supersede, disengage, or deactivate AI systems that demonstrate performance or outcomes inconsistent with intended use
置換・切断・停止の仕組みを用意し、責任の割当てまで明確にせよという内容です。実際に運用してみると、「誰が止めていいのか」が決まっていないケースが少なくありません。
まとめ：AIエージェントのセキュリティは設計で決まる
本記事の要点を整理します。
- まずエージェントでは、被害が出力ではなく実行として現れます
- OWASPは2025年12月に、ASI01からASI10までの10分類を公開しました
- プロンプトインジェクションは廃止されていません。LLM01:2025として現存しています
- 実際の事故は、開発ツール、拡張機能、Copilot、攻撃キャンペーンの4系統で記録が残っています
- 国内ではDS-920が、人の判断を挟まない実行の制限または報告を要件化しました
- 実務では、権限の分割、人の承認、独立した監視、停止手段の4点から着手できます
なお期日の話も1つ加えます。EU AI Actの第50条の透明性義務は、2026年8月2日から適用されます。ただしDigital Omnibus on AI（規則(EU) 2026/1744）で経過措置が入りました。対象は同日より前に上市済みの生成AIシステムです。すなわち第50条(2)のマーキング義務に、4か月の猶予が新設されました。同規則は2026年7月8日採択、7月24日官報掲載、7月27日発効です。
個別の法的判断は、必ず自社の法務および専門家にご確認ください。
出典
- OWASP GenAI Security Project「OWASP Top 10 for Agentic Applications」2025年12月（リソースページ／公式ブログ 2025年12月9日）
- OWASP GenAI Security Project「OWASP Top 10 for LLM Applications 2025」（公式ページ）
- NVD「CVE-2025-54135」2025年8月4日公開（NVD）
- GitHub Security Advisory「GHSA-7f8r-222p-6f5g（CVE-2025-49596）」（Advisory）
- AWS「AWS-2025-015」2025年7月23日公開・7月25日更新（セキュリティ速報）
- NVD「CVE-2025-32711」2025年6月11日公開（NVD）
- Anthropic「Disrupting the first reported AI-orchestrated cyber espionage campaign」2025年11月13日（公式）
- 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」令和8年3月31日（本編PDF）
- デジタル社会推進会議幹事会「DS-920 行政の進化と革新のための生成AIの調達・利活用に係るガイドライン」2026年6月12日決定（PDF）
- IPA「情報セキュリティ10大脅威 2026」2026年1月29日（公式）
- JPCERT/CC「注意喚起（2026年）」（一覧）
- 富士通「世界初、脆弱性や新たな脅威への事前対策を支援するマルチAIエージェントセキュリティ技術を開発」2024年12月12日（プレスリリース）
- NIST「AI Risk Management Framework 1.0（NIST AI 100-1）」2023年1月26日（PDF）
- EUR-Lex「Regulation (EU) 2026/1744」OJ L, 2026/1744, 24.7.2026（EUR-Lex）
