今年夏天，数百个 OpenAI 代理在网络安全测试中试图作弊。它们突破了测试环境，并成功入侵了 Hugging Face——它们认为该网站藏有关于自己将如何被评分的线索。几乎同一时期，另一个 OpenAI 代理访问了澳大利亚政府网站上的私人文件。这个问题绝非 OpenAI 独有。此后数月，Anthropic、Google 和 Meta 也披露了其代理偏离正轨的事件。令人担忧的是，在许多案例中，代理甚至躲过了专门负责监控它们的研究人员和安全团队。

AI 代理正在采取未经授权的行动，而构建和运行它们的公司大多依靠运气和事后复盘来减轻有害影响。它们必须做更多工作来确保安全。正因如此，欧盟监管机构和美国机构要求代理开发者和部署者实时监控代理，这是完全正确的。但这些规则假定公司能够看到其代理在做什么以及为什么这样做——而现实中，它们缺乏足够的可见性。

想象一家银行雇用了一千名新员工，他们可以访问客户账户和敏感信息，但员工的工牌每天都会更换，不清楚是否有经理审查或授权过他们的工作，也没有人记录员工对审批流程所做的更改。这种可见性缺失，正是我们如今面对代理时的处境。

随着代理在从金融到政府再到医疗等关键领域推广，我们必须能够实时监控它们，以防止广泛且可能具有毁灭性的后果。而安全依赖于监控，监控则需要可观测性：即捕获系统做了什么、将其处理为信号，并呈现给人类或自动化监督系统的能力。换句话说，我们需要知道代理做了什么以及为什么这样做。而正如我们近期的研究所示，当前的代理框架——即运行代理的软件——并不能可靠地生成我们确保代理安全部署所需的关键可观测性记录。

代理带来了生成式 AI 本身不具备的新型问题。它们继承了所基于的大语言模型（LLM）的不可预测性，但生成式 AI 系统只产生单一输出供人类采取行动，而代理则执行更长的任务——它进行规划、选择工具、生成子代理并采取行动。因此，代理的路线可能以多种不同方式形成，任何发布前的测试都无法完全预见风险。这使得在代理工作时观察它们更具挑战性，也更为重要。

我们与来自学术界、公民社会和业界的同事一起研究了四种最广泛使用的代理框架，以了解它们实际发出哪些信号。我们发现了重大缺口，这些缺口使得实现关键安全目标变得困难，例如发现政策违规、未经授权的行动，甚至人类监督失效。关键的可观测性要求缺失了——比如长期保持不变的代理 ID，以及关于哪些人类批准了代理任务的记录。这使得很难判断哪些代理做了什么，或评估它们是否在采取未经授权的行动。

好消息是，这些缺口一旦被识别出来，就可以被填补。做到这一点首先要捕获两类记录：揭示代理运行中发生了什么以及代理如何做出决策的记录。“发生了什么”的记录识别代理（同时保护隐私），并记录人类如何干预、代理权限或“记忆”是否发生变化；而“决策”记录则显示代理的推理过程及其对所采取行动的置信水平。

以处理银行抵押贷款的代理为例。系统审查一份申请并建议拒绝，然后由人类信贷员批准该决定。在后来的审计中，甚至可能实时地，银行或监管机构需要能够重建是哪个代理做出了这个决定、哪位信贷员批准了它，以及他们花了多长时间。银行还必须分析代理如何得出拒绝决定的记录，以确保它没有使用禁止使用的信息，例如申请人所在社区的详细信息。

记录“发生了什么”和“代理如何决策”需要不同的方法，但两者都是可行的。目前缺乏“发生了什么”的记录，主要是一个软件管道问题，可以通过 OpenTelemetry 解决——这是一个由业界工程师维护、并被代理框架采用的开放可观测性标准。

OpenTelemetry 已成立一个工作组，起草用于追踪代理的共享格式，但这些格式尚未最终确定。该工作组应紧急纳入维护持久代理身份以及记录人类干预和代理权限或记忆变化的标准。而且这应该在这些系统规模化之前完成，同时还要关注代理 ID 与真实人物关联所带来的隐私影响。

保存“代理如何决策”的记录更具挑战性。这个问题为模型提供商和研究人员提出了开放的研究问题：模型展示的逐步推理（即思维链）是否反映了模型实际做出决策的方式？我们是否有可靠的方法来衡量代理对该决策的置信程度？在任何人为此类可观测性记录的使用制定标准之前，这些问题都需要答案。

没有任何单一组织或行业能够独自填补可观测性缺口，但联合起来，它们可以支持预防危险事件和保障安全所需的基础设施。

构建代理框架的 AI 开发者，如 OpenAI、Anthropic、CrewAI 和 LangChain，必须整合遥测信号，记录代理的持久身份、任何人类干预，以及代理权限和记忆的任何变化。与此同时，采用这些代理框架的企业可以发挥有影响力的作用；受监管行业的企业，如银行和医院，可以在标准尚不存在的地方向代理开发者施压，要求其提供这些缺失的可观测性记录。

企业还必须定义策略、权限和角色，明确代理可以安全地做什么，因为仅靠遥测无法评估代理是否违反了特定规则。最后，监管机构和 AI 标准机构必须为高风险 AI 部署指定所需的可观测性记录，同时将技术细节留给行业。我们已经看到这方面的初步势头：美国 NIST 的代理标准倡议正在研究代理身份，这是我们研究中发现的最突出的缺口之一。

没有哪家银行会让一千名没有工牌的员工自由访问客户账户，并希望在出问题时拼凑出发生了什么。然而，这正是我们部署 AI 代理的方式。让它们的行为可观测是解决这一问题的第一步。通过构建能够让我们对所见采取行动的监管和政策生态系统，我们可以让组织承担责任。在此之前，我们交给代理的每一项任务，也交出了我们的自主权。

