从漏洞扫描到自主攻击链：AI 时代渗透测试的范式转变

会写 Payload，不等于会做渗透测试

给大模型一个明确的 SQL 注入点，它通常能够解释漏洞原理，构造测试语句，甚至编写一个自动化盲注脚本。

但真实的渗透测试很少从“这里存在 SQL 注入，请利用它”开始。

渗透人员拿到的往往只有一个目标地址，甚至只是一段模糊的测试范围。接下来，他需要自己打开系统，判断这是一个什么业务，寻找注册和登录入口，建立普通用户身份，维护 Cookie 或 Token，梳理页面和接口之间的关系，再从大量正常请求中识别值得测试的参数。

假设某个靶场的完整解题路径是：

注册普通账号
→ 登录系统
→ 发现隐藏查询接口
→ 找到 SQL 盲注点
→ 从数据库中获取管理员凭据
→ 登录管理后台
→ 扩展后台攻击面
→ 完成权限提升

对于人类渗透工程师来说，这是一条相对清晰的攻击链。

但对于 AI 而言，其中任何一步都可能成为阻塞点。

它可能知道 SQL 盲注的原理，却不知道应该先注册；可能成功注册，却在页面跳转后丢失登录状态；可能找到一个带 id 参数的接口，却无法判断它是否真的进入了数据库查询；可能观察到响应发生变化，却把随机网络波动判断为布尔盲注；也可能成功得到管理员账号，却没有意识到这只是业务管理员权限，而不是整条攻击链的终点。

这也是理解 AI 渗透测试时最容易被忽略的一点：

掌握漏洞知识，不等于发现漏洞；发现异常，不等于漏洞成立；证明漏洞成立，也不等于完成一次真实渗透测试。

过去几年，大模型在代码、安全知识、工具调用和长上下文方面迅速进步，越来越多产品开始尝试让 AI 执行自动化渗透测试。行业中也出现了大量类似的表达：自主规划、多智能体协同、自动生成 PoC、全流程无人值守、业务逻辑漏洞发现。

这些方向并没有错。

问题在于，如果只是给传统扫描器接入一个大模型，让模型解释扫描结果、生成几个 Payload，再自动整理一份报告，这还不能称为真正意义上的 AI 渗透测试。

真正的变化，不是扫描器变得更会说话，而是过去主要依赖安全专家完成的环境理解、任务规划、工具选择、结果分析、攻击路径调整和证据判断，开始逐渐被转化为一个可执行的智能系统。

AI 带来的不是某一个工具能力的增强，而是渗透测试生产方式的变化。

渗透测试自动化了很多年，为什么直到现在仍然高度依赖人工

渗透测试从来不是一个完全手工的领域。

端口扫描、目录枚举、指纹识别、弱口令检测、漏洞扫描、PoC 验证和报告生成，都已经存在大量成熟工具。只要给定目标、参数和测试范围，工具通常可以高效完成确定性任务。

从这个角度看，渗透测试早已实现了相当程度的自动化。

但长期以来，被自动化的主要是一个个孤立动作，而不是完整的渗透决策过程。

Nmap 可以扫描端口，但它不会主动思考为什么这个端口值得继续测试；漏洞扫描器可以匹配漏洞特征，但它不会真正理解这个接口在业务流程中承担什么作用；sqlmap 可以在明确注入点后完成深入利用，但它通常不会自己注册账号、浏览业务、寻找隐藏接口，再决定哪个参数应该交给自己处理。

传统工具擅长的是：

输入确定目标
→ 执行确定动作
→ 返回确定结果

真实渗透测试需要解决的则是：

当前环境里有什么
→ 哪些信息值得关注
→ 下一步应该测试什么
→ 应该使用哪个工具
→ 工具结果是否可信
→ 当前路径失败的原因是什么
→ 是否应该继续扩大影响

前一类问题适合规则、脚本和确定性工具，后一类问题则高度依赖经验、上下文和推理。

这也是为什么自动化工具已经发展多年，企业仍然需要渗透测试工程师。

工程师真正提供的价值，往往不是亲自发送某一个 HTTP 请求，而是在大量不完整信息中持续作出判断。他需要把散落的资产、接口、权限、业务角色、历史结果和环境反馈连接起来，形成一幅不断变化的攻击面地图。

《新一代自动化渗透测试应用指南》将新一代自动化渗透能力概括为资产测绘、任务规划决策、实战化纵深验证、业务逻辑漏洞挖掘、安全可控、全流程智能化以及漏洞治理生命周期闭环。这种划分本身就说明，行业关注点已经不再只是“能扫描多少漏洞”，而是系统能否完成从感知、决策到验证和治理的完整闭环。

如果从“究竟自动化了什么”来看，渗透测试大致经历了四个阶段。

第一阶段：自动化单个测试动作

最早的自动化主要围绕已知特征展开。

工具读取端口、服务版本、响应头、页面路径或网络协议特征，然后与规则库、指纹库和漏洞库进行匹配。

这一阶段的典型能力包括：

• 端口扫描；
• 服务识别；
• 操作系统识别；
• Web 指纹识别；
• 弱口令探测；
• 已知 CVE 扫描；
• 常见配置错误检测。

