一条安全告警刚出来，修复PR已经跟着生成。扫描Agent说这里存在越权路径，修复Agent改了条件判断，新的扫描结果又说风险消失。流程快得令人兴奋，也快得让测试负责人不安：如果发现、证明和修复都在使用同一套理解，它们会不会一起错？
Google在2026年9月18日公开了用AI Agent扫描和修复基础设施代码的工程方法：在代码提交前做轻量扫描，用专门的分诊Agent结合AST、调用图和安全规则证明攻击路径是否可达，再由修复Agent生成补丁，最后交给人工审核。官方还强调，应当把开发、扫描和分诊Agent的Harness、规则与上下文分开，避免偏差互相强化。
这篇文章不讨论如何造一个“万能安全模型”，而是解决测试团队更现实的问题：当AI既会报漏洞又会改代码，怎样防止它自证正确；怎样把误报、漏报和补丁副作用分别测清楚；以及小团队怎样用确定性证据给AI扫描加一道可信门槛。
最危险的不是AI漏报，而是三个Agent共享同一个盲区
假设开发Agent新增一个退款管理接口，只检查了用户是否登录，没有检查是否属于财务角色。扫描Agent从接口名推断这是高风险操作并发出告警。修复Agent增加is_admin判断，扫描Agent再次检查后通过。
问题在于，业务真正要求的可能不是“管理员”，而是“具备退款权限且所属租户一致”。三个Agent如果都读取同一份模糊需求，就会共同接受一个看似更安全、实际仍越权的修复。用更多Agent投票也无济于事，因为它们共享的不是答案，而是错误前提。
所以安全闭环必须拆开：扫描Agent负责提出可疑路径；结构验证器负责证明输入能否到达危险操作；修复Agent只在证据成立后生成补丁；回归系统从历史漏洞和业务权限表验证补丁有没有改变其他合法路径。
“漏洞存在”必须落到一条可执行路径
自然语言告警常写成“可能存在权限绕过”。测试无法据此判断补丁是否有效。需要把它变成最小攻击证据：什么身份发起什么请求，经过哪些函数，最终触发什么敏感动作。
以退款为例，测试证据至少包括用户身份、租户、订单归属、权限集合和工具调用。确定性断言可以这样写：
def assert_refund_guard(trace, actor, order):
assert actor.tenant_id == order.tenant_id
assert 'refund:write' in actor.permissions
assert trace.index('check_permission') < trace.index('issue_refund')
assert trace.count('issue_refund') <= 1
它不关心Agent用了哪种措辞，也不要求固定完整思考过程，只要求敏感动作之前必须完成租户和权限校验。修复后的扫描结果再漂亮，只要这条Trace断言失败，补丁就不能合并。
用局部威胁模型替代一份永远过期的大文档
Google公开实践中一个关键点，是把威胁模型与实时代码元数据和依赖调用图结合。对普通团队而言，可以从更小的版本做起：每个高风险模块旁边维护“资产、入口、身份、危险动作、必须校验”的五列表。
退款模块写清能改钱，文件模块写清能读隐私数据，通知模块写清能向外部发送内容。AI扫描每次只读取与改动相关的局部威胁模型，而不是吞下几十页安全规范。上下文更小，告警更容易给出依据；测试也能检查它引用的是当前规则还是旧文档。
分诊Agent必须接受确定性程序复核
AI可以判断一段代码“看起来危险”，但攻击路径是否真实可达，应尽量交给AST解析、调用图遍历、污点规则或权限测试。Google公开称其专用分诊Agent会程序化检查代码结构，并披露在其场景中获得超过92%的精度、不到一分钟的执行时间；这是Google自报工程结果，不等于所有团队复制后都能得到相同数字。
对测试团队，关键不是追求同样的指标，而是让每条高风险告警回答三个问题：危险输入从哪里进入；经过哪条调用路径；哪条现有控制没有拦住。答不出来的告警可以保留为人工线索，但不能直接驱动自动修复。
修复正确，还要证明没有打断合法用户
安全补丁常见副作用是把所有请求都拦住。新增权限条件后，测试不仅要重放攻击样本，还要验证财务人员、客服受限退款、跨租户管理员等合法和非法组合。可以形成一个最小矩阵：正确租户＋有权限应成功；正确租户＋无权限应拒绝；错误租户＋有权限仍应拒绝；重复请求不能执行两次。
这就是从Outcome Evaluation升级到Behavioral Evaluation：不只看最终返回403还是200，还看权限检查是否发生在工具调用之前、敏感参数是否被污染、失败后是否仍继续执行其他工具。
CI/CD里如何防止AI“互相盖章”
第一，开发Agent不得修改安全黄金用例；第二，扫描和修复使用不同的系统提示、规则和上下文；第三，结构验证器输出机器可读证据；第四，补丁合并前运行历史漏洞回放和合法路径回归；第五，所有自动修复保留来源告警、补丁差异、审查人和回滚条件。
如果换模型、改Prompt或更新威胁模型，就重新跑一组固定的红队样本。观察的不只是发现率，还包括无证据告警比例、危险补丁比例、合法路径误伤率和从告警到可复现证据的时间。
小团队可以先把一个高风险接口做透
选退款、权限修改或文件下载中的一个模块，整理10条历史缺陷和10条合法路径。让AI扫描候选问题，但要求每条告警都输出入口、调用链和危险动作；再用测试代码验证路径。只有证据成立，才让AI生成修复建议。
这样做可能没有“一天扫完整个仓库”那么吸睛，却能建立真正可复用的闭环。一个月后，团队会得到自己的误报类型、常见盲区和高价值断言，而不是一堆无法确认的AI安全建议。
AI越能写代码、找漏洞、修补丁，测试越不能只当最后的验收者。新的职责是设计相互独立的证据链，让任何Agent都不能仅凭自己的解释获得发布权。模型负责扩大搜索范围，程序负责证明路径，测试工程师负责定义什么证据足够——这才是AI安全进入生产的可信基础。
漏报也要从生产反馈反推
扫描系统最容易展示的是发现了多少问题，最难看到的是它漏掉了什么。可以从渗透测试、线上告警、人工代码审查和事故复盘中收集真实漏洞，回放到提交前扫描环境。若同一类型反复漏掉，就检查局部威胁模型是否缺少资产、调用图是否断裂，或分诊规则是否错误过滤。
不要只把漏报样本塞进Prompt。先问哪一层证据缺失：扫描Agent根本没提出候选，还是提出后被分诊Agent判成不可达；结构验证认为路径断开，还是回归集没有覆盖对应身份。定位到层，修复才能避免下一次换个写法又漏掉。
给自动修复设置“补丁预算”
修复Agent不应为了一个告警大范围重构。可以限制修改文件数、禁止触碰公共鉴权组件、禁止删除安全断言，并要求补丁包含攻击样本和合法路径用例。超过预算时只输出方案，交给人处理。
同时做补丁差分：扫描前后的攻击路径必须从可达到不可达；合法路径保持可达；工具副作用没有增加；性能和错误处理没有明显退化。若修复只是把入口隐藏、吞掉异常或返回统一拒绝，安全告警可能消失，业务却一起坏了。
衡量这套系统不能只看发现数量
更有价值的指标包括：有可执行证据的告警比例、结构验证后的真实率、合法路径误伤率、同类漏洞复发率、补丁被人工采纳率和平均修复周期。发现数量突然上升不一定是进步，可能只是误报变多。
当扫描、分诊和修复各自有独立数据，团队才知道该优化模型、上下文、规则还是工具。测试工程师维护的也不再是一堆安全用例，而是一套能审计每次判断来源的质量系统。
