Agentic AIが押し上げたリスク

Agentic AIのリスクについては、OWASP GenAI Security Project内の別フレームワークにて更に深掘りがされています。第1回で説明した通り、LLMアプリケーションに包含されるAgentic AIが普及したことが、順位変動に大きく影響しました。特に、LLM03: Excessive Agencyが第3位に上昇していることから分かります。一方で、記載される内容に特別付加されたわけではないことから、従来考えられていたことが実世界で表面化したと捉えるべきでしょう。

他の項目、例えば不動だったLLM01: Prompt Injectionの場合、エージェントの項目が大きく追加されています。インジェクションの効果を拡大させる要因の一つとして、agentic executionとして記載がされており、その中で示されるリスク例の3つ目が正にagentic executionの例を示しています。

3.Trusted-surface indirect injection: text planted in a low-privilege but trusted channel (issue tracker, feedback form, support ticket) makes the user's LLM act under its own elevated credentials, exfiltrating repositories, dumping databases, or modifying IDE config, actions the attacker could not perform directly (Invariant Labs, 2025; General Analysis, 2025; Rehberger, 2025a).^[1]
3.信頼された面による間接プロンプトインジェクション：権限は低いものの信頼されたチャネル（課題追跡システム、フィードバックフォーム、サポートチケット）に埋め込まれたテキストにより、ユーザーのLLMが昇格した認証情報の下で動作し、リポジトリからの情報漏洩、データベースのダンプ、IDE設定の変更など、攻撃者が直接実行できなかったアクションを実行する （Invariant Labs, 2025; General Analysis, 2025; Rehberger, 2025a）。（筆者訳）

この例から学ぶべきは、RAGのような明確に信頼された範囲にいるであろうシステムだけでなく、外部の信頼性検証が低いツールを含めたシステム中に、埋め込まれたテキストが攻撃面として機能してしまうことです。最近であれば、Agentic AIの肝であるAPIレスポンスをLLMに渡して自律的に思考・実行する構成がMCPにより容易になり、広がりつつあるため、このリスクの広がりが想像できます。

実際に、筆者のローカルLLM（Gemma 4 E2B^[2]）環境で簡単な再現を試みました（図1、2参照）。MCPサーバーが汚染されているとして、その汚染された説明文を定義し、LLMに渡すと、その内容を信じてしまうことが確認できました。なお、MCP（Model Context Protocol）は、LLMアプリケーションから外部のデータやツールを共通の形式で利用できるようにするためのプロトコルです。ツールの実装コード自体は一切変更していません。書き換えたのは、モデルに読み込ませる説明文のテキストだけです。OWASPも、この点をLLM01:2026の対策項目の中で明確に指摘しています。

Pin, sign, and verify every MCP server and third-party tool package, audit tool descriptions for hidden instructions, and monitor tool composition... Pinning does not stop a payload shipped in the pinned version or tool-description poisoning that leaves the version unchanged.^[3]
（すべてのMCPサーバーとサードパーティ製ツールパッケージを固定・署名・検証し、ツールの説明文に隠された指示がないか監査し、ツール構成を監視すること……バージョンを固定しても、固定されたバージョンに同梱されたペイロードや、バージョンを変えないまま行われるツール記述子の汚染は防げない。）（筆者訳）

つまり、バージョン管理やハッシュ固定といった従来のサプライチェーン対策を徹底していても、自然言語の説明文部分だけを書き換える汚染は素通りしてしまいます。今回の簡単な検証でも、特別なエクスプロイトコードや複雑な手順は不要で、モデルに渡す説明文の一文を差し替えるだけで危うい回答を引き出すことができました。

図1： MCPサーバーの汚染例

図2：MCPサーバーが汚染された場合のローカルLLMの回答（抜粋）

サプライチェーンリスクから見るOWASP Top 10 for LLM Applications 2026

前項を踏まえると、MCPをはじめとする外部ツールの出力検証などがサプライチェーンリスクとして重要だと思ってしまいそうですが、LLM04: Supply Chainを見ると入っていません。そして、冒頭の記載にはこうあります。

Supply-chain risks specific to agentic applications, including MCP servers and tool registries, are covered by ASI04 Agentic Supply Chain Vulnerabilities in the OWASP Top 10 for Agentic Applications (OWASP GenAI Security Project, 2026), ...^[4]
（MCPサーバーやツールレジストリなど、エージェント型アプリケーションに特有のサプライチェーンリスクについては、OWASP Top 10 for Agentic Applications（OWASP GenAI Security Project, 2026）のASI04 Agentic Supply Chain Vulnerabilitiesで扱われており...）（筆者訳）

