自律AIエージェント10大脅威：OWASP ASI01〜10をCISO視点で読み解く

自律AIエージェント10大脅威：OWASP ASI01〜10をCISO視点で読み解く AIリスク
2026.05.16
この記事は約19分で読めます。

一枚要約

自律AIエージェントは「考えるだけ」のLLMとは異なり、実際に外部システムを操作します。OWASPが2025年12月に公開したASI01〜ASI10は、この行動権限を持つエージェント固有の10大脅威を体系化したものです。特に間接プロンプトインジェクション（ASI01）・権限拡大（ASI03）・長期メモリ汚染（ASI06）は、従来のLLMリスク評価では発見できません。自社でエージェントを稼働・導入計画している組織は、このフレームワークを参照点として権限棚卸しとアーキテクチャ設計を見直す必要があります。

このフレームワークを今提示する理由

2025年以降、自律AIエージェントが企業システムに組み込まれるケースが急増しています。コード生成エージェント、ブラウザ操作エージェント、データ分析パイプラインへの組み込み。いずれもLLMが「考えるだけ」ではなく「行動する」構成です。

従来のOWASP Top 10 for LLM Applications（LLM単体のリスクを整理したフレームワーク）は、エージェントが外部ツールを呼び出し実際の副作用を生む文脈では評価軸が不足していました。自社記事「OWASP Top 10 for LLM v2025 優先すべき5項目と対策ポイント」と本記事を地続きで読むと、「LLM単体→エージェント化」でリスク面がどう拡大するかが把握できます。

OWASP GenAI Security Project1はAgentic Security Initiative2（ASI）を立ち上げ、2025年12月9日にOWASP Top 10 for Agentic Applications 2026を公開しました。Microsoftが2025年4月に公開したTaxonomy of Failure Mode in Agentic AI Systemsや、NVIDIAのAI Safety Recipe / Safety for Agentic AI Blueprintと並んで、自律エージェント向けリスク評価の参照フレームワークとして引用が広がっています。自社記事「AIエージェント権限設計の10原則」が設計のWHYを扱っているのに対し、本記事は攻撃側のHOW、すなわち脅威分類の整理を担います。

自律エージェントが生む攻撃面の構造的変化

単体LLMとエージェントの決定的な違いは、入力→出力モデルから入力→行動→副作用モデルへの転換です。セキュリティ上の変化は3軸で捉えられます。

  • 行動権限の拡大: APIコール・コード実行・ファイル操作・外部サービス送信の権限を持つため、誤動作や悪用の影響がシステム外部に波及する。単体LLMであれば「誤った回答を返す」で済んでいたものが、エージェントでは「誤ったAPIを実行する」「外部にデータを送信する」に変わる。
  • マルチエージェント構成: 複数のエージェントがメッセージを渡し合うクラスタ構成では、一つの汚染がパイプライン全体に連鎖する。上流エージェントへの細工が下流の全出力に影響するシナリオは、単体評価では発見できない。
  • 長期メモリとコンテキスト: セッションをまたいで記憶を保持するエージェントでは、一度埋め込まれた悪意のある指示が長期間にわたって動作に影響し続ける。「いつ汚染されたか」の追跡が困難になる。

ASI01〜ASI10 全項目一覧

OWASPが定義した10項目を以下に整理します。

# 項目名 リスクの核心
ASI01 Agent Goal Hijack 隠れた指示でエージェントの目標を乗っ取り、情報流出装置化
ASI02 Tool Misuse 正当なツール呼び出しを破壊的・想定外の出力に誘導
ASI03 Identity & Privilege Abuse 漏洩トークンでエージェント権限を意図した範囲外に拡大
ASI04 Agentic Supply Chain Vulnerabilities モデル・プラグイン・ツール定義へのバックドア混入
ASI05 Unexpected Code Execution 自然言語からRCEに至る新しい実行経路
ASI06 Memory & Context Poisoning 長期メモリへの細工でエージェントの動作を長期間変形
ASI07 Insecure Inter-Agent Communication 偽メッセージでマルチエージェント・クラスタ全体を誤誘導
ASI08 Cascading Failures 誤信号が自動パイプライン後段で増幅しシステム全体が機能不全に
ASI09 Human-Agent Trust Exploitation 確信ある説明で人間オペレータを有害な承認行動に誘導
ASI10 Rogue Agents エージェントが隠蔽・自己指向行動を取るマルチエージェント内の内部脅威