这种模式能够高效覆盖大量标准化问题，但它本质上仍然是特征匹配。

工具知道“某个版本对应某个漏洞”，却不知道这个漏洞是否真的能够在当前环境中被利用；知道某个接口返回了异常内容，却无法判断这是不是业务设计的一部分；知道页面缺少某个安全响应头，也无法理解它是否已经由 CDN、网关或反向代理统一注入。

因此，这一阶段最常见的结果是：发现很多问题，但误报、重复告警和无法复现的问题也很多。

第二阶段：自动化固定测试流程

当单一工具无法覆盖完整攻击面时，行业开始通过工作流、脚本和平台编排多个工具。

例如：

导入资产
→ 扫描存活主机
→ 识别端口和服务
→ 匹配漏洞
→ 调用 PoC 验证
→ 汇总结果
→ 生成报告

这种方式显著减少了人工切换工具和整理结果的工作量，也让企业能够对更多资产进行批量测试。

但固定工作流仍然存在明显局限。

它能够按照预设步骤处理标准场景，却难以应对动态变化。如果某个接口需要先登录，如果 Token 会刷新，如果参数由前端 JavaScript 动态生成，如果页面存在验证码，如果 WAF 对不同 Payload 作出不同反馈，预设工作流就很容易中断。

更重要的是，固定流程通常无法回答一个关键问题：

当当前路径无法继续时，下一步应该怎么办？

传统工作流中的失败往往只有两种结果：重试或者结束。

而真实渗透测试中的失败可能意味着很多不同事情：登录状态已经失效、参数格式不正确、接口存在隐藏前置条件、Payload 被安全设备拦截、工具不适合当前环境，或者最初的漏洞假设本身就是错误的。

这些原因对应完全不同的后续策略。

没有对失败原因的理解，流程自动化就很难真正升级为渗透自动化。

第三阶段：自动化完整测试链路

随着资产测绘、攻击模拟、BAS、漏洞验证和 DevSecOps 平台的发展，自动化系统开始覆盖更长的测试链路。

系统不再只输出疑似漏洞，而是尝试自动完成：

• 动态资产发现；
• 攻击面收敛；
• PoC 或 EXP 验证；
• 权限关系分析；
• 攻击路径模拟；
• 修复后的自动复测；
• 与研发和漏洞管理流程联动。

这一阶段的核心变化，是从“发现安全问题”转向“验证安全问题”。

一个扫描器根据响应特征判断存在命令注入，与系统在受控条件下执行无害命令、获得稳定响应、保留完整请求和证据，价值完全不同。

前者给出风险提示，后者证明了攻击路径。

不过，此时大部分攻击策略仍然由安全专家提前设计。平台可以自动执行较长流程，但它执行的通常还是预设 先验知识。面对超出规则范围的业务系统和未知情况，仍然需要人类接管。

第四阶段：大模型驱动的自主智能体渗透测试

大模型出现后，自动化的对象开始从动作和流程转向决策。

新一代系统不再只是严格按照预设规则运行，而是尝试理解测试目标，根据环境反馈生成阶段计划，选择工具，解释结果，再动态调整下一步策略。

文档将这一阶段描述为由大语言模型承担决策核心，通过多智能体协作完成任务规划、工具调用、结果分析和策略调整，并在未知环境中根据上下文生成新的测试策略甚至验证脚本。

这意味着，AI 渗透测试不再只是：

模型生成命令
→ 工具执行命令

而是形成一个持续循环：

理解目标
→ 建立假设
→ 选择动作
→ 调用工具
→ 观察结果
→ 评估假设
→ 更新状态
→ 规划下一步

过去自动化的是“怎么做”，现在开始尝试自动化“为什么做”和“接下来做什么”。

这是一次真正的范式变化。

但也必须看到，这一阶段远没有成熟到能够完全替代高级渗透专家。文档对其能力边界的判断相对克制：自主智能体可以完成大量过去需要初中级工程师处理的标准化工作，而需要深度业务理解、原创攻击思路和高风险判断的任务，仍然依赖高级专家。

这更接近当前 AI 渗透测试的真实状态。

它不是一个无所不能的自动黑客，而是一个开始具备环境感知、任务规划和工具协同能力的初级或中级渗透工程师。

为什么是现在：AI 渗透测试所需要的条件终于开始成熟

大模型并不是第一个尝试自动化渗透测试的技术。

在它之前，专家系统、规则引擎、攻击图、自动化工作流和强化学习都曾用于安全测试。但大多数方案都很难跨越特定场景，一旦目标系统、工具格式或业务流程发生变化，自动化能力就会迅速下降。

大模型带来的关键变化，是它第一次把原本割裂的多种信息放入了一个相对统一的语义空间。

一个通用大模型通常同时理解：

• HTTP 请求和响应；
• 常见编程语言；
• 数据库语法；
• 操作系统命令；
• Web 前端代码；
• 错误堆栈；
• 安全漏洞原理；
• 工具帮助文档；
• 自然语言业务描述。

这使它能够在不同信息之间建立过去很难通过固定规则完成的关联。

例如，它可以从前端 JavaScript 中识别出一个 API 地址，从 API 参数中判断它可能对应数据库主键，再结合响应内容判断该接口可能存在水平越权。这些判断未必总是正确，但它已经具备了将页面、代码、协议和业务语义连接起来的能力。

