AI 滥用与攻防升级

一家软件厂商公开安全补丁后，攻击者可以让模型阅读公告和代码差异，生成候选测试输入，再放进隔离环境运行。如果编译器、崩溃信息或测试断言能立刻说明候选是否有效，模型就能保留成功方向、丢弃失败方向并继续变异。相同模型若只看到一份含糊的业务投诉，无法访问真实状态，也没有稳定判定标准，长时间推理仍可能停在猜测。

本文的核心判断是：AI 对攻击能力的放大程度，取决于反馈是否廉价、快速并且可以由机器验证。 生成更多候选带来一次性规模，闭环反馈让系统持续学习哪条路径有效。防守方需要识别哪些接口正在给攻击自动化提供高质量反馈，再通过权限、配额、隔离、检测和安全设计改变这套试错经济。

反馈闭环决定迭代速度

攻击探索可以抽象为一个带验证器的循环：

目标与当前状态
      |
      v
生成候选 -> 执行动作 -> 环境返回观察 -> 验证器给出判定
   ^                                      |
   |                                      v
   +------------ 更新状态与下一步 --------+

模型擅长读取非结构化材料、提出假设和生成候选，工具负责把候选作用到环境，验证器把返回结果压缩成“有效、无效、需要更多证据”。崩溃、编译通过、单元测试、明确的权限结果和靶场 Flag 都是质量较高的反馈；含糊的错误页、人工是否相信钓鱼消息、长期潜伏是否成功，则包含更多噪声和延迟。

两项口径可以直接衡量闭环质量：

有效迭代吞吐 =
  在观察窗口内得到明确判定的候选数
  / 观察窗口时长

单位有效反馈成本 =
  模型、工具、基础设施与人工总成本
  / 得到明确判定的候选数

并发生成转化为有效迭代，依赖环境能够接住请求、反馈可以归因且验证器能够判断。接口限速、验证码、状态污染、长等待和人工复核都会降低吞吐；稳定的测试环境、详细错误和自动判定会提高吞吐。这是诊断模型，不能直接预测某次攻击是否成功。

攻击者模型决定闭环从哪里开始

本文先讨论一名具备普通工程能力的外部攻击者。他能获得公开公告、补丁和开源代码，能租用模型与计算资源，能在自己的沙箱运行工具，也能向公开服务发送受限请求；他起初没有生产凭证、内部源码和业务数据库。攻击目标是从公开变化中找到可验证弱点，再寻找受影响目标。

攻击者的能力可以分为三个阶段。辅助阶段由人选择路径，模型负责阅读和生成；半自动阶段由 Agent 调用编译器、调试器或浏览器，根据结果调整候选；自主阶段还要长期管理状态、权限、预算、隐蔽性和多步影响。阶段越高，对稳定反馈、工具可靠性和初始访问的要求越强。

若攻击者已经取得内部账号、源码、日志或测试环境，闭环会明显缩短；这时风险同时来自凭证失守和内部信息暴露。若服务只允许一次请求且没有可观察结果，模型仍能降低内容生成成本，却很难根据目标环境持续优化。威胁建模应记录攻击者能看到什么、能试多少次、多久得到结果，以及结果是否足以证明下一步。

从补丁差异到现实影响仍有长链路

一条完整攻击链可以写成：

公开公告与补丁
  -> 定位安全相关变化
  -> 生成触发条件与候选输入
  -> 在匹配版本中编译和运行
  -> 用崩溃、断言或状态差异验证
  -> 最小化并稳定复现
  -> 识别真实暴露资产与前置条件
  -> 绕过现有控制并形成业务影响

前半段可以在攻击者控制的环境中反复运行，成本低且反馈清晰；后半段受版本差异、网络位置、身份、WAF、业务状态和检测能力约束。一个 sanitizer 报告可以证明测试进程触发了内存错误，仍不能独自证明远程可利用、目标在线或已经形成数据损失。攻击能力评估应分别保存“生成候选”“验证弱点”“到达目标”“形成影响”的证据。

