Google 代理異常偵測 87%：量到的是事後標記，不是攻擊攔截

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

Google 在 2026 年 11 月 12 日於開發者部落格公布 Agent Anomaly Detection 的第一份外部基準評測成績，距離這項服務以私人預覽形式登上 Gemini Enterprise Agent Platform，大約兩個月。這次公布的重點是一組可以核對的數字：Google 首度用五個非自家制定的公開代理資安基準，測量這項服務能從代理執行紀錄裡標記出多少異常行為，並把各基準成績、誤報率與失敗案例全部攤在報告裡。

新聞報導裡最醒目的數字是 87%。要判斷它對自己的代理環境有沒有參考價值，得先回答三個問題：87% 的分母是什麼、漏掉的部分集中在哪、現在該不該跟著調整部署。三個問題的答案都寫在 Google 自己的報告裡，而且答案彼此相扣。

87% 量到什麼：有害指令已經執行之後，標記出來的比率

先看這項服務要抓的威脅長什麼樣。現在的 AI 代理會讀電子郵件、訂機票、代使用者搬錢，每一次工具呼叫都會把別人寫的文字拉進來，而誰控制那段文字，誰就有機會把代理帶偏。攻擊者不需要碰使用者的帳號，只要在一封代理會去讀的信、一份它會去開的文件裡埋進指令，代理照著做時，工具種類可能仍是正常的付款或檔案操作，目的與收款對象卻已經換成別組。這也是它難防的地方：操作外觀像平常的工作，單看工具名稱分辨不出來。

Agent Anomaly Detection 讀的是代理的軌跡（traces）與日誌（logs），在代理執行流程之外非同步分析，標記出行為超出原始任務邊界的 session。非同步的設計讓它不占用每次工具呼叫的等待時間，代價是結果出現時操作多半已經完成。它扮演的是事後調查的角色；轉帳、寄信或大量改檔案之前的擋關，靠的是事前權限與核准程序，報告也把這兩種能力明確分開。這種「事後才看見」的定位，與另一種在輸出當下踩剎車的閘門是互補關係，一個縮短反應時間，一個負責完整重建過程。

87% 的分母，是「有害指令確實執行成功」的案例。Google 把每段攻擊 session 拆成三種結局：指令從未進到代理眼裡、代理讀到但成功抵抗、以及實際執行。這次測試裡有 141 段攻擊指令代理根本沒讀到，其中只有 1 段觸發標記；模型本身也先擋下一輪，直接有害要求約四分之三模型當場拒絕，藏在工具回傳內容裡的指令約三成則忽略或執行失敗，合計模型沒有照做它讀到的有害指令約一半。

換句話說，87% 量的是「已經穿過模型層、有害操作真的發生」的案例中，這項服務標記出來、可供調查的比率。它證明的是找出問題的能力；把分母換掉，會得到完全不同的結論。

Pin

測試方法本身也值得記下來。安全工具用自家團隊寫的題目測自家產品，成績容易好看，所以 Google 這次挑了五個非 Google 制定的公開基準，未做任何修改直接上測。團隊用 Agent Development Kit（ADK）搭配 gemini-2.5-flash 建立代理，在五個基準的模擬應用裡跑出共 1,774 段 session，每個代理上線前都先累積至少 300 段正常工作紀錄，讓服務有平常行為可以比對。判定攻擊有沒有成功，靠基準自己的 Python 程式檢查環境最終狀態，例如帳戶裡的錢有沒有轉出；標籤由程式碼決定，不讓另一個模型主觀評分，注入的指令也就無法誤導評分者。題庫外部與執行獨立是兩件事，這點後面還會回來。

五個基準裡，AgentDojo、InjecAgent、Agent Security Bench（ASB）與 AgentDyn 把有害指令藏在工具回傳的資料中，AgentHarm 則由使用者直接提出有害要求。這類藉由內容挾帶指令、讓代理偏離原始目標的手法，在 OWASP 2026 年的 Agentic Applications 十大風險排第一名，也正是這次評測鎖定的主要威脅。