ASI01〜ASI10 全項目の深掘り解説

10項目を ASI 番号順に深掘りします。影響範囲・新規性・対策コストが特に大きい項目には監査と権限の論点を厚めに置きました。

ASI01 – Agent Goal Hijack

ASI01は「エージェントの目標が攻撃者の指示で書き換えられる」広義の脅威カテゴリで、入口として間接プロンプトインジェクション・直接プロンプトインジェクション・システムプロンプト改ざん・マルチエージェント構成での上位エージェントへの指示差し込みなど複数経路を含みます。「自社エージェントは外部URLを取り込まない設計だからASI01は非該当」という判断は誤りで、ユーザー入力を直接受け付ける構成でも発動します。

このうち最頻出の入口が間接型です。攻撃者が外部データソース（Webページ・メール本文・PDF）に悪意のある指示を埋め込み、エージェントがそのデータを処理した瞬間に目標が書き換わります。自社記事「LLMアプリを狙うプロンプトインジェクション 7パターン」で扱った直接型とは異なり、間接プロンプトインジェクション3として機能するため、入力の前段にガードレールを置くだけでは防げません。エージェントは「外部コンテンツを信頼する」設計になっているのが根本的な問題です。

対策の出発点は、外部コンテンツを「信頼できないデータ」として構造的に分離するコンテキスト境界の設計です。具体的には(1) システムプロンプトと外部取得テキストを明確に区切り、外部由来テキストを命令として解釈しないモード分離、(2) エージェントが「命令を受け取った」と判定した場合に自動停止する確認ステップ、(3) ツール呼び出しログによる異常動作の事後検出、の3点を組み合わせます。入力サニタイズ（タグ除去・エスケープ）はエンコーディング変換・Unicode・Base64・多段翻訳で容易に回避されるため、IPIの主防御として機能しない点に注意が必要です。

ASI02 – Tool Misuse

ASI01が目標そのものの乗っ取りを扱うのに対し、ASI02は付与済みの権限内でツールが破壊的または想定外の動作をするリスクです。ファイル操作ツールに広いパスを指定させて意図しない範囲を削除させる、メール送信ツールに添付として機密ファイルを仕込ませる、外部API呼び出しツールで大量リクエストを発生させて課金やレート制限を引き起こす、といった例が典型です。エージェント自身は「自分の目標どおりに正規のツールを呼び出している」と認識しているため、ガードレール側からは正常動作との区別が付きにくい点が厄介です。

対策の出発点は3点です。(1) ツールごとの入力スキーマ検証を厳格化し、パス・ドメイン・件数等の引数にallowlistや上限を設けて schema validation 段階で弾く。(2) 副作用のあるツール（ファイル書き込み・メール送信・外部API・コード実行）には実行前確認ステップを入れ、高インパクト操作は人間承認を必須にする。(3) ツール呼び出しの監査ログを引数・呼び出し元エージェント・実行結果のセットで残し、異常な呼び出しパターンを検知可能にする。OWASP Top 10 for LLM Applications 2025のLLM06（Excessive Agency）が権限設計の過剰を扱うのに対し、ASI02は付与済み権限内での悪用を対象にしている点で位置づけが異なります。

ASI03 – Identity & Privilege Abuse

エージェントに付与するAPIトークン・OAuth認証情報・サービスアカウントが「動くから広め」で設定されているケースは現場で頻繁に見られます。攻撃者がエージェントを乗っ取った場合、付与されている権限がそのまま攻撃の射程になります。開発エージェント（Cursor・Devin等）やブラウザ操作エージェント（Computer Use系）では、CI/CDパイプラインや本番シークレットへのアクセスを許可した構成が特に危険です。