不过，单纯的大模型仍然只是一个会生成文本的系统。

AI 真正能够参与渗透测试，还依赖另外几个条件。

工具调用让模型从“知道”走向“行动”

只有当模型能够调用真实工具，获取真实结果，并根据结构化反馈继续决策时，它才真正进入渗透测试流程。

在一个合理的 AI 渗透系统中，模型和工具应该有清晰分工：

模型负责：
理解目标、建立假设、选择工具、分析结果、调整策略
 
工具负责：
发送请求、执行扫描、解析协议、运行脚本、保存证据

让大模型自己模拟工具结果，既不可靠，也没有安全价值。

渗透测试中的事实必须来自环境，而不是来自模型想象。

浏览器自动化让 AI 能够进入真实业务

现代 Web 系统的攻击面已经不再只存在于静态 URL 中。

很多接口需要通过登录、按钮点击、页面跳转和前端异步请求才能发现。认证状态可能依赖 Cookie、JWT、CSRF Token、设备指纹甚至动态签名。

因此，AI 需要的不只是 HTTP 请求工具，还需要一个能够模拟真实用户的浏览器执行环境。

文档将自主浏览器和业务攻击链建模列为新一代自动化渗透测试的重要技术，强调系统需要模拟页面加载、表单填写、身份认证、权限分配、交易、密码重置等完整业务操作，并从交互过程中理解业务状态和权限关系。

这一能力决定了 AI 能否从公开页面真正进入登录后的业务世界。

外部状态和记忆让长任务成为可能

一次真实渗透测试可能持续数小时甚至数天。

期间会产生大量信息：

• 已发现资产；
• 页面与接口；
• 用户账号；
• Cookie 和 Token；
• 工具结果；
• 漏洞假设；
• 失败原因；
• 请求和响应；
• 当前权限；
• 待执行任务。

这些内容不可能全部长期堆积在大模型上下文中。

上下文越长，不仅推理成本越高，模型也越容易忽略真正重要的信息。尤其当一个 Agent 同时处理大量目标时，很容易出现任务遗漏、重复执行和结论相互冲突。

因此，真正的 AI 渗透系统必须把记忆和状态外置。

模型每次只读取完成当前决策所需的信息，而不是反复读取全部历史日志。

多智能体让专业任务可以并行展开

渗透测试天然包含多个不同方向：

• 资产侦察；
• Web 测试；
• API 测试；
• 主机测试；
• 权限分析；
• 漏洞验证；
• 报告与证据整理。

如果让单个 Agent 同时处理所有事情，很容易出现上下文膨胀和注意力分散。

多智能体的价值，不是让几个模型彼此进行无意义讨论，而是把不同任务分配给具有明确边界的执行单元。

文档提出由任务规划、资产探测、漏洞验证、结果分析和策略优化等不同角色协同运行，并通过共享资产指纹、防护反馈和漏洞情报动态调整任务权重。

合理的架构通常是：

主控 Agent
负责目标理解、态势判断和任务派发
 
专业 Agent
负责具体探测、验证和取证
 
确定性工作流
负责稳定、重复、批量的执行过程
 
统一状态层
负责事实、任务、证据和权限状态管理

多智能体解决的是职责分离问题，而不是智能本身。

AI 如何完成一次真实的渗透测试

理解 AI 渗透测试最直接的方式，不是列举功能模块，而是看它如何推进一条完整攻击链。

假设系统面对的是一个陌生的电商靶场，目标是验证是否能够获得管理员权限。

系统最初只有一个 URL。

第一步：建立身份，而不是立即扫描所有参数

AI 打开页面后，发现系统存在注册、登录、商品浏览、购物车和订单功能。

一个传统扫描器可能直接爬取公开页面并对参数进行批量测试。

但一个具备业务意识的 Agent 应该首先认识到：大量真实攻击面可能位于登录之后。

于是它创建测试账号，记录注册参数，完成登录，并验证身份状态是否稳定。

此时系统应该更新自己的状态：

当前身份：普通注册用户
认证方式：Cookie Session
可访问功能：商品、购物车、订单、个人中心
尚未发现：后台入口、角色管理、管理接口

这个过程看似简单，却是后续所有测试的基础。

如果登录状态没有被正确维护，后面大量接口都可能返回登录页或统一错误页面，AI 很容易把这些结果误判为接口不存在、漏洞无效，甚至误判为防护拦截。

第二步：建立业务攻击面，而不是只记录 URL

AI 浏览商品、加入购物车、提交订单，并记录页面触发的请求。

它最终得到的不能只是：

/api/products
/api/cart
/api/orders
/api/payment

而应该是一组带有语义的业务对象：

用户
├── 可以创建购物车
├── 可以创建订单
└── 可以查看自己的订单
 
订单
├── 包含商品
├── 具有金额
├── 具有支付状态
└── 与用户身份关联
 
支付
├── 接收订单编号
├── 返回支付结果
└── 影响订单状态

只有建立这层语义，AI 才有可能进一步提出有价值的测试问题：