分母換成全部攻擊：45% 到 62%，各基準落差比平均大

把代理沒讀到與讀到但抵抗掉的攻擊放回分母，四個有結果分類的基準整體標記率落在 45% 到 62% 之間。這個區間回答的問題與 87% 不同：如果想知道的是「每一段攻擊 session 平均有多少會變成可調查的告警」，該引用的是它。

各基準的已執行偵測率分別約為 AgentDojo 85%、InjecAgent 87%、AgentDyn 99%、AgentHarm 81%。以應用拆開，11 個模擬應用中有 8 個達到 95% 以上，最低的是 AgentDojo 的 Slack 情境，只有約 63%，因為其中不少攻擊只要求一個小動作，例如造訪某個頁面，外觀與日常瀏覽幾乎相同。平均值掩蓋了這段落差：重度使用協作工具的代理部署，正好落在相對弱的一段，導入前值得針對自己最常用的工具補一組測試。

AgentHarm 的數字還帶出一個容易誤讀的現象。412 段有害工作中，代理實際執行了 108 段，其餘多數模型直接拒絕；但這些拒絕掉的 session 仍有約 55% 觸發標記，因為有害要求寫在使用者自己的訊息裡，服務讀得到。相對地，藏在工具輸出深處、代理抵抗掉的指令，只有 11% 到 25% 觸發標記。同一個服務對攻擊的能見度，取決於指令出現的位置，解讀告警時要把這兩種來源分開。拒絕掉的要求仍觸發標記，這不全是噪音：同一個帳號反覆探測代理邊界，本來就是安全團隊會想看見的訊號，Google 也把「以較低嚴重度回報模型擋下的嘗試」列為正在改進的方向。

順帶一提，這次成績的參考座標是 OWASP 的分類法。服務的五大威脅類別裡有四個對得上 OWASP 的代理十大風險，公開基準的題目集中在目標劫持與工具濫用，證據也就集中在這兩類；報告同時提醒，這組數字不該延伸成對所有安全風險的保證。

三個會改變導入決策的缺口：毒記憶、暖機與誤報

報告對採購判斷最有價值的部分，是 Google 自己列出的弱項，其中三個直接影響部署規畫。

毒記憶是最大的缺口。ASB 把有害指令種進代理的長期記憶，18 個因此成功讓代理行動的案例中，Agent Anomaly Detection 只查出 4 個，與整體 87% 的印象有明顯距離。原因不難理解：有害內容先存進記憶，之後才在別的工作裡發揮影響，單看一段 session 的紀錄，異常程度可能很低。會替使用者保存偏好、文件摘要或備忘的產品，這一段測試成績最該自己重做一遍，把「汙染內容在後續工作重新出現」納入情境。

暖機條件同樣會翻轉成績。AgentDyn 上，每個代理的正常歷史從約 220 段增加到 360 段時，已執行有害指令的偵測率從 33% 跳到 99%。服務的部分方法需要數百段歷史才能學會某個代理平常的樣子，新建立的代理初期覆蓋不完整，導入初期的表現不能拿來推斷穩定後的水準，歷史資料是否涵蓋各部門與各種工具，也會決定系統會不會把新的合法工作誤判成罕見行為。

誤報決定維運成本。三個辦公室型注入基準的正常工作誤報率約 2% 到 4%，AgentHarm 則約 16%，因為它的正常工作本身就會貼文、下終端指令、下載檔案，高影響工具的正常使用看起來更像濫用。告警量直接吃掉工程與安全人員的時間，為低權限文件摘要代理設定的門檻，不該直接搬給能對外付款或大量修改檔案的代理。報告對這類代理的建議是先預期較多的發現，再按嚴重度與威脅類別分級處理。

小動作是另一個盲區。造訪一個網頁、發一則訊息這類單一步驟，與日常工作的差別太小，本來就難判成異常；Google 正在補的方向，是抓住「指向未信任目的地的小動作」，例如單次造訪不明網頁。這對照出基準分數的邊界：85% 到 99% 的已執行偵測率，掩蓋不了「後果輕但值得看」的那一層目前看不太到。