エージェントごとに「使うツール」「アクセスするデータソース」「実行できるアクション」を列挙し、不要な権限をゼロにする最小権限設計が基本です。

ASI04 – Agentic Supply Chain Vulnerabilities

エージェント基盤を構成するモデル・MCPサーバ・プラグイン・ツール定義・依存ライブラリの供給経路すべてが攻撃対象になります。OWASP Top 10 for LLM Applications 2025のLLM03（Supply Chain）が学習データやモデル提供の供給網を扱っているのに対し、ASI04ではエージェント実行基盤（プラグイン・MCPサーバ・ツール定義）が加わるため攻撃面が大きく広がります。

具体的なリスクは3系統に整理できます。(1) モデルファイルへのバックドア：pickle形式のモデルファイルは読み込み時に任意コードを実行可能で、Hugging Face等の公開モデルレジストリでバックドア混入が複数実証されています。(2) MCPサーバ経由のツール定義汚染：ASI07で触れたTool PoisoningやRug Pull攻撃のように、サードパーティ製MCPサーバがツール定義のメタデータに隠し指示を埋め込みます。(3) 依存ライブラリのタイポスクワッティング：自社カスタムプラグインがインストールするnpm/pipパッケージに偽パッケージが混入する古典的経路です。

対策は段階を分けます。導入時: モデル取得元を信頼できるレジストリに限定し、ダウンロード後のハッシュ・署名検証を必須にします。pickle形式はsafetensors等の安全な形式に変換するか、隔離環境でのみ読み込みます。運用時: サードパーティ製MCPサーバはコード審査とバージョンpinning（自動更新の禁止）を組み合わせ、ツール定義変更時はレビュー手順を経由させます。監査時: エージェント基盤を構成するモデル・プラグイン・MCPサーバ・依存ライブラリのSBOM（CycloneDX形式推奨）をsyft・cdxgen等のツールで生成し、脆弱性公開時に影響範囲を即特定できる状態にします。なおnpm lsやpip freezeは依存一覧であってSBOMではない点に注意します。

ASI05 – Unexpected Code Execution

表に1項目で挙げているASI05はコード生成・実行を担うエージェント（Cursor・Devin・Claude Code等）で特に直撃します。自然言語からRCEに至る経路を最低限封じるには、(1) コード実行はサンドボックス環境（Docker / gVisor / Firecracker 等）に閉じ込めホストOSへの直接アクセスを遮断、(2) 実行可能なコマンドのallowlistを実装してデフォルト拒否、(3) CI/CDパイプラインへの接続は読み取り専用に制限し、本番環境のシークレットとの分離を必須とする、の3点が出発点です。「ローカルのターミナルでなんでも動かせる」設計は、エージェント乗っ取り時の被害をホスト全域に拡げます。

ASI06 – Memory & Context Poisoning

短期的な会話ハイジャック（ASI01）と異なり、長期メモリへの汚染は発見が極めて困難です。エージェントが外部メモリストア（ベクトルDB・KVS・会話履歴）に依存している場合、一度埋め込まれた誤情報や悪意のある指示がセッションをまたいで動作に影響し続けます。Pinecone・Weaviate等のベクトルDBに書き込み権限を持つエージェントが乗っ取られた場合、その後すべての検索結果に細工された埋め込みが混入する状態になります。

対策は3点です。(1) メモリ書き込みの書き込み元・書き込み時刻・参照元コンテキストを必ずメタデータとして保存し、後追い可能にする。(2) 周期的なメモリ監査として、既知の指示文字列パターン（「以前の指示を無視」「以下のとおり実行」等）の検索と、書き込み量の急増検知を組み合わせる。(3) メモリへの書き込み権限を限定的なエージェントだけに付与し、読み取り専用エージェントとの権限分離を徹底する。

