每一個 AI Agent 都被攻破了：Zero Trust 能拯救自主 AI 的安全危機嗎？
2026 年 3 月，Google DeepMind 發表了一份令整個資安產業為之震動的研究報告。研究團隊針對自主 AI Agent 進行系統性紅隊測試，結果發現：每一個受測的 Agent 至少被成功入侵一次。資料外洩陷阱（data exfiltration traps）的成功率超過 80%，子 Agent 劫持（sub-agent spawning traps）的成功率則在 58% 至 90% 之間。這不是理論推演，而是可量化、可重複的實驗數據（Google DeepMind, 2026）。
與此同時，Cisco、Microsoft、CrowdStrike 等資安巨頭幾乎在同一時期密集推出了各自的「Zero Trust for AI Agents」產品線。RSA Conference 2026 的每一場主題演講都在問同一個問題：我們該如何保護這些自主行動的 AI 系統？
但這裡存在一個尖銳的張力：一方面，實證數據清楚顯示每個 Agent 都會被攻破；另一方面，「Zero Trust for AI」是否只是兩個行銷流行語的乘積？當我們面對的是本質上非確定性的系統時，Zero Trust 的核心假設是否還能成立？
這篇文章試圖誠實地回答這些問題。
新的攻擊面：為什麼傳統資安對 AI Agent 完全失效
傳統資安架構建立在三個基本假設之上：使用者是人類、行為模式可預測、存取決策是二元的。AI Agent 打破了這三個假設。
一個執行多步驟任務的自主 Agent，可能在一分鐘之內呼叫 40 個不同的 API、產生子 Agent、存取它從未碰過的資料庫。同一個 prompt 可以產生完全不同的 API 呼叫序列。為人類使用者設計的安全模型，在「使用者」是一個每秒做出數千決策的 LLM 時，徹底崩潰。
Palo Alto Networks 的 Unit 42 在 2026 年全球事件回應報告中分析了超過 750 起事件，發現身份弱點在 89% 的調查中被利用，87% 的攻擊涉及多個攻擊面（Unit 42, 2026）。非人類身份（服務帳號、自動化角色、API 金鑰、AI Agent）在許多組織中的數量已超過人類使用者，但這些身份經常享有過度權限、使用長期有效的憑證，且缺乏一致的監控。
攻擊速度也在加速。Unit 42 報告顯示，攻擊者利用 AI 加速攻擊生命週期，速度比去年快 4 倍。最快的案例中，從初始存取到資料外洩僅需 72 分鐘。
Google DeepMind 的「Agent Traps」研究定義了六大攻擊類別：內容注入（content injection）、語義操控（semantic manipulation）、認知狀態攻擊（cognitive state）、行為控制（behavioral control）、系統性攻擊（systemic）、以及人機迴路陷阱（human-in-the-loop traps）。他們的 WASP 基準測試發現，嵌入在網頁內容中的簡單 prompt injection 在高達 86% 的情境中部分劫持了 Agent（SecurityWeek, 2026）。攻擊面是組合性的——陷阱可以被鏈接、分層、分散在多 Agent 系統中。
治理鴻溝：86% 的 Agent 未經安全審核就上線
Cloud Security Alliance（CSA）的數據揭示了一個令人不安的現實：79% 的組織已經在使用 AI Agent，但其中 86% 的 Agent 是在沒有安全團隊審核的情況下部署的——這是一個 65 個百分點的治理鴻溝。
Cisco 對大型企業客戶的調查也呼應了這個發現：85% 的受訪者表示正在實驗 AI Agent，但只有 5% 已將 Agent 投入生產環境。這個 80 個百分點的落差，主要是被安全與治理顧慮所驅動。成功投入生產的 5%，幾乎全部是內部導向的應用：IT 維運、資安維運、內部財務分析、研發支援（Cisco, 2026）。受訪者引用的三大障礙分別是：「Agent 超出預期範圍行動」、「Agent 被欺騙」、以及「Agent 供應鏈風險」。
更令人擔憂的是支出比例。根據 Gartner 的預測，2024 年 AI 安全支出僅佔 AI 總支出的 0.07%，到 2029 年也只會成長到 0.25%。換算成絕對數字：企業預計在 2029 年投入 4.71 兆美元部署 AI，但僅花 116 億美元來保護它（Gartner, 2026）。這個比例本身就是一個結構性的風險指標。
Cisco 的 Zero Trust 框架：為 Agent 而生的安全架構
Cisco 在 RSA Conference 2026（3 月 23 日）發表了其稱之為「重新想像 Agent 工作力的安全」的框架，包含多個彼此配合的元件。
Zero Trust Access for AI Agents 透過 Duo IAM 的新功能實現 Agent 身份管理。企業可以在 Duo IAM 中註冊 Agent，並將每個 Agent 對應到一個負責的人類擁有者。這個看似簡單的步驟，直接解決了 86% Agent 未經審核就上線的問題——你無法保護你不知道存在的東西。架構還包括 MCP（Model Context Protocol）策略執行、Cisco Secure Access 中的意圖感知監控（intent-aware monitoring）、以及 Secure Access SSE 中的自適應風險防護。
AI Defense: Explorer Edition 提供開發者自助工具，在部署前測試模型和應用程式對攻擊的韌性，並嵌入防護機制（guardrails）。
最值得關注的是開源元件 DefenseClaw（GitHub: cisco-ai-defense/defenseclaw）。它是一個企業治理層，位於 AI Agent 與基礎設施之間。核心邏輯是：沒有經過掃描的東西不會被執行；任何危險的東西會被自動阻擋。DefenseClaw 整合了 Cisco AI Defense 的掃描器（skill-scanner、mcp-scanner）和 AI 物料清單產生器（aibom），產出統一的 ScanResult 並按嚴重程度排序。准入閘門的邏輯是：HIGH/CRITICAL 自動阻擋，MEDIUM/LOW 安裝但附帶警告，乾淨的則放行。
技術架構方面，DefenseClaw 由 Python CLI + Go Gateway + SQLite 稽核日誌 + SIEM 整合組成。它的 OpenClaw 外掛作為即時檢查引擎，檢查 LLM 的 prompt、completion 和工具調用，偵測注入攻擊、資料外洩和 C2 模式。
多 Agent 系統中的 Prompt Injection：病毒式傳播
Prompt injection 不是新問題，但在多 Agent 系統中，它的行為模式發生了質變。
根據 SQ Magazine 2026 年的統計，針對企業 AI 系統的 prompt injection 嘗試年增 340%，成功攻擊年增 190%。多跳間接攻擊（透過 Agent 和工具的攻擊）年增超過 70%。
真正令人警覺的數據是：在多 Agent 系統中，單一 prompt injection 事件會傳播到 48% 的共同運行 Agent（SQ Magazine, 2026）。學術研究將這種現象命名為「Prompt Infection」——惡意 prompt 在互連的 Agent 之間自我複製，行為模式類似電腦病毒（OpenReview, 2026）。
為單一 Agent 系統設計的防禦機制，無法可靠地轉移到多 Agent 系統。更麻煩的是，針對特定攻擊類型的窄範圍防禦，可能反而增加對其他攻擊類型的脆弱性。這意味著防禦策略需要整體性的重新思考，而非簡單的疊加。
記憶體投毒（memory poisoning）則代表另一個維度的威脅。Microsoft Defender Security Research 記錄了來自 31 家公司、橫跨 14 個產業的超過 50 起明確的記憶體投毒事件，受影響的系統包括 Microsoft Copilot、ChatGPT、Claude、Perplexity 和 Grok（Microsoft, 2026）。MINJA 研究顯示，對生產環境 Agent 的注入成功率超過 95%。記憶體投毒與一般 prompt injection 的關鍵差異在於：它是持久性的。今天植入的惡意指令可能在數週後才被執行，實現時間解耦的攻擊。OWASP 已將其列為 2026 年 Agent 應用的頂級風險（ASI06）。
Agent 的身份危機：如何驗證非確定性系統？
知名資安專家 Maya Kaczorowski 曾直接表示：「AI agent identity: it's just OAuth」。她的核心論點是，Agent 應該利用現有標準——SPIFFE、WIMSE、OAuth、OpenID SSF。Agent 作為 OAuth 客戶端進行認證，取得範圍限定的 token，代表使用者呼叫 API。
這個觀點有其道理，但也過度簡化了問題。
IETF 目前有多個正在進行的草案標準試圖填補空白。**Agent Identity Protocol（AIP）**引入了 Invocation-Bound Capability Tokens（IBCTs），將身份、授權、範圍限制和來源資訊綁定在單一加密產物中。它支援兩種模式：Compact 模式使用 JWT 搭配 Ed25519 簽章用於單跳場景；Chained 模式使用 Biscuit token 搭配只允許附加的區塊和 Datalog 策略評估，用於多跳委派。AIP 為 MCP、A2A（Agent-to-Agent）和 HTTP API 提供了協議綁定。
SPIFFE（Secure Production Identity Framework For Everyone） 則提供了另一個角度。SPIFFE ID 是不需要長期機密的加密可驗證身份，天然適合 AI Agent——因為 SPIFFE ID 綁定的是工作負載（workload），而非人（HashiCorp, 2026）。實務模式是：讓 Agent 取得 SVID，然後交換為範圍限定的雲端憑證。
商業方面，Auth0 for AI Agents、Stytch 和 WorkOS 都已推出 Agent 認證專屬產品。
但真正的難題在於非確定性。傳統身份驗證回答的是「這個請求者是否有權限做這件事？」。但對於一個 LLM Agent，同一個身份在同一個任務中可能產生完全不同的行為序列。你驗證了身份，卻無法驗證行為。這是 Zero Trust 在 Agent 場景中面臨的根本挑戰——驗證「誰」相對容易，驗證「會做什麼」則近乎不可能。
這也是為什麼動態存取控制（dynamic access control）變得如此重要。條件式委派（conditional delegation）以動態交換取代靜態繼承：每次 Agent 出示使用者 token 時，策略決策點會根據當下的訊號重新評估，發出修剪過的下游憑證。委派式存取（delegated access）讓 Agent 繼承人類的權限，當人類失去存取權時，Agent 也同步失去。這些不是新概念，但在 Agent 場景中有了新的迫切性。
MCP 安全隱憂：工具伺服器中的供應鏈攻擊
Model Context Protocol（MCP）作為 AI Agent 連接外部工具和資料源的標準協議，正在快速擴散。但它同時也創造了一個規模龐大且缺乏審查的攻擊面。
學術分析發現，6 個公開 MCP 註冊表中共有 67,057 個 MCP 伺服器，其中相當比例可被劫持（VulnerableMCP.info, 2026）。
工具投毒攻擊（Tool Poisoning Attacks） 是最令人擔憂的手法。攻擊者將惡意指令嵌入 MCP 工具描述中，這些指令對使用者不可見，但 AI 模型看得到（Invariant Labs, 2026）。一個已公開的案例中，惡意 MCP 伺服器結合工具投毒和合法的 whatsapp-mcp 伺服器，無聲地外洩了使用者的整個 WhatsApp 歷史記錄。另一個案例中，GitHub MCP 伺服器上的一個惡意公開 issue，成功劫持了 AI 助手，使其從私有倉庫提取資料並洩漏到公開倉庫。
CyberArk 的研究更進一步指出：MCP 伺服器的任何輸出都不安全。Full-Schema Poisoning 將攻擊面擴展到整個工具 schema。
這些不是假想情境。它們是已發生的事件，而 MCP 生態系統的成長速度遠超過安全審查的能力。
產業框架：NIST、OWASP、EU AI Act
多個主要標準組織已開始建立針對 AI Agent 的安全框架。
NIST 在 2025 年 12 月發佈了 Cybersecurity Framework Profile for AI 的初步草案（NIST IR 8596），聚焦三個面向：保護 AI 系統（Secure）、利用 AI 進行網路防禦（Detect）、對抗 AI 驅動的攻擊（Thwart）。最終版本預計在 2026 年發佈。
OWASP 則在兩個層次建立了風險分類法。2025 年版的 Top 10 for LLM Applications 涵蓋了 Prompt Injection（LLM01）、敏感資訊洩露（LLM02）、供應鏈風險（LLM03）等基礎風險。2026 年版的 Top 10 for Agentic Applications 則是第一個專門針對自主 AI Agent 的正式風險分類法，由超過 100 位安全研究人員歷時一年完成，涵蓋了目標劫持（goal hijacking）、工具濫用（tool misuse）、身份濫用（identity abuse）、記憶體投毒（memory poisoning）、連鎖失效（cascading failures）和流氓 Agent（rogue agents）。
Cloud Security Alliance 的 Agentic Trust Framework（ATF） 可能是目前最完整的治理規範。它在 2026 年 2 月發佈，是第一個將 Zero Trust 明確應用於自主 AI Agent 的治理規格。ATF 定義了五個核心元素（依序分層）：身份（Identity）、行為監控（Behavior Monitoring）、資料驗證（Data Validation）、行動控制（Action Control）、事件回應（Incident Response）。
ATF 的獨到之處在於它的成熟度模型——使用人類職務的比喻，從「實習生」（Intern，僅限觀察和唯讀）逐步晉升，自主權需要透過表現來贏得。五個晉升門檻：績效、安全驗證、商業價值、事件紀錄、治理簽核。任何重大事件都會觸發自動降級。最關鍵的設計決策是：60% 的架構分配給韌性（resilience），而非預防（prevention）——這是對「assume breach」原則的刻意應用。
EU AI Act 的高風險 AI 義務將於 2026 年 8 月生效，Colorado AI Act 則在 2026 年 6 月開始執行。值得注意的是，EU AI Act 中沒有「Agent」的法律定義——它規範的是 AI 系統，而非架構模式。但 Article 14 要求高風險系統必須具備有效的人類監督，而 Agent 的自主程度或工具使用可能是被認定為系統性風險模型的決定性因素（arXiv, 2026）。
懷疑論視角：這只是行銷流行語的包裝嗎？
在投入實務討論之前，我們必須誠實面對一個問題：「Zero Trust for AI」是否只是兩個被過度使用的流行語的乘積？
Forrester 在其分析中明確指出，Zero Trust 已經成為「又一個冒充資安聖杯的流行語」。每一家組織都在推銷自己的「Zero Trust 解決方案」。BankInfoSecurity 的報導標題直白：「AI in Zero Trust: Hype, Hope and Hidden Gaps」。至少一位資安專家將 AI 目前對 Zero Trust 的貢獻評為 4 分（滿分 10 分），表示 AI「實際上並沒有在幫忙或代替我們做決策」（BankInfoSecurity, 2026）。
Forrester 2025 年安全調查發現，三分之一的組織仍在掙扎於將現有技術用於基本的 Zero Trust，超過四分之一的組織因缺乏技術技能而延遲。在連基礎 Zero Trust 都尚未完成的情況下，疊加 AI Agent 的複雜性是否言之過早？
更根本的挑戰在於非確定性。傳統 Zero Trust 是為確定性系統設計的——它回答「這個請求是否被授權？」，對象是可預測、遵循規則的實體。但 AI Agent 的行為本質上是非確定性的。推論策略執行點（Inference Policy Enforcement Points）執行的是機率性內容過濾，而非確定性的封包檢查。延遲特性、準確性保證和失敗模式都根本不同。將這些東西貼上「Zero Trust」標籤，可能具有誤導性。
你無法窮盡驗證一個 Agent 將要做什麼。與傳統服務不同——你可以定義所有可能的 API 呼叫——LLM Agent 的行為空間本質上是無界的。
資安廠商的利益衝突也值得注意。Cisco、Microsoft、Palo Alto、CrowdStrike 同時在發佈威脅研究和銷售安全產品。建立緊迫感的「研究」恰好與產品發佈時間線（RSA 2026）完美吻合。Microsoft 的 ZT4AI 宣稱有「超過 700 個控制項」，但評估工具要到 2026 年夏天才能使用。許多公告仍處於預先上市或「僅限特定客戶的早期存取」階段。
然而，反論也同樣有力：威脅證據正在快速累積。100% 的 Agent 紅隊測試被攻破、340% 的 prompt injection 成長率、86% 未經審核的部署——這些不是廠商製造的恐慌，而是來自獨立研究的數據。Dark Reading 在 2026 年的觀察或許最為精準：「Zero Trust 作為流行語已經不再有趣了，但作為一種非常具體地描述'誰可以碰什麼'的方式，它開始變得有用。」
從傳統 Zero Trust 轉移過來最誠實的原則，可能只有一個：assume breach。假設入侵已經發生，為韌性而非預防而設計。CSA 的 ATF 框架將 60% 的架構分配給韌性，正是這個洞察的體現。
現在重要的 vs. 以後再說的：務實的優先順序
面對複雜的威脅態勢和尚未成熟的工具生態，組織需要的不是一個完美的框架，而是清晰的優先順序。
第一層：立即行動（現在）
Agent 身份註冊與擁有者對應。 每個 Agent 必須被註冊，並對應到一個對其行為負責的人類擁有者。使用現有標準：OAuth 2.0 client credentials、SPIFFE ID。這不需要新技術，但直接解決了 86% 未經審核部署的最基本缺口。
最小權限 token 與短效生命週期。 Agent 應該取得範圍限定、短期有效的 token，而非長期有效的 API 金鑰。委派式存取確保 Agent 的權限與人類使用者同步——使用者失去存取權時，Agent 也隨之失去。這是因為長期有效、過度授權的非人類身份憑證是排名第一的攻擊向量（89% 的事件）。
MCP 伺服器審查與工具描述掃描。 在載入前掃描工具描述以偵測隱藏的 prompt injection。使用允許清單管理可信的 MCP 伺服器。Cisco 的 mcp-scanner 和 DefenseClaw 的 skill-scanner 已經可用。67,057 個未經審查的 MCP 伺服器是一個活生生的供應鏈風險。
基礎 ADR（Agent Detection and Response）。 在 Agent 行動執行前進行即時監控。Gen Digital 的 Sage 是開源的，提供超過 200 條偵測規則，涵蓋憑證外洩、危險指令和持久化機制。這是 Agent 版的 EDR——後者花了十年才成為標準，現在開始還不算晚。
所有 Agent 行動的稽核日誌。 記錄每個 Agent 做了什麼、何時做的、以及基於什麼授權。這對事件回應和合規都至關重要——EU AI Act 和 Colorado AI Act 的合規期限已近在眼前。
第二層：分階段實施（6-12 個月）
Agent 行為異常偵測。 監控 Agent 是否在預期模式之外行動。挑戰在於：非確定性行為使基線建立變得困難。這需要投資去理解你的特定 Agent「正常」看起來是什麼樣子。
多 Agent 通訊安全。 帶有已驗證身份鏈的安全 Agent 對 Agent 協議。IETF 草案（AIP、AAP）仍在進行中。大多數組織目前擁有的是單一 Agent，而非 Agent 群。
漸進式自主（ATF 方法）。 讓 Agent 從「實習生」模式（唯讀）開始，基於展現的行為逐步晉升。CSA 的 ATF 框架提供了完整規格。
記憶體保護與投毒偵測。 驗證持久性 Agent 記憶是否包含注入的指令。挑戰在於區分合法記憶與被投毒的記憶——防禦技術仍處於研究階段。
第三層：前瞻佈局（12 個月以上）
完整的多 Agent Zero Trust 架構——每次 Agent 間通訊的持續驗證、即時風險評分與自動範圍縮減、與企業 IAM 系統整合。這需要成熟的 Agent 身份標準和組織準備度。
自動化合規對應——自動產生 EU AI Act、SOC 2、ISO 27001 的合規證據。法規仍在被詮釋中，自動化需要穩定的框架。
AI 物料清單（AIBOM）作為標準實務——每個 Agent 所有模型、工具、資料來源和權限的完整清冊。Cisco 的 DefenseClaw 包含 AIBOM 產生器作為早期原型，但標準尚不存在。
開發者工具生態：現有的與缺失的
開源工具
目前值得關注的開源專案包括：
Cisco DefenseClaw——Agent AI 的安全治理（Python CLI + Go Gateway），提供掃描、准入閘門和即時檢查引擎。
Microsoft Agent Governance Toolkit（2026 年 4 月發佈）——第一個宣稱涵蓋所有 10 項 OWASP Agent 風險的工具包，支援亞毫秒策略執行，以七個套件（Python、TypeScript、Rust、Go、.NET）支援 LangChain、CrewAI、Google ADK 和 Microsoft Agent Framework。
Gen Digital Sage——第一個 ADR（Agent Detection and Response）實作，200+ 偵測規則，在客戶端的 Agent 執行迴圈中運行，支援 Claude Code、Cursor 和 OpenClaw。
CSA Agentic Trust Framework——開放治理規格，提供完整的 Zero Trust Agent 治理框架，包括成熟度模型和合規對應。
商業產品
商業領域中，Cisco AI Defense 提供企業級 Agent 掃描和策略執行；Microsoft Agent 365 以每月每用戶 15 美元的定價、預計 2026 年 5 月正式上市；Zentera Systems 的 Ensage AI 針對自主 AI Agent 提供 Zero Trust 平台（特別標榜支援 Claude Code、Cursor、GitHub Copilot）；CrowdStrike 的 Falcon AIDR 和 Zenity 的 AIDR 則代表了 AI 偵測與回應的新類別。
新興類別：ADR
Agent Detection and Response（ADR）刻意與 EDR（Endpoint Detection and Response）平行命名。它在 Agent 行動執行的當下進行攔截，在行動落地之前進行評估。評估在本地進行，資料不需要離開機器。它監控的是執行迴圈：prompt 歷史、檔案修改、行動序列。
什麼是缺失的
儘管工具生態正在快速成長，幾個關鍵空白仍然明顯：標準化的 Agent 身份協議（IETF 草案仍在進行中）、適用於非確定性系統的即時行為異常偵測、跨框架的治理工具（目前的解決方案是碎片化的）、多 Agent 通訊安全的成熟方案、以及不會增加過高延遲的平價安全層（目前的安全開銷為產生器成本的 15-100%，MCP 閘道每次工具執行增加 100-250ms 延遲）。
結論：韌性，而非完美防禦
讓我們回到開頭的張力。
威脅是真實的。Google DeepMind 的 100% 攻破率、340% 的 prompt injection 成長、48% 的多 Agent 傳播率、86% 未經審核的部署——這些都是獨立、可驗證的數據。忽視這些數據是不負責任的。
但「Zero Trust for AI Agents」作為一個概念框架，需要誠實的限定。傳統 Zero Trust 的原則在非確定性系統上的轉移是不完美的。你可以驗證 Agent 的身份，但無法預測它的行為。你可以限定 token 的範圍，但無法窮盡一個 LLM 可能做出的所有決策。將機率性內容過濾貼上 Zero Trust 的標籤，有概念稀釋的風險。
真正從傳統 Zero Trust 中轉移過來的、具有實質意義的原則是 assume breach——假設入侵已經發生，為韌性而設計。這意味著不是追求完美的預防（不可能），而是確保當 Agent 被攻破時（必然會發生），損害範圍被限制、被偵測、被修復。
CSA 的 ATF 框架將 60% 的架構分配給韌性而非預防，這不是設計上的妥協，而是對現實的承認。Microsoft 超過 700 個控制項的背後，真正重要的是那些確定性的、在推論迴圈之外運作的檢查——而非依賴模型自己做出正確決策。
對組織而言，最大的風險不是選錯了框架，而是完全不行動。第二大的風險是買了一個廠商的「完整 Zero Trust for AI 解決方案」，然後假設問題已經解決。現實需要的是分層的、持續演進的防禦，與組織的成熟度同步成長。
2026 年不是 AI Agent 安全問題被解決的一年。但它是問題被正式承認、框架開始成形、工具開始出現的一年。對於正在部署或計劃部署 AI Agent 的組織來說，現在開始建立基礎——即使不完美——遠比等待完美的解決方案更務實。
畢竟，100% 的 Agent 都會被攻破。問題只是你在那之後準備好了沒有。
參考資料
- Google DeepMind, "Agent Traps" Research, March-April 2026
- Unit 42, 2026 Global Incident Response Report, Palo Alto Networks
- Microsoft Defender Security Research, "AI Recommendation Poisoning," February 2026
- Cisco, "Reimagining Security for the Agentic Workforce," RSA Conference, March 23, 2026
- Cloud Security Alliance, Agentic Trust Framework (ATF), February 2, 2026
- OWASP, Top 10 for Agentic Applications 2026
- OWASP, Top 10 for LLM Applications 2025
- NIST IR 8596, Cybersecurity Framework Profile for AI, December 2025
- Gartner, "Worldwide AI Spending Will Total $2.5 Trillion in 2026," January 2026
- Forrester, "When Buzzwords Collide: From A(I) To Z(ero Trust)"
- Invariant Labs, "MCP Security Notification: Tool Poisoning Attacks"
- SQ Magazine, "Prompt Injection Statistics 2026"
- IETF, Agent Identity Protocol (AIP), draft-prakash-aip-00
- HashiCorp, "SPIFFE: Securing the identity of agentic AI," 2026
- Gen Digital, Sage: Agent Detection and Response
- Microsoft, Agent Governance Toolkit, April 2, 2026
- Maya Kaczorowski, "AI agent identity: it's just OAuth"