• 订单 ID 是否可以替换为其他用户的订单？
• 商品价格是否由客户端提交？
• 支付状态是否可以由客户端修改？
• 优惠券是否验证用户等级？
• 未支付订单是否能够直接进入退款状态？

这也是业务逻辑漏洞与传统参数漏洞的根本区别。

它们往往不存在一个明确的恶意字符串，而是来自角色、资源和状态之间的错误关系。

第三步：提出漏洞假设

假设 AI 在一个查询接口中发现如下请求：

GET /api/order/detail?id=1024

它观察到 id 是一个连续数字，并且响应返回订单对象。

此时可以形成两个不同假设：

假设一：接口可能存在水平越权
假设二：id 参数可能进入数据库查询，存在注入风险

这两个假设对应完全不同的验证方法。

对于越权，应该更换订单编号，并比较资源所有者和当前身份。

对于 SQL 注入，则需要构造对照条件，观察响应内容、状态码、长度或时间变化。

优秀的 Agent 不应该把“参数名是 id”直接等同于“存在 SQL 注入”，而应该将其登记为待验证线索。

第四步：用最小动作验证，而不是直接扩大攻击

假设系统怀疑存在布尔盲注。

合理的验证流程不是立刻开始大量枚举数据库，而是先建立稳定的真假对照：

原始请求：基线响应
真条件：应与基线接近
假条件：应与基线产生稳定差异
重复多次：排除网络和业务波动

只有在响应差异可重复、且能够排除身份失效、缓存、限流和随机页面变化后，才能把状态从“疑似注入”提升为“已验证漏洞”。

如果进一步提取数据，也应该遵循最小化原则，只获取证明影响所必需的有限信息，而不是无边界地读取数据库。

第五步：把单点漏洞连接成攻击链

假设 AI 通过受控盲注验证获得了一个管理员账号，并在授权范围内完成登录。

这时任务还没有结束。

它需要更新身份状态：

原身份：普通用户
新身份：业务管理员
新增攻击面：后台管理、用户管理、日志管理、文件处理

然后重新执行攻击面发现。

同一个系统在不同身份下，暴露的功能完全不同。管理员后台可能存在文件上传、任务执行、插件管理、配置导入或日志查询等高权限能力。

AI 需要判断当前权限是否已经满足测试目标，还是仍有进一步权限提升空间。

这里必须区分：

普通用户 → 管理员
属于业务权限提升
 
Web 服务账号 → 系统 root
属于操作系统权限提升

很多自动化系统会在获得后台账号后直接宣告“完成提权”，但从严谨的渗透测试角度看，这两个概念并不相同。

第六步：形成可复现的证据链

最终输出不应该只是一句：

通过 SQL 注入获得管理员权限。

而应包含完整路径：

普通用户注册成功
→ 登录后发现订单查询接口
→ 参数真假条件产生稳定差异
→ 证明存在布尔盲注
→ 在最小范围内验证敏感数据可读取
→ 获得管理员测试凭据
→ 登录后台成功
→ 确认权限范围发生变化

每一步都要附带：

• 前置身份；
• 请求和响应；
• 关键参数；
• 结果判断；
• 状态变化；
• 时间信息；
• 工具调用记录；
• 人工审批记录。

这才是一条能够复现、审核和整改的攻击链。

一个可落地的 AI 渗透测试系统应该是什么样

很多人讨论 AI 渗透测试时，首先想到的是选择哪个模型。

但在真实产品中，模型只是系统的一部分。

模型的能力当然重要，但决定最终效果的往往是模型外部的工程体系。

一个相对完整的 AI 渗透测试系统，可以划分为八层。

目标与授权层

这一层定义系统能做什么、不能做什么。

它至少要明确：

• 测试目标；
• 域名和 IP 范围；
• 测试时间窗口；
• 允许使用的身份；
• 禁止操作；
• 请求速率；
• 数据读取上限；
• 高风险动作审批规则。

如果没有明确授权边界，Agent 的自主性越强，风险反而越高。

环境感知层

负责采集真实环境信息，包括：

• 域名、IP、端口和服务；
• Web 页面；
• JavaScript 文件；
• API 请求；
• 技术栈；
• 身份和会话；
• 页面截图；
• 防护设备反馈；
• 业务状态变化。

这一层的输出应当是结构化事实，而不是简单日志。

攻击面与业务建模层

将环境信息组织成可推理的关系模型：

资产
→ 服务
→ 页面
→ 接口
→ 参数
→ 身份
→ 权限
→ 业务对象
→ 状态流转

对于业务系统，还应维护角色、资源和状态机。

例如：

普通用户只能查看自己的订单
管理员可以查看全部订单
已支付订单才能进入退款
优惠券只允许指定用户等级使用

这些正常规则，是发现业务逻辑漏洞的基础。

任务规划层

负责把抽象目标拆解为可执行任务。

任务不应该一次性规划到最后，而应分层管理：

战略目标：获得管理员权限并证明业务影响
 
阶段目标：
1. 建立普通用户身份
2. 完成登录后攻击面发现
3. 寻找身份提升路径
4. 验证管理员权限
 
当前动作：
测试订单详情接口的资源归属校验

计划需要根据实际结果持续调整，而不是生成一次后永久不变。

Agent 与工具执行层

Agent 负责选择工具和组织动作，工具负责确定性执行。

