智能体代你操作时权限怎么收：作用域令牌、最小权限与高危动作二次确认

结论先说：给智能体权限的正确姿势不是「给它一个高权限账号然后祈祷它别乱来」，而是把权限收紧在任务作用域里——按次授权、按资源限定、高危动作强制人工确认。权限设计的目标不是让它什么都做不了，而是让它出事故时损失可控。

一、为什么「万能钥匙」一定出事

把智能体接进业务系统时，最常见的做法是复用一个服务账号，把能想到的权限全开上。这在 demo 阶段没问题，一旦进入真实环境就会暴露三个缺陷：

• 爆炸半径不可控：一次误判可能直接作用于全量数据，而不是当前任务涉及的那几条记录。
• 无法归因：所有操作都来自同一个账号，事后分不清是模型主动行为还是被人诱导。
• 无法撤回：长期有效的凭据一旦泄露，只能整体轮换，影响面远大于单个任务。

Anthropic 在 Agent SDK 的权限文档里把这个问题拆得很细：权限判定不是一次性开关，而是一条有明确顺序的判定链。理解这条链，是设计作用域的基础。

二、三层收口：身份、作用域、动作

三层要一起生效。只做身份不做作用域，等于给正确的人一把万能钥匙；只做作用域不做动作分级，删除和读取会被同等对待。

三、权限判定的执行顺序

Claude Agent SDK 给出的判定顺序是六步，前面的步骤可以提前终结判定：

1. Hooks：最先执行，可以直接拒绝，也可以放行——但放行不会跳过后面的 deny 和 ask 规则，它们照常评估。
2. 拒绝规则：来自 disallowed_tools 和 settings.json 。即使在 bypassPermissions 模式下，命中拒绝规则也会被拦截。
3. 询问规则：来自 settings.json 的 ask 规则。命中后落到 canUseTool 回调等待确认，同样不受 bypassPermissions 影响。
4. 权限模式：bypassPermissions（除关键路径的 rm/rmdir 外全部放行）、 acceptEdits（自动批准文件类操作）、 plan 模式（文件编辑与 shell 写入一律走回调，规划阶段无法自动批准写操作）等。
5. 允许规则：来自 allowed_tools 和 settings.json，命中即批准。
6. canUseTool 回调：前面都没解决时调用，暂停执行直到返回决定。

四、高危动作：分级比禁止更实用

一刀切禁止写操作，智能体就退化成问答机器人。可行做法是按可逆性分级：

• 可自动放行：只读查询、在当前工作目录内的读取、明确列入白名单的命令。
• 需二次确认：删除文件、写入数据库、发送对外消息、付款与下单、修改权限配置。
• 一律拒绝：指向关键路径的 rm / rmdir 、凭证外发、越权访问其他用户数据。

判定依据不是「这个动作危不危险」这种主观判断，而是两个客观标准：能不能撤销、影响范围是否超出当前任务。两个都踩中的，一律拒绝。

五、一份可抄的规则配置

{
  "permissions": {
    "allow": [
      "Read",
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(curl:*)",
      "Write(.env)"
    ],
    "ask": [
      "Bash(git push:*)",
      "mcp__prod-db__*"
    ]
  }
}

这份配置体现的是同一个原则：默认拒绝、按范围授权、不可撤销的单独隔离。Read 与只读命令自动放行；删除、网络请求、敏感文件写入直接拒绝；推送与生产库这类「能放行但代价高」的动作走确认。

需要提醒的是，作用域只解决「智能体自己不越界」，解决不了「被诱导越界」。提示注入可能让模型把恶意指令当成用户意图执行，这层防护需要独立的输入校验与输出净化策略，可参考MCP 场景下的提示注入防护与智能体护栏的落地实现。

六、凭据与审计

权限的作用域要靠短时效凭据落地——长期密钥一旦泄露，作用域设计全部失效。具体做法是按需签发、任务结束即失效，密钥本身集中存储且禁止明文进入对话上下文，详见MCP 服务器凭据管理。

审计侧至少记录四个字段：调用主体（代表哪个用户）、工具名、完整入参、执行结果。缺少入参的日志在事后复盘时几乎没有价值。对于会产生外部副作用的动作，还要配套幂等键与补偿逻辑，避免重试造成重复下单，相关设计见智能体写操作的幂等与补偿。