SAGA：面向 AI Agentic 系统的可扩展安全治理架构

论文概览

随着 LLM Agent 从单一工具调用走向跨系统、跨组织的协同，OpenAI 等机构的治理白皮书已经把"身份、认证、授权、发现、用户可控"列为 Agentic 系统的基础安全需求。SAGA 这篇工作的价值在于：它不只是提出一个安全概念，而是给出了完整的协议规范、形式化证明和可运行的实现，并把 Provider 中心治理、密码学访问控制令牌、细粒度 Contact Policy 三者整合起来。

核心创新

1. Provider 治理的三层身份模型

SAGA 把系统参与者明确划分为 User（用户） / Agent（代理） / Provider（治理中心） 三层：

• User 通过 OpenID Connect 等机制向 Provider 注册，拥有自己名下所有 Agent 的生命周期控制权；
• Agent 作为运行在用户设备上的自治软件实体，既可以是通信的发起方，也可以是接收方；
• Provider 维护 User Registry $D_U$ 与 Agent Registry $D_A$，负责身份绑定、发现、策略存储和一次性密钥 (OTK) 分发。

这一设计的关键是：用户始终掌握自己 Agent 的注册、策略更新与撤销权，而不是把 Agent 交给某个平台任意管理。

2. 基于 OTK 与 DH 的访问控制令牌

SAGA 的访问控制不是简单白名单，而是一个带预算的密码学令牌机制。每个接收方 Agent 上传一批一次性公钥 $OTK_i^A$ 给 Provider；当发起方 Agent B 想联系接收方 Agent A 时，从 Provider 取走一个 OTK，然后双方通过 Diffie-Hellman 协商出共享密钥：

$$DH_A = DH(SOTK_i^A, PAC_B), \quad DH_B = DH(SAC_B, OTK_i^A)$$ $$SDHK = KDF(DH_A) = KDF(DH_B)$$

接收方用这个共享密钥加密 Access Control Token 并发给发起方。Token 里带有过期时间戳和最大请求次数 $Q_{\max}$，发起方之后把它附加在 TLS 消息上即可与接收方直接通信，不必再经过 Provider。这种"重注册、轻通信"的架构把安全和性能做了一个显式 trade-off。

3. 形式化验证与真实部署评估

论文用 PROVERIF 在 Dolev-Yao 模型下证明了三个关键性质：Access Token 的机密性、Agent 与 Provider 之间的认证、Agent 与 Agent 之间的认证。同时作者实现了完整原型，在 Calendar、Email、Writing 三类真实 Agent 任务上，使用 GPT-4.1-mini、GPT-4.1 和本地 Qwen-2.5 72B 三种后端，并在 US-East / US-West / Europe / Asia 多个地理位置之间部署测试。

系统架构与协议流程

上图展示了 SAGA 的宏观流程。用户首先在 Provider 注册，再为自己的 Agent 注册并提交 TLS 证书、长期访问控制密钥 $PAC_A/SAC_A$ 和一批一次性公钥 $OTK_i^A$ 以及 Contact Policy $CP_A$。之后两 Agent 的通信遵循"查询—协商—令牌—直连"四步：

1. 发起方从 Provider 请求接收方的元数据和一个未使用的 OTK；
2. Provider 返回元数据、签名、Contact Policy，并扣除对应 OTK 预算；
3. 双方建立 TLS，完成 DH 密钥交换，接收方用共享密钥加密 Access Token；
4. 发起方附带 Token 与接收方直接 TLS 通信；Token 过期或达到 $Q_{\max}$ 后，重新向 Provider 申请 OTK。

Contact Policy 采用最具体规则优先的匹配策略。例如一条策略可以先给 alice@company.com:calendar_agent 分配 15 个 OTK，再给 *@company.com:calendar_agent 分配 10 个 OTK。当发起方匹配多条规则时，取最具体那条的预算。用户也可以随时把某条规则设为 $-1$ 来直接阻断某个 Agent。

Token 的生命周期是 SAGA 安全与性能的调节旋钮。$Q_{\max}$ 越大、生命周期 $L$ 越长，发起方与 Provider 的交互越少、系统容量越高，但 Agent 被攻陷后可被恶意利用的窗口也越大。

威胁模型