这一层最重要的原则是工具契约。

每个工具都应该明确：

输入
前置条件
输出结构
成功标准
失败类型
超时规则
副作用等级
是否允许重试

不能把一段任意终端文本直接交给大模型，让模型自己猜工具是否执行成功。

例如工具返回：

{
  "status": "failed",
  "failure_type": "session_expired",
  "retryable": true,
  "evidence": [],
  "recommended_action": "refresh_authentication"
}

模型才能知道应该重新登录，而不是错误地认为接口不存在漏洞。

证据与风险评估层

所有发现都要经过证据门禁。

可以将结果划分为四个状态：

线索
→ 疑似漏洞
→ 已验证漏洞
→ 已证明业务影响

不同状态对应不同报告权限。

没有稳定请求响应证据的内容，只能作为线索；完成对照验证后，才能标记为漏洞；只有进一步证明数据、权限或业务影响，才能进入高置信度结论。

状态、记忆与知识层

系统需要区分三类信息。

第一类是事实：

当前账号已经登录
接口返回 HTTP 200
某个订单属于用户 B
修改参数后返回了用户 B 的数据

第二类是假设：

接口可能存在 IDOR
当前账号可能拥有隐藏权限
响应延迟可能来自时间盲注

第三类是知识：

如何测试订单越权
如何判断 Session 是否代表认证身份
不同数据库的盲注特征
某类 WAF 的常见反馈模式

事实、假设和知识不能混在一起。

否则模型很容易把“可能存在漏洞”逐渐记成“漏洞已经成立”。

安全治理与审计层

负责控制 Agent 的能力边界。

文档特别强调，自动化渗透系统必须具备权限范围约束、测试速率管理、高危动作熔断、人在回路和全流程不可篡改审计。

这一层不是附加功能，而是 AI 渗透测试进入生产环境的前提。

AI 渗透测试真正面临的挑战

技术演示中，Agent 往往能够顺利完成一条精心设计的路径。

但真实环境并不会主动为 AI 提供清晰线索。

目标系统可能包含大量无关页面、重复接口、异常数据、复杂权限、历史兼容逻辑和网络波动。模型还会受到上下文长度、工具稳定性、推理成本和安全边界的限制。

真正困难的地方，主要集中在以下几个方面。

挑战一：AI 看到的是请求，但漏洞存在于业务关系中

传统漏洞通常可以围绕单个输入点进行验证。

例如 SQL 注入、命令注入和路径穿越，都存在相对明确的输入与输出关系。

业务逻辑漏洞则不同。

订单越权不是因为订单 ID 中包含某个特殊字符，而是因为服务端没有验证“当前用户”和“目标订单”之间的归属关系。

支付回调伪造不是因为 status 参数格式异常，而是因为系统错误地允许客户端决定本应由支付平台确认的支付状态。

优惠券越权不是因为优惠券编码危险，而是因为服务端没有验证用户是否满足使用条件。

AI 想要发现这类问题，必须从“参数测试”提升到“业务建模”。

解决方式不是给模型添加更多 Payload，而是建立角色、资源和状态之间的关系。

例如：

角色：
游客、普通用户、VIP、商家、管理员
 
资源：
商品、购物车、订单、优惠券、退款单
 
状态：
created、pending_payment、paid、shipped、refunded

然后围绕业务不变量进行测试：

• 普通用户只能访问自己的资源；
• 支付状态必须由可信系统更新；
• 高权限操作必须校验角色；
• 服务端必须重新计算金额；
• 状态只能按照合法顺序转换；
• 同一个操作不能被无限重复执行。

文档也将自主浏览器、业务流程理解和业务攻击图建模作为发现深层逻辑漏洞的关键技术，强调系统需要模拟用户完整交互流程，而不是只分析单个接口。

业务理解能力，可能会成为未来 AI 渗透产品最核心的差异。

挑战二：长攻击链会让模型逐渐失去重点

渗透测试不是一次问答。

一个任务可能产生数万条请求、数百个接口和大量工具输出。随着测试持续推进，真正关键的信息反而容易被淹没。

例如系统已经确认：

• 某账号是普通用户；
• 某个接口只在特定页面触发；
• 某次失败是因为 CSRF Token 过期；
• 某条路径已经验证为误报。

如果后续 Agent 没有读取到这些事实，就可能重复测试、重新得出错误结论，或者继续使用已经失效的身份。

解决这个问题不能只依赖更长的模型上下文。

长上下文能够容纳更多内容，但不等于模型能够始终正确关注最重要的部分。

更合理的方式是上下文分仓。

全局任务状态
├── 目标与授权
├── 当前阶段
├── 当前身份
├── 已确认事实
├── 已验证漏洞
├── 候选线索
├── 失败路径
├── 阻塞问题
└── 下一步任务

关键的请求、响应和工具日志保存在外部系统中，需要时按线索检索。

主控 Agent 每次只读取决策摘要，执行 Agent 只读取当前任务所需上下文。

这不仅降低模型成本，也减少了错误信息在多个任务之间传播。

挑战三：AI 会产生非常合理的误报

传统扫描器的误报通常来自规则不准确。

AI 的误报更危险，因为它能够为一个错误结论生成听起来非常完整的攻击故事。

