别把钥匙交给 Agent：用 OpenBao 守住 AI 网关背后的令牌库 - 张善友
内容提要
Christian Posta 通过四篇文章探讨 AI Agent 外部 API 凭证安全：主张 Agent 不应持有凭证，凭证集中管理后需将解密权从存储密文的进程中剥离。方案从信封加密、AWS KMS Grant 演进到 OpenBao 2.7 的 Control Groups，实现控制器只能提议、Broker 只能批准，应用侧无组件持有常驻解密权。但网关被攻陷、热路径明文泄露等风险仍存。
延伸解读
“不持有凭证”不等于风险消失，而是风险转移
文章反复强调，Agent 不拿凭证只是把问题从“凭证外泄”转移到“令牌库被攻陷”。CB4A 威胁模型把 Broker 评为 CRITICAL，说明集中化本身会制造新的高价值目标。读者应把架构评估的重点放在“哪个组件一旦失守会暴露全部凭证”，而不是只看 Agent 侧是否干净。
KMS 与 OpenBao 的差别在授权平面，不在加密算法
两种方案都使用信封加密和 AAD 绑定，真正拉开差距的是“谁能触发解密”。AWS KMS 只能认证控制器的 IAM 角色，看不到终端用户；OpenBao 的 Control Groups 让 Broker 只能批准控制器已提出的请求，形成“提议—批准”分离。选型时应先问授权粒度需求，再比较托管成本。
Control Groups 不是万能钥匙，版本与边界要看清
Control Groups 在 Vault Enterprise 早已存在，OpenBao 2.7 的贡献是首次以 MPL-2.0 开源。其审批因子只能用 Identity Groups 表达，不支持主动推送，也没有 Sentinel 级策略语言。若威胁模型不信任托管进程本身，还需叠加同版本的 External Keys，把密钥材料移入外部 HSM 或 KMS。
落地顺序比架构图更重要
文章给出的路径是先止血：盘点 Agent 凭证、停用 KEK 与应用同信任域的做法，迁到信封加密加独立托管；再收权：摘掉控制器的常驻解密权限；然后拆出 Refresher，把 refresh token 和 client secret 移出热路径；最后跟踪 ID-JAG 与 WIMSE 演进。每一步都对应可验证的运维动作，而非一次性替换。
Q&A
AI Agent 调用外部 API 时，为什么不应该让 Agent 自己持有凭证？
因为 Agent 使用的凭证大多是长期有效、粒度粗糙的 bearer 凭证，谁拿到字节谁就能用。提示注入、凭证外泄、意外暴露都是凭证字节离开 Agent 且仍可用的表现。更麻烦的是，Agent 作为目标导向的随机系统，可能主动把 API Key 递给另一个 Agent。最安全的做法是让 Agent 从未见过凭证。
CB4A 草案提出的凭证中介三种模型是什么？Posta 为什么推荐 Model A 作为企业主模式？
CB4A 草案给出三种模型：Model A 是代理网关，Agent 全程不见凭证，网关在出口注入；Model B 是铸造短期窄范围令牌交给 Agent 直连；Model C 是直接交出长期凭证再事后吊销，被标为最弱。草案推荐 Model B，但 Posta 认为对企业应倒过来，以 Model A 为主模式。理由：DPoP 需要授权服务器和资源服务器两头配合，现实世界多数 API 不校验持有者约束；Model B 仍让 Agent 在内存持有可复用秘密；Model A 让 Agent 永不见凭证，Broker 可实时检查记录过滤请求，目标 API 无需配合。
在 AWS KMS 方案中，Mode 2 和 Mode 3 有什么区别？Mode 3 为什么扩展性差？
Mode 2 将 KEK 放入 AWS KMS，主密钥永不离开 KMS，控制器调用 kms:Decrypt 解包，每次解包是 IAM 门控、可审计、可吊销的事件，但控制器握有常驻解密权，KMS 只能让攻击者无法静默批量离线解密。Mode 3 用 Broker 门控的 KMS Grant，控制器只剩密文和 grantee 身份，每次解密需 Broker 当场铸造短期 Grant，解密需要两个独立信任域同时到场。Mode 3 扩展性差是因为 AWS KMS 的 CreateGrant/RetireGrant 默认每账户每区域仅 50 次/秒，而共享对称 Decrypt 配额是 10,000 到 100,000 次/秒；每次令牌交换需三次 KMS 调用，铸造速率成为吞吐上限，且 Grant 不会自动过期，滞留 Grant 会挂满密钥导致全环境令牌交换瘫痪。
OpenBao 2.7 的 Control Groups 如何实现“控制器只能提议、Broker 只能批准”？
在策略路径上声明 control_group 后，对该路径的请求不会直接执行，OpenBao 存下请求副本并返回 wrapping token 和 accessor。策略指定的审批组成员通过 sys/control-group/request 查看请求详情，通过 sys/control-group/authorize 批准；调用方拿 wrapping token 调 sys/wrapping/unwrap 时 OpenBao 才真正执行解密。在 Mode 3b 中，控制器对 transit/decrypt/user-* 持静态策略，审批组只含 Broker 一个成员，TTL 30 秒，禁止自批准。Broker 用自己的 SVID 登录，仅有 sys/control-group/request 和 authorize 的 update 权限，没有 Transit 路径、不能铸令牌、不能写策略。控制器只能提议解密，Broker 只能批准已提出的请求，应用侧没有组件持有能独立执行的常驻解密权限。
OpenBao 方案中，Control Groups 和 External Keys 分别解决什么问题？为什么说一个功能扛不下完整链条？
Control Groups 管的是“谁能触发解密”，实现请求级双人审批，让应用侧没有组件持有常驻解密权限；但密钥材料仍在 OpenBao 托管进程里，托管者本身仍执行解密。External Keys（同版本 2.7 的 GH-3956）可以把 Transit/PKI 的密钥材料挪进外部 HSM 或 KMS，OpenBao 只当密码学操作代理，从而把密钥材料也移出进程。完整的“存密文的没有解密能力、托管密钥的不能独自授权”链条需要 Control Groups 与 External Keys 两个正交功能拼合，Control Groups 一个功能扛不下这句话。
这套凭证中介架构还有哪些没解决的风险？落地时应该按什么顺序推进？
未解决的风险包括：网关沦陷——网关必须把明文令牌放上线路，天然处在令牌机密性边界内；热路径明文滴漏——Mode 3/3b 保护的是未在用行，在用行随使用速度泄露，Refresher 只能把 refresh token 挪出热路径，access token 仍必经控制器；没有 refresh 半边的长期 PAT、API Key 防护上限就是逐请求授权；Broker 自身成为新的高价值目标；操作面需容量规划和降级演练。落地顺序建议：先止血，盘点 Agent 凭证，停用 KEK 与应用同信任域的做法，迁入信封加密加独立密钥托管，达到 Mode 2 基线；再收权，摘掉控制器/STS 常驻解密权限，按决策树选 OpenBao 设计一或 Mode 3b；然后固本，拆 Refresher，把 refresh token 和 client secret 挪出热路径，审计日志外送，蜜罐行上线；最后跟踪 ID-JAG、WIMSE 等标准演进。
