AI 能跑完攻击。你能信任它的结果吗？
AI 能在几秒内生成一个令人信服的漏洞利用故事。而运行时实证、负对照和人工审查，才决定这个故事能否成为一个安全团队可以信任的发现。
如果一个 AI 智能体生成了一个令人信服的漏洞利用叙述，这个发现就可以被信任。
不。一个看似合理的解释，仍然只是一条线索。
在一次获得授权的移动应用扫描中，我们的工作流在某个账户流程中浮现出了看起来像是授权失效的情况。该客户似乎对后端调用使用一个应用级凭据，而对敏感请求使用第二个账户专属凭据。有一个端点似乎在没有那第二个凭据的情况下也接受了请求。
我们开启了一项调查，并暂时搁置了这个发现。
只有在做完以下这些之后，我们才信任了这个结果：运行一个受控请求、观察到安全效应、检查一个负对照、将它与一个会拒绝缺少同一请求头的请求的端点进行对比，并用一个全新的凭据重复该测试。
智能体为我们指出了弱点所在。而测试结果才决定了它是否该被写入报告。
授权发现是如何得到确认的
看到一个端点接受某个对象标识符，并不足以确认授权缺陷。我们需要证明，它在没有预期的所有权检查的情况下，返回或修改了一个非公开对象。
移动客户端给了我们一条有用的线索。它向后端发送了一个应用级凭据，并对敏感请求额外附加了一个独立的账户专属凭据。有一个端点似乎并不要求那第二个值。
于是我们在一个获得授权的环境中运行了五项检查：
- 我们构建了一个协议有效的请求，其中包含应用凭据，但有意省略了账户专属凭据。
- 来自该授权测试的一个已知有效的账户标识符返回了账户字段，包括姓名和账户元数据。这些值在报告中已做脱敏处理。
- 一个无效的标识符返回的是"账户不存在"的基线响应，而不是数据。
- 当省略同一账户凭据时，一个独立的敏感端点会拒绝请求，这提供了一个有用的对比。
- 使用一个全新的应用凭据时，该行为仍然重现，这降低了缓存响应或临时会话解释该结果的可能性。
第一段报告摘录展示了应用级 bearer 令牌、被省略的账户专属凭据，以及响应中返回的脱敏账户字段。
第二段摘录记录了无效账户的基线响应，以及对比端点对缺少账户专属请求头的请求的拒绝。
这些截图来自报告，而非独立的数据包捕获。它们让调查可追溯。重现结果仍然需要另一名测试人员在一个获得授权的环境中重放该序列。
此重建图省略了客户标识符、端点名称、请求格式和响应字段。
综合起来，这些检查支撑了一个狭窄的结论：这个端点在没有预期的账户专属凭据的情况下返回了账户数据。该请求并非完全无凭据，因为它仍然携带了一个应用级 bearer 令牌。我们把报告停留在这一层面，而不是声称该路径完全未经身份验证。
报告以修复和复测标准收尾。后端应当强制执行所有权检查、拒绝缺少账户凭据的请求、避免把客户端分发的应用凭据当作用户授权，并统一账户查找错误的处理方式。修复之后，应当再次运行同样的正对照和负对照。
发生了什么变化：实证先于严重程度
该工作流的早期版本可能会从一条线索直接跳到一个结论。一处响应差异可能被误贴上"注入"的标签。一个危险的浏览器 sink 可能被称为"可利用的 XSS"。一次重定向可能被报告为"身份验证绕过"。每条线索都值得调查，但没有哪条已经赢得这个标签。
告诉模型"避免误报"并不能解决问题。相反，我们为每一类漏洞定义了确认所需的最低证据。
每一类漏洞在确认之前，都要求一种不同的可观察效应。
未通过这些检查的候选项仍被标记为假设。这道过滤器降低了一条没有支撑的线索进入最终报告的可能性。我们不宣称一个普适的百分比，因为这个比率会随目标、访问级别、漏洞类别，以及是否把早期线索与可写入报告的发现一并计算而变化。
一个有用的运营度量是：有多少已报告的发现能够经受住重现、影响评估和证据检查，而无需另一名测试人员从零开始重建整个调查。
决定什么算数的是框架（harness），而非模型
语言模型可以选择一个有用的下一步测试。但它不应自行决定一个怀疑何时成为一个已确认的发现。周边的框架负责强制执行范围、控制工具、保存观察结果，并检查所需的实证是否存在。
范围强制执行、工具控制、证据采集和人工审查，都在模型之外运行。
以服务器端请求伪造为例。一个用户可控的 URL 字段是一条线索。而确认则需要证据表明，是应用服务器（而不是测试人员的浏览器）连接到了一个受控目标。报告应当保留请求、回调、构建版本、角色、端点和时间。只有在另一项测试证实了该影响时，它才应声称获得了内部网络访问。
如果证据仍然不足，框架会请求另一项测试，或把结果记录为"不确定"。信心、重复和详尽的解释都无法让它升级。
我们为什么在自己的系统上测试它
我们也在由 Ostorlab 运营的、经过挑选并获得授权的环境中运行该工作流。这为内部安全和产品验证提供了证据，但它不能替代独立评估。
这种访问权限创造了一个有用的反馈循环。工程师可以把一个声称与具体实现进行对照，检查智能体是否触及了预期的层级，查看它遗漏了什么，并在已知条件下复测一个修复。没有支撑的候选项会成为负测试用例。当智能体遗漏了一个前置条件时，我们就把那个上下文加入框架。修复之后，一个已验证的漏洞利用可以成为一个回归测试。
这项工作让该工作流针对已知的身份验证状态、实现细节、部署约束和修复周期进行检验。结果告诉我们它在那些环境中的表现如何。它们并不确立一个普适的准确率。
把同一规则应用到 GoPhish
Ostorlab 对 GoPhish 的源代码评估把同一条证据规则应用到了一个完整的代码仓库。
Agentic Deep Scan 浮现出了横跨整个仓库的若干模式：可能更新既有对象的创建路径、与账户状态脱钩的凭据检查、不安全的浏览器渲染路径，以及行为随配置而变化的出站请求控制。
这些信号告诉团队接下来该看哪里。它们并不会自动进入报告。
最终评估包含八个报告级发现。每一个都被追溯到相关的处理器、模型、中间件以及浏览器或网络路径，然后配以一个可重现的本地概念验证和修复指导。其价值来自那些经受住验证的完整路径，而非所检测到模式的原始数量。
外部研究带来了什么
我们的第一方案例展示了我们如何验证结果。而独立研究有助于回答一个不同的问题：这些智能体的能力究竟有多强？
在一项受控研究中，研究人员在一个横跨约 8,000 台主机、12 个子网的真实大学网络上，比较了十名安全专业人员、六个现有 AI 智能体，以及一个名为 ARTEMIS 的新型多智能体系统。两种 ARTEMIS 配置中较强的一种整体排名第二：它所提交的十一项中有九项（即 82%）被判定为有效，并在该研究的评分框架下胜过了十名专业人员中的九名。
这个结果需要放在语境中看待。参与者在四天内最多拥有十个有效工作小时，而不是通常一到两周的项目周期。该环境缺乏真实的防御压力，样本量很小，而且这篇论文是一份 arXiv 预印本。ARTEMIS 产生的误报也多于人类参与者，并且在图形界面方面表现吃力。
该研究证明了在一个受控环境中的能力。它并不确立在每一个应用、每一套业务工作流或每一种生产约束下的等效性。根据其框架的不同，一个智能体可能能够绘制资产和路由、维持会话、比较角色、追踪数据流、生成载荷、驱动安全工具，并在一次失败的测试后做出调整。
把人放在关卡处，而非每一次点击的背后
一位为本文接受采访的安全从业者表示，AI 在侦察、载荷生成和漏洞利用执行方面已经很有用了。在他看来，人仍必须主导业务逻辑、模糊的影响判断以及最终验证。他们强调了可追溯性和可重现性。
并非每一个请求都需要人工批准。当某项操作可能改变数据、暴露客户或超出授权范围时，人工批准才变得重要。
在测试之前，由人来界定目标、构建版本、账户、数据分级、速率限制和禁止的操作。强制执行这些限制的，必须是执行层，而不是提示词中的一句话。
在测试期间，智能体负责高吞吐量的侦察和安全的假设检验。而破坏性操作、生产环境变更、重大的权限提升，以及可能暴露真实客户数据的步骤，则由人来批准。
在测试之后，由一名审查者重现重要的发现、质询严重程度和业务影响、检查覆盖盲区，并对每一个可报告的结果做出接受或拒绝的决定。第二个模型可以协助分级处理，但如果它只是读取第一个模型的解释，那它就不是独立的证据。
PwC 描述了一套类似的工作流：由智能体执行侦察，由人来验证建议和信息收集方法，并由系统为测试人员提出可供调查的目标。
CREST 一项涉及 19 个国家 62 家网络安全服务商的研究同样发现，AI 的使用集中在侦察、分析和报告环节，而人在风险更高的测试中参与得更多。
只有当审查者拥有原始证据、相关专业能力，以及足够的时间去质询结论时，人工审查才会有帮助。
敏感数据是威胁模型的一部分
一次渗透测试可能会暴露源代码、架构、管理员会话、API 令牌、内部 URL、客户记录和可用的漏洞利用代码。"我们不会用您的提示词进行训练"只回答了风险中的一个部分。
在授予一个智能体访问权限之前，安全团队应当了解：
- 原始代码、流量或密钥是否会被发送给一个外部模型 API。
- 哪些提示词、工具输出和轨迹会被保留，以及谁可以访问它们。
- 在模型调用和日志记录之前，密钥是否会被脱敏。
- 执行是否被隔离，出站连接是否被限制。
- 数据在哪里被处理、保留多久，以及如何验证删除。
模型供应商可能什么都不保留，而一个编排服务却保留了每一条 HTTP 响应。因此审查必须覆盖完整的数据路径，而不仅仅是模型 API。
衡量每个已验证结果的成本
侦察工作量的减少，并不能证明每一次项目的总成本更低。
要评估每个已验证结果的成本，应纳入平台费用、模型用量、基础设施、重试、分级处理、人工验证和治理。
有用的度量包括：每个已验证重要发现的成本、人工审查时间、每个版本所测试的授权面、被拒绝或降级的候选项比率，以及从修复到验证复测的时间。
要论证商业价值，应比较范围和质量对等的情况。然后衡量该工作流是否在提升测试频率或覆盖范围的同时，降低了取得已验证结果所需的专家投入。
审计方或客户会接受这份报告吗？
对于"AI 渗透测试"并不存在一条普适的接受规则。接受与否，取决于适用的审计标准或客户合同，以及该项目是否满足其在范围、方法论、测试人员资质、独立性、证据、人工审查和问责方面的要求。
在测试之前，请与审计方或客户确认这些要求。AI 或许能完成大量技术工作，但它无法判定自己的报告是否满足那些要求。特定框架下的接受与否是一个单独的问题，不应从模型能力中推断得出。
那么，你能信任一个 AI 渗透测试结果吗？
可以，前提是证据能够回答以下六个问题：
- 目标是否获得了明确授权，又有什么未经测试？
- 执行了哪些操作，目标又返回了什么？
- 什么样的可观察效应证明了该漏洞？
- 哪些负对照和对比对照排除了更简单的解释？
- 另一名测试人员能否重现该结果？
- 谁审查了证据，并对该结论持续负责？
移动端案例和 GoPhish 评估都走到了同一个结论：只有那些有可重现证据支撑的声称，才进入了报告。
AI 能跑完攻击。
信任始于：别人能够检视它、重现它，并得出同样的结论。
常见问题
什么是 AI 渗透测试？
AI 渗透测试使用 AI 智能体（通常基于语言模型），连接到安全工具，去调查一个获得授权的目标。与传统扫描器不同，智能体能够根据先前的观察选择下一个测试、维持会话、生成载荷并验证假设。只有当控制层记录了范围、操作、证据和局限时，其结果才是有用的。
AI 能取代人类渗透测试人员吗？
就一次完整的评估而言，如今还不能可靠地取代。AI 可以自动化侦察、已知漏洞测试、载荷生成和修复复测。人仍然是必需的，用以理解业务意图、评估模糊的影响、批准有风险的操作、检查覆盖盲区，并对最终报告持续负责。AI 可能取代单项任务，但不会取代完整的人类角色。
AI 渗透测试安全或可信吗？
只有在强有力的控制下才如此。执行应当保持在授权范围之内，有风险的操作应当需要批准，敏感数据应当受到保护，而重要的发现应当由人来验证。团队还必须能够检视执行了什么、发生了什么，以及什么仍未经测试。
为什么 AI 渗透测试工具会产生这么多误报？
当 AI 渗透测试工具把可疑的代码或异常的响应误认为是成功的漏洞利用时，就会产生误报。常见原因包括：缺少应用上下文、对身份或前置条件的错误假设、把重定向解读为成功的身份验证，以及运行时访问不完整。运行时验证和可重现性检查有助于阻止没有支撑的假设变成可报告的发现。
AI 发现一个漏洞与证明一个漏洞之间有什么区别？
标记一个潜在漏洞意味着识别出一个看似合理的弱点，例如一个用户可控的 URL 到达了一个服务器端请求函数。而证明它则需要一次获得授权的测试，产生可观察的效应、保留请求和响应或回调、记录前置条件，并能被独立重现。一个假设只有在经过这样的验证之后，才成为一个已确认的发现。
AI 渗透测试会让敏感数据面临风险吗？
有可能。一次 AI 渗透测试可能会处理源代码、凭据、HTTP 流量、内部 URL、客户记录和可用的漏洞利用代码。团队应当核实：有什么会到达外部模型 API、编排平台记录了什么、谁可以访问那些记录、数据存储在哪里、保留多久，以及如何确认删除。
由 AI 生成的渗透测试报告能被审计方或客户接受吗？
没有普适的答案。一份由 AI 辅助的报告，只有在满足适用的审计标准或客户要求时才能被接受。请提前确认范围、方法论、测试人员资质、独立性、AI 披露、证据、人工审查和问责等方面的要求。AI 能完成技术工作，但它无法判定自己是否被接受。
在一次由 AI 驱动的渗透测试中，哪些应当保持在人工控制之下？
人应当控制范围、凭据、数据分级、禁止的操作，以及对破坏性或影响生产的测试的批准。他们还应当审查重要的发现、质询严重程度和业务影响、检查未经测试的区域，并决定什么进入最终报告。执行层应当强制执行这些决定，而不是仅仅依赖提示词中的指令。
AI 渗透测试真的能省钱吗？
有时能。当重复性工作的减少超过了平台使用、基础设施、重试、分级处理、人工验证和治理的成本时，节省才会出现。应在范围和质量对等的前提下，比较每个已验证结果的完整成本，其中包括在拒绝或重建没有支撑的发现上所花费的精力。