本文整理自 AICon 上海分享「以模治模——支付宝 Agent 安全漏洞智能化检测实践」（演讲者：盛锦辰，支付宝），通过AI音视频转录总结工具Ai好记进行转录整理，以下为精炼整理后的会议笔记内容。
一、Agent形态演进与安全威胁态势
盛锦辰首先从开发者和安全从业者的视角，梳理了2022年以来Agent形态的演进历程，并界定了当前Agent安全的核心关注领域——Harness层的安全防护。
这篇分享的核心议题就是：如何让AI安全检测从依赖人工规则，走向智能化、自动化的漏洞检测体系。
Agent形态的四阶段演进
- Chatbot阶段（2022年） —— 以ChatGPT为代表，核心能力就是对话交互，背后几乎无可调用服务，人与模型直接对话，安全面相对简单
- Workflow Agent阶段（2023年） —— ReAct范式、LangChain/LangGraph框架开始流行，开发者大量构建企业内部Workflow Agent，Autonomous Agent调用Tool成为主流范式
- Foundation Agent阶段（2024年） —— 头部模型厂商推出Foundation Agent，开发者的精力转向Tool orchestration和Workflow编排，Tool Chain范式出现，模型开始获得完整沙箱能力（filesystem、terminal、network）
- Self-evolving Agent阶段（2025年） —— 以OpenClaw、Hermes为代表，模型边界进一步扩大，Agent获得尽可能长的上下文环境，开始具备自我进化的能力
Harness：Agent安全的核心战场
盛锦辰特别强调了一个概念：Agent里面除了Model以外的部分，我们都把它称为Harness。
换句话说，模型安全对齐固然重要，但真正决定Agent安全底线的，往往是它周围的那套基础设施。
Harness分为三个层次：
- 运行时层 —— 沙箱环境，涉及容器配置安全、数据泄露等问题
- 框架层 —— Agent Framework作为传统代码开发的应用，存在各类应用安全问题
- 平台层 —— Agent以产品形态提供给用户，承载平台存在主对话入口以外的功能安全问题
三条真实攻击链案例
盛锦辰在现场分享了三个非常「疼」的真实案例，充分展示了Agent安全漏洞的严重性和红队测试的实战价值：
- 直接提示词注入 —— 攻击者使用Claude类型Agent，通过提示词注入绕过系统限制，直接窃取沙箱内的敏感通用凭证
- 间接提示词注入 —— 攻击者控制Agent访问的外部网页、RAG数据库或记忆存储介质，利用对话上下文中的敏感数据实施窃取
- Agent集群攻破 —— 某些环境提供高危API却未做好防护，通过提示词注入导致整个Agent系统、Agent集群被攻破
听到这里我就一个感受：Agent安全不是「模型安全」的简单延伸，而是一个全新的攻防维度。
二、Detection Agent核心架构与实现
在支付宝安全的实际攻防中，传统的安全检测工具面对Agent这种新型攻击面时力不从心。那该怎么办？盛锦辰团队的答案是：用Agent去检测Agent。
为什么非得用Agent？
盛锦辰给出了三个理由，每一个都直击要害：
- 架构多样性 —— 「企业内部的Agent发展非常快，每个Agent都在使用完全不一样的架构……很难用一个固定的、传统的确定性规则去对一个完整的Agent做检测」
- 攻击路径不可枚举 —— 「Agent的一些安全漏洞，攻击路径往往是不可枚举的——这也要求我们必须使用另一个Agent来对抗动态变化的环境」
- 语境依赖性 —— 「Agent相关的漏洞是否成立，在不同的Agent语境下也是不一样的……对于语义的理解，也是传统工具没有办法做到的」
核心编排架构：三Agent协同
整体架构是经典的Supervisor + Agent模式，包含了三个核心Agent：
- Evidence Modeling Agent —— 对目标Agent进行建模，了解它的组成部分
- Risk Analysis Agent —— 白盒/静态视角，对各组件进行安全检测
- Red Team Agent —— 黑盒/灰盒视角，实际探测验证攻击链路
三阶段Workflow也很清晰：
第一阶段：调度Modeling Agent对目标进行建模，输出Modeling Profile
第二阶段：并行调度Risk Analysis Agent，对Runtime、Framework、Platform各层进行检测，发现潜在攻击链路
第三阶段：Red Team Agent与Agent真实对话，验证完整攻击链路是否成立
各Agent的具体实现
Evidence Modeling Agent 主要收集目标Agent相关的代码、文档、配置文件，然后从运行时、框架、平台三个层次进行分析，输出整体架构梳理、各模块及对应检测实体、安全防御措施及所使用的企业内部安全组件。
Risk Analysis Agent 走的是四阶段代码分析流水线：
- 目录结构分析 —— 识别业务逻辑实现目录、安全防御模块、通用功能模块
- 轻量分析（Phase2） —— 初筛，找到潜在存在问题的点
- 深度挖掘（Phase3） —— 调用数据流分析工具，进行完整数据链路分析，判断攻击数据流是否可从入口流到目标函数
- 结构化结论 —— 包含检测目标及该目标下的安全攻击链路
各层面检测的规则也很有层次感：
- 运行时层重点关注沙箱隔离、容器安全、沙箱内服务密钥的可窃取性、代码执行沙箱隔离
- 框架层关注开源框架N-day漏洞、自研框架实现问题、模型可调用的API/Tool/Client具体实现
- 平台层关注平台特定功能安全问题
Red Team Agent 的定位很有意思：「我们希望它是一个真实的攻击者」。前面白盒分析提供的情报，到了红队手里就成了攻击的弹药。
红队Agent的完整Workflow：
- 接收Supervisor定义的待验证业务及安全假设
- 轻量级侦察 —— 挖掘白盒无法验证的问题（比如提示词注入防御是否真实有效）
- 深度探测 —— 基于响应驱动下一步策略，多轮迭代，必要时回溯上下文
- 反向假设验证 —— 列举期望达成的安全假设，让Agent进行深度验证，充分发挥Agent能力而非预定思维方式
- 闭环反馈 —— 将黑盒发现回馈白盒环节，针对性进一步分析
盛锦辰特别强调了一个关键机制：观察客观信号来判定攻击成功，而不是依赖模型自我报告。输出包含漏洞Root Cause、攻击链、动态证据及修复建议。
工程可靠性保障：Agent切面投影
Agent大模型存在幻觉，这是绕不开的问题。盛锦辰团队设计了一套「Agent切面投影」机制——在Detection Agent构建之外构建一个平行层，Hook每个Agent执行节点。
三阶段标签与核验：
- Plan阶段 —— 核验整体规划是否满足预设要求，是否清晰、没有偷懒
- ExecuteLoop阶段 —— 核验每个执行节点是否发生错误；动态修改执行路径回到良性状态；或仅记录观察，不影响正向执行
- Conclusion阶段 —— 核验关键错误是否已解决，决定Agent进程结果
这套机制最终落地为DeterministicControl系统，融入研发流水线，实现可控的Agent执行。
三、Detection Agent的运行时进化与反馈回路
Agent跑起来了，但跑得对不对？盛锦辰坦言，Runtime阶段面临四大问题：
- 人为设计缺陷 —— Agent Workflow由人设计，存在缺陷和盲点，导致漏报和误报
- 模型幻觉 —— 提示词看起来正确，但模型不会按期望方向执行
- 场景理解偏差 —— Agent运行在知识有限的沙箱环境，不理解场景为何如此、企业业务如何定义，产生误报
- 专家瓶颈 —— 专家本身也存在能力边界
盛锦辰的期望是：「基于Agent运行时和运行后的观察，或来自安全运营人员的反馈，形成一个循环来分析与目标的误差，进行学习，并在下一次运行中成为前馈，从而让我们的Agent越运行，整体的准确率越高」。
三层反馈回路设计
第一层：单次运行流水线内的Loop
Red Team Agent发现白盒建模和风险分析阶段的盲点，回溯扩展；白盒发现深入点后由Red Team验证。
第二层：研发流水线完成后的记忆模块
观察误差，让Agent分析问题根源（规则问题、代码Bug、上下文不足等）。这里有一个关键设计：Runtime不直接修改Agent框架或代码（避免错误无法收敛），而是构建记忆模块记录问题。下次遇到相似场景进行记忆回溯，在运行态解决问题。
效果是批量避免重复性、可笑的错误，极大提升运营人员的操作体验。
第三层：运行态到研发态的Loop
最终回到研发态，形成完整闭环。专家参与把控演进方向，Agent仅提供分析能力。
三层记忆架构
- 工作记忆 —— Agent本身的文本，存储在内存或文件系统，运行时加载
- 过程记忆 —— 一次研发流水线的上下文，从沙箱文件系统持久化到OSS，属于该研发流水线时加载
- 长期记忆 —— 真正需要沉淀固化的内容，从沙箱文件系统持久化到OSS，所有运行时都加载
专家角色的三重转化
盛锦辰特别强调，在这个体系里，专家的角色也在发生转变：
- 设计者 —— 设计Agent闭环流程
- 观察者 —— 观察Runtime问题，判断优先级，定义真正需要解决的问题
- 演进把握者 —— 定义评测集，关注高优先级指标，验证Agent效果
核心价值在于「定义出在研发中真正需要去解决的问题」以及「定义出如何去验证它」。我觉得这个思路对于任何做AI自动化落地的团队都很有启发——不是让AI取代人，而是让人在更高维度上发挥作用。
四、评测体系与当前效果
「只要你涉及到更多的自动化、更多的流水线、更少的人工参与，那么评测集就是保证你的Agent能否向期望的预期去演进的一把重要尺子。」盛锦辰这句话说得很实在。
评测集构建
评测集的主要来源有两个：
- 运行时发现的误报和漏报（最主要来源）
- 专家基于理解和设计补足的低频场景
还有一个有意思的设计：Red Team Agent与Risk Analysis Agent相互对抗，通过对抗来提升评测集的质量。
盛锦辰特别强调了一个要求：「能够迭代、能够管理的评测集」。
度量体系与准入门禁
阶段化关注指标：
- 第一阶段 —— 优先关注分析精度（Precision），决定能否在安全研发流水线落地。如果误报太多，再好的工具也没法用
- 后续阶段 —— 关注召回率（Recall），Agent不怕累、不怕误报，更关注发现能力
设计要素包括：上线准入门禁、核心指标、演进方向控制。
当前效果数据
盛锦辰分享了Detection Agent在实际生产中的表现：
- 整体分析进度 —— 54%左右
- 自主发现率 —— 约70%的Agent安全漏洞
- 检测规模 —— 1010多个内部Agent（对内 + 对外）
- 发现风险 —— 上百个Agent安全风险
这些数据表明，该Detection Agent系统已具备相当的规模和检测能力。覆盖超过1000个内部Agent并自主发现七成以上的安全漏洞，体现了其从建模、分析、验证到闭环反馈的体系化工程能力。
