真正可怕的不是漏洞数量而是验证方式这个叫 PageBreak 的内部代理不是把 AI 的猜测直接丢给工程师而是先把每个疑似跨站脚本攻击放进接近真实的环境里跑一遍能证明恶意代码确实在浏览器里执行才升级为安全结论。对长期被扫描器噪音折磨的安全团队来说这件事的信号很直白AI 漏洞扫描开始从“像真的”走向“可复现”。谷歌公开的时间线并不长。PageBreak 在 2025 年 11 月进入试点2026 年 1 月转为完整项目核心思路是以证据驱动的方式调用 Gemini 模型做网络安全审计。它扫的不只是代码也看请求路径、响应逻辑、跳转关系、缓存键和脚本加载链路随后把这些“疑似风险”交给专门设计的验证器而不是把大模型输出当成最终裁决。对于跨站脚本攻击验证器会注入测试性 JavaScript用类似浏览器的系统打开目标并确认代码是否真的触发。这也是 PageBreak 最值得写入防御手册的一点它演示效果而不是只标记危险片段。谷歌把近乎零误报归功于这种验证机制同一套方法还被扩展到 SQL 注入、路径遍历、远程代码执行、服务器端请求伪造等方向。换句话说AI 负责扩大搜索面验证器负责把误报挡在工单系统之外。XSS 之所以难缠在于它经常藏在正常业务流里一条链接、一段被反射的输入、一个被错误信任的跳转参数最后都可能在受害者浏览器里执行。传统扫描器容易把“看起来危险”的代码标成高危也容易漏掉真正可利用的链路而 PageBreak 的价值在于把输入、上下文和浏览器执行结果连成闭环让安全审计更接近攻击者视角。更值得注意的是边界测试结果。截至 2026 年 9 月 4 日PageBreak 在基于谷歌高安全性 Web 框架构建的数百个应用里只发现两个 XSS 漏洞且都限于内部应用或调试端点。这个对比很刺眼同一套 AI 代理在普通面上能挖出 500 多个已验证问题落到统一框架、统一输出编码、统一资源策略的系统里漏洞数量被压到极低。谷歌借此论证的是另一层安全哲学——框架控制能防住整类错误自动化测试则负责在剩余缝隙里补刀。真正暴露风险的三条链路也远比“某处忘了过滤”更复杂。第一条发生在 JavaScript 文件服务上核心是缓存中毒。未检查的 URL 路径段被拼进返回代码却没有进入缓存键意味着攻击者一旦让边缘节点缓存了恶意响应同一地理区域的后续访问者就可能拿到同一份被污染的脚本。谷歌强调未发现该漏洞被实际利用的证据但危害面很清楚受影响域包括 apis.google.com且加载相关 JavaScript 的外部站点也可能被牵连。它再次提醒做 CDN 缓存投毒防护的人缓存键设计不是性能细节而是安全边界。第二条链路出现在管理控制台。直接的重定向滥用原本被加密签名拦住但代理顺着授权逻辑找到了能生成有效签名的端点把“看起来够不着”的受保护入口拆成了一条可到达的跨站脚本路径。这类发现的价值不在于单点洞而在于它证明 AI 已经开始拼接漏洞利用链签名、授权、跳转、脚本上下文每一段单独看都未必致命连起来就成了风险。第三条则来自标签助手扩展。外部连接检查偏弱、一次性随机数可被恢复、消息转发边界不清晰再叠加对数据 URL 的处理最终让攻击者控制的脚本内容触达正在调试的页面。这里的关键词是“调试态”很多高风险能力在正式发布前被临时打开最容易被安全流程遗忘也最适合被自动化代理反复探测。PageBreak 的工作方式也没有回避 AI 安全代理自身的短板。报告承认不完善的验证器可能漏掉真实漏洞因此谷歌会把未经核实的发现留存下来用于改进未来扫描和验证器而不是直接丢给产品团队。发布流程上工程师仍会审查提出的修复。这套边界很现实自动化负责把问题找出来、复现出来、排好优先级人负责判断业务影响和最终上线。从行业视角看PageBreak 的意义不只是“谷歌又找到了一批洞”。它把 AI 驱动的 Chrome 漏洞修复思路外推到 Web 应用安全自动查找、重现、分类、修复再由人验证补丁。下一步谷歌明确想做的是自动化修补把产品团队从“反复判断 AI 报告是不是真问题”转向“验证已提出的修复是否正确”。当安全审计从找洞变成闭环处置漏洞响应速度才会真正拉开差距。对企业来说可抄的作业并不神秘。输入输出要统一编码跳转参数要校验白名单缓存键必须覆盖会改变响应的路径与头部脚本资源来源要收敛调试端点默认关闭并加访问控制更重要的是不要把 AI 扫描报告直接进工单先经过可复现验证。AI 生成概率再低的安全结论也应该是证据先行。需要说明的是目前公开资料中的受影响域、示例路径与测试工件更接近防御性披露与验证材料用于说明风险链路不应被理解为已确认恶意基础设施也不适合直接转成黑名单。真正的结论反而朴素跨站脚本攻击没有消失只是从单点注入升级成链路工程而 PageBreak 这类 AI 安全代理正在证明自动化不是替代安全工程师而是把他们从噪音里解放出来去打更难的那场仗。