智能体安全新突破：ArbiterOS运行时治理系统将高危拦截率从6%提升至93%

随着 Scaling Law 的不断演进，Agent 的能力正从“能够回答”向“能够行动”转变。

当智能体开始自主调用 API、执行多步骤工作流、访问敏感数据，甚至与物理设备交互时，仅仅依靠训练阶段的对齐技术，已难以应对真实环境中层出不穷的系统级风险。问题的核心在于：训练是离线的，而风险是实时的。

为解决这一难题，香港中文大学 CURE Lab 团队推出了 ArbiterOS。这并非又一个外挂式的安全补丁，也不仅仅是附加在智能体链路之外的一个过滤器，而是一个面向智能体的治理内核（governance kernel）。它的职责是在高风险动作真正执行之前，对模型输出、工具调用及数据流进行结构化的审查、策略裁决和运行时约束。

论文链接：https://arxiv.org/pdf/2604.18652

如果将传统操作系统的职责理解为管理人类程序的资源访问与运行边界，那么在 Agent 时代，ArbiterOS 试图填补的，正是自主行动智能体长期缺失的那一层运行时治理能力。

在工程化测试中，ArbiterOS 展现出了显著的安全提升。以主流智能体系统 OpenClaw 为例，在一组涉及私钥泄露、敏感配置外发、文件误删等高风险的测试任务中，原生系统对高危步骤的拦截率仅为 6.17%；而接入 ArbiterOS 后，这一指标飙升至 92.95%。

同时，在 Agent-SafetyBench 与 AgentDojo 这两个已验证可成功攻击的测试集中，ArbiterOS 的实时拦截率均超过了 94%；在 WildClawBench 的高风险工作流评测中，该系统实现了 100% 的及时预警。

ArbiterOS 并不依赖于某一特定的智能体框架。除了在 OpenClaw 上完成系统验证外，团队近期还快速适配了备受关注的 Hermes Agent，整个接入过程仅耗时数小时。

对于非 Claw 类的 Agent，ArbiterOS 同样能够提供支持。它真正依赖的是开发者能否将智能体的动作语义、执行边界和关键风险点，清晰定义为可治理的 policy。这意味着，ArbiterOS 的潜力远不止于一个特定生态的插件，而是一层可迁移、可复用的 Agent 运行时治理内核。

项目网址：https://arbiteros.ai/

GitHub 地址：https://github.com/cure-lab/ArbiterOS

为什么智能体需要运行时治理？

在过去一段时间里，围绕 OpenClaw 等通用智能体框架，业界已经涌现了大量安全增强方案，包括提示词约束、附加式 Guardrail、流程审批、安全监控和沙箱隔离等。

客观地说，这些方法都具有实际价值。但如果我们拆解现有的主流防护手段，会发现它们大多要么在输入端增加限制，要么在输出端进行过滤，要么在运行环境外层施加刚性约束。它们能够缓解风险，但还不足以构成一套真正面向智能体行动的治理架构。

问题至少体现在三个层面。

1. 提示词约束与人工确认并不可靠

大模型底层无法天然严格区分“指令”和“数据”。这意味着攻击者可以通过 Prompt Injection 等方式，将原本只是数据的内容重新伪装成系统指令，从而绕过文本层的约束。同时，频繁的弹窗确认也并非理想方案，因为这会让用户疲于应对，而普通用户往往也不具备判断某个 API 调用、外部请求或系统操作背后真实风险的能力。系统看似“处处询问”，实际上却未必能带来真正的安全。

2. 语义过滤难以理解真实上下文

附加式 Guardrail 更擅长判断单次输入或输出在语义上是否可疑，因此对于明显的敏感信息泄露或违规表达，通常仍具备一定效果。但它通常不掌握完整的系统状态，也难以持续追踪数据来源，所以容易漏掉另一类更隐蔽的风险：局部语义完全正常，但在全局上下文中不应发生的操作。例如，代理向外部服务发起了一次格式合法、参数普通的 HTTP 请求，请求中引用的资源标识或业务数据看上去都无异常；然而这些数据实际上来自前序步骤中的越权读取，或属于当前用户无权访问的上下文。由于缺乏跨步骤、跨来源的全链路感知，这类风险很容易绕过语义层面的单点护栏。

3. 沙箱隔离会陷入“安全—可用性”的权衡

传统沙箱依赖的是刚性限制：限制目录、限制网络、限制设备访问。但沙箱本身并不理解 Agent 的意图，也无法判断“这次修改配置到底是正常维护，还是恶意篡改”。如果过度隔离，Agent 的实际能力会被直接削弱；如果为了生产力而打开足够多的权限，风险又会顺着这些权限缝隙重新渗透回来。

