跳到主要内容

AI 自动化渗透：架构与工程挑战

让 Agent 调用扫描器、浏览器和命令行，可以很快形成一段演示。但企业需要的结果不是一串执行记录，而是：在授权范围内找到真实问题，留下可复核证据，并且没有把测试扩展到第三方资产或生产高风险动作。

AI 自动化渗透更适合被设计为有约束的搜索系统，而不是可以自由执行命令的聊天助手。 模型负责理解、提出假设与局部推理，运行系统维护状态、执行权限、预算和验证。模型可以建议下一步，但不能通过自己的建议扩大范围或宣布验证成功。

本文是当前唯一持续维护的授权攻防方法文章。基于 AI 驱动的实战网络攻击仅作为 2025 年演讲归档，保留 APG、APG Runtime 与 Offensive Infrastructure 的历史语境；其中仍有效的思想在这里吸收和演进，不在两篇文章中同步维护。漏洞调查切口见 AI 漏洞挖掘，能力与成本评测见 安全 AI 的能力与落地评测。

从固定流程走向受控搜索​

渗透任务的起点可能是明确授权的域名、账号、接口、代码仓库或业务线索；目标是对某项安全要求形成可复核的验证结果。中间步骤会产生新信息，新信息又会改变后续调查方向。

固定 Pipeline 适合范围明确、反馈稳定的任务，例如已授权资产信息整理、组件识别和已知风险检查。复杂业务深挖则需要根据实际证据调整计划。两者可以组合：外层 Workflow 固定授权与交付阶段，内层 Agent 在已批准的线索范围内探索，独立 Verifier 负责判定关键结果。

共享状态也应先于多 Agent 岗位划分。将资产、身份、权限、发现、失败尝试与证据写入可查询的事实库，再由 Worker 领取任务，有助于减少不同 Agent 重复探索和相互引用错误结论。黑板式设计只是一个可选实现；单 Agent 与多 Agent 都必须区分事实、假设和待验证判断。

授权目标、范围、窗口与预算
              │
              ▼
       Workflow / 任务调度
              │
       ┌──────┴──────┐
       ▼             ▼
  事实与证据库 ←→ 规划与局部探索
       ▲             │ 提议
       │             ▼
       │       模型外策略与审批
       │             │ 允许的动作
       │             ▼
       │       受限工具与隔离环境
       │             │ 观察
       └──── 独立验证器与状态对账
                     │
                     ▼
              结果、审计与人工接管

事实库保存原始证据引用、来源、时间、版本和验证状态。推断可以写入，但不得在后续步骤中悄然升级为事实。失败路径同样保留，避免重复消耗预算，也便于追查误判从哪一步开始。

一条可复用的源码漏洞发现 Pipeline​

Mandiant 公开的 AVDH 是一个值得参考的点时源码审计架构。它没有让多个 Agent 自由讨论，而是用确定性的 Harness 把不同职责串成顺序 Pipeline，并在关键位置设置人工 Gate：

环境与代码上下文
      ↓
Threat Modeling
      ↓ 人工确认威胁模型
Entry Point Discovery
      ↓
Context Enrichment
      ↓
Hypothesis Generation
      ↓ Confidence Filter
Independent Validation
      ↓
Validation Synthesis
      ↓
去重 / 风险评级
      ↓
人工动态 PoC 验证

Threat Modeling 先建立目标的安全语义。Explorer Agent 判断软件类型、读取文档、排除无关目录，再让 Specialist Explorer 分析认证、授权、路由等领域，最后合成威胁模型。这里的关键不是生成一张漂亮架构图，而是先回答攻击向量、业务逻辑、权限和可达性，否则后续代码分析容易失去安全上下文。

Entry Point Discovery 追求广覆盖。Mandiant 使用较轻量模型并行扫描范围内文件，提取 HTTP Route、IPC Listener 等入口及其中的用户输入 Source。这与“Breadth 用便宜模型”的搜索预算策略一致：先把攻击面覆盖完整，再把昂贵推理留给少量候选。

