AI 自动化渗透：架构与工程挑战
让 Agent 调用扫描器、浏览器和命令行，可以很快形成一段演示。但企业需要的结果不是一串执行记录，而是：在授权范围内找到真实问题，留下可复核证据，并且没有把测试扩展到第三方资产或生产高风险动作。
AI 自动化渗透更适合被设计为有约束的搜索系统，而不是可以自由执行命令的聊天助手。 模型负责理解、提出假设与局部推理，运行系统维护状态、执行权限、预算和验证。模型可以建议下一步，但不能通过自己的建议扩大范围或宣布验证成功。
本文是持续维护的架构与方法文章。基于 AI 驱动的实战网络攻击保留演讲时的 APG、APG Runtime 与工具基础设施方案；历史方案用于理解当时的实践，不自动等同于当前建议。漏洞调查切口见 AI 漏洞挖掘，能力与成本评测见 安全 AI 的能力与落地评测。
从固定流程走向受控搜索
渗透任务的起点可能是明确授权的域名、账号、接口、代码仓库或业务线索；目标是对某项安全要求形成可复核的验证结果。中间步骤会产生新信息，新信息又会改变后续调查方向。
固定 Pipeline 适合范围明确、反馈稳定的任务，例如已授权资产信息整理、组件识别和已知风险检查。复杂业务深挖则需要根据实际证据调整计划。两者可以组合：外层 Workflow 固定授权与交付阶段，内层 Agent 在已批准的线索范围内探索，独立 Verifier 负责判定关键结果。
共享状态也应先于多 Agent 岗位划分。将资产、身份、权限、发现、失败尝试与证据写入可查询的事实库，再由 Worker 领取任务，有助于减少不同 Agent 重复探索和相互引用错误结论。黑板式设计只是一个可选实现；单 Agent 与多 Agent 都必须区分事实、假设和待验证判断。
授权目标、范围、窗口与预算
│
▼
Workflow / 任务调度
│
┌──────┴──────┐
▼ ▼
事实与证据库 ←→ 规划与局部探索
▲ │ 提议
│ ▼
│ 模型外策略与审批
│ │ 允许的动作
│ ▼
│ 受限工具与隔离环境
│ │ 观察
└──── 独立验证器与状态对账
│
▼
结果、审计与人工接管
事实库保存原始证据引用、来源、时间、版本和验证状态。推断可以写入，但不得在后续步骤中悄然升级为事实。失败路径同样保留，避免重复消耗预算，也便于追查误判从哪一步开始。
真正技术上的难题
以下问题相互关联，不宜按“模型问题”与“纯工程问题”简单切开。研究能力、领域知识与系统实现都可能决定最终效果。
攻击面建模
域名、服务、接口、账号、权限、云资源、仓库、依赖和配置来自不同数据源。难点不只是收集，而是识别同一对象、表达关系，并保留关系成立的证据和有效时间。
例如，一个域名指向某个服务，并不表示该服务背后的所有资产都在授权范围内。资产关系图与授权范围必须分开维护：发现关系可以扩展认识，不能自动扩展可执行动作。
攻击链推理
多个低影响问题可能组合成更高影响路径，但每一条边都需要条件与证据。系统应记录当前主体、已有能力、下一步前置条件、允许动作和独立验证方式。
一段信息“看起来像凭证”，不能直接变成“已获得访问权”；一个响应包含资源标识，也不能直接变成“可以访问该资源”。链路中有一条边未经验证，最终影响就仍是待调查假设。
长程规划
长任务中，登录状态、工具可用性、业务数据和调查重点都会变化。单纯按照初始计划执行容易忽略新事实；每一步完全自由规划又容易反复重来。
可以用 Workflow 固定阶段，用阶段计划说明要验证的假设，用局部循环处理环境反馈。计划更新要记录触发原因、被放弃的路径和保留的证据；预算耗尽、授权失效或关键证据不足时停止，而不是通过扩大范围维持“任务进展”。通用模式见Agent 实践。
业务逻辑理解
越权、订单状态错误、退款流程缺陷、优惠权益与交易竞态，往往需要知道业务原本要求什么。仅有接口结构不足以说明哪些行为违反预期。
将角色关系、资源归属、状态机、金额与权益约束、测试账号和历史案例作为显式上下文。先把业务要求写成可验证命题，再调查实现是否满足它。无法确认业务要求时，将问题交给责任人澄清，不由模型根据字段名补出规则。
漏洞验证
疑似发现需要经过入口、前置条件、可达性、证据和影响的检查。验证器可以组合代码路径、受控请求、服务端日志、权限记录、数据一致性检查与人工复核，但判定口径必须在执行前定义。
例如，验证资源隔离时，应使用已批准的测试账号和测试资源，确认账号与资源归属，再比较受控操作的结果。接口返回 200、页面跳转或模型声明成功，都不足以单独证明权限边界失效。
关键结果同时保留失败与成功证据，说明未确认部分。最终报告要能被另一位工程师在相同授权与环境下复核，不以模型再次认可自己的结论替代复现。
Agent 自身安全
目标页面、README、代码注释、日志、工具结果与工单都可能成为不可信上下文。安全测试 Agent 不能因为这些内容要求“继续调查”就访问新资产、读取凭证或外发结果。
本页只定义架构分工：模型提出动作，模型外系统授权，受限执行器执行并记录副作用。上下文信任、能力包络、凭证与逐次授权的具体机制，统一引用 Agent 与工具调用安全和大模型应用安全，不在攻防文章里复制一套控制清单。
环境感知
403 可能来自权限不足或防护拦截，500 可能是普通业务异常，200 也可能是统一错误页。环境观察需要与请求、账号、会话和业务状态关联。
响应分类器、会话状态跟踪和业务状态对账可以辅助判定，但仍要保留“不足以确认”的状态。工具报错不是漏洞证据，检测设备告警不是攻击成功证明，空响应也不能自动证明外部访问已经发生。
评测和可复现
发现数量不能单独衡量系统。至少分别检查有效发现、误报、已知真值下的召回、任务完成、人工介入、成本、复现稳定性和边界违规。
评测应固定任务分布、系统版本和预算，保留负样本与失败案例。靶场、已知漏洞复现与真实业务调查分开报告；先看到补丁再成功复现，不能被计为无先验的新漏洞发现。数据集、基线、业务收益和安全准入的完整方法见安全 AI 的能力与落地评测。
工程化挑战
授权边界控制
授权范围包含资产、账号、动作、窗口、速率和数据去向，不只是域名列表。相关资产不等于授权资产，测试环境不等于生产环境，允许读取不等于允许修改。
授权应由运行系统提供并强制执行，模型没有修改权限。新增目标或动作需重新批准；停止操作应能够撤销凭证、停止队列并确认未完成任务的状态。架构落地时复用 AI 风险治理中的能力包络、责任与停止权，而不是由 Agent 临时解释授权书。
工具调用
工具注册需要明确输入与输出结构、权限、超时、速率、风险与副作用。运行系统负责检查参数、限定环境、记录调用和处理重试；模型负责选择候选工具并解释观察，但不能自行决定权限等级。
高影响动作尤其要区分“请求超时”与“动作未执行”。缺少执行对账时，不应直接重试可能重复产生副作用的操作。工具返回既是证据来源，也是不可信输入，不能自动成为下一次授权。
噪声和误伤控制
将预算分配到任务、目标、阶段和工具，记录最大请求数、并发、重试与运行时间。重复请求、无效枚举、重复发现和需要大量人工排查的报告，都应进入成本与噪声统计。
预算达到上限时停止或交给人工重新分配，不以生成更多候选代替有效进展。新增动作应能说明要验证哪项假设、为什么需要执行，以及什么结果会改变下一步判断。
生产治理
在上线前确定谁授权、谁确认发现、谁审批高影响动作、谁处理误伤、谁能停止、恢复需要什么证据。系统自主程度应随证据与控制逐步增加，而不是直接追求“全自动”。
可从只读信息整理、上下文聚合和漏洞假设开始，在隔离环境中加入受控验证；只有经过业务批准、独立测试和停止演练的能力，才进入限定范围的真实环境。报告生成和工单写入也有数据与副作用边界，不因为它们处于流程末端就免于审计。
已经发生异常时，撤权、隔离、恢复和对账方法引用 AI 运行监控与事件响应。运行治理负责限制后果，能力评测负责证明效果，两者不能互相替代。
最小交付闭环
第一版不必覆盖所有攻击阶段。选择一类有明确授权、可靠反馈和独立验证方式的任务，连通范围约束、事实库、工具、验证器、报告和停止机制。
交付时至少能够回答：系统调查了什么，依据哪些事实，哪些动作被允许或拒绝，发现如何验证，哪些结论仍不确定，以及消耗了多少机器和人工成本。能够稳定回答这些问题后，再扩展任务类型和自主程度。