AI渗透测试Agent平台建设实践

导读

在 AI 时代，业务交付速度和系统复杂度持续提升，传统依赖人工、周期较长的渗透测试方式越来越难以覆盖快速变化的业务风险，因此，渗透测试智能体正在成为企业 SDL 建设中不可或缺的安全能力。我们的建设思路是构建以大模型为核心的 Harness 工程，将模型能力与安全扫描、多并发调度、资产管理、Token 管理、安全门禁和结果运营等平台能力结合起来，形成面向企业 SDL 的渗透测试 Agent 平台，为安全测试提供统一、可持续运行的基础设施。目前围绕 AI Native SDL 流程，该能力已在测试阶段和线上运营阶段投入常规实际应用，用于新业务和功能上线前的安全验证，以及上线后的持续扫描、风险发现。

01

背景

随着 AI 能力快速发展，业务创新和产品交付速度也在持续提升。新的应用、接口、服务和业务流程不断上线，安全团队需要覆盖的测试对象越来越多。在这种情况下，传统依赖人工推进的渗透测试模式，很难持续覆盖快速变化的业务需求。

而大模型具备较强的自然语言理解、长上下文组织、任务规划、工具调用和结果总结能力。基于这些能力构建的渗透测试 Agent，可以围绕授权目标组织资产发现、风险判断和验证执行，快速、高效地完成目标测试；在测试范围和证据充分的前提下，既能够发现常规安全漏洞，也能够结合业务流程、权限关系和功能设计识别业务逻辑漏洞，并形成结构化、可复核的测试结论。

02

问题与挑战

2.1 如何让 Agent 的测试效果对标甚至超越人类工程师

渗透测试 Agent 的核心能力，不只是能够调用工具或生成测试报告，更重要的是测试效果能否对标甚至超越经验丰富的人类安全工程师。评价测试效果，至少需要同时关注基础漏洞覆盖度和业务逻辑漏洞覆盖度两个方面。

基础漏洞覆盖度关注常规安全风险的识别和验证，包括认证与授权、注入、跨站脚本、服务端请求伪造、路径穿越、敏感信息泄露、错误配置和组件风险等。Agent 需要具备足够的资产发现和测试执行能力，在有限时间内覆盖更多页面、接口、功能和服务，减少因测试范围不足造成的遗漏。

业务逻辑漏洞的发现难度更高，通常依赖对业务流程、权限模型、服务关系和实际功能特性的综合理解，主要包括：

常见的越权漏洞，例如水平越权、垂直越权和多角色之间的权限边界问题

低风险漏洞组合利用后形成高风险危害，例如多个看似独立的权限、信息泄露或配置问题被串联利用

服务上下游之间由于请求解析、参数处理或安全策略不一致产生的差异

由于业务特性差异形成的长链路、多步骤复合利用漏洞，需要跨页面、跨接口或跨服务组织完整的攻击路径

因此，平台不仅要提升常规漏洞的自动化覆盖率，还要让 Agent 能够持续积累服务画像、理解业务上下文、关联多个事实和验证结果，并据此发现需要人工经验才能识别的复杂风险。

2.2 如何控制 Agent 扫描的安全边界

企业内部业务的稳定性非常重要，尤其是内网生产服务往往缺少面向安全测试设计的健壮性。部分接口可能直接执行数据写入、修改或删除操作，异常参数、重复请求、较高并发或不符合预期的业务流程，都可能造成数据删除、数据修改、服务异常等安全事件。

因此，Agent 不能仅以“发现漏洞”为目标，还必须明确测试对象、测试环境、访问范围、请求频率、工具能力和允许执行的动作。对于内网生产服务，需要区分低影响的观察和验证行为与可能改变业务状态的操作，默认采用最小必要、可回滚、可审计的测试方式，并在必要时转入人工确认。

安全边界也不能只依赖提示词中的自然语言要求。平台需要将测试约束落实到规则审批、工具调用控制和网络访问策略等工程机制中，并保留完整的执行记录和停止能力。只有在不影响业务稳定性的前提下，Agent 才能真正应用于企业 SDL 的测试和线上运营流程。

03

系统设计

平台采用“资产与上下文输入—任务执行—漏洞与安全运营”的横向能力分区，并以安全治理和 Docker 运行底座提供纵向支撑。各分区通过结构化上下文、任务状态和验证证据协作，形成从测试准备、智能执行到结果运营的闭环。