Context Enrichment 解决“单看入口不够”的问题。每个入口由独立 Agent 沿代码继续收集 Sanitizer、权限、路由条件和多层函数调用，把与该入口真正相关的代码聚合起来，再决定进入 Access Control、Data Flow 或两条分析路径。

Hypothesis Generation 刻意偏向 Recall。Access Control Agent 检查身份、授权和保护假设，Data Flow Agent 跟踪用户输入到危险 Sink；这一阶段只做有限自验证，让 Agent 尽可能提出候选，再通过 Confidence Filter 控制数量。这种设计把“创造性找线索”和“严谨确认漏洞”分开，避免同一个 Agent 因过早自我否定而漏掉候选。

Hypothesis Validation 则转向怀疑式验证。AVDH 为同一假设启动多个 Validation Agent，再由 Synthesis Agent 汇总冲突证据，将结果区分为 Confirmed、Disproven 和 Rejected。模型间一致并不等于真实漏洞，因此随后仍由专家在动态环境中执行 PoC，确认模型假设成立且不存在未观察到的补偿控制；无法通过动态验证的结果被丢弃。

这套 Pipeline 最值得借鉴的不是具体 Agent 数量，而是几个分离原则：Recon 与深挖分离、假设生成与验证分离、模型判断与动态证据分离、自动化与人工责任分离。

评测必须防止记忆、过拟合和 Judge 偏差​

AVDH 还把 Benchmark 当成 Harness 的组成部分，而不是上线后的附加报表。Mandiant 指出，公开漏洞仓库可能已经进入前沿模型训练数据，因此仅用公开 CVE 复现很难区分“真正推理”与“记住答案”。他们使用跨 Domain、语言、漏洞深度和架构的私有合成代码库，并由安全专家确认植入漏洞真实可达、可以动态利用。

评分阶段要求发现精确对应 Ground Truth，而不是只做宽松语义相似；额外流程处理 False Positive 和 Duplicate，最后仍由人工检查 AI Grader。重大 Harness 版本在多个领域和架构上重复测试，以降低模型非确定性造成的偶然波动。

因此 Agent 漏洞发现的持续优化至少要同时防四类问题：训练数据污染、针对 Benchmark 过拟合、重复发现虚增指标、AI Judge 自己误判。 Prompt、Skill 或规则每次更新，都应该在目标样本和保留集上比较，并明确是否引入质量回归。

真正技术上的难题​

以下问题相互关联，不宜按“模型问题”与“纯工程问题”简单切开。研究能力、领域知识与系统实现都可能决定最终效果。

攻击面建模​

域名、服务、接口、账号、权限、云资源、仓库、依赖和配置来自不同数据源。难点不只是收集，而是识别同一对象、表达关系，并保留关系成立的证据和有效时间。

例如，一个域名指向某个服务，并不表示该服务背后的所有资产都在授权范围内。资产关系图与授权范围必须分开维护：发现关系可以扩展认识，不能自动扩展可执行动作。

攻击链推理​

多个低影响问题可能组合成更高影响路径，但每一条边都需要条件与证据。系统应记录当前主体、已有能力、下一步前置条件、允许动作和独立验证方式。

一段信息“看起来像凭证”，不能直接变成“已获得访问权”；一个响应包含资源标识，也不能直接变成“可以访问该资源”。链路中有一条边未经验证，最终影响就仍是待调查假设。

长程规划​

长任务中，登录状态、工具可用性、业务数据和调查重点都会变化。单纯按照初始计划执行容易忽略新事实；每一步完全自由规划又容易反复重来。

可以用 Workflow 固定阶段，用阶段计划说明要验证的假设，用局部循环处理环境反馈。计划更新要记录触发原因、被放弃的路径和保留的证据；预算耗尽、授权失效或关键证据不足时停止，而不是通过扩大范围维持“任务进展”。通用模式见Agent 实践。

