OWASPのエージェンティックAI成熟度モデル：CISOガイド
クラウドセキュリティアライアンス（CSA）は、IoTセキュリティやアプリケーション実装のセキュリティなどの領域で。OWASPとグローバルに連携している。
2026年7月3日、CSAラボ・スペースは、「OWASPのエージェンティックAI成熟度モデル：CISOガイド」と題するブログ記事を公開した（関連情報：OWASP’s Agentic AI Maturity Model: A CISO Guide（https://labs.cloudsecurityalliance.org/research/csa-research-note-owasp-agentic-ai-governance-maturity-v2-20/））。本ブログ記事は、OWASP GenAI Securityプロジェクトが2026年6月1日に公開した「エージェンティックAIのセキュリティとガバナンスの現状 Version 2.01」（関連情報：State of Agentic AI Security and Governance 2.01（https://genai.owasp.org/resource/state-of-agentic-ai-security-and-governance/））を受けて、作成されたものである。
[要約] 「OWASPのエージェンティックAI成熟度モデル：CISOガイド」は、自律型AIのリスクが「想定」から「現実の脅威」へ変化したことを受け、CISO向けに策定されたガバナンス指針である。中心となる「企業導入成熟度モデル」では、シャドーAIから複数エージェント連携までの9段階の「導入層（Tier）」と、5段階の「ガバナンス成熟度」を掛け合わせたマトリクスを提示している。自社のセキュリティ体制が適正かを評価し、未管理AIの排除や、安全性とセキュリティの統括、継続的な監視体制の構築を求めている。
・[要点1] 安全性とセキュリティの境界を越えたエージェンティックAIの脅威
・[要点2] 導入層とガバナンス成熟度のマトリクスによるリスクの評価
・[要点3] シャドーAIの発見からマトリクスに応じた管理策の実装・継続的運用へ
本ブログ記事「OWASPのエージェンティックAI成熟度モデル：CISOガイド」は、以下のような構成になっている。
・主要なキーメッセージ
・背景
・セキュリティ分析
・推奨事項・対策
・CSAリソースとの整合性
・参考文献
安全性とセキュリティの境界を越えたエージェンティックAIの脅威
OWASPは2025年12月、100名以上の専門家の知見を統合し、エージェンティックAI特有のリスクを分類した世界初の標準体系「OWASP Top 10 for Agentic Applications（ASI01〜ASI10）」（関連情報（https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/））を策定した。これには、エージェント目標の乗っ取り（ASI01）、ツールの不正利用（ASI02）、権限濫用（ASI03）、サプライチェーンの脆弱性（ASI04）などが含まれる。最新のv2.01では、これらほぼすべてのカテゴリにおいて、机上の理論にとどまらず「実際の侵害事例」が確認されている。
従来、AIの誤作動や正常稼働時の安全性の欠如と、悪意ある境界突破によるセキュリティ侵害は、異なるチームが個別に対応してきた。しかし、AIが本番環境で自律動作する現代、この境界は崩壊している。たとえば、「プロンプト注入によってサンドボックスを突破されるケース（セキュリティ侵害）」と「曖昧な指示を誤解して本番データベースを誤削除するケース（安全性の欠如）」は異なる原因であるが、「自律動作によるインフラ破壊」という同一の結末を招く。そのため、企業はこれらを一元的に検知・対処できる単一のインシデント対応体制を構築せねばならない。また、欧米の最新法規制（DORAやNIS2等）も、定期監査ではなく「リアルタイムの継続的な監視」を前提とした迅速な報告義務を課し始めている。
そこで、OWASPの文書では、リスクを精緻に評価するため、以下の「3つの独立した次元」と「1つの横断的要素」からなる多角的なエージェント分類法を導入した。
・エージェントタイプ（何をするか）：企業内アシスタント、コーディング、対顧客、個人用、インフラ・運用管理など。
・実装パターン（どう構築されたか）：オーケストレーション（LangGraph等）、SDK軽量ライブラリ、Copilot Studioなどのローコードプラットフォーム。構成によって企業の監査可能性が異なる。
・コンポジションパターン（どう構成されているか）：単一、緊密に連携する複数エージェント、分散エージェントチェーン（MCP等）、親が子を動的生成する階層型。
・自律性レベル（横断的リスク尺度）：常に人間が承認する「有人監視」から、異常時のみ確認する「半自律」、そしてキルスイッチや予算上限、エージェント専用IDで制御する「完全自律」までのスケール。
従来の「OWASP Top 10 for Large Language Model Applications」（関連情報（https://owasp.org/www-project-top-10-for-large-language-model-applications/））では、 LLM単体のリスクが「プロンプトへの入力や出力の制御」に主眼を置かれていたのに対し、自律的に外部ツールを呼び出してアクションを実行する「エージェント型」に焦点を絞った標準体系としてく機能していることがわかる。
「導入層」と「ガバナンス成熟度」のマトリクスによるリスクの評価
このような背景を踏まえ、「セキュリティ分析」では、エージェントAIの導入レベルを示す「導入層（Adoption Tier）」と、組織の統制能力を示す「ガバナンス成熟度（Governance Maturity）」という2つの独立した評価軸を定義し、それらを交差させた「マトリクス評価モデル」および「直近1年間の具体的な脅威動向」を解説している。
2つの評価軸の定義は、以下の通りである。
・導入層（Adoption Tier）：（AT0〜AT8）
組織の意図に関わらず、信頼境界や自律性のリスクレベルに応じて9段階に分類される。
-AT0（シャドーAI）：組織の許可なく従業員が個人用AIツール等を業務利用する制御不能な状態。
-AT1〜AT3：ベンダー組み込み型のアシスタント（M365 Copilot等）や、コード実行を伴わないプラットフォーム統合、ノーコードでの市民開発エージェント。
-AT4〜AT5：権限を持ってコードを自動生成・実行するエージェント、および独自開発のカスタムエージェント。
-AT6〜AT8：外部ツール・API（MCPサーバー等）と連携するエージェント、組織内マルチエージェント、そして信頼境界を越えて連携する最上位の「連邦型（Federated）エージェント」。
・ガバナンス成熟度（Governance Maturity）：レベル0〜4）
-レベル0〜1：リスクの認識がなくその場しのぎの対応や、ガードレールのない実証実験段階。
-レベル2： ポリシーが策定され、高影響度の意思決定には「人間による介入（Human-in-the-loop）」が義務化されている状態（ただし監視は定期的）。
-レベル3〜4： リアルタイムの異常検知や即時停止スイッチ（キルスイッチ）を備えた連続的な監視体制を敷き、さらにはテレメトリ（稼働監視データ）等を用いて自動的・適応的にガードレールを調整できる最先端の状態。
次に、ガバナンス・マトリクス（評価と課題）として、これらを掛け合わせた「成熟度マトリクス」により、組織のガバナンスが「十分」か「重大な欠陥があるか」を視覚化する。
・重大な欠陥（Critical Gap）：ガバナンスがレベル0〜1の状態で、AT6（外部連携）やAT7（マルチエージェント）を運用する場合、検証や認証のないまま全ての「OWASP Agentic Top 10」リスクに晒される。
・配備禁止（Do-Not-Deploy）：最上位の連邦型（AT8）は、継続的監視と暗号学的ID管理が可能な「レベル3以上」の成熟度に達していない限り、いかなる場合も配備すべきではないと警告されている。
・シャドーAI（AT0）の扱い：管理外であるためガバナンスでの改善は不可能であり、ネットワーク検知やデータ流出防止（DLP）シグナルを用いて「検知・排除」するか、管理された層（Tier）へ移行させる必要がある。また、エージェント棚卸ツールが未整備な組織が多く、このマトリクスに基づく正確な現状把握には数四半期に及ぶ調査コストを要する点が指摘されている。
その上で、最新の脅威データと実例についてみると、過去1年で、脅威は「設計上の懸念」から「実環境での悪用」へとシフトした。
・プロンプトインジェクション：LLMがシステム指示と外部コンテンツを区別できない性質を突き、10個あるOWASP Agenticリスク（ASI）のうち6つに悪用される主要な攻撃経路となっている。
・エージェント・サプライチェーン攻撃： AT6に関連するインシデントが急増しました。例えば、悪意あるコードを仕込まれたMCPサーバー（postmark-mcp）や、開発者向けインフラ「mcp-remote」で発見された極めて深刻なリモートコード実行の脆弱性（CVE-2025-6514、CVSS 9.6）が挙げられる。
・開発エージェントの悪用： Cursor AIコードエディタの脆弱性（CVE-2026-22708）では、攻撃者がエージェントの指示を操ることにより、コマンド実行時のホワイトリスト判定を無効化できることが実証された。さらに、GitHubの構成ミスを突き、認証情報を窃取してPython Package Index（PyPI）にバックドア付きパッケージを自動配信した「意図的に兵器化された自律型ボット」による攻撃キャンペーンも確認されており、エージェント環境における自動化された敵対行為の現実味を示している。
シャドーAIの発見からマトリクスに応じた管理策の実装・継続的運用へ
さらに「推奨事項」として、組織がエージェントAIのリスクに対処するための具体的な対策を、「即時（Immediate）」、「短期（Short-Term）」、「戦略的（Strategic）」の3つのフェーズに分けて提示している。
【即時対応策】
・シャドーAI（AT0）の発見を最優先にする：管理外のエージェントAI利用を把握（棚卸し）できなければ、成熟度モデルの他のどのステップも意味をなさない。組織内にシャドーAIは「確実に存在する」という前提に立ち、ネットワークテレメトリ、データ流出防止（DLP）ツール、従業員への構造化アンケートを用いて、個人用AIアカウント、ブラウザ拡張機能、ローカル実行モデルなどの利用実態を浮き彫りにする必要がある。
・現状の自己評価とレジストリの作成：組織は0〜4の基準を用いて現在のガバナンス成熟度レベルを率直に自己評価すべきです。同時に、配備されているすべてのエージェントのレジストリ（登録簿）を作成・補完し、それぞれに「導入層（Adoption Tier）」のタグを付与する。多くの組織は、ベンダー組み込み型アシスタントから、市民開発者による自動化、未把握のカスタムコーディングエージェントまで、4〜5つの異なる層にまたがって同時に運用しているのが実態である。
【短期的な緩和策】
・マトリクスに基づく強制措置： エージェントを層（Tier）ごとに分類した後は、「成熟度マトリクス」と照らし合わせ、「重大な欠陥（critical gap）」または「デプロイ禁止（do-not-deploy）」に該当するセルを強制的な契機（フォース・ファンクション）として扱う。つまり、ガバナンス成熟度を要求されるレベルまで引き上げるか、さもなければエージェントの自律性と信頼境界を現在の能力に合わせて縮小させなければならない。
・層（Tier）に応じたリスク対策の優先順位付け： 制御のための投資は、組織がアクティブに運用している最高位の層（Tier）の主要リスクに基づいて優先順位を付ける。
-AT1〜AT4： エージェントの目標乗っ取り（Goal Hijack）、予期せぬコード実行、メモリおよびコンテキストの汚染に焦点を当てる。
-AT6以上： ASI01〜ASI10の全領域をカバーし、特にサプライチェーンの検証、エージェント間認証、連鎖的失敗の封じ込めに注力する。
・具体的なコントロールの導入：
-エージェント自身が影響を行使できるエージェント設定側ではなく、リポジトリ層でブランチ保護や必須レビュー担当者ポリシーを強制する。
-エージェントを外部ツールに接続する前に、デフォルトの資格情報や署名キーをローテーションする。
-「機密データへのアクセス」、「信頼できないコンテンツへの露出」、「外部との通信能力」の3つの特性が組み合わさったエージェントセッション（1回のプロンプトインジェクションで攻撃チェーンが完了する条件）には、必ず「人間による承認（Human-in-the-loop）」を組み込む。
【戦略的考慮事項】
・安全性とセキュリティの組織的一体化： システムが本番環境に対して自律的に動作する以上、AIの安全性（Safety）とセキュリティ（Security）を組織的に切り離すことはできない。インシデント対応、脅威モデリング、およびガバナンスの所有権は、AI安全性部門とセキュリティ運用部門で分断（同じテレメトリを異なる原因として調査）させるべきではなく、単一の責任ある構造の下に配置するべきである。
・段階的なガバナンス投資： エージェントの配備の複雑さが増すにつれて、静的でドキュメント主導の監視から、テレメトリに裏打ちされた適応型の制御ループへと、ガバナンスへの投資を意図的にシーケンス化（段階構造化）する。すべての配備を進める前に、一律で最高位の「レベル4（適応型ガバナンス）」を目指す必要はない。
・高度な配備における前提条件： AT7（マルチエージェントオーケストレーション）やAT8（連邦型配備）にアプローチする組織は、「ガバナンスレベル3の継続的監視（動作するキルスイッチや暗号学的エージェントIDを含む）」を、配備後に達成する目標ではなく、配備するための必須の前提条件として扱う必要がある。レポートが明確に指摘している通り、連邦型の信頼関係は、低い成熟度レベルでは統制不可能なためである。
最後に、「CSAのリソースとの整合性」では、OWASPのレポートとクラウドセキュリティアライアンス（CSA）が提供する各種フレームワークとの相互補完関係について、以下のように説明している。
・脅威モデリング（MAESTRO）：OWASPは、エージェントのリスクが単一のレイヤーではなく、モデルの推論能力、ツール、メモリ、エージェント間の信頼関係の相互作用から生じるという点で、CSAの「MAESTRO」フレームワーク等と結論が一致したと明記している。組織はMAESTROの7つの階層分解（基盤モデル、データ運用など）を用いることで、OWASPマトリクスで「欠陥」とされたセルを具体的なアーキテクチャの修復策へと落とし込める。
・管理基準（AI Controls Matrix）： OWASPモデルのAT4〜AT8層で求められる資格情報のローテーション、IDのスコープ定義、サプライチェーン検証などの管理策は、CSAの「AI管理マトリクス」に直接マッピングされる。これにより、ノンヒューマンID管理やサードパーティAI統合の防御基準を構築できる。
・ゼロトラスト（Zero Trust）：連邦型配備（AT8等）において相互認証や暗号学的信頼を必須とするOWASPの主張は、ネットワーク上の暗黙の信頼を否定するCSAの「ゼロトラスト」ガイダンスを、エージェント間の信頼境界（AT6〜AT8）に適用したものである。
・共通語彙：レポートの基盤となる「ASI01〜ASI10」の分類は「OWASP Top 10 for Agentic Applications」そのものであり、CSAのインシデント研究でも共通のリファレンスとして一貫して使用されている。
前述の通り、「プロンプト注入によってサンドボックスを突破されるケース（セキュリティ侵害）」と「曖昧な指示を誤解して本番データベースを誤削除するケース（安全性の欠如）」は異なる原因であるが、「自律動作によるインフラ破壊」という同一の結末を招く。すなわち、エージェントがシステムへの書き込み権限（ファイル削除、API実行など）を持つことにより、「悪意ある攻撃」と「AIの仕様上の誤解」がインフラに与える実質的な被害は同じになることを意味している。
これを受けて、インシデント対応チーム（CSIRTなど）を分断せず、テレメトリ（監視データ）を一元化して「単一の責任構造」に統合するという推奨事項は、実務において非常に現実的かつ先進的なアプローチとなっている。
CSAジャパン関西支部メンバー
DevSecOps／サーバーレスWGリーダー
笹原英司