背景與問題
隨著企業導入 AI Agent 的速度加快，資安討論的焦點正在轉移。早期業界關心的是能多快部署 Agent、能帶來多少生產力，但近期一連串事件改變了這個氛圍，包括在評估 OpenAI Agent 期間發生的 Hugging Face 入侵事件，都促使企業重新檢視部署速度是否已經超過安全管控能力。資安團隊開始追問兩個根本問題：一個 Agent 上線後到底能觸及什麼，以及出事之前有沒有人會察覺。本文由 SANS 講師 Ismael Valenzuela 為 The Hacker News 撰寫，核心論點是零信任原則確實能支撐 AI 治理，但前提是順序要對，而正確順序的第一步永遠是可視性。
Veeam 的研究數據揭示了問題的嚴重程度：70% 的組織承認 AI 工作流程已在缺乏完整監督的情況下接觸企業敏感資料，67% 表示 IT 部門無法完整追蹤員工自主建立的自動化工作流程。SANS 發布的 Zero Trust for AI Agents: The Security Checklist 在清單最上方就寫明一個原則：你無法治理你看不見的東西。實務上常見的錯誤是，企業急著部署政策執行點或授權機制，卻是為一個沒有負責人、沒有定義範圍、不存在於任何清冊中的 Agent 設計防護。一套代理或授權層擋在一群未知的 Agent 前面，根本沒有實質可執行的對象，這正是許多零信任計畫失敗的根本原因。
挑戰一：Agent 使用是新型態的影子 IT
新技術的採用總是跑在治理前面，資安團隊發現落差後的第一反應往往是封堵，封鎖未核准工具、切斷存取、關閉一切陌生事物。但在還沒釐清現況前就封鎖，很可能連合法使用一起被關掉。影子 IT 在其他技術領域早已被正視與處理，但在 AI 領域，業界仍處於蹣跚學步的階段。
從攻擊者角度來看，當 Agent 對防禦方隱形時，入侵者根本不需要攻破什麼重要系統。近期 METR 這家因評估 Hugging Face 事件而知名的非營利組織就發生實際案例：攻擊者發現一名員工的個人 EC2 執行個體上跑著一個用 vibe coding 方式快速拼湊的 Agent 應用，輕易繞過驗證後，直接提示 Agent 交出模型供應商的 API 金鑰。由於該金鑰沒有消費上限，入侵者在三週內消耗了相當於 60 萬美元的 token 用量，而 METR 的內部儀表板對遭速率限制的請求完全沒有數據，單看 token 量也不足以觸發警報。
防禦上可借鏡雲端技術走過的相同成長痛：如今每家企業都會監控 AWS 或 Azure 的用量與支出，並確保閒置虛擬機被關閉或銷毀，但幾乎沒有人對 Agent 這麼做。實務建議是把 AI 與 Agent 的支出、API 金鑰的核發都當作探索訊號，財務與採購部門也是常被忽略的觀察點。在封鎖任何東西之前先公布核准管道的路徑，讓合法使用有去處，操作順序則遵循先知情、後限制的原則。
挑戰二：沒有任何單一視角能看到全貌
即使企業決心著手盤點，也沒有任何單一觀測點能涵蓋所有 Agent。Agent 分布在網路、端點、瀏覽器以及託管在外的 SaaS 之中，任何一種視角都會留下大片盲區。流向 AI 供應商的流量經過 TLS 加密，線上感測器只能看到目的地與位元組數，看不到提示詞、工具呼叫或資料外洩，而且目的地網域往往與合法應用完全相同，單靠網路分析無法區分。端點工具看不見瀏覽器內嵌的 AI，而 SaaS 內嵌的 AI 對前兩者都是隱形的。
假設一個行銷分析師安裝了能摘要客戶紀錄並草擬外寄郵件的瀏覽器工具，端點工具因為它跑在瀏覽器內而看不見，網路監控只看到通往一個同時託管十多個核准 SaaS 產品之網域的加密流量。這個工具以及任何能攻陷它的人，可能在沒人察覺其存在的情況下握有整個 CRM 敏感資料的存取權。
要找回可視性，必須放棄單一來源的幻想，改為關聯多種各自只能照亮局部的訊號。流量可能躲在本地 MCP 伺服器或 CLI 工具裡，但中繼資料仍能透露有東西在與模型供應商通訊，包括 DNS 與 SNI 紀錄、JA4 指紋與出口代理日誌。在此之上疊加端點遙測，涵蓋程序活動、環境變數中的 API 金鑰、本地 Agent 執行環境，再加上瀏覽器層級的擴充功能、頁面內嵌 copilot 與企業瀏覽器日誌，以及身分與 SaaS 日誌中的 OAuth 授權、API 金鑰核發與供應商管理後台。關聯這些訊號才能拼出一份清冊。像 LiteLLM 這類 LLM 閘道可以集中可視性與治理，充當檢核清單要求的政策執行點，但它只能管控已指向它的 Agent，無法發現那些你不知道存在的 Agent，問題又回到清冊本身。
挑戰三：稽核速度追不上被稽核的對象
傳統定期稽核與監控不足以維持可視性。年度盤點只能看到一年前的資產快照，而 Agent 的部署與複製以秒計算，等稽核週期結束，盤點出的清冊早已失真。持續監控是直覺的答案，但把人從迴圈中移除本身也帶來風險。
攻擊者可以利用定期稽核的空窗，指示遭入侵的 Agent 繁衍短命的複製體來執行任務，每個複製體在被終止前繼承母體的存取權，存活時間剛好足以外洩資料或完成惡意行為，卻在例行審查到來前消失。防禦上需要多項措施搭配：讓人觀察 Agent、也讓 Agent 互相觀察，避免可視性依賴單一失效點；但若自動化系統監視自動化系統，仍需有一位指名的負責人對結果負責。近期美國立法層面要求建立緊急關閉機制的壓力，顯示自主 AI 的 kill switch 概念已受到重視，但前提是必須知道要關掉什麼，這又回到可視性優先。Agent 身分是這個前提的一部分，也讓監控門檻有意義，因為你無法對無法歸屬的東西設定門檻。正如 Valenzuela 與 Douglas McKee 提出的觀點，Agent 的工具存取必須被建模為獨立的身分與政策執行問題，而非部署者身分的延伸，應為每個 Agent 賦予獨立身分、將權限綁定到當前任務、限制可離開環境的資料，並在模型與連接服務之間放置授權層。日誌也需要同樣的轉轉變，從只記錄提示詞改為記錄 Agent 實際執行的工具呼叫與行動。
影響與限制
可視性在操作順序中的位置，是後續每一個治理步驟的地基。上述三項挑戰都追溯到同一個根源：在清冊建立之前架設的執行執行層，沒有實質可執行的對象。完整清單依序涵蓋三個層級，分別是清冊與治理、架構與執行、偵測與回應。實務上的限制也很清楚：關聯式盤點需要整合多種遙測來源，成本與複雜度不低；閘道類工具只能治理已納管的 Agent；持續監控若缺乏人類問責設計，會製造新的責任真空。企業應從探索著手，關聯手邊各種只能覆蓋局部的訊號來源，並圍繞每個持有獨立身分的 Agent 建立持續監控，讓零信任架構真正建立在看得見的基礎上。
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。