🤖 machine learning

Sovereign Execution Brokers: Enforcing Certificate-Bound Authority in Agentic Control Planes

本文介绍了主权执行代理（Sovereign Execution Broker, SEB），这是一种运行时强制执行边界，通过将动作提议与执行解耦来保障智能体基础设施的安全，确保所有生产环境的变更在由短寿命、可审计的身份执行之前，都经过针对认证权威、策略约束以及实时状态条件的严格验证。

原作者： Jun He, Deying Yu

发布于 2026-06-19

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Jun He, Deying Yu

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你有一个非常聪明但有点难以捉摸的机器人助手。这个机器人很擅长规划事情，比如“让我们为访客开一扇新门”或者“让我们关掉空房间里的灯”。然而，由于机器人的思维方式是非线性的、具有创造性的，它偶尔可能会出现“故障”，或者被一个糟糕的提示词（prompt）误导，从而产生“炸掉整栋建筑”或“删除数据库”的想法。

在过去，为了让这个机器人能够工作，我们必须给它一把万能钥匙（永久凭证），它可以打开大楼里的任何一扇门。这是很危险的：如果机器人出了故障，它可以使用这把万能钥匙来摧毁一切。

这篇论文介绍了一种新的安全系统，叫做主权执行代理（Sovereign Execution Broker，简称 SEB）。你可以把 SEB 想象成不是一个持钥匙人，而是一个严格的高科技保安，站在机器人与大楼门扉之间。

以下是该系统的工作原理，使用了简单的类比：

1. 三步走流程

与其让机器人持有钥匙，不如将过程分为三个不同的角色：

规划者（机器人）： 机器人提出一个想法（例如，“打开前门”）。它没有任何钥匙。它只是提出了一个提议。
裁判（主权保障边界）： 一个受信任的人类或 AI 系统会对提议进行审查。如果这个想法是安全的且符合规则，裁判就会发放一张特殊的、一次性的门票（加密证书）。这张门票会说明：“是的，这项特定的操作是被允许的，但仅限于这扇特定的门，且仅限现在。”
保安（SEB）： 这是故事中的新英雄。机器人带着门票去找保安。保安并不信任机器人。保安会非常仔细地检查门票：
- 门票是真的吗？（是由裁判签署的吗？）
- 这是对应正确门的门票吗？（请求是否与计划相符？）
- 门票过期了吗？（是否经过了太长时间？）
- 大楼发生变化了吗？（在我们等待时，是否有人把那扇门锁上了？）
- 规则手册改变了吗？（是否刚刚出台了新的安全策略？）

2. “一次性”的魔力

如果保安满意了，他们不会把钥匙交给机器人。相反，保安会暂时解锁那扇门，仅持续一秒钟，让机器人推开门，然后立即重新上锁。

没有万能钥匙： 机器人永远不会持有永久性的钥匙。它无法绕过保安，也无法在之后使用这把钥匙。
作用域限制： 如果门票写着“打开前门”，保安会确保机器人无法打开后门，即使它试图欺骗系统。
即时撤销： 如果发生安全警报（比如火灾），裁判可以立即使所有门票失效。即使机器人的口袋里揣着门票，保安也会看到警报并说：“抱歉，这张门票现在是废纸了，”然后拒绝开门。

3. 为什么这比旧系统更好

旧方式（IAM）： “这是万能钥匙。你可以做任何事。”如果机器人被黑客攻击，黑客就会得到万能钥匙。
折中方式（审计日志）： “随你去做，但我们稍后会记录下你的行为。”这就像是一个只在抢劫发生之后才进行记录的安全摄像头。它无法阻止犯罪。
SEB 方式： “除非你有一张新鲜的、经过验证的门票，并且我在行动的那一瞬间进行检查，否则你碰都别想碰这扇门，而且我会为你开门正好一秒钟。”这在犯罪发生之前就将其阻止。

4. 这篇论文实际测试了什么

作者使用真实的云技术（如 Amazon AWS 和 Kubernetes）构建了一个运行中的“保安”系统原型。他们测试了以下内容：