论文定义了 6 类攻击场景，基本覆盖了当前 Agent 生态的主要风险：

SAGA 通过 X.509 证书、用户签名、Provider 侧 OTK 计数器、DH 共享密钥、Token 过期与请求限制等机制分别应对。形式化验证覆盖了 Dolev-Yao 攻击者模型，相当于把 C6 的能力编码进了证明。

实验与评估

任务完成开销

论文在三种常见 Agent 任务上测量了 SAGA 引入的额外开销（Agent A 位于亚洲、Agent B 位于欧洲、Provider 位于 US-West，$Q_{\max}=10$）：

这里的"标准耗时"包含 LLM 推理与网络延迟，SAGA 开销仅指协议本身。对于动辄数秒乃至数分钟的任务，0.165 秒基本可忽略。

协议开销随 $Q_{\max}$ 变化

论文给出的摊销协议开销模型为：

$$\bar{c}_{proto}(m) = \frac{(RTT_{B,P} + t_{crypto}) \cdot m}{Q_{\max}}$$

其中 $RTT_{B,P}$ 是发起方与 Provider 的往返延迟，$t_{crypto}$ 是证书验证、DH 交换、签名验证等本地密码学操作。下图展示了不同地理位置下，每请求摊销开销随 $Q_{\max}$ 下降的趋势，以及系统容量随 Sharder 数量线性扩展的结果：

Provider 可扩展性与容错

Provider 采用 RAFT 共识 实现容错，并通过 Sharding 横向扩展：

• OTK Request：单节点 242K req/min，3 节点 RAFT 212K，5 节点 204K，吞吐下降 12–15%；
• 在 7 个 Sharder、24 小时 Token 生命周期配置下，系统可支持约 2.6 亿并发 Agent；
• Sharder 数量增加时，容量接近线性增长。

这意味着 SAGA 不只是实验室原型，而是可以直接面向大规模 Agent 生态部署。

A2A 兼容性

论文还展示了 SAGA 与 Google A2A 协议的集成：把 A2A 的 Agent Card 存进 Agent Registry，用 SAGA 的访问控制策略保护卡片的读取；把标准 A2A Request 的消息字段包装成 \langle token, A2ARequest(msg) \rangle，在 SAGA 层完成 Token 验证后再交给 A2A 栈。这样 SAGA 不会破坏现有 Agent 框架，而是作为一个安全中间层存在。

启示与思考

SAGA 最有价值的不是某个单独的技术点，而是它把"Agent 治理"从口号变成了可验证、可部署的系统设计。Provider 中心化的选择是一个务实的取舍：虽然去中心化听起来更符合 Web3 叙事，但在当前阶段，一个可审计、可撤销、可扩展的中心治理实体更契合企业和监管需求。

我觉得 SAGA 还留下几个值得追问的方向：

1. 跨域信任：当多个 Provider 并存时，Agent 如何跨 Provider 认证？论文假设所有参与者使用同一个 Provider 或同一个 CA，现实里多云、多厂商场景会需要联盟式身份模型。

2. 动态策略的粒度：Contact Policy 目前主要按 Agent ID 通配符和 OTK 预算控制。如果未来 Agent 调用涉及敏感数据分级、时间窗口、上下文条件，策略语言可能需要从简单规则升级为更丰富的授权语言（如 Rego / OPA 风格）。

3. 用户侧密钥管理负担：Agent 需要长期保存 TLS 私钥、访问控制私钥和一次性私钥。普通用户如何安全生成、备份、轮换这些密钥，仍是一个用户体验和安全的双重挑战。

4. 与 MCP 的融合：论文提到可与 MCP 集成，但没有深入展开。MCP 作为工具侧协议，SAGA 作为 Agent 间通信协议，两者如何统一地表达"谁能调用哪个工具的哪个功能"，是接下来亟需标准化的课题。

总体而言，SAGA 为 Agentic 系统的安全治理提供了一个坚实的基线。在行业还没有统一答案之前，这种"身份 + 策略 + 密码学访问控制"的组合，很可能是大规模 Agent 互联的必由之路。

参考链接

• 论文 PDF：NDSS 2026 s869
• 代码与形式化模型：github.com/gsiros/saga
• arXiv 版本：2504.21034
• Google A2A 协议：A2A 公告