跳到主要内容
SecondHome

藏住 key,管不住权限:agent 凭据的最小权限设计

6 分钟进阶7aL13 p.26-29 ↗录像 ↗支撑材料 5 篇

沙箱管执行面,本篇管授权面(L13 p.26-29):先立身份与权限三元组:调用者、请求的动作、权限检查(p.27),金句点破「把 API key 藏起来不能阻止 agent 滥用它所代表的权限」(参考 GitHub PAT 管理与 RFC 8693 Token Exchange);再拆三层落地:细粒度 token 按账户分权,issue 处理账户读 issue ✓ 打标签 ✓ 发版 ✗,发布账户读已批准源码 ✓ 发版 ✓ 改 issue 缓存 ✗,资源/动作/有效期三个旋钮同拧,GitHub App installation token 1 小时过期(p.28);凭据代理让 agent 全程不碰真实密钥:请求+运行 ID 进、broker 查权限后代持密钥发调用、事件单独落账(OpenShell 架构、RFC 8693,p.29);贯穿原则:访问规则与执行机制必须置于 agent 控制之外(p.21,与 p.36 检查/日志/停止控件同源)。反例是 PocketOS(p.4):staging 任务持能删生产数据的 token,生产卷与备份同删。前沿补两篇 2026:FAVA(arXiv 2607.27267)论证静态工具级权限在动态执行中根本不够,提出权限随证据走的带证据权限图;SecureClaw(arXiv 2606.09549)用不透明句柄+有界摘要的去分类接口与 PREVIEW→COMMIT 写入协议,在 AgentDojo/AgentLeak/ASB 公共 harness 下唯一同时守住效用与两个边界。权限设计的本质:拆掉 lethal trifecta。

L13 p.27 的金句先打碎最常见的幻觉:把 API key 藏起来,并不能阻止 agent 滥用它所代表的权限。

key 只是一串字符,藏没藏好是运气,它背后的授权范围才是设计。

L13 p.4 的 PocketOS 反例是这句话的实体版:一个 staging 任务手里握着能删生产数据的 token,结局是生产卷与备份一起消失。

一、三元组:权限检查到底在查什么

讲义把身份与权限拆成三元组,L13 p.27:调用者是谁在请求,请求的动作针对哪个资源,权限检查问本任务是否被允许。任何一次工具调用,都要能回答这三问。

缺了任何一问,检查就退化成「有没有 key」。而有没有 key,是最没信息量的一问。

最常见的反模式是一个长期 PAT(Personal Access Token,个人访问令牌)走天下:agent 拿着用户的完整身份调用一切,三元组的第一问被整个抹平。上游只看得到用户本人,看不到用户派出的、正在执行某个任务的 agent。

讲义列了两条参考,GitHub PAT 管理与 RFC 8693 OAuth 2.0 Token Exchange,指向同一个方向:给 agent 换发一个「任务级身份」,别让它顶着用户的全量身份。

RFC 8693 定义的 token exchange 就是这件事的标准化版本:拿一个已有凭证,换出一个作用域更窄、生命期更短的凭证,并保留委托语义。上游能分辨这是替谁、以什么范围在调用。

二、细粒度 token:按账户切权限

第一层落地是分账户最小权限,L13 p.28。讲义的例子把一条发布流水线拆成两个互不知晓对方权限的身份:

读 issue ✓・打标签 ✓・发版 ✗—— 面向公开协作面,碰不到任何发布动作。

读已批准源码 ✓・发版 ✓・改 issue 缓存 ✗—— 只吃已过审的内容,发完即走。

三个旋钮要同时拧,L13 p.28:能访问哪些仓库与目录,许可读、写、打标、发版里的哪几种,有效期多长。GitHub App 的 installation token,1 小时后过期。

即便 token 被提示注入套走,它代表的权限也只是这一个小时内、这几个动作。泄漏概率、可用窗口、许可动作,最小权限(least privilege)把每个因子都压到任务所需的最小值,损失期望是三者连乘,跟着一起被压小。

三、凭据代理:把密钥和检查一起搬出 agent

第二层落地是凭据代理(credential broker),L13 p.29:agent 从头到尾不接触真实密钥。

agent 发起请求时只带请求内容与运行 ID。broker 检查这次运行被允许做什么,然后要么换发一个临时 token,要么干脆代持密钥、以自己的名义把调用发出去。结果回到 agent,事件则单独记进 agent 摸不到的日志,出处是讲义点名的 OpenShell 架构与 RFC 8693。

