Agent 的权限设计：最小权限 + 人在回路

全文分三层：

1. 通俗理解：给新员工开权限
2. 实际用处：编程 Agent 的权限模式、浏览器 Agent、企业 Agent
3. 原理与工程要点：动作风险分级、审批界面怎么设计、短期凭证与代理

第一层：通俗理解

1.1 给新员工开权限

一个合理的公司会这样给新员工开权限：

• 第一天：能看文档、能看代码，不能改生产环境、不能动财务；
• 需要做敏感操作时：提交申请，主管批准，用完收回；
• 所有操作留记录。

Agent 也应该这样。区别在于：Agent 比新员工更容易被骗（见《提示词注入》），而且一秒钟能做几十个动作。

1.2 三个原则

第二层：实际用处

• AI 编程工具的权限模式：主流编程 Agent 通常提供几档模式：每次执行命令都询问、只对写文件和执行命令询问、对某些"允许列表"里的命令自动放行、在沙箱里完全自动运行等。用户可以按项目配置允许和禁止的命令。
• 浏览器 Agent：在付款、提交表单、发送消息等关键步骤暂停，等待用户接管或确认。
• 企业 Agent：通过 OAuth 获得限定范围的访问权限（比如"只读日历"而不是"完全访问 Google 账号"），并支持随时撤销。
• OWASP 的"过度代理"：OWASP LLM Top 10 把"给了 Agent 过多的功能、权限或自主性"列为一类单独的风险（见《AI红队测试》）。

第三层：原理与工程要点

3.1 动作风险分级

判断风险的维度：能否撤销、影响范围（只影响自己 vs 影响他人 / 公开）、是否涉及钱或凭证、是否对外发送数据。

3.2 审批界面怎么设计

一个好的确认界面要让人在几秒钟内看懂：

• 要做什么：完整的命令、要访问的地址、要发送的内容，而不是 Agent 自己写的摘要（摘要可能被注入篡改）；
• 为什么要做：Agent 的理由，但要标注"这是 Agent 的说法"；
• 影响：会修改哪些文件、发给谁；
• 选项：允许一次、本次会话内允许同类动作、拒绝、拒绝并说明原因。

避免确认疲劳的办法（参见《风控评分与摩擦设计》）：

• 低风险动作不打扰；
• 允许"本次会话内允许同类命令"，但对高风险类别不提供"永远允许"；
• 对高风险动作的确认加一点摩擦（比如要求输入目标仓库名），打断无意识的点击。

3.3 命令允许列表的陷阱

"允许 git 命令"看起来安全，但 git 可以推送到任意远程仓库；"允许 npm"意味着允许 npm install 任意包，而安装脚本可以执行任意代码（见《依赖投毒》）。允许列表应当尽量具体到子命令和参数，并且考虑命令的组合（管道、&&、$(...)）。

3.4 凭证：短期、窄范围、不进上下文

3.5 记录一切

每个动作（包括被拒绝的）都要记录：时间、动作、参数、谁批准的。这既是事后追查的依据，也是发现异常的信号源：Agent 突然尝试大量被拒绝的动作，很可能已经被注入。

总结