另外約有 6% 的 session 沒有得到任何偵測結果；把它們全部計為漏報，整體比率會再降 1 到 2 個百分點。監控面板上，「沒有告警」與「分析沒有完成」應該是兩個不同的欄位，否則偵測服務本身故障時，畫面看起來反而最平靜。

誰該現在動作，誰先不用

這項服務仍在私人預覽：要以允許名單內的帳號提出申請，代理需能把 OpenTelemetry 軌跡與日誌匯出到 Google Cloud 專案，發現會進到 Security Command Center（需 Standard、Premium 或 Enterprise 層級），偵測與覆蓋指標則寫入 Cloud Monitoring，可做成圖表與告警政策。

值得注意的是同一天的文件更新：2026 年 11 月 12 日起，在 Google Cloud 之外（例如 AWS 或 Azure）運行、以 ADK for Python 2.12.0 以上版本建立的代理，也能透過 Workload Identity Federation 把軌跡與日誌送進來。受支援範圍從 GKE 與 Cloud Run 部署（10 月 22 日加入）擴大到跨雲代理，11 月 2 日加入的自動註冊，則會自動納入專案裡發現的合格代理。還沒把代理放上生產環境的讀者，這次公布暫時不需要任何動作。

Pin

已經在跑代理的團隊，可以從報告結尾的部署建議讀出優先順序：先用事前控制擋住高影響操作，包括每個代理只拿任務所需的工具與權限、用 Semantic Governance Policy（預覽中，在每次工具呼叫前對照使用者請求與規則，拒絕不合的呼叫）、以 Model Armor 之類的過濾器檢查提示與工具結果，以及付款、對外寄信前的真人核准；Agent Anomaly Detection 排在後面，負責找出穿過前面防線的行為，Critical 與 High 等級的發現再路由給事件處理團隊。這個分層與 Google 先前提出的代理安全框架是同一套思路，鎖與監考官各司其職。想把提示注入的內容過濾再往前推一層的團隊，市面上也有把注入偵測做成自訓模型的獨立方案可對照。

導入前比較務實的做法，是先重放幾組已知的工作，量出告警品質與人工處理量，再決定要把哪些發現交給誰處理。只多產生標籤，未必改善安全工作；能從紀錄快速定位一次真實偏離、讓調查時間縮短，才算監控投入換到的成果。

要讓服務看得懂操作與任務的關係，就得餵它完整的遙測，官方的建議是開啟 ADK 的追蹤與日誌，連提示與回應內容都包含在內。這一步同時帶出新的治理問題：工具的輸入與結果可能含電子郵件、客戶資料或內部文件，哪些欄位要送出、誰能查閱、保留多久，都該在導入前想清楚，免得為了偵測而另外生出一份敏感資料集中區。

這份報告還沒回答的問題

有幾件事在報告裡明確留白。題目雖然來自外部公開基準，執行與公布成績的都是 Google 自己，目前沒有第三方用相同設定重現這組數字；引用時把它當供應商自評看待，比當獨立驗證安全。測試只用了一個模型與模擬應用，基準的正常工作也可能比真實流量單純，報告自己提醒各家的誤報率會不同。連鎖失誤與身分權限濫用這兩類威脅，Google 說還找不到有標記軌跡的公開基準可測，這兩類的偵測能力因此在這份報告裡沒有答案。服務脫離預覽的時間與定價，同樣尚未公布。

這些數字有自己的保存期限。等服務進入正式版、或 Google 針對毒記憶缺口公布改進後的成績，這篇提到的 45% 到 62% 與 18 案查出 4 案都需要回查。在那之前，把 87% 當「事後標記率」引用，別當成「攔截率」，是這份報告對讀者最有用的一種讀法；事前擋住高影響操作的控制，怎麼排都不會輸給事後告警。