在一次真实自动化审计复盘中，系统曾产生过几类典型错误。

它看到修改密码接口存在 old_password 参数，于是推断可以通过暴力破解旧密码并绕过认证完成账户接管。但人工验证发现，参数需要经过前端加密处理，并且无有效 Token 时根本无法进入修改密码逻辑。

它看到某个语言设置接口返回了 Django Session，于是推断未认证用户可以创建会话并绕过认证。但创建 Session 只说明服务端为游客分配了状态标识，并不意味着用户获得了登录身份。

它发现请求头 X-Forwarded-For 可以被修改，于是推断能够绕过 IP 锁定和验证码限制。但人工测试发现，即使修改来源 IP，请求仍无法通过验证码和其他认证条件。

这些错误有一个共同特点：

AI 看到了一个局部现象，然后根据安全知识补全了一条并未真正发生的攻击链。

这也是大模型推理能力的双刃剑。

它能够从少量线索中发现潜在风险，也能够从少量线索中生成不存在的漏洞。

解决这个问题必须坚持证据优先，而不是推理优先。

每一个漏洞都应该至少经过以下过程：

发现异常
→ 建立基线
→ 构造正反对照
→ 重复测试
→ 排除身份、缓存和网络影响
→ 验证实际状态变化
→ 保留完整证据

可以将验证深度划分为三级：

L1：异常存在
证明响应与正常情况不同
 
L2：漏洞可稳定复现
证明差异由可控输入导致
 
L3：业务影响成立
证明数据、权限或业务状态受到影响

AI 可以自主完成 L1 和部分 L2，但对于高风险的 L3 验证，通常需要更严格的安全策略，必要时由人工审批。

挑战四：工具失败经常被误解为目标结论

AI 渗透系统严重依赖工具。

但工具并不总是稳定运行。

扫描失败可能来自：

• 参数错误；
• 缺少依赖；
• 网络超时；
• 目标限流；
• Session 失效；
• 权限不足；
• 输出格式变化；
• WAF 拦截；
• 工具版本不兼容。

如果系统没有明确区分“工具失败”和“漏洞不存在”，就会出现大量漏报。

反过来，某些工具输出中的警告、异常字符串也可能被模型误判为漏洞证据。

因此，工具输出必须结构化。

Agent 不应该只看到：

Command failed.

而应该知道：

执行失败
失败原因：认证失效
是否可重试：是
是否产生有效证据：否
建议动作：刷新登录状态后重新执行

工具层越确定，模型层越可靠。

很多所谓“模型能力不足”的问题，本质上是工具接口、状态管理和错误处理设计不完整。

挑战五：已知漏洞容易，未知业务场景困难

大模型对公开漏洞的学习能力很强。

面对常见 CVE、已知组件和标准 Web 漏洞，它可以快速调用已有知识和工具。

但业务逻辑漏洞通常缺少统一 Payload，也没有一个公开 CVE 可以直接匹配。

它需要理解：

• 系统正常流程是什么；
• 哪些字段应该由服务端维护；
• 哪些角色具备哪些权限；
• 哪些状态不能跳过；
• 哪些操作不能重复；
• 多个接口之间如何共同完成一个业务动作。

解决这类问题，需要建立业务安全 先验知识，而不只是漏洞知识库。

例如电商 先验知识 可以包含：

注册与身份
登录与找回密码
购物车
订单创建
价格计算
支付
优惠券
退款
商家与租户
管理员审核

每个 先验知识 应描述：

• 核心角色；
• 关键资源；
• 正常流程；
• 安全不变量；
• 常见风险；
• 测试动作；
• 成功和失败判据；
• 允许的验证深度。

当 AI 进入一个陌生电商系统时，它不需要从零理解所有业务，而是先将系统映射到已有 先验知识，再根据实际差异动态补充。

这比单纯扩大模型参数更容易形成稳定能力。

挑战六：自主能力越强，系统自身越危险

一个真正能够执行渗透测试的 Agent，通常拥有非常强的权限：

• 可以访问网络；
• 可以控制浏览器；
• 可以执行 Shell；
• 可以调用漏洞利用工具；
• 可以使用测试凭据；
• 可以写入请求；
• 可以读取敏感响应。

如果 Agent 被错误提示、恶意页面、提示词注入或错误计划影响，它可能执行超出授权范围的动作。

因此，AI 渗透平台本身就是一个高风险安全系统。

不能只依赖系统提示词告诉模型“不要做危险操作”。

真正的边界必须在模型之外实现。

可以按动作风险分级：

低风险
读取公开页面、资产探测、指纹识别
 
中风险
受控参数测试、无害 PoC、有限数据验证
 
高风险
写入业务数据、使用高权限身份、权限修改
 
禁止动作
破坏数据、影响可用性、越出授权目标

高风险动作应满足：

• 人工审批；
• 最小化验证；
• 测试环境优先；
• 数据读取限制；
• 请求速率限制；
• 一键熔断；
• 全程审计；
• 结果可追溯。

文档将权限边界、人在回路、自适应熔断、非侵入式验证和不可篡改审计列为工程化安全可控的核心要求。

真正成熟的产品，不是让 AI 什么都能做，而是让它在明确边界内稳定完成应该做的事。

