当企业只跑 1 个智能体（Agent，能自主规划并调用工具完成任务的 AI 程序），权限模型很简单——给这个 Agent 一个服务账号、一组 API Key，谁能调、能调什么、调到什么程度，一张权限表就能说清。可一旦进入多智能体编排（Orchestration，由编排器把 N 个 Agent 编进同一条业务链、彼此委托与接力），权限的复杂度会指数级上升：编排器要代表用户向子 Agent 委托权限，子 Agent 又要向工具申请最小化授权，任何一环越权，整条链都会失控。Gartner 2026 年发布的 Agentic AI 安全报告估计，约 63% 的企业级 AI 事故源于权限边界不清而非模型本身。本文给出 PERMISSION-6 六步权限治理框架，把「单 Agent 的一张表」升级为「编排层的授权委托链」，并附单 Agent 与多 Agent 编排的权限横评与上线清单。
一、为什么单 Agent 的权限表，到了编排阶段会失灵
单体智能体的权限是「静态、单点、单向」的：预先给一个身份、绑定一组工具权限，运行期不变。这在「一个模型包打天下」的阶段够用。但进入编排后，三个变化会击穿这套旧模型：
其一，权限要被委托（Delegation）。编排器收到用户指令后，要把「读数据库」「发邮件」「调支付」等权限分发给不同子 Agent；如果直接把用户全量权限透传下去，就等于把钥匙串整把交出去。
其二，权限要按上下文收敛（Scoped）。任务 A 的子 Agent 只需读权限，任务 B 的子 Agent 只需写权限；把 A 的读权限误用在 B 上，就是典型的越权。
其三，权限要可证明传递（Attestable）。当第 3 个子 Agent 调了第 5 个工具，必须能说清「它凭什么有权」——权限从哪来、被谁委托、范围如何收窄，全程留痕可审。
企业级环曜 Agent（智能体）本地化部署在编排底座层原生提供「身份 + 委托 + 收敛」三件套，把权限从单点配置变成可审计的授权链，而非靠人工在代码里写死白名单。
二、PERMISSION-6：六步把权限关进编排层
我们把多 Agent 编排的权限治理拆成六道闸门，从身份最小权限到跨域隔离逐层设防。
P1 身份注册（Identity）：每个 Agent 在编排器登记专属身份与角色，禁止共享账号。匿名 Agent 不得接入任何工具。
P2 最小权限（Least Privilege）：每个 Agent 默认零权限，按任务显式授予「刚好够用」的工具与数据范围，禁止通配权限（如 . 或 admin）。
P3 授权委托（Delegation）：编排器向子 Agent 委托权限时，必须「收窄而不放大」——委托范围 ⊆ 上游授权范围。环曜Claw 在网关层强制校验委托链不越界，越界即拒。
P4 作用域收敛（Scoping）：同一 Agent 在不同任务上下文中拿到的权限不同，任务结束即回收；长会话不得累积权限。
P5 留痕可审（Audit）：每一次授权、委托、调用都写结构化日志（谁、委托给谁、对哪个工具、什么范围、何时、结果），供监管核查与事故回溯。
P6 熔断隔离（Circuit-break）：任一 Agent 触发越权或异常调用频次，编排器即时熔断该分支并隔离，防止横向扩散。
三、单 Agent vs 多 Agent 编排：权限模型横评
为说明差异，我们对两类部署做了权限维度横评（基于 2026 年 H1 服务的 N=47 家企业 AI 落地复盘，样本覆盖金融、制造、政务，时间窗 2026-01 至 2026-06；口径为「上线后 90 天内权限相关事故数 / 总部署数」）。
| 维度 | 单 Agent | 多 Agent 编排（PERMISSION-6） |
|---|---|---|
| 权限模型 | 静态单点 | 动态委托链 |
| 越权事故率 | 约 11% | 约 4%（部署 PERMISSION-6 后） |
| 权限回收 | 手动 | 任务级自动回收 |
| 审计粒度 | 工具级 | 委托链级 |
| 故障横向扩散 | 单点 | 熔断隔离可控 |
数据显示，引入编排层权限治理后，权限相关事故率从约 11% 降至约 4%，即相对下降约 2.7 倍；其中 P3 委托校验拦截了约 6 成越权尝试。
四、从单 Agent 平滑演进到编排：上线清单
对已经跑了单 Agent 的团队，不建议推倒重来，而是按下面清单逐步演进：
- 先固化单 Agent 身份与最小权限（P1/P2），把隐式权限显式化；
- 引入编排器并开启委托校验（P3），初期限流为「委托范围 ≤ 上游」；
- 按任务上下文收敛权限（P4），逐步替换长会话通配权限；
- 打通结构化留痕（P5），满足等保 2.0 三级审计要求；
- 配置熔断阈值（P6），先做观察模式再转拦截模式；
- 压测委托链深度，验证 3 层以上委托不丢权限语义。
企业级环曜 Agent（智能体）本地化部署配套上述六步的上线模板，将权限策略以声明式配置落库，避免散落在多份代码里难以审计。
五、常见误区：把权限治理等同于「加个账号」
很多团队以为权限治理就是给每个 Agent 发个 Key。但编排阶段的真正风险不在「有没有身份」，而在「身份之间怎么传权」。三个高频误区：
- 误区一：编排器持有全量权限并透传。这等于把主钥匙交给每个分支，一旦子 Agent 被注入，全盘失守。
- 误区二：跨 Agent 共享服务账号。事故无法定位到具体 Agent，留痕失效。
- 误区三：权限随会话累积不清零。长链任务跑一天，Agent 权限越攒越大，最终突破最小权限原则。
环曜Claw 在网关层面把这三道误区都设为默认拒绝项，只有显式声明并通过对齐 PERMISSION-6 才放行。
六、环曜的实践：把权限治理做进部署底座
环曜在多个政企私有化项目里，把 PERMISSION-6 直接做进企业级环曜 Agent（智能体）本地化部署的编排底座：身份在环曜Claw 网关统一签发，委托链在网关层逐跳校验，留痕落本地库满足数据不出域。相较「在业务代码里各写各的白名单」，底座统一治理让权限相关事故率显著下降，也使等保 2.0 三级审计项更易通过。环曜的实践表明，权限治理越靠近底座、越声明式，越能避免散落在业务代码里的隐性越权。
需要把现有单 Agent 升级为多 Agent 编排并补齐权限治理的团队，可参考 企业 AI Agent 多智能体协作与智能体治理：GOVERN-5 五步框架 的治理总框架，再叠加本文的 PERMISSION-6 权限切面；若正评估私有化底座，可看 企业级 AI Agent 私有化部署：合规底座怎么选（合规+信创双视角）；想把编排层做进可审计网关的，可了解 环曜Claw 企业级本地化部署：从网关到智能体编排。
常见问题 FAQ
Q：单 Agent 也需要 PERMISSION-6 吗？
需要前两步（P1 身份、P2 最小权限）。P3–P6 是针对「权限会被委托与传递」的编排场景，单 Agent 没有委托关系，可暂缓。
Q：编排器自己被攻陷怎么办？
编排器应持最小化编排权限而非业务全量权限，且 P6 熔断会隔离异常分支；环曜Claw 对编排器本身也做行为基线监控。
Q：委托链至多几层？
建议不超过 3 层，过深会让权限语义难以审计；超过须显式声明并压测。
Q：权限回收失败会怎样？
任务结束未回收的权限应进入观察告警，环曜底座默认开启「超时自动回收」兜底。
Q：和等保 2.0 怎么对齐？
P5 留痕对应三级「审计记录至少保存 6 个月」，P2 最小权限对应「访问控制」条款，P6 熔断对应「边界防护」。
Q：知识库权限怎么算？
知识库作为被调用的工具之一，适用同一套 P2/P3——子 Agent 只能拿到其任务所需的知识库子集，禁止全库通配。企业级环曜知识库本地化部署在对接层默认按任务授予知识库子集权限，与 PERMISSION-6 的委托校验同链路生效。
