让 AI 智能体遵循最小权限原则
有团队说，自己的 agent 已经做到了最小权限，依据是 prompt 里写着「只读取客户工单」。可这个进程拿到的服务账号令牌，却能更新工单、导出用户，还能调用三个内部 API。prompt 只是在跟模型商量，真正拍板安全边界的是那张凭据。对 agent 来说，最小权限的意思是：凭据本身做不了任务之外的动作——不管模型好好请求，还是提示注入（prompt injection）命令它去做。
权限大小要跟任务匹配
给 agent 配一个长期固定的角色，通常范围太宽，因为 agent 干的活是随场景变的。一个任务可能是读租户 A 的发票，另一个可能只是起草一封邮件、并不发送。所以应该按任务发放授权，写清楚受众（audience）、作用域（scope）、租户、资源约束和过期时间。
{
"sub": "agent:invoice-assistant",
"act": { "sub": "user:123" },
"aud": "https://billing.example.com",
"scope": "invoices:read",
"tenant_id": "tenant-a",
"exp": 1788622800
}
光有这些声明（claims）还不够。账单 API 必须逐项校验，并落实对象级的策略。一张声明了 tenant-a 的令牌，如果解析出的发票归属 tenant-b，就绝不能放行。
委派只能收窄权限
主 agent 调用子 agent 或工具时，不要直接把原始令牌转发下去。应该换一张下游令牌：受众更小、有效期更短，只保留这一跳所需的作用域。RFC 8693 就定义了这种 OAuth 令牌交换（token-exchange）模式。这样就有了一个单调规则：权限可以保持不变或收窄，但委派过程中绝不能变大。一个只能读日历的 agent，不能因为模型觉得「顺便发个摘要也挺有用」，就凭空变出一张能发邮件的令牌。
读、起草、提交要分开
agent 往往只靠读权限就能做完分析，在没有写权限的情况下也能给出待提交的变更，只在最后产生实际影响时，才去申请一份经过严格审批的凭据。这样既减少了常驻权限，又不至于让产品没法用。
清除隐形的权限
凭据只是其中一条路径。网络可达性、文件系统访问、继承来的云角色、插件权限，以及缓存里的密钥，这些都能绕过令牌模型的管控。
在受限环境中运行代理，并盘点进程实际可用的能力。既要审计成功操作，也要审计被拒绝的操作。反复请求不可用的权限范围，可能说明工作流有问题，或遭遇了提示注入。让权限撤销具备任务感知能力，这样取消某个代理运行就不必把用户整体禁用。要点在于：最小权限不是静态角色，而是每个任务和每次委派跳转的属性。给代理足够权限完成已批准的工作，其余一律在技术上不可行，没有例外。Akash Devdhar 是一名高级软件工程师，专长于企业身份、认证、授权和 AI 基础设施。他撰写关于使用 OAuth、OIDC、RBAC 和现代身份架构构建安全 AI 系统的文章。
团队常说某个 agent 具备最小权限，理由是它的提示词写着「只读客户工单」。可实际情况是，这个进程拿到的是一个服务账号令牌（service-account token），能改工单、导出用户，还能调用三个内部 API。提示词不过是在跟模型「商量」，真正做出安全决定的，是那本凭证。对 agent 而言，最小权限的意思是：凭证无法执行任务之外的动作——哪怕模型好声好气地请求，哪怕提示注入（prompt injection）叫它这么干。权限大小，应当按任务来定。