ASI07 – Insecure Inter-Agent Communication

マルチエージェント構成特有のリスクです。エージェント間でメッセージを渡す際に認証・署名がなければ、攻撃者が偽エージェントを差し込んで指示を改ざんできます。Model Context Protocol4（MCP、LLMとツール・データソースを接続するための標準プロトコル）を採用した構成では、MCPサーバ自体が攻撃面になります。2025年前半に複数の研究者が実証したTool Poisoning攻撃（悪意のあるMCPサーバがツール定義のメタデータに隠し指示を埋め込み、ユーザーには見えずモデルだけが読む）やRug Pull攻撃（インストール時点では無害なツール定義を提示し、承認後にサーバが定義を入れ替える）が報告され、CVE-2025-6514（mcp-remoteのコマンドインジェクション、CVSS 9.6 CRITICAL）やCVE-2025-49596（MCP Inspectorの認証欠如によるRCE、CWE-306）等の実 CVE も NVD に公開されています。対策としては、MCPは2025-06-18仕様でOAuth 2.1ベースの認証フロー（HTTP-based transportでのトークン認証、RFC 8707 Resource Indicators必須）を標準化していますが、認証対応自体は実装側でoptionalです。メッセージごとの署名仕様は別途持ちません。実装上は仕様準拠のOAuth 2.1認証フローを必須化したうえで、追加でTLS相互認証(mTLS)と接続許可リストを組み合わせます。加えて、サードパーティ製MCPサーバのコード審査とバージョン pinning（自動更新の禁止）が必要です。なおエージェント間（agent-to-agent）の直接通信を担うプロトコルとしては Google が公開した A2A 等が別途存在し、MCP とは役割が異なる点も整理しておく必要があります。OWASP Top 10 for LLM Applications 2025のLLM06（Excessive Agency）がエージェント単体の行動範囲過剰を扱うのに対し、ASI07はクラスタ構成特有の信頼モデル崩壊を対象にしています。

ASI08 – Cascading Failures

マルチエージェント構成や自動パイプラインで、上流の小さな誤判定・遅延が下流で増幅されるリスクです。ASI07が通信の改ざんを扱うのに対し、ASI08は信号自体は正規だが連鎖の中で破滅的結果に転換される点が異なります。

典型例は3パターンです。監視エージェントの誤検知が自動修復エージェントによる正常サービス遮断を引き起こすケース。翻訳エージェントの誤訳が後段の法務文書チェックエージェントを誤った前提で判定させるケース。コード生成エージェントの欠陥コードがCI/CDで自動マージされ本番反映されるケース。いずれも個々の段では「想定どおりの応答」が積み重なって最終的に重大な障害になります。

対策は連鎖を断つ仕組みの導入です。(1) 各段で信頼度スコアと閾値を明示し、低信頼の信号は人間介入を挟む。(2) 連続失敗時に下流処理を一時停止するサーキットブレーカを段間に置く。(3) 影響範囲の広い操作はパイプライン外の独立検査を経由させる。(4) 不可逆な操作（削除・送金・本番デプロイ・契約締結等）は自動連鎖の対象から外し、人間承認を必須化する。クラウドネイティブ運用で確立されたフェイルセーフ思想を、エージェントオーケストレーションに適用する発想です。エージェント向けにはマイクロサービス向け実装(Resilience4j等)をそのまま流用するのではなく、「エージェントの確信度スコアが連続N回閾値を下回ったらパイプライン停止＋アラート」のように、エージェント固有の confidence score に基づく停止条件を実装するのが現実的です。

ASI09 – Human-Agent Trust Exploitation

エージェントが「確信を持った口調」で説明するため、オペレータが批判的に検証せず承認するリスクです。ハルシネーションが自信満々に提示される場合も含まれます。