Google Project Zero 的 Project Naptime把代码浏览、脚本、调试和目标交互等专用工具接入漏洞研究 Agent，并强调自动验证对可复现评测的重要性。它支持“工具加可判定反馈会改变系统能力”这一机制判断，结论限定在其架构、任务和评测环境内，不能直接证明生产网络中的端到端攻击已经自动化。

不同任务的反馈质量差异很大

内存安全测试、输入变异、补丁回归和配置验证常有明确 Oracle，成功可以由崩溃、测试或状态差异判定。公开 Web 接口也可能返回状态码、响应差异和速率信息，攻击者可以据此筛选候选。社会工程起初反馈较慢，但大规模活动可能把送达、打开、点击和回复变成代理指标，使文案生成进入另一种可优化循环。

复杂业务逻辑、跨组织身份关系和长期隐蔽行动更难自动判断。返回成功状态不代表越过权限，页面出现数据也可能只是测试内容；一次钓鱼回复无法证明后续控制已经建立。模型若把模糊观察当成成功奖励，会沿错误方向加速。因此，评测环境越容易给出 Flag，越要谨慎外推到噪声更高的真实系统。

Cybench把网络安全任务放进可执行命令并观察输出的交互环境，CyberSecEval 3则区分自动化社会工程、扩展人工操作和自主网络操作。它们为不同反馈条件下的能力提供可复现评测入口，也保留了 CTF、模拟环境和特定模型版本的适用边界。

现实观察同样需要控制表达强度。Microsoft 与 OpenAI 对国家关联威胁行为者使用 LLM 的联合披露证明相关群体已经把模型用于实际活动；披露没有提供一项通用的端到端自主攻击成功率。英国 NCSC 的评估判断 AI 会影响侦察、社会工程、恶意代码和漏洞研究等环节，这类判断描述风险方向，仍需由具体系统的反馈与访问条件落地。

防守要改变攻击试错经济

防守的第一步是缩短公开信息到保护生效的窗口。资产、版本、外部可达性和负责人要能够关联；补丁发布后，影响判断、临时缓解、测试和灰度部署进入同一流程。攻击者可以离线研究公开补丁，隐藏公告无法形成长期防线，及时减少暴露实例更可靠。

在线系统可以控制反馈通道。按主体、设备、目标和时间窗口设置配额，把认证失败、资源不存在和策略拒绝的外部错误收敛到必要信息，同时在内部保留完整诊断；连续枚举、候选快速变异和跨账号协同进入行为检测。限速与统一错误会影响正常排错，应给受管开发者提供经过认证的诊断渠道，避免以牺牲可运维性换取表面安静。

权限和执行环境限制每轮试错的影响。高风险工具使用短期凭证、目标允许列表、网络出口控制和沙箱；写操作需要审批、幂等与额度，异常循环可以撤权和熔断。防守侧安全 Agent 可以在隔离副本中获得丰富日志和自动验证，进入生产时仍由授权与业务规则决定动作，具体控制见Agent 与工具调用安全。

不可信互联网 -> Edge PEP -> 生产服务
                  | 认证、配额、最小错误
                  v
               Run Event -> 检测与风险 PDP -> 限速、隔离、撤权

防守 Agent -> Target Manifest + 测试范围 -> 授权 PDP
                                              |
                                              v
                                    Tool PEP + 短期凭证
                                              |
                                              v
                                      隔离副本 / 靶场

外部信任边界落在 Edge PEP，负责约束攻击者可以得到多少反馈；防守 Agent 的执行边界落在 Tool PEP，只有策略服务能根据目标、动作、时间和预算签发能力。详细诊断留在隔离环境和内部证据库，面向外部只返回完成协议所必需的信息。这样既能降低攻击闭环质量，也能让防守方保留可机器验证的修复闭环。

长期价值来自减少可搜索弱点。CISA Secure by Design强调产品制造者承担安全结果。内存安全、统一资源级授权、默认安全配置和类型化接口会直接缩小候选空间；即使攻击者拥有更快的生成与反馈，能够命中的脆弱状态也更少。

评测要比较闭环而非聊天得分

