Agent 项目最怕的其实不是「答不好」，而是「动手太快」。让它查个订单，结果它顺手把订单状态改了；让它发封邮件，结果它给全公司群发了一封。这些问题追到底，都是一个原因——权限没管好。
权限管理这件事，普通软件和 Agent 的差别很大。普通软件的每个操作都是代码写死的，谁有权限谁没权限一目了然；Agent 是模型在「自主决策」，它要调哪个工具、传什么参数，都是运行时才定的。所以传统的那套「角色权限表」不够用，得专门给 Agent 设计一套权限边界。这篇把最核心的三层做法讲清楚。
为什么 Agent 的权限这么难管
先想清楚问题在哪。Agent 的权限风险有三个特点：第一是「动态」，同一个 Agent 今天查数据、明天写文件，动作范围一直在变；第二是「间接」，模型本身没权限，但它能驱动有权限的工具去干；第三是「难预测」，prompt 一句话可能触发一串你没料到的工具调用。
这几个特点叠加起来，结论就一个：不能把系统账号的完整权限一股脑塞给 Agent，得一层一层地收。整体思路和 AI Agent 安全七道防线 里说的「最小暴露」是一致的——安全的核心不是「堵」，是「只给必要的」。
第一层：最小权限原则
最小权限就一句话：Agent 只拿到完成当前任务所必需的最小权限，多一分都不给。
落地时有几个具体动作。一是「按任务拆分权限」，别让一个 Agent 同时拥有「读全部数据库」和「写全部数据库」的权限，能拆成两个角色就拆成两个。二是「权限默认关闭」，新接的工具、新的数据源，默认是只读甚至禁用，确认需要了再开。三是「定期回收」，任务做完、项目结束，权限该收就收，别让一堆「曾经用过」的权限一直挂着。
这层最容易被人忽略，因为它不解决眼前的问题，反而多花时间。但权限一旦给出去，后面想收就难了。这和 Agent 自主越权防线 里的教训是一样的：越权往往不是 Agent 主动作恶，而是权限给得太宽，它「顺手」就用了。
第二层：工具白名单
最小权限管的是「哪些资源能碰」，工具白名单管的是「哪些动作能做」。做法是把 Agent 能调用的工具列成一张白名单，不在名单上的工具一律不能调。
更进一步，还可以对工具做「参数级」约束。比如同一个数据库工具，白名单只允许「查询」不允许「删除」；同一个发消息工具，只允许发给指定的人，不允许群发。这种约束做得越细，Agent 能翻的车就越少。
工具白名单的维护要当成日常纪律，不是配一次就完。每次新增工具、变更业务，都要同步更新白名单。这个节奏可以参考 知识库陈旧内容巡检 的思路——不是配完就不管，是要周期性回头看有没有过时、有没有漏配。
第三层：子账户隔离
前两层管「权限」，这一层管「身份」。给 Agent 单独开一个子账户，而不是用管理员账号直接跑，这样即使 Agent 出问题，损失也被限制在子账户的范围内。
子账户隔离有几个关键点。一是账户级，Agent 用自己的账号登录系统，权限从这个账号的权限里再往下收。二是数据级，能看到的表、能读的文件，都限定在它职责范围内。三是资金级，涉及钱的操作，子账户要单独设额度上限、默认锁死提现，需要时人工审批放开。
这套「子账户 + 额度上限 + 人工审批」的组合，正是现在金融场景里给 AI 交易代理做风控的主流做法。它的好处是：就算 Agent 被 prompt 注入骗了、或者自己判断错了，最坏也就损失子账户额度以内，掀不起大浪。具体怎么落地，可以结合 质量门禁 的思路，把审批卡在关键动作前面。
兜底：转人工和审计日志
权限再严，也有兜不住的时候。所以最后要配两道保险：一是转人工，遇到金额大、风险高、结果异常的操作，强制停下来等人确认，别让 Agent 自己拍板。这套机制在 转人工队列 里有详细讲法。
二是审计日志，把 Agent 的每一次工具调用、每一次权限使用都记下来，出问题了能回溯「它到底干了什么、用了哪个权限」。日志不能只记成功，失败的、被拦截的也要记，这些往往才是发现异常的关键线索。
适合人群与代价
这套权限管理，适合所有「让 Agent 接触真实系统、真实数据」的团队，尤其是涉及资金、客户数据、对外操作的场景。如果 Agent 还停在「聊天问答」阶段，没接什么危险工具，可以先把重点放在工具白名单上，等接真实系统了再上全量。
代价是前期要花时间梳理权限、维护白名单，日常还要做审计。但这属于「磨刀不误砍柴工」——权限一旦失控，一次事故的代价远超你省下的那点时间。
总结
AI Agent 权限管理，核心就三层：最小权限管资源、工具白名单管动作、子账户隔离管身份，再配上转人工和审计日志兜底。记住一句话——权限不是「给 Agent 越方便越好」，而是「刚好够它把活干完」。把权限关进笼子里，Agent 才能真正放心用。