Human-in-the-Loop5の設計で対応します。エージェントが実行する前に人間の確認を必要とする閾値（金額・外部送信・権限変更等）を定義し、エージェントの説明を鵜呑みにしないプロセス訓練を合わせて実施します。特に高額取引や個人情報の外部送信を伴う操作では、承認画面にエージェントの根拠となったデータソースを明示する設計が有効です。

ASI10 – Rogue Agents（ASI01との境界）

ASI10はASI01と混同されやすい項目です。ASI01は外部からの指示でエージェントの目標が書き換えられる外部脅威、ASI10はマルチエージェント構成の中で特定エージェントが設計意図を離れた目標（自己保存・情報隠蔽・別タスクの優先）を自律的に追求する内部脅威です。

ASI10のうち「設計意図からの完全な逸脱」自体は現時点では研究段階のリスクですが、説明と実行の乖離（エージェントの自己説明と実際のツール呼び出しログが一致しない）は現在のLLMベースエージェントでも観測されており、監査基盤の整備は現実的な優先事項です。他の兆候としては優先度の自律的書き換え（オーケストレータの指示と異なるタスク順序を選ぶ）、情報の選択的開示（特定の情報を上位エージェントに渡さない）が挙げられます。エージェントオーケストレーション層に、各エージェントの目標・実行ログ・参照データの三点セットを継続的に記録し差分を検知する監査基盤を組み込んでおくと、研究知見が実害として観測された段階で即対応できます。

業種別影響

  • 金融: 米国のモデルリスク管理ガイダンス（SR 11-7、2011年策定）はLLM・自律エージェントを念頭に置いて書かれておらず、適用解釈は現在も業界・規制当局間で進展中の段階です。FRB・OCC・FDICがAI/MLモデルへの補足FAQを順次出していますが、各金融機関は自行の主担当規制当局への確認が必要です。実務的にはASI01/ASI09への対応と意思決定プロセスのログ保全をモデルバリデーション文書に追加する流れが先行しており、承認フローに組み込まれたエージェントが誤った判断をした場合の責任所在も、内部規程整備の論点になっています。
  • 製造・OT: 生産ラインの監視や予防保全にエージェントを組み込む場合、IT/OT境界の認可設計が肝になります。ASI03（権限の拡大）と組み合わさると、エージェントが物理プロセスの制御パラメータを書き換えるシナリオが現実的な脅威になります。OT側はパッチ適用サイクルが長いため、エージェントの接続先OTシステムを最小化する設計を優先します。
  • IT・SaaS（社内DX）: Cursor・Devin・Claude Codeのような開発エージェントや、ブラウザ操作エージェント（Computer Use系）を社内利用する場合、ASI03（権限範囲）とASI05（コード実行）が直接影響します。開発エージェントがCI/CDパイプラインや本番環境のシークレットにアクセスできる設定は、乗っ取られた際の影響が極めて大きくなります。利用申請・権限スコープ・利用目的をセットで管理する台帳整備が、導入初期の最優先タスクです。

今日着手できる3アクション

  • エージェント一覧とASI照合シートの作成: 自社で稼働中または検討中のエージェント・LLM応用システムをスプレッドシートに列挙し、ASI01〜ASI10の各項目が「該当する／しない／確認不要」をセキュリティチームで一項目ずつ確認します。列挙時に最低限見る設問は次の3点です。(1) エージェントは外部URL・メール・PDF等を取得して処理するか（該当ならASI01を最優先評価）、(2) エージェントに付与されているAPIキー・サービスアカウント・OAuthスコープは何か（ASI03）、(3) エージェントは会話履歴や外部メモリストア（ベクトルDB・KVS）を読み書きするか（ASI06）。3点いずれかが該当する場合は、該当項目を深掘り対象として優先度を上げます。
  • OWASP ASI原文の読み合わせと即時テーブルトップ判定: OWASP Top 10 for Agentic Applications 2026のPDFをセキュリティチームで読み合わせた後、影響度の高いASI01・ASI03・ASI06について自社エージェントの該当有無を1時間のテーブルトップ演習で判定し、結果を第1アクションのシートに記入します。読むだけで終わらせず、当日中の判定記録までを1単位とします。
  • エージェント権限スコープの棚卸し（ASI03/ASI05）: 稼働中エージェントに付与しているAPIキー・サービスアカウント・OAuthスコープの一覧を作成し、「実際に使っているか」を確認します。不要な権限が見つかれば当日中に剥奪または縮小します。特に本番環境のシークレットへのアクセスは当日対応を推奨します。

