OWASP Agentic AI 安全成熟度評估框架 2026：你的 Agent 安全達到幾級了？
83% 的組織計畫部署 agentic AI，但只有 29% 認為有能力保護它（Cisco State of AI Security 2026，via Practical DevSecOps）。這 54 個百分點的落差說明了什麼？問題不是「有沒有做安全」，而是「做到了哪個層級」。很多團隊裝了 Promptfoo、設了 WAF，就以為完成了；但根據 OWASP 在 2026 年 6 月正式發布的 Enterprise Adoption Maturity Model，這類做法頂多只到 Level 1（事後響應），距離可以負責任地生產部署的 Level 2，還有一段明確的鴻溝。
本文解析 OWASP 官方框架的完整二維矩陣（採用層級 AT0-AT5 × 治理成熟度 Level 0-3），補強 OWASP Agentic Top 10 中最常被忽略的 3 個多 agent 威脅（ASI06/ASI07/ASI08），並提供可操作的自評方法與升級路線圖。
TL;DR
- OWASP 官方定義二維矩陣：6 個採用層級（AT0-AT5）× 4 個治理成熟度（Level 0-3）
- 79% 組織停在 Level 1：有工具、無治理（Practical DevSecOps, 2026）
- 3 個最常被忽略的多 agent 威脅：ASI06（記憶體毒化）、ASI07（agent 間通訊）、ASI08（串聯故障）
- Level 1 到 Level 2 的關鍵不是更強的過濾器，而是可觀測性：工具調用日誌 + 命名所有者
- OWASP 官方目前定義到 Level 3；Level 4-5 是 Practical DevSecOps / SANS / CSA 等業界框架的延伸，非 OWASP 官方定義
為什麼「有安全工具」不等於「安全成熟」
這是最常見的認知陷阱：裝了 Promptfoo 或 LLM Guard，就認為安全工作做好了。
Practical DevSecOps 的調查數據很直接：79% 的組織停在 Level 1（Reactive）（Practical DevSecOps AI Security Maturity Model 2026，樣本為其訓練學員與企業客戶群體）。Level 1 的真實樣貌是：有基本 prompt 過濾、有 WAF 擋在 LLM 前端、出了 incident 才啟動響應。但它沒有的東西更重要：
- 沒有 AI 資產清單（不知道組織裡跑了哪些 agent）
- 沒有工具調用日誌（agent 做了什麼沒有可追溯記錄）
- 沒有命名所有者（出事了誰負責，不清楚）
成熟度框架的核心認知翻轉是：從「點狀防護」到「系統性治理」。就像有防火牆不等於有成熟的網絡安全姿態，有 LLM 過濾器不等於有 agentic AI 治理能力。
Level 2 的入場券是可觀測性，不是更強的過濾器。你能不能知道你的 agent「現在正在做什麼」、「剛才做了什麼」、「誰批准了這個操作」——這三個問題回答得出來，才算進入 Level 2。
OWASP Agentic AI Top 10 完整清單（ASI01-ASI10）
OWASP Top 10 for Agentic Applications 2026 定義了 10 個威脅（官方編號 ASI01-ASI10）。下表整理完整清單，並標注哪些已有完整繁中資源覆蓋：
| 代碼 | 威脅名稱 | 核心風險 | 繁中資源覆蓋狀況 |
|---|---|---|---|
| ASI01 | Agent Goal Hijack | 攻擊者透過直接/間接注入操控 agent 目標 | 已覆蓋 |
| ASI02 | Tool Misuse & Exploitation | 不安全的工具組合或過度調用產生有害結果 | 部分覆蓋 |
| ASI03 | Agent Identity & Privilege Abuse | 跨 agent 信任鏈的未授權操作 | 已覆蓋 |
| ASI04 | Agentic Supply Chain Compromise | 外部 agent、工具、schema、prompt 遭入侵 | 已覆蓋 |
| ASI05 | Unexpected Code Execution | Agent 生成或觸發的代碼在未隔離環境執行 | 已覆蓋 |
| ASI06 | Memory & Context Poisoning | 記憶或上下文狀態的注入/洩漏，影響未來推理 | 未覆蓋 |
| ASI07 | Insecure Inter-Agent Communication | Agent 間訊息遭攔截、注入或偽造 | 未覆蓋 |
| ASI08 | Cascading Agent Failures | 小型 agent 故障傳播，造成大規模衝擊 | 未覆蓋 |
| ASI09 | Human-Agent Trust Exploitation | 利用人類對 agent 的過度信任操控行為 | 間接提及 |
| ASI10 | Rogue Agents | Agent 因目標漂移或意外行為超越預期目標 | 間接提及 |
ASI01-ASI05 的技術防護細節，可參考 OWASP Agentic AI 安全防護指南，這篇文章有完整的實作方法。
以下重點展開 3 個缺口威脅：
ASI06 記憶體毒化：最被低估的持久性威脅
為什麼危險：89% 的 agent 跨用戶/session 共享記憶體且無完整性驗證（Repello AI 2026 企業安全路線圖報告）。
一般 prompt injection 是即時攻擊，當次 session 結束就結束了。ASI06 記憶體毒化的特徵是「低頻植入、持久影響」——攻擊者在一次 session 中注入惡意資訊進入 agent 的長期記憶庫，後續數週的 agent 推理都可能受影響（Repello AI 2026 企業安全路線圖報告），且難以追溯攻擊發生點。
典型攻擊路徑：
- 攻擊者透過一次 session 向 agent 記憶庫注入「用戶偏好」類的惡意資料
- 下次不同用戶使用 agent 時，毒化記憶體影響 agent 行為
- RAG 資料源投毒：汙染向量資料庫，影響所有依賴該知識庫的 agent
防護方法：按用戶/租戶隔離記憶體、對每個記憶體條目標記來源和 session、使用次要模型驗證記憶體寫入、設置記憶體條目過期機制。
ASI07 Agent 間通訊攻擊：多 Agent 架構的盲點
為什麼危險：多 agent 架構（orchestrator + sub-agents）在 2026 年成為主流。Agent 間通訊通常假設信任，但沒有加密或認證。
典型攻擊方式：
- MitM（中間人）：攔截 A2A 或 MCP 協議的訊息
- 注入：向 sub-agent 注入惡意指令，偽裝成 orchestrator 的合法指令
- 重播攻擊：重複使用截獲的舊指令觸發意外行為
- 身份偽冒：偽裝成合法 agent 發送指令
防護方法：為每個 agent 分配獨特加密身份（SPIFFE/SPIRE、inter-agent mTLS）、對 agent 間訊息進行簽名、每次下游請求都重新授權、完整記錄所有 agent 間通訊。
ASI08 串聯故障：架構設計層級的問題
為什麼危險：76% 的多 agent 系統缺乏 circuit breaker（Repello AI 2026 企業安全路線圖報告）。在 orchestrated multi-agent 系統中，一個子系統被入侵等同於整個 agent 網絡面臨威脅。
類比：2003 年美加大停電不是發電廠本身的問題，而是故障傳播機制沒有截斷點。ASI08 的問題同樣是架構設計問題，不是單點漏洞。
典型故障模式：一個被入侵的 agent 在多 agent 管道中傳播惡意指令；資源耗盡（一個 agent 觸發過度工具調用，消耗下游系統資源）；狀態汙染（毒化輸出成為另一個 agent 的輸入）。
防護方法：實施 circuit breaker、設計安全失敗模式（agent 失敗時暫停並升級到人類，而非繼續）、隔離 agent 邊界、為可逆操作建立事務回滾機制。
OWASP Enterprise Adoption Maturity Model 解析
OWASP State of Agentic AI Security and Governance v2.01（2026 年 6 月 1 日）定義了一個二維矩陣：你部署了什麼（採用層級），以及你的治理做到什麼程度（治理成熟度）。
重要提醒：這兩個維度相互獨立。一個組織可以同時是 AT4（有代碼執行能力的 agent）但仍停在 Level 0（完全沒有治理）。這是最常見的高風險組合，也是最容易被忽略的診斷盲點。
維度一：採用層級 AT0-AT5（你部署了什麼）
| 層級 | 名稱 | 典型特徵 |
|---|---|---|
| AT0 | Shadow AI | 組織未知情或未核准的 AI 工具使用 |
| AT1 | Vendor Embedded Assistant | 完全由廠商控制的 AI 助理（你消費，不建置） |
| AT2 | Platform Integrated | AI 原生平台使用你的資料，但無法執行任意代碼 |
| AT3 | Citizen Developer Agent | 低代碼/無代碼平台，用戶配置流程但不寫代碼，操作真實組織資料 |
| AT4 | Code Executing Agent | 生成並執行代碼，具有本地或雲端權限 |
| AT5 | Custom In-House Agent | 組織自建系統，控制身份、工具和邊界 |
安全責任的轉移點在 AT3：從 AT1-AT2 的「廠商主要負責」，轉為「組織必須主動治理」。AT4-AT5 的安全責任幾乎完全落在組織自身。
維度二：治理成熟度 Level 0-3（你的治理做到哪）
| 層級 | 名稱 | 核心特徵 |
|---|---|---|
| Level 0 | Unaware and Ad Hoc | 無正式治理認識，影子 IT 實驗，日誌最少，使用通用 IT 事故處理 |
| Level 1 | Experimentation Without Guardrails | 試點專案缺乏自主限制和決策範圍，偶爾紅隊測試，無持續監控，問責制模糊 |
| Level 2 | Policy-Defined, Human-in-the-Loop | 正式政策、法規對齊（EU AI Act、GDPR），高影響決策需人工確認，命名所有者，建立日誌和版本控制 |
| Level 3 | Integrated, Continuous Oversight | Agentic AI 視為關鍵基礎設施，即時儀表板、kill switches、治理即代碼（Governance-as-code） |
OWASP 官方框架目前定義到 Level 3。業界有些框架（Practical DevSecOps 到 Level 4，SANS 到 Stage 5，CSA 到 Level 4）有更高層級的定義，但這些是各家機構自己的延伸框架，非 OWASP 官方標準，引用時需注意來源區別。
二維矩陣：高風險組合
| Level 0 | Level 1 | Level 2 | Level 3 | |
|---|---|---|---|---|
| AT1-AT2 | 低風險 | 可接受 | 超標準 | 超標準 |
| AT3 | 中風險 | 需改善 | 最低要求 | 良好 |
| AT4 | 高風險 | 需立即改善 | 最低要求 | 目標 |
| AT5 | 極高風險 | 不應部署 | 最低要求 | 良好 |
AT4-AT5 + Level 0-1 是需要立即關注的組合。AT3 + Level 0-1 屬於中高風險：AT3（公民開發者 agent）操作真實組織資料，雖然無任意代碼執行，但資料外洩和未授權操作的風險仍然存在，仍需至少達到 Level 2。根據上面的 54% 落差數據，大量組織正處於這個高風險位置。
安全成熟度自評方法
5 維度評分法（Practical DevSecOps, 2026）
各維度 0-10 分，總分對應成熟度層級：
| 維度 | 0 分（Level 0） | 5 分（Level 1-2 邊界） | 10 分（Level 3） |
|---|---|---|---|
| AI 資產清單 | 完全不知道有哪些 agent | 知道主要 agent，影子 AI 未盤點 | 完整清單含影子 AI |
| 政策與合規 | 無任何 AI 政策 | 有通用 AI 政策，未映射到法規 | 正式政策對齊監管框架 |
| 監控與偵測 | 無監控 | 有基本 alert，無 runtime 監控 | 即時工具調用監控 |
| 測試與驗證 | 從未進行安全測試 | 偶爾紅隊測試，無定期計畫 | 每季紅隊 + 持續自動化測試 |
| 事故響應 | 使用通用 IT 流程 | 有 AI 專屬 playbook 但未演練 | 演練過的 AI 事故處理流程 |
評分標準：0-10 = Level 0，11-25 = Level 1，26-40 = Level 2，41-50 = Level 3
79% 的組織按這個評分只能到 Level 1（11-25 分），主要拉低分數的是「監控與偵測」和「AI 資產清單」兩個維度。
企業版 vs. 個人開發者版的現實差異
企業版 Level 2 門檻：
- 命名的 agent 所有者（每個 agent 都知道誰負責）
- 高影響操作的人工確認流程
- 工具調用完整日誌，每次操作捕獲：agent 身份、授權者、存取資料、操作內容、政策結果、時間戳
- NIST AI RMF 四個功能對齊（Govern/Map/Measure/Manage）
- 每季紅隊測試
個人開發者 / 小型工具的 Level 2 門檻（現實可行版）：
- 工具調用基本日誌（記錄 agent 做了什麼、什麼時候做的）
- 每個工具明確最小化（只給 agent 需要的工具，不開放全部）
- 每個 agent 使用獨立身份（非共享帳號或 API Key）
- 至少每次發布前跑一次手動安全審查
CISA 標準的 SHA-256 hash chain 日誌和 6 個月保留，對個人開發者不切實際。重要的是開始建立可觀測性的習慣，而不是完美符合企業合規標準。
從 Level 1 到 Level 3 的 90 天路線圖
來源：Repello AI 2026 年 OWASP Agentic AI Top 10 企業實施路線圖。
Phase 1（第 1-4 週）：能見度建立
- 清點所有 agent 部署，包含影子 AI
- 對每個 agent 進行爆炸半徑評估（如果這個 agent 被入侵，最壞情況是什麼）
- 建立 ASI 風險基線（對照 ASI01-ASI10 逐一確認有無對應控制）
Phase 2（第 5-8 週）：快速修復
- 縮小 service account 權限，實施短效憑證
- 沙箱化代碼執行環境
- 按用戶/租戶隔離 agent 記憶體（解決 ASI06 最低要求）
- 建立工具調用日誌（Level 2 的最低要求）
Phase 3（第 9-12 週）：主動防禦
- 部署目標變更和工具誤用的預執行驗證
- 實施行為異常偵測
- 用簽名認證強化供應鏈（解決 ASI04）
- 為多 agent 系統加入 circuit breaker（解決 ASI08）
Phase 4（持續）：持續驗證
- 針對 agentic 攻擊向量進行專業化紅隊測試
- 維護行為基線並定期重新驗證
- 建立 Governance-as-code 自動化政策執行
個人開發者的簡化路徑：
完成 Phase 1 + Phase 2 的基礎工作（清單、最小化工具、工具調用日誌）就能達到適合個人工具的 Level 2 標準。Phase 3-4 是企業優先項。具體起點：
- 清單：列出你的 agent 使用的所有工具（shell、filesystem、API），確認每個工具的最小化授權
- 日誌：每次工具調用記錄 agent 身份、時間戳、操作內容（可以是簡單的 JSONL 日誌檔）
- 身份隔離：每個 agent 使用獨立 API key，不和其他服務共享
各成熟度層級的真實樣貌
以下場景根據 OWASP Level 定義描述典型組織的實際狀況，並非聲稱特定組織的親身經歷。
Level 0 典型場景：獨立開發者用 Claude Code 做 side project，從未審查工具權限，agent 有 shell 存取但不知道有沒有洩漏 API key。發生異常時用通用方式處理，沒有 AI 專屬 incident 流程。
Level 1 典型場景：小型 SaaS 公司，有部署 LLM Guard 在 API 前端，也有基本的 prompt 過濾。但沒有 AI 資產清單（不知道還有哪些 agent 在跑）；因為一次 API key 洩漏事件，才開始臨時跑安全掃描。問責制模糊。
Level 2 典型場景：中型企業，有建立 AI 資產清單、每季進行一次紅隊測試、工具調用有基本日誌記錄。每個高影響決策需要人工確認。但監控是定期批次，不是即時告警。
Level 3 典型場景：大型金融機構或受監管行業，real-time dashboard 追蹤 agent 行為漂移；有 kill switches 可以即時暫停自主性；治理政策機器可讀、自動在 AI 生命週期中執行；每個決策完整可追溯。
結論
先花 5 分鐘做一次自評：對照上面的 5 維度評分表，把你的系統給個分數。如果總分在 11-25 之間，你在 Level 1，和 79% 的組織一樣（Practical DevSecOps, 2026）。
接下來的決策路徑很清楚：
如果你是個人開發者或小型工具，AT1-AT2 的優先行動是確認廠商的安全政策；AT4-AT5 則是把 Phase 1 + Phase 2 的基礎工作（工具最小化 + 工具調用日誌 + 獨立 agent 身份）優先排進這個月的開發計畫。
如果你是企業安全或工程主管，Level 2 是可以負責任地生產部署的最低門檻。根據 OWASP 框架，在沒有命名所有者、沒有工具調用日誌、沒有人工確認機制的情況下部署 AT4-AT5 的 agent，屬於 Level 0-1 的高風險組合，不建議上生產。
技術防護的具體實作（ASI01-ASI05 的工具鏈、配置方式、代碼層面的防護），可以到 OWASP Agentic AI 安全防護技術指南 繼續深入。
FAQ
OWASP Agentic AI 安全成熟度 Level 0-3 各代表什麼？
Level 0（Unaware and Ad Hoc）：無正式治理，影子 IT 實驗；Level 1（Experimentation Without Guardrails）：試點專案缺乏定義限制，問責制模糊；Level 2（Policy-Defined, Human-in-the-Loop）：正式政策、命名所有者、高影響決策需人工確認；Level 3（Integrated, Continuous Oversight）：即時儀表板、kill switches、治理即代碼。OWASP 官方目前定義到 Level 3。
如何評估我的 AI agent 系統在哪個成熟度層級？
使用 5 維度自評法：AI 資產清單完整性、政策與合規覆蓋、監控與偵測能力、測試與驗證頻率、事故響應成熟度，各項 0-10 分。總分 0-10 對應 Level 0，11-25 對應 Level 1，26-40 對應 Level 2，41-50 對應 Level 3。
AT 採用層級和治理成熟度 Level 有什麼不同？
AT 層級（AT0-AT5）描述「你部署了什麼類型的 agent」，從影子 AI 到自建系統。治理成熟度（Level 0-3）描述「你的安全治理做到什麼程度」。兩者相互獨立：一個組織可以是 AT4（有代碼執行能力的 agent）但仍停在 Level 0（完全沒有治理）。
ASI06 記憶體毒化和一般 prompt injection 有什麼差別？
Prompt injection 是即時攻擊，影響當次 session。ASI06 記憶體毒化是「低頻植入、持久影響」——攻擊者在一次 session 中汙染 agent 的長期記憶庫，影響後續數週的推理行為。89% 的 agent 跨用戶/session 共享記憶體且無完整性驗證（Repello AI 2026 企業安全路線圖報告），使這個攻擊面比 prompt injection 更難追溯。
從 Level 1 升到 Level 2 最關鍵的三件事是什麼？
1. 建立 AI 資產清單（盤點所有 agent 部署，含影子 AI）；2. 建立工具調用日誌（每次 agent 操作都有可追溯記錄）；3. 為每個高影響 agent 指定命名所有者（明確問責制）。Level 2 的門檻不是更強的過濾器，而是可觀測性。
個人開發者需要達到哪個成熟度層級才算負責任部署？
取決於你的 AT 層級。AT1-AT2（使用現成平台、不能執行代碼）：廠商負主要責任，無需嚴格自評。AT4-AT5（你的 agent 能執行代碼、存取外部系統）：最低要達到 Level 2，具體要求：工具調用日誌、每個工具明確最小化、每個 agent 使用獨立身份（非共享帳號）。
這篇文章對你有幫助嗎？