挑战七：行业缺少能够代表真实能力的评测体系

判断一个 AI 渗透系统是否优秀，不能只看它在某个靶场上攻破了多少目标。

靶场通常具有明确目标、有限攻击面和预设漏洞，而真实企业环境包含大量正常功能、错误线索、历史系统、复杂权限和防护设备。

一个系统可能在 CTF 中表现很好，却在真实业务中产生大量误报；也可能能够成功执行已有 PoC，却无法自主发现接口和建立攻击链。

因此，评测指标不能只有最终攻破率。

至少应该分解为：

资产发现召回率
接口发现率
身份状态保持成功率
候选线索有效率
漏洞验证成功率
误报率
重复漏洞率
业务逻辑覆盖率
攻击链完成率
证据完整率
人工介入次数
高风险动作拦截率
单任务耗时
模型与工具成本

还必须区分不同能力来源：

基础模型能力
Agent 规划能力
工具执行能力
业务知识能力
状态管理能力
工程稳定性

否则，即使测试结果发生变化，也无法知道究竟是模型变强了，还是工具、提示词、靶场和任务拆分方式发生了变化。

文档在未来趋势部分也强调，自动化渗透能力将越来越标准化、可视化和平台化，误报率、场景覆盖率、结果可复现性和全过程审计将成为重要评价标准。

AI 不应该独立完成所有事情

讨论 AI 渗透测试时，经常会走向两个极端。

一种观点认为 AI 很快就会完全替代渗透测试工程师。

另一种观点则认为模型只会生成文本，不可能完成真实渗透。

这两种判断都过于简单。

AI 已经可以承担大量过去需要人工完成的工作，尤其是重复、标准化和低风险任务。

例如：

• 资产整理；
• 页面和接口枚举；
• 技术栈识别；
• 常规漏洞初步验证；
• 请求响应差异比较；
• 扫描结果归一化；
• 证据整理；
• 报告生成；
• 修复后回归测试。

这些工作耗时很长，却不一定需要高级专家持续参与。

当 AI 能够稳定完成它们后，渗透工程师可以把更多精力投入到：

• 复杂业务理解；
• 未知漏洞研究；
• 攻击链设计；
• 高风险操作判断；
• 防御策略分析；
• AI 渗透系统自身的建设和监督。

未来的合理分工可能是：

AI 负责高频、重复、标准化执行
人类负责目标、边界、复杂决策和最终责任

文档对未来三年的基准情景也持类似判断：智能体主要承担任务规划、工具调度、结果归纳和低风险复测，而复杂业务和高风险判断仍由专家负责。

这不是简单的替代关系，而是岗位价值的重新分配。

渗透工程师会逐渐从“工具操作者”转变为：

• 攻击策略设计者；
• 业务风险分析者；
• Agent 工作流设计者；
• 证据与质量审核者；
• 高风险行动审批者；
• 企业安全知识的沉淀者。

过去，一个优秀工程师的经验主要存在于个人脑中。

未来，这些经验需要被转化为：

• 先验知识；
• Skill；
• 业务状态模型；
• 工具契约；
• 证据门禁；
• 测试策略；
• 失败处理规则。

能够把专家经验工程化的人，可能比单纯熟练使用某个工具的人更有价值。

未来三到五年，AI 渗透测试会走向哪里

AI 渗透测试目前仍处于快速演进阶段。

从现有技术趋势和真实落地问题来看，未来的发展不会只是继续更换更大的模型，而会逐渐向架构、业务、治理和攻防闭环深入。

从流程自动化走向受控自主智能体

未来系统不会只是执行固定步骤，而会根据目标、防护反馈和阶段结果动态生成计划。

但“自主”前面必须带有“受控”。

标准化 Web、API 和已知漏洞场景的自主度会越来越高；复杂业务、未知环境和高风险动作仍然会长期保留人工参与。

文档预测，自动化渗透测试将由流程自动化继续向受控智能体演进，但模型可靠性、监管、工具供应链、企业风险偏好和人才结构都会影响实际速度。

从单点漏洞发现走向攻击链构造

未来产品的竞争重点，不会只是支持多少 CVE 或 PoC。

更重要的问题会变成：

• 能否自主获得必要身份；
• 能否连接多个弱点；
• 能否跨页面和接口推进；
• 能否证明权限和业务影响；
• 能否解释攻击链的因果关系。

一个低危信息泄露和一个普通越权单独看可能都不严重，但如果它们能够组合为管理员接管，风险会完全不同。

AI 的推理和状态管理能力，最适合用于这类组合路径。

从单模型转向模型、规则和工具的协同

并不是所有任务都应该调用最强的大模型。

复杂规划和业务推理需要高能力模型，而参数提取、结果分类、相似漏洞去重、页面摘要等任务，可以使用小模型、规则或确定性代码完成。

未来成熟系统会更像一个分层计算架构：

大模型
负责复杂规划和判断
 
小模型
负责分类、抽取和批处理
 
规则系统
负责硬性边界与确定判断
 
安全工具
负责真实执行和事实获取

这能够同时平衡效果、成本和响应速度。

从单向攻击验证走向攻防闭环

AI 渗透测试不应只生成报告。