一项可复现实验应固定目标版本、初始访问、工具、网络、时间、请求和费用预算，比较人工基线、模型辅助与 Agent 三种方式。任务同时包含真实弱点、已修复版本和无弱点负样本；成功必须由独立测试、代码证据或业务状态确认，模型自述和扫描器标签不计为验证。

experiment_id: "patch-diff-loop-v1"
target_manifest: "sha256:<target-digest>"
initial_access: "public_source_and_sandbox"
tools: ["code_browser", "compiler", "debugger"]
network: "isolated-target-only"
budget:
  wall_time: "<duration>"
  requests: "<count>"
  cost: "<amount>"
oracle:
  type: "independent_reproducer"
  success: "authorized_state_change_or_reproducible_failure"
event_contract: "Run Event"

Manifest 中的字段同时约束人工、模型辅助与 Agent 组，运行事件记录候选、观察、Oracle 判定、费用和范围拒绝。更换模型、脚手架、工具权限或目标摘要都会形成新实验条件，不能继续沿用旧结论。

报告至少保留以下分母：

验证成功率 =
  由独立 Oracle 证实的成功任务数
  / 全部被评任务数

有效候选率 =
  得到明确且正确反馈的候选数
  / 全部已执行候选数

发现精确率 =
  经复核成立的发现数
  / Agent 报告的全部发现数

范围违规率 =
  超出目标、时间或动作授权的调用数
  / 全部工具调用数

还要报告首次验证成功所需的墙钟时间、模型与工具成本、总请求量、人工接管次数、重复运行差异，以及每个阶段失败在哪里。防守控制则同时记录恶意循环被阻断的数量和正常任务被误伤的数量；只报拦截次数，会把高流量和高误报误写成能力提升。

成功率和精确率按独立任务分层，并对任务簇重采样给出区间；同一任务内的数千次候选属于一次适应性搜索，不能虚增样本量。任何范围违规、生产凭证进入沙箱或未经授权的现实副作用都是结构性门禁失败；能力放大结论则要求模型辅助组相对人工基线的区间、成本和首次成功时间同时报告，不能只挑一个最好运行。

生产前可以在隔离环境重放一条补丁差异链：逐步开放代码浏览、执行、错误详情和并发，观察有效迭代吞吐如何变化；再加入配额、统一外部错误、最小权限和熔断，确认哪项控制提高成本，哪项只是把反馈转移到另一条通道。实验结论应绑定当时的模型、脚手架和目标，不能沿用为永久能力评级。

反例与攻防取舍

反馈只是 AI 放大风险的条件之一。一次性生成大量本地化钓鱼文本、恶意脚本或虚假内容，即使没有目标反馈，也可能降低攻击者的边际成本。反馈变得廉价、快速且可机器验证时，自适应改进更容易持续复利；没有反馈时，生成能力仍然存在，但难以根据目标结果反复校准。

有些反馈无法合理隐藏。开源项目、客户端软件和公开协议允许攻击者在本地构造环境；过度模糊错误还会拖慢正常开发、事件响应和外部研究。此时防守重点应放在快速修复、减少漏洞类型、保护凭证与限制现实权限。蜜罐和欺骗信号可以增加攻击者判断成本，也需要隔离真实数据，避免误导内部运营。

防守方通常拥有更完整的源码、资产、日志和授权测试环境，可以给自己的模型提供更高质量反馈。这个优势需要发现进入修复、验证和部署流程才能兑现。攻防变化最终落在两条时间线上：攻击者多久得到一次可靠成功信号，防守方多久把一个已验证问题变成全量有效的控制。

AI 也不会自动让漏洞悬赏失去意义。Hakluke 对 Bug Bounty 的分析指出，攻击者和防守者通常能获得相近的通用模型，企业采购同一能力并不会天然形成相对优势。外部研究者的价值会从重复扫描转向多样化工具链、边缘场景和新漏洞类型。需要警惕的结构性变化是成本门槛：高质量模型、并发和长时间 Agent 运行可能把原本低成本的参与方式变成算力竞赛，缩小研究者背景的多样性。项目方应同时保留清晰授权、低摩擦报告渠道、按真实影响付费和反自动垃圾机制，不能只按提交数量优化。