AI智能体的最小权限，不是简单地给它分配一个低权限角色，而是限制它在特定任务、特定资源和特定时间内能够执行的具体动作。企业需要先区分三类身份：提出请求的发起人、负责规划和调用工具的智能体，以及实际提供数据或执行操作的下游系统。三者不能被压缩成一个共享账号，否则就无法判断权限究竟来自谁，也难以追责。
从“能访问什么”改为“在什么条件下做什么”
权限策略应至少同时描述任务、资源、动作和有效条件。智能体可以读取某个业务流程所需的客户记录，不代表它可以导出全部客户数据；可以生成付款申请，也不代表它可以直接完成付款；可以创建工单，也不代表它能够关闭涉及退款的工单。
因此，授权应尽量表达为：“哪个身份，在什么条件下，对哪些资源执行什么动作”。资源范围要尽可能具体，动作也应区分读取、创建、修改、发送、审批和删除。除了最小范围，还要控制最短时间：一次任务结束后，临时权限和访问凭证应立即失效，避免智能体长期持有完成单次任务所不需要的能力。
高风险动作必须增加控制点
智能体调用工具时，每一跳都应重新校验发起人、智能体身份、目标资源和具体动作，不能因为上游已经认证，就让下游自动继承全部权限。不同工具应使用相互隔离的受限凭证，禁止把密钥写入代码、提示词、配置文件或日志，也不能用共享账号掩盖多个智能体或业务流程。
对于发送外部通知、修改合同或客户状态、触发付款、删除关键记录、批量变更权限等动作，不宜完全自动执行。应根据资源敏感度、影响范围和动作是否可逆，设置人工确认、二次授权或双人复核。高风险操作即使认证通过，也应保留明确的责任节点。
权限设计还必须配合运行时监测。企业应记录智能体常用工具、调用顺序、访问范围和任务时长；一旦出现异常循环、调用爆发或越界访问，应限制调用、阻断工具或冻结临时凭证，而不能只发出告警。
真正可用的验收标准，是能从一条业务结果反查发起人、智能体、工具、授权决策和执行结果。只有当权限做到“最小资源、最小动作、最短时间”，并且每次调用都可验证、可撤销、可审计时，智能体才算真正遵循了最小权限原则。