智能体最小权限（Least Privilege）

本条讲的是权限与边界治理：智能体会真实地执行操作，读写文件、调用接口、发送消息。它判断失误时，后果取决于被授予了多大权限。智能体最小权限（Least Privilege for Agents）要求每个智能体只拿到完成当前任务所必需的能力，并在高风险动作上加人工确认。这不是不信任模型，而是承认任何自动化流程都会出错，权限边界是出错时的最后一道闸门。

具体怎么收紧

• 只读优先：默认给只读权限，需要写入时按任务临时提权，任务结束即收回。
• 按范围限定：明确允许访问的路径前缀与域名白名单，而不是整机或全网放行。
• 凭证不落盘：工具使用短期凭证，避免智能体在文件或日志里读到长期密钥。
• 高风险动作二次确认：删除、支付、对外发送、修改生产配置必须由人确认。
• 全程留痕：记录每次工具调用的参数与结果，事后能还原它到底做了什么。

权限为什么容易失控

常见的失控来自权限的传递与继承。智能体本身只被允许执行一个脚本，但脚本继承了更高权限，前面的限制就形同虚设；同理，智能体调用的工具若持有长期密钥，等于把整片资源暴露出来。另一类问题来自上下文注入：外部文档或网页里藏着的指令可能诱导智能体调用它本不该调用的工具，因此对输入来源的信任分级要与权限收紧同时做。

常见误区

• 一味拒绝：权限收紧到无法完成任务同样是失败，应从真实任务反推所需能力。
• 环境不隔离：测试与生产必须分开授权，别让试跑的智能体碰到真实数据。
• 只看工具名不看参数：同一个工具传入不同参数风险差别很大，限制要落到参数范围上。
• 忽略审计时效：日志只在事后可查还不够，异常调用应当能实时告警或中断。
• 和沙箱混为一谈：权限控制管「能碰什么」，沙箱管「碰坏了影响多大」，两者互补而非替代。

和人在回路的关系

最小权限与人在回路（Human-in-the-loop）常被放在一起讨论，但作用不同：权限收紧决定智能体「最多能做什么」，人在回路决定「关键时刻由谁拍板」。前者是静态边界，后者是动态拦截，缺一不可。只做人在回路而权限全开，一次误判就可能造成不可逆后果；只收紧权限而无人确认，则会把本该自动化的简单任务拖成低效流程。

落地时可以从一张权限清单开始：列出每个智能体可用的工具、可访问的资源范围、必须人工确认的动作，随任务迭代更新。清单越具体，出问题时的排查范围就越小，评审时也更容易看出哪里放得过宽。