AI 编程代理已经不再只是个人效率实验，而是开始进入企业开发环境。Uber 开源 ADR 之所以值得关注，正因为它没有把 Claude Code、Cursor、OpenAI Codex CLI、Cline、Claude Desktop、Warp Terminal 或 opencode 当成带补全功能的普通编辑器。它把这些工具视为会读取提示、观察代码库、选择工具、调用 shell、修改文件、连接 MCP 服务器，并且可能接触类似凭证内容的系统。如果安全团队只看进程和文件事件，就很难看清这条链路。

跟踪 AI 编程代理行为的安全运营面板

Uber 开源了什么

这里的 ADR 指 Agentic Detection and Response，不是常见的架构决策记录。GitHub 仓库把它描述为面向企业 AI 代理的安全系统，并称其已在 Uber 部署。发布时该仓库采用 Apache-2.0 许可证，主要语言是 Python，约有 1,334 个 stars 和 112 个 forks，并在 2026 年 8 月 10 日更新。这些数字不是结论，但说明主题正处在活跃期。

ADR 不是一个神奇扫描器。它的框架包括 observability、benchmark、detection 和 prevention。当前开源部分包括 Sensor、ADR-Bench 和 Detector；prevention 层以及部分内部 explorer 工具没有随本次发布公开。这个边界很重要：团队可以把它当作参考架构学习，但不能把克隆仓库等同于生产级 SOC 控制。

被 MLSys 2026 Industry Track 接收的论文提供了更强背景。摘要提出三个长期问题：可观测性有限、鲁棒性不足、检测成本高。论文还称系统在 Uber 运行超过十个月，覆盖 7,200 多台 unique hosts，每天处理 10,000 多个 agent sessions。这是 Uber 报告的部署经验，并不自动适用于所有公司。

为什么 EDR 和 SIEM 看不够

传统 EDR 擅长回答系统层问题：哪个进程写了文件，哪个程序打开连接，哪个主机访问了可疑域名。这仍然必要。但 AI 代理在用户意图和系统事件之间增加了一层。一个 shell 命令本身可能正常，但如果它来自 issue、文档或 MCP 响应里的 prompt injection，风险就完全不同。

在 agentic development 中，更有用的问题是：用户要求了什么，模型读了哪些上下文，展示了什么计划或 reasoning，提出了哪些 tool calls，实际执行了哪些，适用什么 policy，最后产生什么结果。没有 session-level 因果链，SOC 只能看到症状，很难看到原因。

Sensor README 提到可解析 Claude Code、Cursor IDE、Cline、Claude Desktop、OpenAI Codex CLI、Warp Terminal 和 opencode 的日志，并区分 macOS、Linux、Windows 的差异。事件会被归一化为包含 session ID、timestamp、chat history、tools、model、project path、session context 等字段的 schema。这正是传统 EDR 缺少的语言。

工具和 MCP 是新的边界

代理真正的力量不在聊天框，而在工具边界。Coding agent 一旦能读取 repository、调用 git、运行 tests、访问内部文档、处理 ticket、使用 deployment helper 或连接 MCP server，就已经进入运营层面。每个 connector 都可能合理，但合在一起会形成难以审计的权限图。

ADR-Bench 把这张图当成检测对象。文档描述了大约三百个场景；Detection README 写到 303 个 scenarios，其中 261 个 benign、42 个 malicious，覆盖 17 种 attack techniques 和 133 个 MCP servers。精确数字不是重点，重点是测试形态：在接近真实工作的流程中，把恶意指令、合成凭证和有漏洞的服务放到代理面前。

Open Source Review 也明确提醒，benchmark 包含 synthetic attack material，并为了复现固定了带有已知 CVE 的依赖。因此它应该在 isolated environment 中运行，而不是放进 production。

企业应该改变什么

对 CTO、CISO 和平台团队来说，结论不是禁止代理，也不是直接安装某个项目。第一步是盘点：哪些 agent tools 被允许，日志在哪里，覆盖哪些操作系统，能访问哪些 repositories，哪些 actions 可以在没有持续人工审查的情况下执行。很多公司现在答不上来，因为采用是从开发者个人开始的。

第二步是 least privilege。代理不应默认继承开发者的所有 credentials、shell permissions 和 browser sessions。Credential gateways、短期 tokens、按 repository 限定的权限、独立开发凭证以及 MCP server 规则，都应成为基本要求。否则，高效工具就会变成披着人类外衣的 automation account。

第三步是 auditability。日志需要展示从 prompt 到 tool call 再到 outcome 的链路。但“全部记录”同样危险。Agent telemetry 可能包含代码片段、内部工单、客户数据和看起来像 secrets 的字符串。类似 ADR 的项目需要 retention limits、redaction、access control、encryption 和谨慎的 SIEM export。

安全团队的新检测面

可疑的代理会话不一定像 malware。它可能只是一台普通开发机、一个普通编辑器和合法 terminal。异常可能藏在工具顺序、prompt pattern、突然读取 credential locations、生成脚本访问异常网络，或者 MCP server 把文档查询变成对真实系统的动作。

规则必须结合上下文。Process telemetry 太浅，prompt scanning 太脆弱，只看模型输出也不能证明实际执行了什么。真正有用的单位是 session：输入、上下文、工具、文件和网络影响、policy decisions。成熟团队会要求检测能解释风险，而不只是匹配正则表达式。

供应商也会受到压力。IDE、cloud workspaces、terminals、agent frameworks 和 MCP platforms 都需要提供结构化、可导出的日志。如果每个工具都使用私有格式，企业采用和 incident response 都会变得更难。

市场信号

关于 Uber ADR 的直接 Hacker News 讨论并不大，但围绕 cloud coding agents、credential gateways 和 sandboxes 的相邻讨论更加活跃。大家关心的是同一个问题：代理在哪里运行，能看到哪些 secrets，workspace 是否隔离，automation 越界时谁负责。

ADR 不是孤立事件。它与 agent sandboxes、credential brokers、AI application runtime monitoring、developer workspace policy engines 一起，指向 managed agent infrastructure。就像云计算一样，使用往往先从团队自发开始，随后才补上 identity、logging、cost controls、policy 和 incident response。代理可能从开发者 terminal 起步，但风险属于企业。

实际行动可以从本季度开始：列出 approved tools 和 data paths，减少 ambient credentials，关联 editor、shell、MCP gateway、Git、pull requests 和 CI logs，然后在隔离 repository 中用 synthetic secrets 做测试。如果团队看不出代理读取了敏感文件、执行了敌意指令或修改了任务范围外的代码，第一批安全 backlog 就已经出现。

结论很简单：AI 编程代理既不是普通编辑器，也不是员工。它们是把 prompts 和 context 转化为 tool use 的 delegated systems。下一阶段的企业 AI 开发，取决于能否让代理工作变得 observable、bounded、reviewable 和 recoverable。