速度： 机器人必须等待多久？（答案是：它增加了一个微小的延迟，简单任务约为 28 毫秒，复杂任务约为 136 毫秒，对于计算机来说这非常快）。
安全性： 如果他们尝试用假门票、过期的门票，或者尝试打开错误的门来欺骗系统，保安会阻止吗？（答案是：是的，100% 成功拦截）。
韧性： 如果保安失去了互联网连接会发生什么？（答案是：它会默认进入“安全模式”，并在能够再次验证规则之前拒绝打开任何门）。

总结

**主权执行代理（SEB）**是一个安全层，它确保即使 AI 智能体处于困惑、被黑客攻击或表现出恶意行为的状态，只要它没有获得由受信任保安在行动时刻实时验证的、新鲜的一次性许可凭证，它就无法对计算机系统造成破坏。它将“信任机器人”转变为“验证行为”。

技术摘要：主权执行代理 (Sovereign Execution Brokers)

问题陈述

随着由大语言模型（LLM）驱动的自主智能体从被动分析工具向主动操作规划器转型，它们正越来越多地被集成到生产基础设施工作流中（例如：自动扩缩容、部署容器、管理安全组）。然而，授予这些具有非确定性推理过程的实体直接的、常驻的访问凭证会带来严重的安全性风险。一次单一的幻觉或对抗性提示注入就可能触发未经授权或破坏性的基础设施变更。

现有的架构试图通过引入准入门控（如主权保证边界，Soverearch Assurance Boundary, SAB）来缓解这一问题，该边界负责验证提议的操作并颁发加密签名的证书 ( $\Omega$ )。然而，仅凭准入证书是不够的，因为缺乏一个在运行时主动要求该证书进行执行的机制，智能体或被劫持的封装程序可能会完全绕过准入门控，直接使用常驻凭证进行操作。此外，即使遵循了准入流程，从提议准入到实际执行之间的时间滞后也会创造一个漏洞窗口，在此期间系统状态可能发生漂移，或者安全策略可能发生变化（即“检查时与使用时”漏洞，Time-of-Check to Time-of-Use, TOCTOU）。

方法论：主权执行代理 (Sovereign Execution Broker, SEB)

本文引入了主权执行代理 (SEB)，这是一种运行时强制执行边界，旨在弥合经过认证的自主提议与实际基础设施变更之间的鸿沟。其核心架构原则是实现提议 (proposal)、准入 (admission) 与 执行 (execution) 的分离。

核心架构

零常驻权限 (Zero Standing Privileges)： 在预期的部署场景中，没有任何智能体运行时或封装程序持有生产环境的常驻变更凭证。所有的自主变更请求必须通过 SEB。
证书验证流水线： SEB 作为守门人，消耗 SAB 证书 ( $\Omega$ $Ω$ ) 和执行请求 ($req$)。在执行之前，它会运行一个形式化验证流水线，检查以下各项：
- 签名 ( $\Phi_{sig}$ )： SAB 签名的有效性。
- 契约匹配 ( $\Phi_{match}$ )： 确保请求参数、目标和操作与认证契约 $C$ 完全一致。
- 有效性 ( $\Phi_{time}$ )： 确保请求处于证书的有效期窗口内。
- 策略与撤销 ( $\Phi_{policy}, \Phi_{rev}$ )： 验证证书是否符合当前的策略版本，且未通过全局纪元计数器（epoch counter）被撤销。
- 漂移检测 ( $\Phi_{drift}$ )： 将实时目标状态 ($St $) 与准入时捕获的证据状态 ($ E_{admit}$) 进行对比，以检测 TOCTOU 引起的变更。
- 重放抵抗 ( $\Phi_{replay}$ )： 确保证书随机数（nonce）此前未被使用过。
受限执行身份 (Scoped Execution Identity)： 验证成功后，SEB 并不使用自身的母凭证进行执行。相反，它作为一个令牌经纪人，铸造一个短寿命的、经过降权处理的执行身份 ( $ID_{exec}$ )，该身份严格绑定于认证契约、目标资源及有效性窗口。
强制执行模式： 为防止绕过，目标基础设施（如 AWS、Kubernetes）必须配置为拒绝所有非来自代理或非代理签发会话的变更请求。这通过服务控制策略 (SCP)、IAM 权限边界以及验证准入 Webhook 来实现。
可审计性： 每一次验证决策（拒绝或准入）以及执行结果都会记录在经签名的、仅追加的账本中，提供将操作与原始证书进行加密关联的证据。