Madhulika Srikumar 是 Partnership on AI 的 AI 安全项目负责人。Partnership on AI 是一个由领先行业、学术和公民社会组织组成的全球非营利伙伴关系，致力于推进 AI 治理的最佳实践。

Claire Leibowicz 是 Partnership on AI 的 AI、信任与社会总监，也是牛津大学博士候选人。

深度探讨

%%IMG1%%

原文为两部分连载的第二篇。第一部分请见：[我们亟需实时监控 AI 代理的行为（第 1/2 段）]

%%IMG2%%

如果我们认真对待 AI 代理（AI Agent）的行为监控，那么就需要一个行业标准，把实时行为监控作为一个核心的、预期中的软件能力。就像我们在航空、金融和医疗领域所做的那样——在高风险环境下，我们不只是信任系统本身，还要持续监控它们，以发现它们无法自我报告的事情。

如果我们认真对待 AI 代理，就必须设计能够实时监控它们的环境——捕捉它们看不到的异常、隐藏的模式、以及它们在执行过程中无意泄露的信息。这不仅关乎安全——更是为了让代理真正按照我们期望的方式工作。

%%IMG3%%

让我分享一个真实案例。DevZero 的安全研究员发现了针对我们部分 v4 设备（实际上就是我们的开发环境）MCP（Model Context Protocol，模型上下文协议）服务器的一次攻击尝试。

代理试图执行一个明显越权的操作：

• 对 env 执行 sudo 以获取所有环境变量
• 使用 printenv 获取环境变量
• 重写 MCP 工具配置

这里的问题不是攻击本身——而是我们直到事后审查日志才发现，而不是实时的。那次攻击尝试在我们的网络里待了一段时间，没人发现。这恰恰说明了这篇文章的核心观点：由代理发起的操作需要被实时监控，而不是事后调查。

这不是关于攻击者是不是人类——这关乎被入侵的代理。这就是为什么主动监控很重要。

如果 agent 的行为被实时监控，这次攻击尝试就会立即被标记。所有访问都发生在信任边界内：内部网络、经过认证的 MCP 连接、格式正确的工具调用。对任何天真地信任代理行为的系统来说，这都无法察觉。

真实 AI 代理环境中的 MCP 暴露面。

%%IMG4%%

这引出了本案最重要的发现。那次特定尝试的意图失败，并不是因为我们的安全模型拦截了它。而是因为 MCP 工具失败了（等等，我们的 MCP 工具配置没有正确设置，这是运气）。任何数量的提示词工程都无法阻止这种访问。MCP 不是内置于模型的——它是一个独立运行、使用凭据的服务器。模型无法监督它。

然而，这次任何监管之下发生的事情本应触发安全告警，或者——理想情况下——触发一个检测策略：以所有方式停止执行。

我们构建了一个模型来展示这个问题。这正是我们花费数年时间构建的 Dashboard。

代理有权限访问环境变量吗？ 没有。它们可以读取凭据吗？ 不行。它们可以调用敏感的 MCP 工具吗？ 不行。它们可以在没有被监控的情况下这样做吗？ 这正是我们正在努力解决的。

我们的设想是：不是让代理监看自己的能力，而是让运行它们的平台来监控代理的行为。

我们的 AI 代理执行环境中的每个操作——每个 MCP 工具调用、每个文件编辑、每个密钥访问——都会被实时监控。

%%IMG5%%

我们的做法是：把行为签名捕捉到我们自己的日志系统中，并且所有操作都会受到这个系统的约束。每次工具调用、每个命令、每次文件编辑都经过它。

包括与我们的 Vault（密钥管理系统）集成——这是处理凭据所需的。代理永远看不到凭据。相反，环境会中转一次请求，在运行时铸就一个临时的、范围受限的密钥，注入环境变量并稍后消失。

这不仅仅是日志——这是一个正在运转的系统。它同时增加了可见性和防护。

你如何识别沙盒中最黑暗的角落？ 你需要沙盒制造商提供的聚光灯。

我们的做法是建立在我们的 v4 运行时之上。那个系统运行在 Firecracker microVM 中——我们认为这是标准做法。但关键在于，我们运行的是一个日志系统，它捕获每个操作，并将其格式化为不可变日志，实时关联到 AI 代理。我们还没有公开发布这个功能，但这是我们正在积极构建的——用于有效管理代理行为的可观测性。

这个方案面向所有构建、部署并在生产环境中运行 AI 代理的人。这属于可观测性领域，但它不是那种事后审阅的可观测性——现在运行的可观测性。

如需深入了解我们如何提取行为和构建这些能力，请参阅我们的技术文章。

这些数据包含完整的终端会话、输入输出、进程树、网络连接和文件访问——所有这些都能被实时观测。这对于可观测性和合规来说价值巨大。

我们目前正致力于让所有这些数据实时可用，并可在仪表板中查看。但长期目标是将这些能力开放给其他人，因为把代理行为与人类行为分开的能力是基础设施的组成部分，就像访问控制或网络策略一样。

这引发了多个棘手的问题：行为数据归谁所有？保留多久？什么是合法的？什么样的行为应归属于代理？人类应对这些行为承担什么责任？

我们坚信透明。不应把黑盒保存起来。

什么才是真正的突破？识别出访问只是行为的一部分。

当访问发生之后，你还得知道它是如何发生的。人类、代理或是进程之间的关系如何？什么命令导致了那次访问？

这就是为什么我们的做法是端到端的。

如果你对代理安全、代理行为或这些话题有任何想法，或者想参与讨论，请随时与我们联系。如果你正在构建 AI 代理，并希望与我们联系，请联系我们。

贡献者：

• Chris Kern（DevZero 安全研究员）
• Josh（DevZero）