1

资产与上下文输入

平台接收用户授权的目标范围和项目配置，汇聚资产管理、传统 DAST、历史知识与服务画像等上下文。资产管理和 DAST 提供域名、IP、端口、页面及接口等基础线索，历史知识与服务画像补充认证方式、技术栈、关联服务和可复用的测试经验，帮助任务在有限上下文内保持覆盖广度。

2

任务执行

总 Dispatch 负责任务编排与调度，每个执行任务运行在独立的 Worker 容器中。推理 Agent 结合共享黑板和双图上下文决定下一步方向，按需调用资产发现、代码审计和渗透测试等执行 Agent；Observer 根据执行结果维护任务图并纠偏。标准能力 Skill 为认证、浏览器、资产检索和证据记录等能力提供一致接口，任务末尾再由知识总结沉淀服务画像与有效攻击链路。

3

漏洞与安全运营

执行结果经过证据整理和结论判断后进入漏洞管理，支持漏洞证明、审计和后续漏洞回验；同时输出覆盖情况、任务日志和安全运营信息，便于人工复核、修复跟踪和 SDL 流程衔接。

4

安全治理与运行底座

所有任务受到提示词安全边界、规则审批和网络策略约束；网络治理同时覆盖任务容器的定制化出站控制与宿主机全局禁扫策略。Docker 底座承载平台服务、共享数据库、总 Dispatch 以及相互隔离的任务 Worker，使不同任务拥有独立运行环境和治理策略。

▲系统架构图

▲ 平台示意图

04

核心设计

4.1 双图驱动：同时管理全局知识和局部任务

AI 渗透测试既需要跨任务积累的长期认知，也需要保留当前任务中的完整现场。平台以共享黑板为协作中枢，将全局黑板与局部黑板组合为双图驱动机制：全局黑板提供稳定、可复用的项目上下文，局部黑板维护本次任务的动态状态和执行细节。

1

全局黑板

全局黑板由总 Dispatch 统一管理和维护，面向项目及资产范围保存已经确认、适合跨任务复用的信息，包括资产关系、服务画像、页面与接口、认证方式、权限线索、漏洞证据和可复用的攻击链路。全局黑板的更新遵循严格的结构化契约校验，只有满足数据结构、状态、证据和授权边界要求的内容才能写入，避免未经验证的推测污染长期上下文。

2

局部黑板

局部黑板属于单个任务，由任务内的 Observer 持续维护。它保存本次测试所需的接口细节、请求参数和响应、已覆盖与未覆盖的接口、采用的测试方式、观察结果、任务状态和漏洞证明。局部黑板随着执行反馈不断更新，在发现任务偏离、重复探索、覆盖缺口或依赖不可用时，及时调整任务状态并触发纠偏。

3

渐进式披露

全局黑板不追求保存所有原始材料，而是只沉淀经过确认的摘要和关系；接口详细参数、原始请求响应、页面快照、覆盖明细等完整材料按任务隔离保存在对应的 Session 目录中。后续任务根据当前目标和推理需要按需获取细节，避免一次性加载全部历史内容造成上下文膨胀，同时保留对原始证据的追溯能力。

两类黑板通过共享黑板和 Agent 交互契约协同工作：全局黑板向任务提供相关背景，局部黑板反馈本次任务的新事实和证据；任务结果经过契约校验和必要的审核后回写全局黑板。由此形成“全局知识复用—局部任务执行—观察反馈—确认后沉淀”的闭环，但两类黑板在数据范围和生命周期上保持清晰边界。

下图展示全局黑板、双图协同层、局部黑板以及任务 Session 目录之间的设计关系：

4.2 三层安全围栏：提示词、智能审批和网络策略

AI 渗透测试的安全边界不能只依赖模型的自然语言理解，需要将约束、判断和强制执行分别落到不同的工程层。平台采用三层安全围栏：第一层通过提示词定义环境和行为边界，第二层通过规则、模型和人工完成分级审批，第三层通过容器与宿主机网络策略形成不可绕过的访问控制。

1

第一层是提示词安全边界

