权限控制
先说结论
权限控制是指对模型、代理、工具和用户之间的可访问资源、可执行操作、数据范围和审批流程进行约束，核心原则是最小权限、显式授权和可审计。
为什么我会单独记这一篇
Agent 系统一旦能调工具、访问知识库、发送消息或改动数据，就不再只是“回答问题”，而是“代表用户行动”。这会带来：
- 过度授权。
- 跨租户串读。
- 高风险动作自动执行。
- 事后无法追责。
因此权限控制的重点，不是限制模型说什么，而是限制系统能做什么。
核心机制
常见权限机制
- RBAC / ABAC
- scope 限制
- 短期令牌 / 临时凭证
- human-in-the-loop approval
- 工具级 allowlist
- 沙箱与环境隔离
核心原则
- 最小权限
- 显式授权
- 读写分离
- 可审计
- 高风险动作审批
设计时真正要权衡什么
- 自动化程度 vs 审批成本：审批越多越安全，但体验更差。
- 共享服务账号 vs 代表用户授权：前者实现简单，后者边界更清晰。
- 单一代理全能权限 vs 多代理分权：后者更复杂，但 blast radius 更小。
容易踩的坑
- 给 Agent 绑定长期高权限密钥。
- 默认允许所有工具，只靠 prompt 说“不要乱用”。
- 模型既能读敏感数据，又能对外发送消息。
- 没有区分读、写、删、支付等操作等级。
- 工具调用日志缺失，事后无法还原动作链路。
工程落地时我会怎么做
- 把工具作为权限边界，而不是把 prompt 当边界。
- 所有工具声明输入 schema、权限范围、允许副作用和审批要求。
- 高危动作走二次确认：付款、删除、发信、外部发布、权限变更。
- 使用短期 token、用户委托授权和每请求最小 scope。
- 做租户隔离和数据标签，避免跨用户上下文串读。
- 日志中记录 actor、delegation chain、request ID、tool、resource 和 decision。
如果要对外讲，可以怎么概括
“Agent 场景里，模型本身不是权限主体，真正的权限主体是工具和执行环境。权限控制的重点是最小权限、短期授权、读写分离和高风险动作审批。只靠 prompt 说‘不要做危险事情’基本等于没有权限控制。”
最后记几条
- 权限边界应落在工具和执行环境上。
- 最小权限和显式授权是核心原则。
- 读、写、删、支付必须分级治理。
- 高危动作默认需要审批。
- 没有审计链路就很难真正做权限治理。