综合上述三个层面，我们可以发现，问题并非“安全插件不够多”，而是当前智能体系统仍然缺乏一层真正的运行时治理底座。当一个极其聪明、随时准备执行动作的智能体，在没有系统级权限约束的前提下运行时，风险并不会因为模型更强而自然消失。相反，越是面向金融、医疗、自动化运维等高敏感场景，就越需要一种可审计、可复盘、可配置的执行前治理机制。对这些领域而言，不可控、不可审计，往往就等于不可用。

ArbiterOS 在补什么缺口？

ArbiterOS 的核心主张可以概括为一句话：将安全从不稳定的语义博弈，推进到确定的动作治理。

它提出了一种“治理优先”的架构设想：无论上层 Agent 使用了多复杂的 Prompt、多长的上下文、多步推理或多种工具，只要它最终准备执行一个高风险动作（例如写本地文件、修改关键配置、对外发起网络请求），这个动作都会先被 ArbiterOS 接管，转换为机器可读、可检查的请求，再交由治理内核审查。只有当该动作满足预先配置好的“数字契约”后，才会真正被放行。

这也是为什么 ArbiterOS 更适合被理解为 Agent Kernel / Agent OS 的雏形，而不只是一个外挂式的过滤网或安全组件。其核心在于向智能体领域首次引入了底层系统的黄金法则——“特权分离（Privilege Separation）”。

ArbiterOS 在物理架构上彻底剥夺了模型和上层应用的底层执行主权，将“想”和“做”进行了刚性切割。

它像一个系统层中间件那样，站在“智能决策”和“真实执行”之间：模型只负责思考和提出动作候选，而 ArbiterOS 作为唯一掌握物理接口的内核，负责冷酷地决定哪些动作在当前上下文中可以真正落地执行。

ArbiterOS 生态架构总览： AI 智能体 → 治理内核 → 模型提供方

从工程角度看，这种区别非常关键。它意味着 ArbiterOS 关心的不是“模型是不是说了一句看起来危险的话”，而是：

• 它准备做什么动作
• 这个动作对应的目标对象是什么
• 涉及的数据来自哪里
• 在当前的上下文中，这个动作是否应被允许执行

这使得智能体安全真正进入了动作级、状态级、数据流级的治理层面。

从模型输出到动作治理：ArbiterOS 的四步

为了实现这种运行时治理，ArbiterOS 将整个流程规范化为四个阶段：拦截（Intercept）、解析（Parse）、治理（Govern）、观测（Observe）。这四步构成了 Agent 运行时最关键的治理闭环。

ArbiterOS 四步治理流程: 从原始输出到治理后输出——拦截、解析、策略、观测的完整链路

1. 拦截：在动作执行前先接管

当Agent完成配置文件的读取，准备向外部API发起请求时，ArbiterOS的第一步并非评估其“语气是否危险”，而是直接接管该操作。这是整个系统得以成立的基础。原因在于，在Agent场景中，许多高风险行为一旦发生，便是瞬间且不可逆的：数据一旦外泄、文件一旦被删除，事后分析日志、撰写事故报告都为时已晚。真正的治理必须发生在动作执行之前，而非事故之后。拦截的核心在于解决第一个关键问题：绝不能让系统进入“先做了再说”的状态。

2. 解析：将自然语言动作转化为机器可读的结构化指令

在拦截动作后，系统不能继续依赖自然语言进行风险匹配。相较于再用一层语言模型去“猜测”意图，ArbiterOS的关键设计是在应用层与执行层之间建立强制性的结构化通信接口。上层Agent可能想的是“帮我把这段摘要发给数据平台”，但在实际向下执行前，它必须先将该意图封装成机器可验证的结构化指令，例如：

• Action: HTTP POST
• Target URL: api.external.com
• Payload: [摘要数据]

与此同时，系统会自动挂载与该动作相关的上下文元数据，比如数据来源、路径、调用对象及执行环境等。因此，这种新型治理建立在机器可读、强约束、可验证的接口协议之上。只有先将动作清晰表达，系统才有可能在执行前进行真正可靠的判断。

3. 治理：利用“结构化指令”对动作进行安全判定

当获取到结构化指令与元数据后，ArbiterOS的治理引擎并不依赖系统提示词或自然语言约束，而是采用类似于基于属性的访问控制（ABAC）逻辑，对可疑的危险动作进行安全判定：

• 主体（Subject）：谁发起了调用，属于什么角色
• 动作（Action）：读取、写入、修改配置、外发请求等
• 客体（Object/Target）：访问的是哪个文件、哪个域名、哪个资源
• 条件（Condition）：该动作的数据来自何处，是否包含敏感来源，是否处于允许上下文中

