简要概括：持续对抗测试是一种把 AI 安全智能体、自动化扫描和人工研判接入日常研发流程的方法。它不只在固定周期做一次渗透测试，而是围绕代码变更、资产变化和产品上线持续发现、验证与分诊风险。要让这类系统真正可用，关键不在于让模型获得更大权限，而在于用模型无法绕过的边界约束它，并让每条发现都有可复核的证据链。

为什么需要持续对抗测试

攻击者不会在两次渗透测试之间停手。服务、端点、依赖和配置会持续变化，单靠每年几次定点测试，很难及时覆盖这些变化。AI 可以扩大安全团队的分析广度，但不能替代测试范围、授权边界和人工判断。

持续对抗测试的目标是把检查前移到变更发生时：代码提交、合并、上线申请和攻击面变化都可以成为触发点。这样做不是承诺自动消除漏洞，而是让风险更早进入验证和处置流程。

持续对抗测试的参考架构

一个可落地的体系通常由变更触发、存量检查、动态测试、验证分诊和审计追踪组成。各模块可以独立建设，但必须共享范围定义、交战规则和证据标准。

变更触发的检查

PR 安全审查：在提交、合并和发布前分析代码差异，优先检查认证、授权、输入处理、依赖升级和敏感数据流的变化。发现应尽量在开发流程内反馈，而不是等到上线后再集中处理。
产品上线评审：根据设计文档、架构变更和数据流，提前识别威胁模型中的缺口。自动化分析适合覆盖面广的检查，涉及业务边界的判断仍需要安全人员确认。
攻击面监控：对主机、服务、代码仓库、域名和公开端点的资产快照做差异比较，并对新增暴露面自动发现、排队和验证。端点与服务代码的映射能帮助团队更快定位责任边界。

存量资产的检查

源码与设计审查：结合静态分析和数据流追踪，检查跨模块调用链中的注入、越权、敏感数据泄露和设计缺陷。单个告警不足以定论，必须回到真实调用路径验证。
Web2 与 Web3 边界：如果后端服务会调用智能合约，应同时检查代码到合约、合约地址到调用方两条路径，避免只审其中一侧。
MCP 服务器治理：为已接入的 MCP 服务器建立登记、威胁建模和变更复查机制，并持续发现未登记的服务。Prompt 注入路径、工具定义和流入模型的不可信内容，应作为同一条风险链处理。
Agent 能力审查：智能体新增工具、数据权限或外部连接前，需要明确用途、访问范围和撤销方式；能力发生变化后，应重新评估。
移动端安全检查：可以将静态分析、隐私权限审计、第三方数据流检查和敌对网络韧性测试纳入发布前验证，但不应把工具输出直接当作最终结论。

动态测试

基础设施测试：默认采取非破坏性策略，枚举可达服务、分析暴露面，并把检查项映射到 NIST SP 800-115、PTES、MITRE ATT&CK 等公开方法。默认只识别问题，不执行漏洞利用，也不使用未获授权的凭据。
Web 应用测试：在明确授权和可控账号下完成认证、抓取和业务流测试，覆盖注入、访问控制和业务逻辑缺陷。自动化发现的异常仍需结合真实业务规则判断影响。
人机协同测试：为安全工程师提供一个可控的交互界面，由智能体基于威胁模型提出对抗场景，工程师决定是否批准、调整或终止。遇到认证决策、业务语义或高风险操作时，智能体必须请求人工介入。

模型不能绕过的护栏

让自主智能体接触真实环境的前提，是把权限控制放在智能体无法触及的位置。权限不能只依赖提示词或模型自我约束，而应由服务端策略和工具执行层共同实施。

交战规则应至少包含测试范围、拒绝列表、允许时间、爆炸半径、脆弱服务豁免和全局终止开关。拒绝列表的优先级高于测试范围；测试窗口限制任务运行时间；爆炸半径限制一次能够触达的资产数量。

另一层独立护栏应在每条命令执行前判断实际影响。只读操作可以默认放行；可能修改数据、状态或生产配置的操作必须被拒绝，除非目标在任务开始前被明确标记为隔离的非生产环境。把检查放在工具执行层，才能避免模型被不可信输入诱导后越权。

如何让发现结果可信

每一条发现都应经过从预检到复核的验证链路，避免把模型输出或扫描器告警直接推给研发团队。

预检先确认代码搜索、模型服务、工单系统、遥测和测试目标是否可用。依赖不可用时应标记本轮结果不完整，而不是让系统继续输出看似确定的结论。

初步分析后，需要建立独立的代码级追踪：从入口定位风险代码，再检查可到达的下游路径。追踪过程还要判断路径上的控制措施究竟能阻断影响、只能事后发现问题，还是并未覆盖该路径。

随后应由不同上下文或不同策略的审查者进行对抗性复核。复核不是重复摘要，而是主动寻找初判遗漏的前提、控制条件和反证。复核深度不足时，可以升级到更严格的检查，但必须设置轮次上限并记录未完成原因。

只有具备可复核证据的发现才应进入处置流程。对于高风险问题，还应结合生产流量、数据分级、服务等级目标（Service Level Objective，SLO）和历史事件，分别判断可利用性、隐私影响和运营影响。互联网可访问的风险可以额外检查日志和 WAF 遥测，确认是否存在已被探测的迹象。

最终进入工单系统的内容应包含测试范围、方法、调用链、控制措施、严重性依据和复核记录。这样，审计与合规所需的证据可以伴随测试过程产生，而不是在事后补写。

如何评估风险影响

通用严重性评分可以提供沟通基础，但在涉及关键业务时不应替代业务语境。除了攻击复杂度、所需访问权限和可利用性，还应单独评估资金、数据和运营三类影响。

这并不要求自建一套复杂评分模型。更重要的是，让每个等级都能追溯到具体资产、数据分类、业务后果和缓解措施，并在条件不足时明确标记不确定性。

增强人类，而不是取代人类

AI 安全智能体的价值在于扩大覆盖面，而不是替代安全工程师。重复性的资产枚举、代码检索、证据整理和初步分诊可以自动化；威胁建模、业务边界判断、攻击路径创新和高风险决策仍应由人负责。

人机协同的重点不是把人工放在流程末尾兜底，而是在范围设定、风险升级、验证结论和处置优先级等关键节点保留可干预的控制权。

演进路线

先从变更触发的只读检查开始，例如 PR 审查、依赖变更和攻击面差异。
再建立统一的证据格式与人工分诊队列，避免不同工具各自输出无法比较的告警。
条件成熟后，将授权明确的动态测试接入隔离环境，并逐步完善生产环境的只读验证能力。
用已知正确的数据集和复盘过的真实案例评估智能体输出，确认提示词、模型或工具变更是否带来真实改进。

成效如何衡量

不要只统计扫描次数或告警数量。更有意义的指标包括：高置信发现的复核通过率、从变更发生到风险进入分诊的时间、重复告警率、研发接受率、已验证问题的修复周期，以及因权限护栏阻止的高风险操作数量。

这些指标应按资产类型、环境和检查方法分层解读。覆盖面扩大不必然代表质量提高；如果误报、重复发现或无法复核的结果同步增加，团队反而会失去处理能力。

展望

持续对抗测试会让安全检查越来越接近日常研发节奏，但它仍然是一套工程治理系统，而不只是给模型接上更多工具。可复用的基础是：明确授权、模型外护栏、可追溯证据和持续复盘。

收录于 FunTester 原创专题：AI ，测试有点东西

↙↙↙阅读原文可查看相关链接，并与作者交流