面向智能体的范围受限凭证

为什么人类级别的凭证在智能体规模上会失败。

一份人类级别的凭证——一段私人 API 令牌、一段长寿命的 OAuth 刷新令牌、一把 SSH 私钥——的那些性质，对一个人来说有道理，对一个智能体则正好相反：

• 长寿命。一段有效期 90 天的令牌，会把"一次"被攻陷（智能体 worker 把秘密误打入日志、一次提示词注入抽走凭证、开发者笔电被偷）翻译成 90 天的攻击者访问。
• 范围宽。一段范围为"该用户所有数据"或"该服务账号能做的一切"的令牌，把智能体本该具备的每一项能力的并集，下放给每一次工具调用。被攻陷的智能体不必再去升权；它已经在最大范围上了。
• 难以粒度化吊销。吊销一份人类级别凭证通常意味着把它在所有配置过它的地方都轮换一遍——worker 池、staging、开发者机器、CI。轮换的痛，恰好是团队推迟它的原因。
• 无上下文。一段 bearer 凭证不携带任何信息说明智能体此刻想干什么；授权系统只能授权"最大"，因为"最小"它看不见。

把这些与智能体的爆炸半径合起来——prompt-injection 里讲的提示词注入能把整张凭证的权力交给攻击者控制的文本——智能体环境里的一份人类级别凭证，就是一把上了膛、等着扣扳机的枪。

范围受限的智能体凭证所需的三条性质。

一份让智能体握着是安全的凭证，需要三条性质；少了任何一条，另外两条的安全保证就塌了：

• 短寿命。寿命按分钟计，不是按天或小时。令牌过期得比攻击者迭代得还快；吊销变成"不再续签"而非主动轮换。令牌寿命，是把一次外泄凭证与一场长期事故隔开的唯一东西。
• 范围窄。令牌授权的是一个具体资源加一个具体动作——"对 order-12345、用户 user-678，最多 50 美元的退款（create-refund）"——而不是一类能力。凭证的爆炸半径，正好等于它被签发的那个动作。
• 按动作。每次工具调用（或接近）派生一份新凭证，而不是每次会话签一次重复用。按动作签发让审计日志诚实：每张凭证映射到它授权的那个动作，每个动作映射到一张凭证。

把三条性质组合起来的实现模式。

这三条性质不会自己实现——它们需要一层夹在智能体与工具之间的基础设施。在生产里站得住脚的模式：

• STS 风格的临时凭证。AWS STS、GCP 服务账号模拟、Azure 托管身份临时令牌。智能体出示一份长寿命但严格范围的身份（一次性核验）；STS 为某个角色与资源签发一份短寿命凭证。真正走到工具调用上的是那份短寿命凭证。
• 带按工具范围的 OAuth。scope 不只是用户级；是工具级。智能体为读工具请求 read:orders、为写工具请求 write:refunds-under-50，每个 scope 一份独立的短寿命令牌。scope 的组合是显式的，而不是聚合成一张大令牌。
• 带受众与动作声明的 JWT。由工具信任的签发方签的一段 JWT，携带受众（哪个工具）、动作（允许做什么）、资源（在什么上做）以及短过期。在线上无状态，无需回到授权服务器即可验证。
• 夹在智能体与工具之间的授权层。一个基于策略签发按动作凭证的策略决策点（PDP）——智能体本身永远不持有底层能力，只持有 PDP 为本次动作派生的那张令牌。实现得好时，这是这套模式最干净、也最容易审计的版本。

这些都不是模型该担的事；全部坐在智能体循环之外，以策略形式被执行。policy-enforcement 那块工程内容就是它依附的工程面。

那些捷径——以及每条的代价。

上面这些模式都要真投入工程。在限期之下，四条捷径在向你招手，而每一条都会把一次性的工程投入变成一份持续、复利的风险：

• 一张全能的 API key。一段令牌、宽范围、永远活着。智能体调用的每个工具都用它认证。这段令牌泄露的那天，就是你最大损失场景兑现的那天；最大值，正好等于这段令牌授权的。
• 长寿命的 OAuth 刷新令牌。"短寿命访问令牌、从长寿命刷新令牌刷出来"看着像范围受限模式；它不是——因为刷新令牌才是真正的长寿命秘密，攻击者偷到它就有了无期限访问。智能体用的刷新令牌需要它们自己的寿命与范围纪律，否则你为这套模式付了钱，却没拿到那个性质。
• "以后再加范围。"没带范围就上线了；团队忙起来了；九个月后审计报告说所有智能体动作都被记为同一个超级用户。给一个已经部署的系统补范围，要比一开始就建进去难得多——因为下游工具已经长成"期待那张宽令牌"的样子。
• "就这次运行给它 admin。"最贵的捷径。授权熬过了这次运行，因为清理被低优了；下一次提示词注入继承了 admin；复盘发现"那个临时其实不是临时"。

对范围本身做审计。

范围受限的凭证只有在范围本身可验证时才有意义——既在签发的那一刻，也在事后重建发生了什么时。两条可观测性性质：

• 每次凭证签发都连同其范围一起被日志化。签发方、请求方（智能体的身份，来自 agent-identity）、被授予的范围、代表谁、过期时间、触发它的请求。这是 audit-trails 那条故事在凭证一侧的形态。
• 每次工具调用都连同授权它的凭证一起被日志化。按 run_id 与凭证 id 与签发日志可关联。"智能体是以什么权限去做 X"这个审计答案就是一次 join，而不是一次取证式重建。

这套范围纪律给你换来的复合性质，是审计故事里最有用的一版：系统里每一个动作都有具名的签发方、具名的主体、具名的凭证、具名的范围、有界的寿命——其中没有任何一项是"那智能体有 admin"。智能体只是行动者；权限属于那些范围窄、寿命短、被审计的、由授权层为那个发生过的动作（且仅为那个动作）签发的令牌。提示词注入落地的那一天，你会庆幸自己付的是模式的钱，而不是捷径的钱。