Google 的 AI 安全代理 PageBreak 已在公司第一方网络应用中发现超过 500 个经过验证的跨站脚本（XSS）缺陷。XSS 是一类注入型漏洞，攻击者提供的脚本会在其他用户的浏览器中运行，这是一种长期存在的网络风险，因为在受信任页面上执行的代码可以以该页面的权限进行操作。该系统会在报告送达产品团队之前，针对实际运行的服务测试每个疑似缺陷——这一验证步骤将可用的漏洞利用与 AI 模型生成的看似可信但实际错误的攻击描述区分开来。该方法旨在确保每份确认的报告都对应一个真实可用的漏洞利用，而不是一个听起来合理的说法。

Google 于 2025 年 11 月启动 PageBreak 试点，并于 2026 年 1 月将其正式立项。公司的产品安全团队表示，该系统在敏感的公司域名上发现了 XSS 缺陷。Google 未公布受影响的应用名称，也未披露严重程度分布；所报告的数字涵盖其整体网络应用资产。

专门验证器将误报保持在接近零的水平

PageBreak 并不会将每条警报直接转给工程师，而是将每个候选问题发送给专门的验证器。对于 XSS 漏洞，验证器会向相关页面注入 JavaScript 并观察代码是否执行。Google 表示，这一流程将误报保持在接近零的水平，并防止未经测试的说法进入产品团队的审查流程。

该系统验证的内容不止浏览器脚本。额外的检查会判断注入的输入是否会改变数据库查询、通过路径遍历暴露文件或触发代码执行，另一个验证器则检查可能到达内部服务的请求。这些检查使 PageBreak 能够评估多种攻击类别，同时让报告聚焦于实际可行的攻击路径。每个候选问题都需要独立证明，工程师才会将其视为漏洞。

大多数扫描由 Gemini 3.1 Pro 或 Gemini 3.5 Flash 执行，但漏洞利用检查由单独的工具完成；验证器并非来自 AI 代理本身。Google 会重复尝试，因为模型可能放弃有效的路径，或尝试在实际应用条件下无法成功的攻击路径。

未经验证的结果不会作为已确认的缺陷流出内部安全工作流。团队可以利用这些结果改进未来的扫描或创建额外的验证器。这一区分非常重要，因为语言模型可能生成听起来令人信服的详细安全叙述，但在实际应用中测试时可能无法复现——而且在大规模场景下，这一差距决定了 AI 生成的发现是节省工程时间，还是在分类排查中消耗时间。

高保障框架应用中出现两个缺陷

截至 9 月 4 日，PageBreak 已在基于 Google 高保障网络框架构建的数百个应用中发现了两个 XSS 漏洞。两个案例都涉及缺少某些防护措施的内部应用或调试端点。这一结果展示了这些框架防护措施在自动扫描下的表现。框架相关的数字是单独统计的，不包括 Google 更广泛应用资产中超过 500 个的发现。

PageBreak 可以通过公司代码库检查跨服务的代码路径。来自实时网络流量的安全数据可以将请求的页面与相关源代码关联起来，现有的扫描器也提供对内部站点的经过身份验证的访问。

这样的环境使 PageBreak 有别于公开的模型扫描。外部研究人员通常无法查看 Google 的代码、流量数据或受保护的测试系统。因此，PageBreak 反映的是一个拥有深度操作访问权限的内部安全工作流，其发现数量并不表明其他组织仅通过运行 Gemini 就能取得同样的结果。

修复工作流：计划集成 CodeMender

Google 计划将 PageBreak 与 CodeMender 更加紧密地连接起来，后者是一个旨在生成安全修复的代理。届时产品团队可以在已确认的漏洞旁边审查提议的修复方案——这种安排将打通从发现到修复的闭环。公司表示，这一组合可以减少大量已验证发现所带来的工作量，但未给出集成的时间表。

类似的验证问题也影响着加密软件领域，AI 工具在其中的安全报告可能数量庞大且看似可信。以太坊基金会曾使用独立的审查人员来复现 AI 代理生成的发现，而一次 Bitcoin Red Team 扫描发现，当时报告的问题中仅有 24.7% 附带可复现的证明。

Google 尚未表示是否会将 PageBreak 向外部项目开放。

来源：Blockonomi，基于 Google 官方 PageBreak 公告。