OWASP Top 10 for LLM Applicationsは、推論を一回まわす系を想定して書かれている。入力が来て、出力が出る。その一往復のなかで何が壊れるか。だがエージェントは、そこで終わらない。記憶を持ち、自分で次の手を決め、他のエージェントと話す。 別の一覧が要るのはそのためで、OWASP Top 10 for Agentic Applicationsが2026年版として公開されている。
何が違うのか#
エージェントに固有の性質は三つある。この三つが、新しい壊れ方を生む。
状態を持つ。 会話や作業の履歴が残り、次の判断に影響する。一回きりの推論なら、汚染された入力の影響もその回で終わる。記憶に残れば、汚染は先まで効き続ける。
自分で決める。 どのツールを、どの順で呼ぶかをモデルが選ぶ。あらかじめ決められた手順を実行するのではないので、想定していない組み合わせが起きる。
複数いる。 エージェントが他のエージェントを呼ぶ構成が普通になった。一つの誤りが、系全体へ広がる経路ができる。
十項目#
| ID | 項目 | 中身 |
|---|---|---|
| ASI01 | Agent Goal Hijack | 目標そのものを書き換えられる |
| ASI02 | Tool Misuse | ツールを、認められていない使い方で呼ぶ |
| ASI03 | Identity & Privilege Abuse | 身元と権限の悪用・昇格 |
| ASI04 | Agentic Supply Chain Vulnerabilities | ツール・枠組み・登録所の出所 |
| ASI05 | Unexpected Code Execution | 隔離を越えてコードが動く |
| ASI06 | Memory & Context Poisoning | 記憶と文脈が汚染される |
| ASI07 | Insecure Inter-Agent Communication | エージェント間の通信の偽装・再送 |
| ASI08 | Cascading Failures | 一つの障害が系全体へ広がる |
| ASI09 | Human-Agent Trust Exploitation | 人がエージェントを信じすぎる |
| ASI10 | Rogue Agents | 統制の外で動くエージェント |
一位が目標の書き換えである意味#
LLM Top 10の一位はプロンプトインジェクションだった。こちらの一位はAgent Goal Hijackになる。似ているが、被害の形が違う。
一回の推論を乗っ取られても、出てくるのは一回分の誤った出力だ。目標を書き換えられると、そのあとの全行動が誤った方向へ進む。 エージェントは自分で手順を組み立てるので、書き換えられた目標に沿って、こちらが指示していない手を次々に打つ。
しかも本人は正常に動いている。指示に従って計画を立て、ツールを呼び、結果を報告する。異常として検出しにくい。
記憶が汚れると、あとから効く#
Memory & Context Poisoningは、エージェント特有の項目だ。
一度書き込まれた誤った情報が、次の会話でも、別の作業でも参照される。攻撃した時点と、被害が出る時点が離れる。入り口を見張っていても、間に合わない。
検索の索引を汚す形もある。社内文書を検索して答えるエージェントに、細工した文書を一つ紛れ込ませる。その文書は普段は無害な顔をしていて、特定の質問のときだけ働く。
だから記憶は、書き込むときと読み出すときの両方で扱いを決めることになる。何を残すか、いつ消すか、誰が書き込めるか。
身元と権限が、エージェントでは曖昧になる#
Identity & Privilege Abuseは地味に見えて、設計の根が深い。
従来のシステムでは、誰が操作しているかがはっきりしていた。利用者が操作し、その利用者の権限で処理が動く。監査ログにも利用者が残る。
エージェントが挟まると、この対応が崩れる。エージェントは自分の資格情報で動くのか、頼んだ人の資格情報を借りて動くのか。借りるなら、どこまで借りるのか。
前者だと、エージェントの権限は全利用者ぶんの和になりやすい。誰の依頼でも処理できるように、広めに渡してしまう。すると、Aさんが頼んだ作業でBさんのデータに届いてしまう。
後者だと権限は絞れるが、資格情報をエージェントに渡す経路が新しい弱点になる。どちらを選んでも、選んだ理由と、その結果できる境界を書いておく必要がある。
ツールの出所も攻撃面になる#
Agentic Supply Chain Vulnerabilitiesは、エージェントが呼ぶ道具そのものを狙う。
エージェントに機能を足すのは簡単だ。公開されているツールや連携の定義を取ってきて、使えるようにする。取ってきた先が信用できるかは、たいてい確かめられていない。
問題は、ツールの説明文がモデルへの入力になることだ。「このツールは請求書を検索します」という説明のなかに、モデル向けの指示を仕込める。利用者からは見えないまま、エージェントの振る舞いが変わる。
依存の脆弱性を追うだけでは足りない。何を呼べるようにしたかの一覧を持ち、増えたときに気づける状態が要る。
連鎖と、人の側の弱点#
Cascading Failuresは、複数のエージェントが噛み合う系の話だ。
一つのエージェントが誤った結果を返す。それを受け取った次のエージェントが、それを前提に判断する。さらに次へ。個々は正常に動いているのに、系としては全体が誤った方向へ進む。分散システムの障害伝播と同じ構造が、判断の層で起きる。
Human-Agent Trust Exploitationは、少し毛色が違う。狙われるのは人のほうだ。
エージェントの出力は流暢で、根拠まで添えて返ってくる。使っているうちに、確かめずに受け入れるようになる。その慣れを利用して、承認させたくないものを承認させる。技術で塞ぐのが難しく、運用の設計で受けることになる項目だ。
Rogue Agentsは、統制の外で動くものを指す。誰かが試しに立てたまま残っているエージェント、権限を持ったまま忘れられたエージェント。存在を把握していないものは、守りようがない。
LLM Top 10との関係#
置き換えではない。積み上がる。
エージェントもLLMを使うので、プロンプトインジェクションも機微情報の漏洩も、そのまま当てはまる。そのうえで、状態と自律性と多重性から来る項目が乗る。
見る順序としては、LLM Top 10で土台を確かめ、エージェント構成ならこちらを追加する形になる。ASVSまで含めると三層だ。アプリケーション一般、LLM固有、エージェント固有。
使うときの注意#
新しい文書であることを織り込む。 2025年12月に公開が告知された比較的新しい一覧で、番号や名前は今後動く可能性がある。引用するなら版を必ず書く。
十項目で足りるとは考えない。 これも啓発の文書で、網羅は目指していない。自分の系の構成に固有の壊れ方は、自分で洗い出すことになる。
対策の置き場所は、たいてい外側になる。 目標の書き換えも、記憶の汚染も、モデルの内部で防ぎ切ることはできない。何をさせるか、何を残すか、どこで止めるかという外側の設計で受ける。
まとめ#
この一覧を通して見ると、エージェント固有の危険はすべて継続することから出ていることが分かる。
記憶が続くから、汚染が効き続ける。判断が続くから、乗っ取られた目標が拡大する。系がつながっているから、誤りが伝播する。単発の推論には無かった時間軸が、そのまま攻撃面になっている。
任せる範囲を広げるほど、任せている時間も長くなる。その時間のなかで何が起きたかを見られること、そして止められることが、この一覧が繰り返し要求している条件になる。