权限校验在哪一步？执行之前，关键步骤一次讲清

AI 智能体的每个动作真正执行之前都有一道闸门，核对身份、范围与时机，这就是权限校验，被拦下的请求走兜底路径。这篇按执行顺序拆解这道闸门，解释它为什么必须挡在前。

校验看的是身份还是动作

两者都看，但重点不同。身份校验回答「你是谁、有没有资格」：来自哪个用户、代表哪个角色、凭证是否有效。动作校验回答「这件事现在能不能做」：目标资源在不在允许清单里、操作是读还是写、当前时段是否放行。只查身份不查动作，等于验了门票却不管你进的是哪个包厢——两者缺一不可，这条判断请带走。

这道闸门装在哪个位置

标准位置在解析之后、执行之前：模型给出动作请求，系统先解析出「对什么资源、做什么操作」，再拿着这个结构去比对规则，通过才真正动手。放太早，请求还没成形没法判；放太晚，动作已经发生拦不回来。与密钥是怎么注入调用的的时序也在这里衔接——凭证在校验通过后才取用，避免没过闸就亮出钥匙。

被拦下之后走哪条路

拦截并非一拦了之。系统会生成一条明确的拒绝原因回给模型：是身份不够、资源不在范围，还是操作类型受限。模型据此改道——换只读方式获取信息、拆分请求只做允许的部分，或者转人工确认，等待与恢复的机制见人工审批是怎么暂停流程的。拒绝原因的清晰程度，直接决定模型能不能一次改对，这与错误信息是怎么反馈给模型的的加工逻辑是同一门手艺。

白名单、只读与人工兜底

工程上常用三档防线：白名单限定可达范围，清单外一律不通；只读模式先跑通流程，确认无误再逐步放开写权限；不可逆动作一律人工确认。三档叠起来，智能体的活动范围就可控了。扣子的应用权限面板、智谱清言的企业空间都提供这类分级管控。清单本身也要有维护规矩：谁来加、加了谁复核、多久清一遍，否则白名单会越积越宽，形同虚设。

三档防线管的东西不一样，配合着用才收得住：

权限自查清单：校验是否在执行之前；拒绝时是否返回了明确原因；写操作与不可逆动作是否分开管控；白名单是否有复核与清理节奏。四项都有答案，闸门才算真闸门。

一句话带走：权限校验的价值不在拦了多少次，而在每一次放行都心里有数。闸门立得住，智能体的手脚才能放得开——松紧得当，才是管控的分寸。

动态权限与临时放行

固定清单管不住动态场景：任务临时要读一个新目录、一张新表，走什么路？常见设计是临时放行机制——任务发起申请，说明目标与理由，审批通过后发一张短时效通行证，任务结束自动作废。通行证要限定范围与次数，防止一张卡反复使用；每次放行都留档，复盘时能回答「当时为什么放它过」这个关键问题。还有降级思路：拿不到写权限时，先把结果攒在只读区，等权限到位再一次性落盘，任务不必整个卡住等待。动态权限的设计原则与白名单一脉相承：范围最小、时效最短、留痕最全，三条缺一不可。临时放行的审批级别要与动作风险挂钩：只读的放行走轻量确认，写入与删除类必须两级审批，宁可流程长一点，也不给误操作留门。放行到期前的提醒也要做，任务还没跑完就该提前续期，避免跑到一半通行证过期，前功尽弃。

换个问法再问权限校验三句

• 校验会拖慢执行吗？：规则比对是毫秒级动作，几乎无感，换来的安全边界物超所值。
• 同一个动作每次都要重新校验吗？：要，资源与时点可能变化，缓存授权结果反而容易出漏洞。
• 只读操作也要过闸门吗？：要，读取范围同样需要限定，敏感数据的可见性本身就是一种权限。