审计通道与结果通道分离:agent 看得到调用结果,改不了行为记录。

Thought: 需要给这个 issue 打上 approved 标签。Action: 向 broker 发 label_issue 请求,附本次运行 ID。tool: broker 按运行 ID 查策略 ——issue 账户、打标签 ✓,代持密钥发出 API 调用。Observation: 标签生效;同一事件另行落账,agent 不可见、不可改。
为什么必须「在 agent 之外」

p.21 的贯穿原则:访问规则与执行机制必须置于 agent 控制之外。p.36 对检查、日志、停止控件说同样的话。沙箱限执行面 p.18-25,凭据限授权面 p.26-29,都逃不开这条原则。凡是放进上下文的东西,就按已泄漏对待。

四、权限要跟着证据走:两个 2026 新答案

静态权限表有个软肋:权限在任务开始前定死,而 agent 的执行是动态的。它下一步要碰什么资源,取决于它刚才读到了什么。

FAVA 正面论证:静态工具级权限在动态 agent 执行中根本不够。它提出权限随证据走的带证据权限图(evidence-backed permission graph):agent 想升级动作,先交证据,权限图随证据生长。

SecureClaw 补上另一半:显式去分类接口(explicitly de-classified interface),工具只返回不透明句柄与有界摘要(opaque handle、bounded summary),agent 拿到的引用就算原样外发也无效。

外部写入走 PREVIEW→COMMIT 两段协议,先预览后落盘。在 AgentDojo/AgentLeak/ASB 公共 harness 下,它是唯一同时守住效用与两个边界的防御。

lethal trifecta(致命三要素)的第三要素是对外通信能力,权限设计要做的就是不让三要素在同一个凭据里聚齐。token 交换、细粒度账户、broker 拆的都是 agent 能做什么;去分类接口拆的是另一条,能带走什么。

与本讲的连接

本篇下钻 7a 伴读的凭据侧。跨篇连读:第 1 讲详解《工具结果注入攻防》结尾守则里的最小权限与双 LLM 隔离,在本篇找到工程落点,broker 就是双 LLM 隔离在凭据层的版本,密钥与策略永远不进 agent 上下文;第 6 讲详解《从一份脚本到一组服务》末尾预告的 Sandboxing and Credential Management 即本讲。

行动项:给自己手头的 agent 做一次凭据盘点,每个 token 列三栏:能碰哪些资源、许可哪些动作、多久过期。再问一句:若这个 token 此刻被注入套走,到期前最多能造成什么?答不上来的,就该换发收窄,或收进 broker。

本节论文与规范

本节资料

  • 2026 年发布:论证静态工具级权限在动态 agent 执行中根本不够,提出「权限随证据走」的形式化授权框架——用带证据的权限图刻画随运行时状态与数据流演化的授权决策。slides L13 p26-29 凭据管理的最新学术对应物。

  • 2025-06-16 发布:私有数据+不可信内容+对外通信三要素并存即可被注入利用,唯一可靠防御是别让三者同时出现。一句话框架讲透防御为何要从架构下手(对应 L13 p21 边界与 p27-29 凭据),社区引用极广。

  • slides L13 p21(工具进沙箱拓扑)与 p29(凭据代理)引用的架构文档:agent 在外、工具调用经沙箱与 broker 越界;权限检查与执行机制置于 agent 控制之外的工程范本。

  • slides L13 p27/p29 引用:OAuth 2.0 Token Exchange——凭据代理签发/交换短时 token 的标准协议基础。

  • 2026 年发布:针对未授权外部动作与运行时明文暴露提出双边界架构——敏感读取经可信网关替换为不透明句柄+有界摘要,外部写入走 PREVIEW→COMMIT 仅受信执行器可提交;AgentDojo/AgentLeak/ASB harness 下唯一同时守住效用与两个边界的防御。与 OpenClaw 事件天然呼应。

AI 生成 · 仅供参考,与课程方无关。选中正文里的任何一段也能直接问我(解释一下 / 举个例子)。

本详解以 CMU 11-768 AI Agents (Fall 2026) 课程大纲为参考框架独立撰写,AI 辅助起草、人工抽审。 涉及的官方课件、论文与课程材料版权归原所有方,讲义为站内镜像、其余外链原文出处; 观点与文字(除标注引用外)为作者原创。