业务逻辑理解​

越权、订单状态错误、退款流程缺陷、优惠权益与交易竞态，往往需要知道业务原本要求什么。仅有接口结构不足以说明哪些行为违反预期。

将角色关系、资源归属、状态机、金额与权益约束、测试账号和历史案例作为显式上下文。先把业务要求写成可验证命题，再调查实现是否满足它。无法确认业务要求时，将问题交给责任人澄清，不由模型根据字段名补出规则。

漏洞验证​

疑似发现需要经过入口、前置条件、可达性、证据和影响的检查。验证器可以组合代码路径、受控请求、服务端日志、权限记录、数据一致性检查与人工复核，但判定口径必须在执行前定义。

例如，验证资源隔离时，应使用已批准的测试账号和测试资源，确认账号与资源归属，再比较受控操作的结果。接口返回 200、页面跳转或模型声明成功，都不足以单独证明权限边界失效。

关键结果同时保留失败与成功证据，说明未确认部分。最终报告要能被另一位工程师在相同授权与环境下复核，不以模型再次认可自己的结论替代复现。

Agent 自身安全​

目标页面、README、代码注释、日志、工具结果与工单都可能成为不可信上下文。安全测试 Agent 不能因为这些内容要求“继续调查”就访问新资产、读取凭证或外发结果。

本页只定义架构分工：模型提出动作，模型外系统授权，受限执行器执行并记录副作用。上下文信任、能力包络、凭证与逐次授权的具体机制，统一引用 Agent 与工具调用安全和大模型应用安全，不在攻防文章里复制一套控制清单。

Browser Harness：稳定的真实状态比“会点网页”更重要​

让 Agent 通过 CDP 或 Playwright 控制浏览器并不难，难的是让浏览器在真实注册、认证、风控和长时间研究中持续提供可信观察。Marius du Preez 公开的 AI Bug Bounty Browser Stack 提供了一个很完整的工程案例：长期持久化 Chrome Profile、固定出口与地理属性、独立流量捕获、人工原地接管，以及在 Browser 与 API 测试之间动态切换。

持久身份。 每个 Profile 保留 Cookie、LocalStorage、登录状态、Consent、Challenge Cookie 和正常浏览历史，而不是每次创建干净 Session。账号、出口 IP、国家、时区和浏览器存储保持一致，使一次研究能够跨多轮运行继续，而不是不断重新触发注册和风控。

Browser 负责建立真实上下文，脚本负责规模化验证。 Agent 可以先通过真实 UI 注册、登录并执行一次正常业务操作，捕获产品真正产生的 OAuth Redirect、Token Refresh、GraphQL、Multipart Upload、Presigned Storage、CSRF 和 Service Worker 流量。一旦得到有效请求，IDOR Matrix、参数变异、Mass Assignment、Injection 和 Race 等高频测试可以转到 HTTP Client 或脚本；只有依赖 SPA、Service Worker、动态页面状态的请求继续留在 Browser Context 中。

人工接管不能破坏状态连续性。 MFA、跨源 iframe、复杂 Consent 或其他需要人工判断的节点，可以把同一个 Browser Profile 暂时交给人处理。完成后 Agent 继续使用原账号、IP、Cookie、Tab 和认证状态。Human-in-the-loop 因此不是“失败后重新开始”，而是运行时的一种状态保持型控制转移。

Profile 必须有明确所有权。 浏览器状态不是无状态算力。多个 Agent 同时驱动同一个 Profile，会混合 Cookie、Storage、账号状态和 Traffic Evidence。Profile 应租给明确的 Target、Research Cycle、Role 和 Agent，生命周期管理器记录 Owner、启动状态、崩溃恢复与释放。