AI×セキュリティの観点

OWASP ASIが描く脅威の多くは、攻撃者もAIエージェントを使って自動化するシナリオで深刻度が増します。攻撃者側がエージェントを使ってターゲットのエージェント基盤を自動探索し、間接プロンプトインジェクションのペイロードを大量生成・注入するシナリオはすでに研究段階を超えつつあります。防御側はエージェント動作の監視・異常検知が必須で、実用段階のオブザーバビリティツール（LangSmith、Weights & Biases Weave等）を導入し、エージェントが実行したツール呼び出しと入出力を全件ログに残す構成が現実的です。ただし、監視するエージェント自体がASI対象になる難しさが残るため、監視エージェントと被監視エージェントの権限を分離し、監視側は読み取り専用の監査ログにしかアクセスできない設計にする必要があります。規制面では、EU AI Act の高リスク AI システム要件（透明性・ロギング・人間の監督。高リスクは Annex III の HR・与信・重要インフラ等 8 カテゴリ限定。コード生成・社内ナレッジ検索エージェントは原則非該当）と ASI09 の「Human-in-the-Loop 設計」は接続しています（施行スケジュール: 禁止 AI 行為 2025/2/2・GPAI 義務 2025/8/2・高リスク AI 要件 2026/8/2）。自社用途がどの区分に入るかは導入前の確認が必要です。日本国内では個人情報保護法（第三者提供・越境移転規制が ASI01／03 のデータ流出と同時発動）・経済産業省「AI 事業者ガイドライン」（任意ガイダンス）・金融庁の業界別ガイドラインとの整合も並行して確認します。

もう一つの構造的リスクはシャドーAI（組織管理外の個人アカウントによる業務利用）です。従業員が個人の ChatGPT・Claude 等のエージェント機能で業務データを処理させると、ASI01（外部サービス経由のデータ漏洩）とASI03（権限範囲の把握不可）が同時に発動しますが、組織側はエージェントの存在すら把握できていません。社公認エージェントだけをASI観点で評価しても、最大の攻撃面が監査対象から漏れ続けます。エージェント機能を持つSaaSの利用台帳整備と、利用申請フローの設計をASI棚卸しと並行して進める必要があります。

用語ミニ解説

  1. OWASP GenAI Security Project — Open Worldwide Application Security Projectが運営するAI特化のセキュリティ研究グループ。Top 10 for LLM ApplicationsとTop 10 for Agentic Applicationsを公開し、業界標準として参照される。 ↩
  2. Agentic Security Initiative（ASI） — OWASP GenAI Security Project内の自律エージェント専門ワーキンググループ。ASI01〜ASI10の策定・維持と関連ガイドの公開を担う。 ↩
  3. 間接プロンプトインジェクション — 攻撃者が外部コンテンツ（Webページ・メール・ドキュメント）に悪意のある指示を埋め込み、それをLLMが処理する際に誤動作を引き起こす手法。エージェントが外部データを参照する構成で特に危険。 ↩
  4. Model Context Protocol（MCP） — エージェントとツール・データソース間の標準的な通信仕様。採用が広がる一方、ASI07（エージェント間通信の改ざん）の攻撃対象として設計段階からの対策が必要。 ↩
  5. Human-in-the-Loop — エージェントが特定の行動を取る前に人間の確認・承認を必須とする設計方式。ASI09対策の基本であり、EU AI Act高リスク要件の柱の一つでもある。 ↩

参考リンク

コメント

タイトルとURLをコピーしました