Google 內部代理 PageBreak 自述發現逾 500 個 XSS：數字怎麼讀、驗證怎麼做

2026 年 9 月，Google 產品安全團隊公開內部 AI 代理 PageBreak，稱這套工具在自家第一方 Web 應用中發現超過 500 個跨站指令碼（XSS）漏洞。APPI News 於 10 月 23 日刊登專文，檢視這項成果的驗證流程與解讀邊界，並討論 AI 代理能否取代傳統漏洞掃描。本文依該文與 Google 公開說明整理事件輪廓。

PageBreak 的試行計畫始於 2025 年 11 月，之後轉為正式專案。依 Google 說明，其目標是在自家 Web 應用中擴大漏洞探索範圍，同時減少安全人員逐項搜尋的負擔。PageBreak 可搭配不同模型，內部多數使用情境採用 Gemini 系列模型。

逾 500 個漏洞是誰的數字

APPI News 的文章反覆強調一件事：這個數字是 Google 對自家第一方應用的說明，未經外部研究團隊獨立重測，也不能直接換算為其他組織的預期成效。應用數量、程式架構、可用測試帳號、登入狀態、測試時間與漏洞去重方式，都會影響最終統計。

文章舉例，若同一個根因出現在多個頁面，是記為一筆共通缺陷，還是依受影響端點分開計算，數字就會大幅變動。報告若未列出測試期間、排除資產與無法測試的功能，這個總數適合描述專案規模，不適合用來對不同工具或團隊做直接排名。

Google 另稱其驗證策略帶來「接近零」的誤報率。APPI News 指出，此描述同屬廠商自述，公開文章並未列出計算方法、樣本母體或第三方驗證，比較適合視為設計目標與內部回饋。安全團隊評估類似工具時，應自行記錄真陽性、誤報與漏報，並說明分母如何定義。

這類廠商自述與獨立評測之間的落差，在其他 AI 安全宣稱場合也反覆出現。例如 METR 與 Redwood 對 OpenAI 監控系統的評估便顯示，外部機構實測結果與廠商說法之間存在需要逐一核實的縫隙。

假設與驗證分離的設計

依 Google 公開說明，PageBreak 的流程分為兩段。代理先提出漏洞假設，再交由非 AI 撰寫的專用驗證器，在實際執行環境中檢查特定條件是否成立。以 XSS 為例，驗證器會監測注入的 JavaScript 是否真的在測試頁面執行。

這個設計背後的判斷是：大型語言模型擅長依程式或應用行為提出可能問題，但文字描述合理，不等於漏洞確實存在。掃描器若只交出敘述而未在環境中重現，安全團隊仍須自行確認。APPI News 同時提醒，驗證器的涵蓋範圍仍有限，驗證通過的條件未必涵蓋所有攻擊路徑。

能否取代掃描：兩個評估軸線

APPI News 建議把評估重點從「它找出幾筆」移到幾個具體問題：在什麼條件下找到、每筆如何驗證、漏掉什麼、團隊花多少時間處理。測試結果應附帶資產清單、測試環境、驗證狀態、風險等級與修補狀態，才能與既有流程比較。

文章並區分兩個概念。探索覆蓋指已測試的主機、路徑、表單與使用者角色，可與預先核準的範圍清單核對；確認品質則看報告是否附有可重現條件、驗證器狀態與人工判定。工具沒有回報問題時，只能說本次測試未提出候選，不能證明未涵蓋的頁面或狀態不存在漏洞。若團隊握有已知測試案例，可在同一隔離環境確認流程能否辨認，並將無法重現或結果不一致的案例另列，避免把測試覆蓋不足誤讀為風險降低。

導入時的授權與複核

導入此類代理涉及實際向應用發送測試請求，授權範圍須事先界定。文章指出，工具只能存取公開頁面，與能以測試帳號進入完整流程、讀取程式脈絡相比，候選漏洞範圍並不相同；評估時應核對可用的使用者角色與測試資料權限。

修補端同樣需要紀錄。每筆候選漏洞從假設、驗證器結果到人工判定，應保留可追溯的狀態；修補完成與否，也會決定「發現數」最終是否轉為實際風險下降。只看總數，無法判斷是否找到高影響弱點，也無法知道修補進度。

AI 安全工具的宣稱與查核之間的張力，近月已有多起案例可對照，專家對 AI 突破宣稱的查核結果整理了其中一輪爭議。

事件脈絡小結

至本文整理為止，可核實的部分是：Google 於 2026 年 9 月公開 PageBreak，稱試行始於 2025 年 11 月，並自述在第一方應用發現逾 500 個 XSS、誤報率接近零。數字未經獨立機構重測，驗證方法的細節以 Google 公開文章為限。至於其他組織導入同類工具的實際成效，目前缺乏可引用的公開比較資料，相關結論仍待後續獨立評測出現。