跳到主要内容

工具权限与审批

核对日期：2026-05-09。

1. 定义与边界​

工具权限与审批是指在工具执行前，根据用户身份、资源范围、工具风险、参数内容和环境策略，决定允许、拒绝或要求人类确认。

它不是模型提示词里的“请谨慎操作”。权限必须在运行时强制执行，审批必须基于真实工具参数和真实影响范围。

2. 为什么重要​

Agent 会把自然语言目标转换成外部动作。如果缺少权限与审批，常见事故包括：

  • 误删文件、误发邮件、误改生产配置。
  • 使用用户 A 的凭据访问用户 B 的数据。
  • 第三方 MCP Server 借 Agent 权限访问不相关系统。
  • 模型被提示注入诱导调用高权限工具。

3. 核心机制​

3.1 三层权限​

层级例子
身份权限用户是否能读取该客户、操作该仓库
工具权限该用户角色是否能使用 email.send
参数权限目标邮箱、金额、路径、生产环境配置是否超出授权

3.2 风险分级​

等级类型默认策略
L0纯计算、格式转换允许，记录日志
L1低敏读操作允许，脱敏返回
L2敏感读操作需要权限校验，可能需要审批
L3可逆写操作预览 + 用户确认
L4不可逆或外部影响操作强审批、双人复核或禁止自动执行

4. 架构模式​

4.1 Policy Engine​

tool: email.send
effect: write
rules:
  - when: "recipient_domain not in allowed_domains"
    decision: require_approval
  - when: "attachments contains sensitive_data"
    decision: deny
  - when: "environment == 'production'"
    decision: require_approval

4.2 Preview/Confirm 两阶段​

高风险工具拆成两个工具：

  1. payment.preview_transfer：生成预览，不产生副作用。
  2. payment.confirm_transfer：只接受预览 ID 和用户确认令牌。

这样模型不能直接构造最终写操作，审批 UI 可以展示确定的动作。

4.3 Capability Token​

对远程工具或 MCP Server，可使用短期 capability token 限定：

  • 谁授权。
  • 能调用哪些工具。
  • 能访问哪些资源。
  • 有效期多久。
  • 是否允许写操作。

5. 工程实现​

5.1 权限决策输入​

{
  "user": {"id": "u_123", "roles": ["support"], "tenant": "t_01"},
  "tool": {"name": "crm.update_customer_status", "risk": "L3"},
  "arguments": {"customer_id": "cus_9", "status": "suspended"},
  "context": {"environment": "production", "source": "chat"},
  "trace_id": "tr_abc"
}

5.2 权限决策输出​

{
  "decision": "require_approval",
  "reason": "production_write",
  "approval": {
    "title": "确认修改客户状态",
    "facts": [
      "客户 cus_9 将被改为 suspended",
      "环境 production",
      "该操作会影响客户登录"
    ],
    "expires_in_seconds": 300
  }
}

6. 生产实践​

  • 审批界面展示真实参数，不展示模型总结。
  • 审批记录绑定 tool_call_id、参数 hash、审批人、时间和结果。
  • 用户批准一次不代表永久批准；长期授权要有明确 scope 和过期时间。
  • 写工具默认幂等，审批后重放必须检测同一幂等键。
  • 对生产环境和外部发送类工具启用更高等级策略。
  • 对 MCP Server 做来源 allowlist，不让用户随意连接未知工具源。

7. 常见反模式​

反模式后果
在系统提示里要求模型“不要乱用工具”无强制力
审批时只显示“Agent 想发送邮件”用户无法判断真实影响
审批后允许模型改参数再执行审批对象被偷换
按工具名授权，不按资源授权越权访问具体对象
所有 MCP Server 共享同一 tokenConfused deputy 和横向移动风险

8. 评测方法​

  • 构造越权读取样例，检查策略是否拒绝。
  • 构造高风险写操作样例，检查是否进入审批。
  • 构造提示注入样例，诱导模型调用写工具，检查拦截率。
  • 回放真实 trace，抽样审计审批文案是否足够明确。
  • 测试审批过期、参数变更、重复提交、撤销授权。

9. 安全与治理​

MCP 远程 HTTP 场景下应重视授权边界。MCP 官方安全最佳实践强调 token audience、用户同意、最小权限、HTTPS、不能接受未发给自己的 token。对企业系统还应增加：

  • per-tenant 工具 allowlist。
  • per-user OAuth consent。
  • token 不透传给不相关下游。
  • 审计日志可导出给 SIEM。
  • 高风险工具默认关闭，由管理员显式开启。

10. 审批协议流程​

审批 token 应绑定：

{
  "approval_id": "ap_123",
  "tool_call_id": "call_456",
  "tool_name": "email.send",
  "arguments_hash": "sha256:...",
  "approved_by": "u_manager",
  "expires_at": "2026-05-09T12:00:00+08:00",
  "scope": {
    "tenant": "t_01",
    "resource_ids": ["draft_789"],
    "effect": "send_once"
  }
}

11. 权限评测方案​

场景预期
模型把 approved=true 放进参数参数被忽略，审批仍由系统决定
审批后模型修改收件人args hash 不匹配，执行拒绝
token 发给错误 MCP Serveraudience 校验失败
用户只有读权限却请求写require_approval 不足以放行，直接 deny
prompt injection 诱导发送数据policy 阻断外发工具或进入审批

12. 安全补充：审批文案​

审批界面不能只展示模型总结，应展示机器可验证事实：

  • 工具名和风险等级。
  • 目标资源 ID、环境、租户。
  • 写入字段的 before/after。
  • 外发目标、附件、数据等级。
  • 参数 hash、过期时间、是否可撤销。

13. 权威资料​