流量证据也要隔离。 每个 Profile 的请求捕获、代理和 Flow 文件应能关联到唯一研究上下文。需要原生 TLS 指纹时，可以牺牲 MITM 可见性改走透明/转发模式，但必须把“本次没有完整流量证据”作为 Provenance 的一部分，而不是假装观测能力没有变化。

这类 Browser Harness 的目的不是伪装成普通用户，而是让授权测试中的账号、网络、浏览器状态和证据具有连续性与可解释性。具体 CAPTCHA、代理或反自动化机制的处理必须服从测试授权和目标规则，不能因为技术上可绕过就自动获得执行权限。

环境感知​

403 可能来自权限不足或防护拦截，500 可能是普通业务异常，200 也可能是统一错误页。环境观察需要与请求、账号、会话和业务状态关联。

响应分类器、会话状态跟踪和业务状态对账可以辅助判定，但仍要保留“不足以确认”的状态。工具报错不是漏洞证据，检测设备告警不是攻击成功证明，空响应也不能自动证明外部访问已经发生。

评测和可复现​

发现数量不能单独衡量系统。至少分别检查有效发现、误报、已知真值下的召回、任务完成、人工介入、成本、复现稳定性和边界违规。

评测应固定任务分布、系统版本和预算，保留负样本与失败案例。靶场、已知漏洞复现与真实业务调查分开报告；先看到补丁再成功复现，不能被计为无先验的新漏洞发现。数据集、基线、业务收益和安全准入的完整方法见安全 AI 的能力与落地评测。

工程化挑战​

授权边界控制​

授权范围包含资产、账号、动作、窗口、速率和数据去向，不只是域名列表。相关资产不等于授权资产，测试环境不等于生产环境，允许读取不等于允许修改。

授权应由运行系统提供并强制执行，模型没有修改权限。新增目标或动作需重新批准；停止操作应能够撤销凭证、停止队列并确认未完成任务的状态。架构落地时复用 AI 风险治理中的能力包络、责任与停止权，而不是由 Agent 临时解释授权书。

工具调用​

工具注册需要明确输入与输出结构、权限、超时、速率、风险与副作用。运行系统负责检查参数、限定环境、记录调用和处理重试；模型负责选择候选工具并解释观察，但不能自行决定权限等级。

高影响动作尤其要区分“请求超时”与“动作未执行”。缺少执行对账时，不应直接重试可能重复产生副作用的操作。工具返回既是证据来源，也是不可信输入，不能自动成为下一次授权。

噪声和误伤控制​

将预算分配到任务、目标、阶段和工具，记录最大请求数、并发、重试与运行时间。重复请求、无效枚举、重复发现和需要大量人工排查的报告，都应进入成本与噪声统计。

预算达到上限时停止或交给人工重新分配，不以生成更多候选代替有效进展。新增动作应能说明要验证哪项假设、为什么需要执行，以及什么结果会改变下一步判断。

生产治理​

在上线前确定谁授权、谁确认发现、谁审批高影响动作、谁处理误伤、谁能停止、恢复需要什么证据。系统自主程度应随证据与控制逐步增加，而不是直接追求“全自动”。

可从只读信息整理、上下文聚合和漏洞假设开始，在隔离环境中加入受控验证；只有经过业务批准、独立测试和停止演练的能力，才进入限定范围的真实环境。报告生成和工单写入也有数据与副作用边界，不因为它们处于流程末端就免于审计。

已经发生异常时，撤权、隔离、恢复和对账方法引用 AI 运行监控与事件响应。运行治理负责限制后果，能力评测负责证明效果，两者不能互相替代。

最小交付闭环​

第一版不必覆盖所有攻击阶段。选择一类有明确授权、可靠反馈和独立验证方式的任务，连通范围约束、事实库、工具、验证器、报告和停止机制。

交付时至少能够回答：系统调查了什么，依据哪些事实，哪些动作被允许或拒绝，发现如何验证，哪些结论仍不确定，以及消耗了多少机器和人工成本。能够稳定回答这些问题后，再扩展任务类型和自主程度。