CAPMAS 是由 EPFL 和 Swisscom 共同开发的，它允许开发者通过 macaroons 为 AI 子代理（child agents）授予范围狭窄的权限。它将 Token 处理延迟降低了 30 倍，并使代理无法获取完整的用户 JWT。

为什么这一变革至关重要

当 LLM 编排下游工具时，团队通常会将用户登录时使用的相同 JWT 移交给生成的“子”代理。JWT 是一个包含用户所拥有的所有权限（如 HR 数据、项目文件、管理员权限等）的签名数据块。如果模型产生幻觉并生成了破坏性命令，子代理就能以用户的全部权限执行该命令。一个错误就可能导致整个组织的数据泄露。

当前权宜之计的缺点

使用 RFC 8693 token-exchange 流程按需铸造窄范围 Token 会增加多次与 IAM 系统的往返交互，增加网络流量，并引入明显的延迟。对于需要启动大量短寿命代理的团队来说，这种开销很快就会变得难以承受。

CAPMAS 的工作原理

CAPMAS 将权限授予分为两个阶段：

  1. IAM 端编码 – IAM 服务运行一个编码器，将自然语言请求（例如“列出 finance 文件夹中的文件”）转换为一组匹配的权限。
  2. Macaroon 创建 – 这些权限成为 macaroon 内部的 caveats（限制条件）。Macaroon 是一种灵活的 Token 格式，允许下游代理添加进一步的限制，但绝不能移除现有的限制。

当代理收到 macaroon 时，它可以收紧范围——例如，将文件列表请求限制在某个子目录中——但不能扩大范围。在每一次跳转时，IAM 服务都会验证所有 caveats 的交集，从而确保没有任何代理会超出原始授权范围。

令人信服的性能数据

  • 速度 – CAPMAS 处理权限请求的时间不足 20 ms，比 RFC 8693 交换流程快约 30 倍。
  • 准确性 – 在一个包含大量工具目录的基准测试中，标准 LLM 遗漏了 53% 所需的权限。CAPMAS 的准确率达到 90.9%，漏失率仅为 2.1%。
  • 带宽 – 由于 macaroon 仅携带最终的 caveats 集合，因此交换的数据量仅为完整 token-exchange 流程所需数据量的一小部分。

务实的采用工作流

  1. 预过滤请求 – 在编排器接触工具目录之前，将用户的自然语言意图转换为 top-k 白名单。
  2. 密封白名单 – 将该白名单编码为子代理无法扩大的 macaroon。
  3. 在服务端验证 – 在执行请求之前，让目标服务请求 IAM 计算所有 caveats 的交集。

这些步骤将“把整套房屋钥匙交给孩子”的模式转变为“递交一把一次性、受限范围的钥匙”模式。

CAPMAS 无法解决的问题

该框架无法阻止提示词注入（prompt-injection）攻击，即攻击者操纵 LLM 的提示词以注入恶意命令。它的保护范围涵盖了“诚实但好奇”的代理以及可能违规操作的不可信 LLM（否则它们可能会利用完整的 JWT 行事）。团队仍需采取独立的防御措施——如输入清洗、沙箱化或模型级护栏——来应对基于提示词的威胁。

谁将从中受益

  • 企业开发者：构建调用内部 API 的 AI 驱动助手。
  • 安全团队：寻求降低模型被攻破后的爆炸半径（blast radius）。
  • 产品负责人：需要为高频生成的代理提供快速、可靠的权限检查。

下一步计划

CAPMAS 是一个提议的设计方案。

核心结论： 将完整的用户 JWT 替换为范围狭窄的 macaroons，为开发者提供了一种既能确保 AI 代理行为合规，又无需承担传统 token-exchange 流程延迟代价的方法。权衡之处在于，仍需持续使用提示词注入防护措施。