核心贡献

本文提出了四个主要贡献：

由代理强制执行的自主性 (Broker-Enforced Autonomy)： 它识别了认证提议与实际变更之间的执行缺口，并将 SEB 定义为防止智能体持有常驻凭证的运行时边界。
证书验证执行模型： 它形式化了代理接口 $Execute(\Omega, req, St, Platform) \rightarrow D | O$ ，详细阐述了关于签名、契约匹配、有效性、策略、撤销、漂移和重放检查的谓词。
受限身份与执行前撤销： 它引入了一种最小权限模型，即凭证仅在执行时铸造，其范围受限于契约，并在执行前立即进行撤销检查。
原型实现与评估： 实现了一个基于 Go 语言的原型（约 4,200 行代码），配备了针对 AWS STS 和 Kubernetes TokenRequest 的适配器，作为强制性的变更路径进行部署，并在现实工作负载下进行了评估。

实验结果

该原型在 AWS 和 Kubernetes 集群（Amazon EKS）上进行了评估，以测量延迟、吞吐量以及在故障注入下的安全性。

延迟开销：
- Kubernetes： 代理为变更操作增加了约 28.2 ms (p50) 的开销。主要的瓶颈在于实时漂移检查 (42.9%) 和凭证铸造 (42.9%)。
- AWS： 开销更高，约为 136.9 ms (p50)，主要由 AWS STS 凭证铸造和漂移检查（DescribeSecurityGroups API 调用）组成。
- 对比： 虽然直接使用 IAM 和仅审计日志的开销几乎为零，但它们缺乏 SEB 的安全保障。SEB 的开销被认为对于高风险、低频率的变更（如防火墙变更、自动扩缩容）是可以接受的，但被指出不适用于微秒级的控制循环。
撤销传播： 使用 5 秒的撤销纪元轮询间隔，系统实现了从纪元推进到 100% 请求拒绝的最大 5.2 秒 传播延迟。
安全性与容错性：
- 在涵盖代理绕过、陈旧证书重放、请求与证书不匹配以及网络分区等威胁的 1,000 个注入测试用例中，SEB 对未经授权或无效请求的拒绝率达到了 100%。
- 故障关闭语义 (Fail-Closed Semantics)： 在网络分区或服务故障的情况下，代理默认拒绝请求以防止不安全执行。
- 崩溃恢复： 系统利用幂等性令牌成功处理了代理崩溃的情况，防止了重复变更，确保了状态的一致性。

意义与主张

本文声称，SEB 提供了一个传统的身份与访问管理 (IAM) 和策略引擎无法提供的运行时强制执行层，用于智能体控制平面。

从身份转向动作： 不同于 IAM 授权“谁可以做什么”，SEB 授权的是“在当前系统证据下，执行这个特定的、经过认证的动作”。
缓解 TOCTOU： 通过在执行前立即检查实时状态漂移和撤销纪元，SEB 封闭了准入与变更之间的漏洞窗口。
强制执行定理： 本文提出了一个形式化证明（定理 1），指出在特定的部署假设下（即智能体不持有常驻凭证，且目标 API 拒绝非代理身份），不受信任的智能体无法引起生产状态变更，除非其匹配一个有效的、未过期的、未被撤销且未被重放的证书，并且其作用范围是可强制执行的。

作者总结道，虽然 SEB 引入了延迟开销，但它将认证权威转化为短寿命、可撤销且可审计的运行时能力，这使得它成为在安全破坏成本高于延迟成本的生产环境中，为自主智能体提供安全保障的可行方案。