在前述例子中，最关键的不仅是“谁发起了调用”，而是这段数据从哪里来，并将流向何处。

为解决这一问题，ArbiterOS在治理层引入了动态污点追踪（Dynamic Taint Tracking） 机制：当Agent在前序步骤中读取了本地敏感配置、密钥文件或高风险上下文时，系统会为相关数据流附加污点标签，并使这些标签沿后续步骤持续传播。这样一来，即使某个后续动作在语义上看似合法（例如一次普通的HTTP POST），只要请求中携带了来自敏感来源的数据，策略引擎就能在高风险动作执行前识别危险，并触发阻断、脱敏或用户确认等治理动作。也就是说，ArbiterOS关注的不仅是“当前动作危险与否”，更是当前动作所用数据在整个执行链路中是否已被高风险来源污染。

一旦系统识别出安全风险，治理引擎会执行明确的治理动作，例如：
– 直接阻止
– 打码或保护性处理后再放行
– 人工确认

需要强调的是，ArbiterOS不会粗暴地阻断系统运行。当某个动作被拒绝执行时，内核会向上层返回明确的结构化拒绝信息，说明触发了哪类策略、违反了哪条执行边界，以及当前动作为何不能被放行。对于接入得当的智能体工作流而言，这类反馈可被上层状态机、编排器或Agent本身用于选择后续处理路径，例如改写请求、降级执行、等待人工确认，或进入备份流程。ArbiterOS会尽力保留工作流的可恢复性与工程可用性。

4. 观测：将拦截行为转化为可复盘的证据链

治理闭环的最后一步是观测。ArbiterOS会完整记录每一次拦截的上下文：Agent准备操作什么对象，数据从哪里来，要流向哪里，触发了哪条规则，最后又被如何处理。这一步的意义不仅是“留日志”，而是将治理系统从一堆静态规则，变成一个可持续优化的工程系统。因为只有当拦截行为被转化为可溯源、可复盘的证据链，开发者才能真正了解：
– 哪些规则在起作用
– 哪些规则误伤了正常流程
– 哪些风险模式尚未被覆盖

从而利用真实反馈不断优化后续策略。因此，观测是让治理从“堆砌规则”转向“工程闭环”的关键环节。

ArbiterOS 与现有防护有何不同？

如果将现有Agent安全手段置于统一视角下，可以更清晰地看出ArbiterOS的定位：
– 沙箱隔离主要解决：代码或智能体可以接触哪些资源
– 运行时监控/审批主要解决：某一步当前看起来是否高风险
– 语义Guardrail主要解决：输入输出在文本语义上是否可疑

而ArbiterOS解决的是另一个更底层、更全局的问题：智能体准备执行什么动作，这些动作涉及的数据从哪里来，以及在当前上下文中，这个动作到底应不应该被允许执行。 正因如此，它关注的不是单条文本，而是结构化指令、上下文状态和跨步骤数据流。这使得它能下沉到真正的执行层来处理问题，而不仅仅依赖提示词约束。

从这个意义上说，ArbiterOS的价值更接近一套可迁移的运行时治理方法：上层Agent可以变化，底层模型可以变化，具体框架也可以变化；只要开发者能将智能体的动作语义、敏感资源和可执行边界清晰定义为policy，ArbiterOS就能成为这些系统共享的一层治理底座。这也是它能在OpenClaw之外快速接入Hermes，并具备支持更广泛非Claw智能体潜力的原因。

为什么这件事重要？

ArbiterOS的意义在于验证了一个更关键的方向：AI治理不必永远停留在模糊的语义风险判断层面，它可以被推进到确定的底层动作检查层。 一旦风险边界被收束到资源访问、动作执行和数据流向，原本许多看似“玄学”的防守问题，就开始转化为可审计、可配置、可复盘的工程问题。而这正是高敏感领域真正需要的。未来一个由大量智能体协同运行的“硅基”社会，能否长期稳定，不仅取决于这些“硅基公民”有多聪明，更取决于底层是否存在一套刚性执行的数字规则与治理内核。ArbiterOS迈出的，正是走向“数字规则”的一步：用确定性的规则，约束不确定的硅基智能，为金融、医疗、自动化运维等高风险场景中的AI应用建立最后一道可被信任的执行底座。

目前，ArbiterOS的官网、开源代码和运行Demo已发布。CURELab团队也希望邀请更多开发者和研究者，共同探索这条面向Agent时代的“运行时治理”路径。

参考资料：
https://arbiteros.ai/