平台根据运行环境采用不同的约束提示词。生产环境以业务稳定性和数据安全为优先，严格禁止删除、修改用户数据或执行可能破坏业务状态的动作，并要求优先选择低影响、可回滚、可审计的验证方式；测试环境可以在明确授权范围内验证数据操作，但仍必须严格限制测试目标，避免扫描或访问其他内网资产。提示词层负责让 Agent 理解当前环境“可以做什么、不能做什么以及何时停止”。

2

第二层是智能审批

对常见的无危害命令和标准工具调用，优先通过确定性规则判断，减少不必要的审批开销；对规则无法覆盖或上下文不足的调用，交由模型结合任务目标、环境、参数和潜在影响进行智能审批。模型判断为低风险的动作可以继续执行，判断可能造成危害或影响不明确的动作必须升级到人工审批，由人工确认是否允许执行，并记录审批理由和责任链路。

3

第三层是网络策略

网络策略分为任务容器内策略和宿主机全局策略。容器内根据当前项目、环境和授权范围生成定制化黑白名单，限制任务可访问的域名、IP、端口和协议；宿主机维护公司级的全局禁扫策略，例如禁止访问的域名、IP 和基础设施保护列表，作为所有任务的最终兜底。即使上层提示词或审批判断出现偏差，网络层仍能对禁止访问形成强制阻断。

三层围栏分别承担引导、判断和强制执行职责：提示词约束模型行为，智能审批控制工具调用，网络策略限制实际可达范围。所有放行、拦截、升级和人工确认结果都纳入审计，形成可追溯的安全治理闭环。

下图展示三层安全围栏的分层控制关系：

4.3 标准流程 Skill 化：按需调用与统一契约

当前设计为“模型负责安全能力、Skill 负责企业流程”，平台在保持模型通用能力的同时，降低企业流程接入成本，并让每次 Skill 调用具备明确的权限边界、可观测性和可审计性。目前主要实现了下面的 skill，后续可以持续进行迭代：

NOTE · 说明

*漏洞原理、风险判断等属于模型应具备的通用安全能力，不作为 skill 引入模型

SSO 标准化 Skill：将企业内 ToC、ToB、ToE 等 SSO 登录流程进行统一封装，由平台在授权范围内使用对应测试账号完成登录并获取登录态，为需要认证的接口测试提供稳定的前置条件，减少 Cookie 有效期、退出登录和重复登录流程对测试覆盖的影响。

服务资产拉取 Skill：与企业资产平台对接，根据当前目标拉取关联的域名、主机、代码库、服务和上下游关系，为任务补充服务边界、资产归属和潜在测试入口，帮助 Agent 建立更完整的目标上下文。

服务画像 Skill：读取历史测试沉淀的服务画像、攻击面和有效攻击链路，为当前任务提供相似服务的已知特征和可复用经验；任务完成后，知识总结任务再将本次确认的服务特征和攻击链路整理回全局知识图。

证据复测与漏洞回验 Skill：可进一步将漏洞证据留存、回验请求构造、修复状态判断和结果归档封装为标准流程，统一处理复测所需的上下文恢复和结果输出。该 Skill 负责流程编排，不替代模型对漏洞原理和验证结果的判断。

05

测试结果与后续规划

目前，渗透测试 Agent 已融入 AI Native SDL 流程，阶段性完成约 1000 次扫描，发现了一批经验证有效的安全漏洞，其中包括一些人工难以发现的高危/严重风险。从测试结果看，Agent 能够较完整地覆盖基础漏洞，并对越权风险进行逐接口验证，在系统化覆盖方面表现出较好的效果。提示词约束、智能审批和网络策略组成的安全围栏运行稳定，当前未发生因 Agent 误操作导致的数据删除、修改等安全事件。

1000次阶段性扫描

0起误操作安全事件

3层安全围栏

目前平台尚未引入验证码识别能力，弱密码检测仍有不足；CVE 检测能力也尚未完善，对 0-day、1-day 类风险暂不具备系统化检测能力；多个任务产生的漏洞还可能重复，漏洞运营与 SOC 平台尚未完全打通。

后续将引入图像识别模型和传统 DAST POC 库，补充登录验证与已知漏洞检测能力，并建设漏洞去重、复测、统一运营和自动提单能力，逐步形成完整的漏洞运营闭环。

声明：本文来自度小满安全应急响应中心，版权归作者所有。文章内容仅代表作者独立观点，不代表安全内参立场，转载目的在于传递更多信息。如有侵权，请联系 anquanneican@163.com。