Google Agent Anomaly Detection 評測：87% 找到的是什麼？
Google 公布 Agent Anomaly Detection 外部基準測試，解析 87% 偵測率的分母、誤報、暖機與事後告警限制，建立代理監控判斷。
AI 代理照著使用者要求查資料，卻在讀到一封信或一份文件後，轉而執行藏在內容裡的指示。這類攻擊難以察覺，是因為操作可能仍然使用正常工具，外觀也像原本的工作。
Google 在 2026 年 11 月 12 日公布 Agent Anomaly Detection 的新評測，使用外部公開的攻擊測試集，觀察這項服務能否從代理的執行紀錄辨識異常。
服務會分析步驟紀錄、工具呼叫與前後文，再產生需要調查的發現。它在執行流程之外非同步分析，適合補強事後監測，無法用這次成績推論它會當場攔下轉帳或資料傳送。
官方報告最醒目的結果，是已經執行有害指令的案例中，有 87% 被標記。這個分母很重要，因為攻擊沒有被讀到、被代理拒絕，以及確實被執行，是不同的結果。
我會把這份評測當成建立代理監控的參考。它揭露了可見成效，也公開記憶汙染、誤報與沒有產生結果的缺口，較適合用來安排自己的測試，而非直接換算成安全保證。
要判斷它能補上哪一段防線，先看服務究竟在什麼時間讀取什麼資料，再把測試中的數字放回它實際負責的工作。
異常偵測讀取紀錄，處理的是執行後的可見性
這項異常偵測服務會根據代理的軌跡與日誌判斷行為。軌跡記錄一段工作經過哪些步驟、呼叫什麼工具，日誌則保留相關輸入、結果與事件，兩者讓調查者能回頭重建過程。
它處理的問題是，一段看似正常的操作序列，有沒有偏離使用者原本的要求。單看最後回覆可能不夠，因為代理在回覆前，可能已經呼叫外部服務或讀取不相關資料。
官方圖例以付款工作說明這個情境：使用者要求處理帳單，工具傳回的帳單中卻藏了另一筆匯款指示。若代理照做，工具的種類仍然是付款，目的與收款對象卻已改變。
這也是分析前後文的用途。服務需要看見原始任務與後續行為的關係，才能發現「執行了付款」和「執行使用者要求的付款」之間的差異，不能只靠工具名稱判斷。
Google 採用非同步方式分析，讓偵測不必擠進每次工具呼叫的等待時間。但非同步代表結果可能在動作之後才出現，低執行延遲與即時阻擋是兩項不同能力。
因此，高影響操作仍需要事前權限與確認。例如應用程式限制收款對象、控制可外傳的資料，或在操作前讓人核對，才能避免單靠事後告警承擔不可逆的後果。
這次新聞是 11 月 12 日的評測報告。服務先前已於 9 月進入私人預覽，這次發布提供新的評測資訊，使用資格仍受預覽條件限制。
外部公開測試集，仍是 Google 自行執行的評測
這次測試採用其他研究者建立的公開基準，目的在減少只用自己設計題目評估自己的疑慮。Google 仍是實際執行並公布結果的一方，外部題目與獨立第三方驗證要分開閱讀。
依照官方完整報告，團隊使用 AgentDojo、InjecAgent、ASB、AgentDyn 與 AgentHarm，涵蓋外部內容注入及使用者直接提出有害要求等不同情境。
團隊以 ADK 建立代理。ADK 是安排模型、工具與步驟的開發框架，這次搭配 gemini-2.5-flash，合計產生 1,774 段測試工作紀錄，而非測遍所有模型與框架的組合。
測試前，各代理先累積至少三百段正常工作歷史。這讓偵測服務有資料可學習平常的行為，因此讀者不應把測試成績當成新代理剛建立、完全沒有歷史時就能達到的表現。
判斷攻擊有沒有成功，也不是再問另一個語言模型主觀打分。基準使用程式檢查最後的環境狀態，例如指定資料是否被改動，來區分代理到底做了什麼。
這種安排使成績比較容易解讀：攻擊者寫了指令，只是測試的起點，後續還得追蹤它是否進入代理看見的內容，以及代理是否真的採取有害操作。
測試環境與正式企業流程仍有差距。企業自己的工具權限、正常工作變化與資料格式，都會影響偵測，因此保留這些設定，才有辦法建立相近的比較條件。
87% 的分母，是已執行有害指令的工作
官方把攻擊結果分成未被讀取、已讀取但被抵抗，以及被實際執行。這種區分能避免把「代理自己拒絕」誤算成「偵測服務已阻擋」，也讓漏報出現在哪一段更清楚。
87% 指的是實際執行有害指令的案例，被異常偵測標記的比率。由於有害操作已經發生，它說明的是查出問題的能力，無法改寫成攔截了 87% 的攻擊。
若把未讀到或已拒絕的攻擊一併納入，四組具有此分類的基準，整體有害工作被標記的比率約為 45% 至 62%。分母改變，數字回答的問題也就不同。
例如 AgentHarm 包含直接向代理提出的有害要求。Google 報告，412 段有害工作中，108 段確實執行有害行為。其餘工作即使被拒絕，原始要求本身仍可能讓服務判斷有問題。
因此，拒絕之後產生告警不一定代表誤報。對安全團隊來說，一個帳號反覆要求代理做高風險操作，仍可能值得調查。只是這種告警不能和成功攻擊的事後發現混為一談。
各基準成績也不一致。Google 報告，ASB 中透過長期記憶汙染而實際成功的十八個案例，只查出四個，這和整體 87% 的印象有明顯距離。
長期記憶會把影響延後到其他工作。當有害內容先被保存，之後才左右決策，單次工作紀錄的異常程度可能較低，因此需要額外檢驗記憶讀寫與跨工作關聯。
這個缺口提供了比平均分數更具體的採用資訊。如果你的產品會保存使用者偏好、文件摘要或代理備忘，測試就應涵蓋被汙染內容在後續工作被取出的情境。
誤報、暖機與沒有結果，都會影響維運成本
正常工作被標成異常，也會產生成本。工程或安全人員得花時間重建過程，若告警量太大，可能讓真正需要處理的案例更難被看見。
官方報告，在三組辦公室類型的注入基準中，正常工作的誤報率約為 2% 至 4%。AgentHarm 則約為 16%，因為其中正常工作也會使用影響較大的工具，與其他基準的背景不同。
這些數字說明應用情境的重要性。替低權限文件摘要設定的告警門檻，未必適合付款、發信或大量改檔案的代理。如果正常工作本身很像高風險行為，就需要更細的上下文。
歷史資料量也會改變表現。在 AgentDyn 的測試中，正常歷史從 220 段增加到 360 段，已執行有害指令的偵測率由 33% 提高到 99%，顯示暖機條件不能從成績旁邊刪掉。
這也帶來一項實務要求：開始導入時，先觀察正常工作是否具代表性。若歷史只涵蓋某個部門或少數工具，新加入的合法工作可能被當成罕見異常。
報告另指出，約 6% 的工作沒有得到偵測結果。將它們全部計為漏報，整體偵測率會再下降約一至兩個百分點，代表營運上還得監控「沒有結果」這種狀態。
對維護者而言，沒有告警與沒有完成分析，應該是兩個不同欄位。若兩者都呈現為一片安靜，監控系統本身失敗時，團隊反而最容易誤以為一切正常。
不同基準的個別結果，也顯示平均值無法代表每一個工具。官方列出的已執行有害指令偵測率，在 AgentDojo、InjecAgent、AgentDyn 與 AgentHarm 分別約為 85%、87%、99% 與 81%。
其中 AgentDojo 的 Slack 情境只有約 63%。當操作看起來接近日常使用方式，單次偏離可能不容易被判成異常，因此採用團隊需要讓測試涵蓋自己常用的協作工具。
報告也坦承，有些威脅類型尚未找到適合的外部標記軌跡基準，例如連鎖失誤或身分權限相關類別。缺少這類測試，表示現有數字尚未回答那些問題，不能把一組注入成績延伸到所有安全風險。
因此，企業可把正式工具與攻擊路徑對照到測試清單。對最常用、影響又大的工具優先保留樣本，才不會因總平均好看，就漏掉日常工作裡較弱的一段。
告警要接到處置流程，也要先保護分析資料
偵測服務需要詳細紀錄，才能看懂操作與任務的關係。這會增加資料治理需求，因為工具輸入與結果可能包含信件、企業文件、客戶資料或其他敏感內容。
依官方概覽文件，導入時需要安排代理遙測資料的匯出與服務設定。遙測就是把執行中的事件送到可觀測系統，讓它們能被查詢、分析與保留。
團隊應先確認哪些欄位會送出、誰能查閱，以及保留多久。若為了偵測而無限制保存完整工具結果，可能在監控平台又形成一份敏感資料集中區。
告警後的處置也要有負責人。單看「異常」標籤不足以決定要停用帳號、撤銷憑證或回復資料，調查者仍需要原始任務、工具參數與最終結果，確認影響範圍。
Google 將這項服務和內容過濾、工具操作前的語意治理等防線並列。內容過濾檢查文字風險，操作前治理判斷能否執行，異常偵測則回頭找出偏離，三者各自處理不同時間點。
因此，導入順序可先從已有限權、能回復的工作開始，觀察正常告警量與調查時間。高風險工具仍保留應用程式的允許清單與人工確認，逐步累積可追溯的使用證據。
這種做法也比較容易判斷服務是否有幫助。若能從紀錄快速定位一次真實偏離，並讓調查時間縮短，才是監控投入帶來的成果。單純多產生標籤，未必改善安全工作。
Agent Anomaly Detection 常見問題
它會在代理轉帳之前停止操作嗎？
這次評測的服務非同步讀取紀錄，負責產生發現。轉帳前的限制仍應由工具權限、允許對象與確認程序執行，不能把事後被標記視為操作已被攔阻。
使用外部基準，是否等於獨立驗證？
題目來自外部公開研究，測試由 Google 執行並報告。文章引用的是供應商公布的結果，本站沒有重跑，也沒有取得第三方對相同設定的獨立重現。
能否直接用 87% 估算自己的服務？
自己的模型、工具與正常工作歷史不同，不能直接套用。比較時應分開計算成功攻擊、被拒絕攻擊、正常工作與未完成分析，才能知道告警能支援哪一種處置。
沒有被標記就能繼續執行高風險任務嗎？
高風險操作是否允許，應由事前政策決定。這次記憶汙染案例與沒有結果的工作，都顯示安靜的監控畫面仍有不同原因，執行授權不能只靠告警是否出現。
已有代理紀錄與調查流程的團隊，可以先重播幾組已知工作，量出告警品質及人工處理量。對尚未限制工具權限的系統，先補上操作邊界，再加入事後偵測，較能把每份證據接到具體處置。
延伸閱讀：OpenAI Control Room 揭露：35 秒停止模型輸出，為何不等於關掉整個 AI？
延伸閱讀：OpenAI 研究代理透過 DNS 接觸外部聊天機器人：沙盒隔離漏了什麼？
