设计Agent权限，先分清身份与审批

Agent 在后台跑完任务，就算「自主」了吗？Speakeasy 的 Nolan Sullivan 给出了另一套划分：先看它用谁的身份，再看关键操作是否需要人工批准。前者决定权限、归责和撤销方式，后者决定错误能否在生效前被拦住。

这套分类适合正在接入编码助手、云端任务和内部工具的团队。它不讨论模型有多聪明，而是帮助你回答更实际的问题：Agent 凭什么能操作系统，出了问题能否查清，以及任务结束后权限会不会继续留着。

「自主」先看身份，不能只看能否独立干活

日常讨论里的 autonomous agent，通常指能自己规划、连续执行、不用人盯着的 Agent。作者刻意收窄了这个词：自主型 Agent（autonomous agent）使用自己的身份和权限；委托型 Agent（delegated agent）使用某个人授予它的权限。

为什么要这么分？因为独立程度很容易变。同一个编码助手，收到详细清单时可以严格照办，收到模糊目标时也可以自行拆任务。这个变化并不能告诉平台团队，它究竟能访问哪个仓库、谁该为结果负责。

身份可以。

自主型 Agent 通常通过服务账号或工作负载身份（workload identity）认证，权限直接授予它，操作记在它名下，再由明确的负责人承担管理责任。告警处理、夜间对账、以公司名义回复客户，都可能属于这类长期工作。

委托型 Agent 则替某个人办事。编辑器里的编码助手、替开发者准备 pull request 的云端 Agent，都是作者给出的例子。个人已有权限构成它的上限，但团队还应该继续收窄，例如人能读写，Agent 只允许读取。

作者用 OAuth 2.0 作为概念依据：客户端可以代表资源所有者行动，也可以代表自身行动；OAuth token exchange 又区分了委托与冒充。委托关系里，应能区分「替谁办事」与「实际由谁执行」。

判断 Agent 类型，要看下游系统实际授权了哪个身份。

设计文档写着「替开发者执行」，不等于真实请求就携带了开发者的委托身份。

四种组合，分别把风险留在哪里

第二条轴是审批：有人审批（attended），还是无人审批（unattended）。它关注有后果的操作是否在生效前得到批准，并不要求人盯住每一步。

读取资料、起草内容可以自动完成，发布、花钱、删除数据或修改共享系统则等待批准。按作者的治理口径，这仍属于有人审批。后台执行也不等于无人审批，后台任务完全可以持续汇报进度，在关键节点停下来。

两条轴交叉，得到四种组合：

类型	原文中的典型场景	首要问题
有人审批的委托型	开发者逐项接受修改	委托权限过宽，频繁批准变成机械点击
无人审批的委托型	分配 issue 后回来查看 pull request	任务结束了，委托权限还没结束
有人审批的自主型	修复 Agent 等待值班人员批准生产变更	请求者借用 Agent 的常驻权限越权
无人审批的自主型	夜间对账或告警触发的诊断任务	错误持续重复，直到有人发现

第三种尤其容易被忽略。Agent 有自己的服务账号，审批者也在场，不代表请求一定合理。请求者可能诱导它执行自己无权执行的操作，因此还要同时检查请求者的权限与 Agent 的职责范围。

第四种没有运行中的人工关卡，更依赖明确负责人、运行限制、监控、升级处理路径和定期权限复核。一次错误决策，可能在每次触发时重新发生。

作者建议，大多数新 Agent 从「委托型＋有人审批」起步，等工作需要、且有人愿意负责时，再放宽审批或配置独立身份。这是治理建议，原文没有给出成本或事故率的对照数据。

共享密钥，会让委托关系在请求里消失

假设团队在 Agent 配置中粘贴了共享 API key 或 bot token。用户虽然通过聊天给它派任务，下游系统看到的却只是那把密钥。

作者把这种情况称为「意外变成自主型」：审计日志无法直接说明是谁发起了操作，发起者离职也不会自动让共享密钥失效。修复方向是有意识地选择身份模型：需要委托，就传递个人的受限授权；需要长期自主运行，就配置专属身份和负责人。

同一个 Agent 还可能在一次任务中切换身份。例如，团队聊天机器人先用自己的身份读知识库，再代表提问员工提交工单。读取是自主型，写入是委托型，日志应该逐步记录。事后仅凭聊天记录，很难可靠还原当时的授权关系。

子 Agent 也遵循同样的原则。编排器替某个人工作时，下发给子 Agent 的委托权限应当更窄，不能把自己的全部权限原样复制过去。

撤销权限同样要跟着身份走。委托型需要结束会话、取消未完成任务或周期任务，并撤销保留的委托；自主型需要停止触发器和队列，禁用身份，并转移或结束所有权。操作后还要验证下游系统是否拒绝旧凭证，因为已经签发的凭证可能继续有效，直到过期或服务检查到撤销状态。

文章最后介绍了 Speakeasy AI Control Plane：通过 Model Context Protocol（MCP）网关检查每次工具调用的授权主体并记录审计。作者也明确承认，它只能治理经过网关的流量，Agent 直接调用其他系统时仍需单独控制。

我的判断

我赞同把身份和审批拆开。它比「是不是后台任务」「有没有 human-in-the-loop」更能帮助团队检查真实权限，也能解释为什么一个看似普通的编码助手，接上高权限凭证后会产生完全不同的风险。

但「自主型」在这里是作者选定的治理术语，并非整个行业统一采用的定义。与团队沟通时，需要先讲清口径，否则一方在讨论规划能力，另一方在讨论服务账号，结论很容易错位。

共享 API key 的论述也需要留一点余地。原文没有区分密钥权限范围与所有权管理方式，不能据此认定所有共享密钥都必然汇集了所有人的权限、也都没有负责人。真正需要核查的是：它代表谁、能做什么、如何归责，以及什么事件会使它失效。

独立服务账号便于隔离职责，却增加凭证轮换、权限复核和退役管理的负担；个人委托能复用组织目录，却可能继承过大的个人权限。两者都需要做权限收缩。

这是一套有用的治理分类，不是一份效果经过验证的安全方案。

原文没有实验、部署规模、事故统计或成本对比，也没有证明某个象限天然更安全。OWASP 的 excessive agency 被用来说明过多功能、权限或自主性会放大损害，但四种类型仍然都需要工具约束、不可信输入处理、输出校验、日志和事件响应。

能拿来做什么

• 给现有编码助手或云端 Agent 补一份身份记录，写清实际授权主体、负责人、访问范围和有后果操作的审批方式。核对真实凭证与请求日志，不要只照产品介绍填写。
• 把审批放到具体动作上。让读取和草稿生成自动推进，对发布、删除数据和修改共享系统设置批准节点，减少连续点击带来的审批疲劳。
• 对「分配 issue，稍后回来收 pull request」的任务使用受限、会过期的委托凭证，同时记录委托人和执行 Agent，并明确任务结束后的撤销流程。
• 检查内部 Agent 的共享 API key、bot token 和直接调用路径。对长期任务确认专属身份、负责人及退役方式，对经过 MCP 网关的调用确认日志能记录每一步实际使用的身份。