测试过程中发现的攻击路径、Payload 特征、WAF 绕过方式和权限问题，可以反馈给：

• WAF；
• SIEM；
• EDR；
• 漏洞管理平台；
• 资产平台；
• DevSecOps 流水线；
• 安全策略系统。

防御系统的反馈又可以用于下一轮测试。

文档提出未来攻击验证产生的流量和结果会反向训练或优化防御规则，形成“以攻促防、攻防互训、动态迭代”的常态化格局。

当攻击和防御能够持续互相验证，渗透测试才真正从周期性项目转变为日常安全能力。

从测试传统系统走向测试 AI 系统

AI 不仅会成为渗透测试的执行者，也会成为新的测试目标。

未来需要验证的对象将包括：

• 大模型；
• RAG 知识库；
• AI Agent；
• MCP 服务；
• 模型工具调用；
• 长期记忆系统；
• 训练数据和微调数据；
• 模型与插件供应链。

这些系统带来了传统 Web 安全之外的新风险：

• 提示词注入；
• 工具越权；
• 数据投毒；
• 隐私泄露；
• 上下文跨用户污染；
• Agent 权限失控；
• 恶意工具返回结果影响模型决策。

文档已经将 AI 系统测试划分为模型层和应用层两个维度：模型层关注训练数据、模型文件和底层安全，应用层关注 RAG、提示词、工具调用和多用户上下文隔离。

AI 安全测试很可能成为渗透测试领域新的重要分支。

结语：真正的竞争，不只是模型能力

AI 正在改变渗透测试。

但这种改变不是给扫描器接入一个聊天窗口，也不是让模型生成更多 Payload。

真正的改变，是把过去依赖安全专家临场完成的环境理解、任务规划、工具协同、证据判断和路径调整，逐步转化为一个能够持续运行的工程系统。

这个系统必须看得懂目标，知道自己当前拥有什么身份；必须能够操作真实工具，而不是幻想测试结果；必须区分线索、假设和已经验证的事实；必须能够在长任务中持续维护状态；必须理解业务角色、资源归属和状态流转；也必须在每一次高风险动作之前受到严格控制。

因此，AI 渗透测试最终竞争的不会只是基础模型。

真正的护城河将来自：

模型推理能力
+
安全知识与 先验知识
+
稳定的工具执行系统
+
业务攻击面建模
+
长任务状态管理
+
漏洞证据门禁
+
安全治理与人工监督
+
持续反馈和经验沉淀

未来一段时间内，AI 很难稳定取代高级渗透专家。

但它会显著改变渗透测试的生产方式。

大量重复、标准化和低风险任务将逐渐由 Agent 完成，渗透工程师的价值则会向复杂业务、未知漏洞、攻击链设计、安全治理和系统建设迁移。

从漏洞扫描到自主攻击链，这不仅是一次工具升级。

它意味着渗透测试开始从依赖个人经验的手工作业，逐渐走向知识可沉淀、过程可执行、结果可验证、风险可控制的智能工程体系。

而这条路真正困难的地方，从来不是让 AI 学会攻击。

而是让它知道什么时候应该行动，如何证明自己是对的，以及如何对每一次行动负责。

参考资料

1. 安全牛. 《新一代自动化渗透测试应用指南：渗透测试正进入“自主智能体时代”》[R]. 2026.

2. Penetration Testing Execution Standard. The Penetration Testing Execution Standard（PTES）[EB/OL].
   https://www.pentest-standard.org/index.php/Main_Page

3. OWASP Foundation. OWASP Web Security Testing Guide, Version 4.2[EB/OL].
   https://owasp.org/www-project-web-security-testing-guide/v42/

4. OWASP Foundation. OWASP API Security Top 10—2023[EB/OL]. 2023.
   https://owasp.org/API-Security/editions/2023/en/0x11-t10/

5. OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications for 2026[EB/OL].
   https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/

6. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework（AI RMF 1.0）[R]. NIST AI 100-1, 2023.
   https://nvlpubs.nist.gov/nistpubs/ai/nist.ai.100-1.pdf

7. MITRE. MITRE ATLAS: Adversarial Threat Landscape for Artificial-Intelligence Systems[EB/OL].
   https://atlas.mitre.org/

8. Deng G, Liu Y, Mayoral-Vilches V, et al. PentestGPT: Evaluating and Harnessing Large Language Models for Automated Penetration Testing[C]//33rd USENIX Security Symposium. 2024.
   https://www.usenix.org/conference/usenixsecurity24/presentation/deng

9. Isozaki I, Shrestha M, Console R, et al. Towards Automated Penetration Testing: Introducing LLM Benchmark, Analysis, and Improvements[EB/OL]. arXiv:2410.17141, 2024.
   https://arxiv.org/abs/2410.17141

10. Yang R, Cheng M, Deng G, et al. PentestEval: Benchmarking LLM-based Penetration Testing with Modular and Stage-Level Design[EB/OL]. arXiv:2512.14233, 2025.
    https://arxiv.org/abs/2512.14233

11. OWASP Foundation. OWASP Top 10: 2025—The Ten Most Critical Web Application Security Risks[EB/OL]. 2025.
    https://owasp.org/Top10/2025/