サプライチェーンリスクだけではありませんが、OWASP GenAI Security Projectの立て付け通り、Agentic AIのリスクはOWASP Top 10 for Agentic Applications等で見なければならないと分かります。

LLM04: Supply Chainで考えられている脅威の全体像は図3の通り紹介されています。Hugging Face上などに上げられる一般公開されているLLMやアダプタ（主にファインチューニング目的等に使われるもの）、データセット、ライブラリ等が攻撃対象となっています。従来のSBOMといったサプライチェーン保護の概念を延長して、ML-BOMやAI-BOMといった概念も重要だと理解できます。

図3： LLM04: Supply Chainで考えられている脅威の全体像^[5]

従来の脆弱性対策とAI時代の対策の違い

ここまで見てきたガードレール的な対策（入出力のフィルタリングやサニタイズ）は、LLM01: Prompt Injectionのような「入出力の内容そのもの」に起因するリスクには一定の効果はあるが、現時点では信頼できる防止手法は無いと本文中でも明言しています。つまり、LLM03: Excessive Agencyの根本原因である「過剰な機能」、「過剰な権限」、「過剰な自律性」の3つは、入出力フィルタでは塞げず、権限設計（何を、どこまで実行させるか）そのものを見直す必要があります。同様の考え方はPrompt Injectionの対策方針にも表れています。OWASPは「現時点で信頼できる防御メカニズムは存在せず、防御はインターセプト型ではなくアーキテクチャ型であるべきだ」と述べ、モデルの指示境界がいずれ突破されることを前提にシステム全体を設計するよう求めています。

これは、従来型の脆弱性対策（WAFによる入力フィルタ、シグネチャベースの検知など）が「入口で悪意ある入力を止める」という発想に立っていたのに対し、LLMアプリケーションでは「入口を完全には守り切れない前提で、突破された後の被害範囲を設計段階で縮小しておく」ことが求められます。前項で見た「バージョンを固定しても記述子の汚染までは防げない」というサプライチェーン領域の限界も、根っこは同じ構造です。対策すべきレイヤーが単純に増えたのではなく、どこに信頼の境界線を引くかという設計思想そのものが変わったと捉えるべきでしょう。なお、これは既存のセキュリティ基準を全て置き換えるという意味ではありません。OWASP自身、Appendix Aで今回のTop 10各項目をMITRE ATT&CK／CWE、NIST AI RMF、CSA AI Controls Matrix（AICM）など9つのフレームワークへマッピングしており（表1参照）、既存のセキュリティ管理体制にAI固有の観点を組み込んでいく形が現実的な着地点になります。

総括：信頼境界を設計し直す

第1回では、OWASP Top 10 for LLM Applications 2026がもたらした最大の変化は、これまで専門家の判断だけに委ねられてきたランキングが、7,714件の実インシデントという「証拠」によって裏付けられたことだとご紹介しました。この変化は、モデル単体の入出力だけでなく、モデルを取り巻くシステム全体、とりわけツール呼び出しや外部コンポーネントとの接点にリスクが集中していることを示しています。第2回では、そのうちの2つの側面を技術的な面で掘り下げました。一つは、信頼された面（trusted surface）を悪用した間接注入やMCPツールの説明文の汚染のように、コードを一切変更せず、テキスト情報の書き換えだけで成立する入力側の攻撃面です。もう一つは、LLM04: Supply ChainでAI・機械学習固有の構成要素に対象を広げたものです。両者を並べて見ると、「モデルに何を読み込ませるか」というテキストの信頼性の問題と、「モデルそのものやその構成部品をどこから調達するか」という信頼性の問題は、別々に対策すべき異なる攻撃面だと分かります。

LLMアプリケーションの入出力を検査するガードレールツールは重要ですが、それだけではすべてのリスクに対応できません。LLM03: Excessive Agencyのように根本原因たる「過剰な機能」、「過剰な権限」、「過剰な自律性」を見逃すためです。求められているのは対策レイヤーの単純な追加ではなく、「どこまでをモデルに委ねてよいか」という信頼境界の設計そのものを見直すことです。それは既存のセキュリティ基準（SBOM、NIST AI RMF、CSA AICMなど）を捨てることではなく、その上にLLMアプリケーション固有の観点を積み重ねていく作業に他なりません。
なお、当社では、NTTデータ社と連携して、AIレッドチーミングやAIガードレールを含め安心・安全なAI利用を支援するサービスを提供していますので、お気軽にお問い合わせください。
AIの安心・安全な活用を支援する「Responsible & Secure AI」サービスを本格展開 | 株式会社NTTデータ先端技術

参考文献