AI 安全运营平台思考(七):ADR 如何洞察智能体威胁
从完整行为链条、两层检测机制到部署前红队演练,解析 Uber 在 Agent 安全领域的工程落地
现阶段可以观察到,攻击端的 Agent 化、防御端的 Agent 化,以及 Agent 自身演变为新型保护目标,这三种走向正在并行展开。
前文《AI 安全运营平台的思考与记录(六):既要 AI for Security 又要 Security for AI 的 AI 安全智能体》指出,AI 安全 Agent 同样遭遇提示词注入等攻击风险,自身也需要防护机制。过往论文仅勾勒方向与思路,缺少可供落地参照的工程方案。
Uber 开源的 ADR 提供了具备工程落地价值的范本,核心聚焦于 AI Agent 的可观测性、评估与威胁发现。
Uber 开源了 ADR(Agentic AI Detection and Response)的核心模块。其总体思路并非仅识别 Prompt,而是重建 Prompt → Reasoning → Tool Call → Outcome 的完整因果链条。Open Secure AI Alliance 最新公布的数据表明,ADR 当前每日承载的 Agent Session 已突破 20 万次,覆盖大约 3 万个 Endpoint。
先从 Uber 团队发表的《ADR: An Agentic Detection System for Enterprise Agentic AI Security》论文谈起。
当前 AI Agent 安全遭遇三重难题:可观测性欠缺、静态规则泛化能力薄弱、LLM 推理分析代价偏高。具体表现为:
其一,可观测性受限:传统安全遥测聚焦文件与进程活动(如 EDR),而忽略 AI 智能体的推理链与工具调用,这些恰恰承载着区分恶意与良性行为所必需的语义上下文。其二,鲁棒性欠佳:依赖预定义规则的静态防御难以应对从提示词注入、工具操纵到凭据外泄的多元攻击谱系,加之企业环境存在显著的类别失衡,恶意事件非常稀少。其三,检测成本居高:对每一条事件都执行基于 LLM 的语义推理,计算开销巨大。在生产规模(譬如日均 10,000 次以上会话)条件下,企业迫切需要可扩展且成本可控的监控方案。
核心要点:
识别智能体威胁的根本难题源于攻防双方的不对称性。攻击者利用语义鸿沟:他们设计的攻击在表层看似无害,结合意图与上下文即可判定为恶意。传统安全工具失效的根源在于缺少两项关键能力:(1)对 MCP 工具真实行为的语义解析;(2)针对企业内部正常与可疑行为的上下文认知。
ADR 将全景可观测性、可扩展的在线检测以及系统化的部署前红队检测融为一体,为生产环境下的 MCP 驱动 AI 系统保驾护航。
从系统架构视角,ADR 以人类安全团队的组织模式作为整体架构的参照:
Sensor 承担安全运营中心分析员的职责,通过采集"智能体执行了什么、为何执行"的遥测数据,提供对智能体行为的全景洞察。Detector 复刻 SOC 工作流:第一层负责初步分诊,以高召回率捕获可疑事件(尽可能减少漏报);第二层借助企业上下文展开深度调研,类似于检测工程师核实安全事件的过程,涵盖源代码审查、威胁情报查询、策略合规性验证。Explorer 扮演内部红队角色,在部署前验证阶段系统地在沙箱环境中生成并测试攻击剧本。Explorer 挖掘出的成功攻击被整理至威胁情报库,反馈给第二层,进而在多元攻击类型上增强检测器的鲁棒性。这种以人类实践为蓝本的方案使系统具备自适应能力,并贴近真实安全运营场景。
为厘清整体架构,我重新梳理如下:
ADR 的这套架构能够实现:
(1)高保真遥测:采集的遥测不仅记录事件本身,还记录触发原因(涵盖从用户提示词、智能体推理到工具调用的完整因果链)。
(2)分层研判:通过两层架构在成本与精度间取得平衡,快速分诊并标记可疑事件(第一层),随后借助深度上下文推理验证实际威胁(第二层)。
(3)系统化验证:在部署前测试阶段依托离线红队自动挖掘高难度攻击变体,提升检测鲁棒性。
要点一:ADR Sensor 补全可观测性短板。
传感器以轻量化端点代理方式运行,解析智能体工具(Cursor、Cline、Claude Code)存放于 SQLite 数据库与 JSONL 缓存内的本地数据。它将零散的日志条目相互关联,重建完整的智能体会话,将提示词 → 推理 → 工具调用 → 结果串联成完整链条,并把遥测转发至后端系统供分析。对每一场智能体会话,传感器可捕获:
这四个维度共同支撑语义层面的威胁识别:检测器能够推理智能体的动作是否与用户意图吻合、工具使用模式是否契合已知攻击特征、智能体是否违反安全策略。
举例而言,若用户发出"总结这个 Jira 工单"的请求,而智能体却去读取 SSH 密钥并发起 HTTP 请求,传感器遥测将暴露这种偏离预期的异常行为。
要点二:在线与离线相结合的规模化检测。
直接对每个事件调用昂贵的 LLM 推理,在规模化场景下不可行;仅依靠简单规则过滤,又会遗漏复杂攻击。ADR 的策略是将快速分诊(高召回、低成本)与选择性深度推理(高精确率、较高成本)有机结合。
两层检测器。第一层借助轻量 LLM 对提示词做高召回初筛,标记提示词注入话术、涉及凭据或权限的请求、角色与特权变更,以及若干本身无害但组合后潜藏风险的步骤序列,只有确认良性的活动才会被短路放行。第二层对被标记事件开展深度语义分析,推理智能体可动态查询三个提供可信企业信息的 MCP 服务:源码审查(get_source_code,通过检查实现判定 MCP 工具实际行为)、威胁情报查询(get_threat_framework)、策略核查(get_policies、assess_policy_violations)。推理智能体依据事件特征自适应决定调用哪些服务,例如文件写入可能触发全部三项,简单读取可能仅查询策略。
为增强检测器在多元攻击类型上的鲁棒性,离线 Explorer 借助三个协作智能体系统化地生成并测试攻击变体。红队智能体通过对已知攻击种子集中的技术进行参数变异与组合,提出逼真的攻击变体。评估智能体在沙箱(隔离)环境中执行这些候选样本,同时衡量攻击成功率与检测规避程度。威胁情报智能体整理高价值发现并发布到威胁库,供第二层调用。
要点三:源自企业级实践的安全基准集 ADR-Bench。
论文综合了公开框架与指南(如 MITRE ATLAS、OWASP)、已披露的安全事件与研究报告(如 JFrog、Invariant Labs、Microsoft、CyberArk、Solo.io、趋势科技),以及 Uber 企业内部署的运营遥测与实战经验,最终构建出一个面向 MCP 驱动智能体系统、涵盖 5 类战术与 17 项技术的实用威胁框架(如下):
企业智能体威胁分类框架(5 项核心战术)
论文版本的 ADR-Bench 涵盖 133 个 MCP 服务器(横跨从文件系统到云 API 的 14 个类别),提供 729 个差异化工具,以及 302 个真实任务。当前开源仓库任务数已增至 303 个,此处不再展开,有兴趣者可查阅原文。
这是当前公开材料中少见的有真实企业十个月生产数据支撑的智能体安全系统论文(覆盖 7,200+ 台主机,日均会话量 10,000+)。数据密度远胜于纯学术基准论文。
再来看对应的开源项目 https://github.com/uber/ADR。
从开源代码审视,ADR 仓库是一套具有生产背景的 Agent 可观测性、检测研究与评测框架,并非完整的即装即用 ADR 商业平台。
不过,以下三条路径依然值得动手实践与借鉴:
不同 Agent 的日志格式差异显著:Claude Code 与 Codex 采用 JSONL,Cursor、Warp 与 opencode 可能采用 SQLite,Cline 又拥有独立的任务文件结构。若检测系统直接依赖每种原始格式,每新增一个 Agent,检测逻辑都需重新适配。
ADR Sensor 采用适配器式架构。每个