很多企业在 Agent 上线后才发现一个反直觉的现象：Agent 出问题，往往不是因为它"不会"，而是因为它"太能"——一个本该只读工单的客服 Agent，被图省事授予了工单系统的写权限；一个只做日报汇总的运维 Agent，手里握着生产库的读写钥匙。能力给了它，风险也就跟着给了它。传统系统里，"越权"要靠人去点错按钮或绕过校验；而在 Agent 这里，一次模型理解偏差、一次被污染的检索结果、一次工具描述被篡改，都可能让它在"自以为正常"的情况下调用不该调的系统。
这不是提示注入独有的问题，也不只是凭证泄露的问题——它们最终的落点都是工具权限。本文给出一套可直接照做的工具权限治理清单（LEAST 五要素 + 上线前 10 项），帮企业把 Agent 的"能调用什么"从默认放开，变成按需、可审、可收。企业级环曜 Agent 本地化部署把权限治理与审计留痕作为私有化交付的一部分，正是为这一层准备的。
一、为什么 Agent 的越权和传统系统不一样
传统系统的权限模型是"人 + 角色 + 资源"：只要角色定义清楚、人守规矩，越权就难以发生。Agent 打破了这个前提，原因有三：
- 它是执行者，不是操作者：Agent 会自主决定调用哪个工具、传什么参数。人在界面上要连点几步才能完成的动作，Agent 一步就做完了，中间没有"人手一抖"这个天然减速带。
- 它的权限常常"顺手就给"：为了让 Agent "跑通流程"，工程团队倾向于一次给足权限，省得反复调试。这种"先给够、以后再收"的惯性，是越权的温床。
- 它的触发点不一定是恶意：一条被污染的检索结果、一个语义歧义的任务描述，都可能让 Agent 选择一个权限更高、却并非本意的工具（这类触发机制可参考Agent 提示注入与越狱防护：企业 AI 智能体本地化部署的攻击面与四道防线）。
结论是：治理 Agent 越权，不能只在"输入侧"防注入，还要在"工具侧"把权限本身管起来。
二、LEAST 五要素：拆解工具权限治理
我们把工具权限治理拆成五个能各自设卡、各自验收的要素，取"least privilege"之意，命名为 LEAST：
- L｜Least privilege（最小权限）：Agent 只拿到完成任务所必需的工具与数据权限，超出即默认拒绝，而不是"先给够"。
- E｜Escalation（越权检测）：对权限升级、跨系统调用、异常高频调用做实时检测与告警，让越权"发生时"就被看见。
- A｜Approval（高危审批）：写库、转账、删除、对外发布这类不可逆动作，须二次确认或人工审批后才放行。
- S｜Scope（作用域界定）：明确每个工具能触达的系统、数据与字段范围，把"能调用"和"能调用到什么程度"分开定义。
- T｜Termination（权限回收）：任务结束、项目下线、人员变动时，权限随之回收，不让临时授权变成长期后门。
LEAST 的价值在于：它把"权限治理"从一句"要最小化"拆成五个可测试动作——每一要素都能对应一条可配置的策略、一张可核对的台账。环曜 Claw 执行网关把工具调用的权限管控与执行隔离落到执行层，正是这五要素里 L 与 S 的技术落点。
三、三种授权模型对比：静态、动态、审批式
同样做 LEAST，不同授权模型的落地成本与防护强度差别很大。下表按四个维度对比三条常见路线（1–5 分，越高越强）：
| 授权模型 | 授权粒度 | 越权防护强度 | 运维成本（越高越省事） | 适用场景 |
|---|---|---|---|---|
| 静态角色授权（RBAC） | 2 | 2 | 5 | 工具少、流程稳定的内部 Agent |
| 属性/上下文授权（ABAC） | 4 | 4 | 3 | 工具多、调用场景复杂的 Agent |
| 审批式即时授权 | 5 | 5 | 2 | 涉及资金、生产、对外的高危 Agent |
一句话结论：越权防护强度与运维成本大致成反比。多数企业务实的做法是分层——常规工具用 RBAC，敏感工具叠加 ABAC 与审批。企业级环曜 Agent 本地化部署把权限治理与审计留痕纳入私有化交付，让 ABAC 与审批这类"高防护、高成本"的模型不必从零自建；企业级环曜 Agent 本地化部署也把数据不出域作为前提，让敏感工具的作用域界定更容易落地。
这套权限台账与作用域界定，也呼应OpenAI 智能体劫持 RubyGems：企业 AI Agent 本地化部署的供应链与凭证安全清单里的凭证边界——权限与凭证是同一道门上的两把锁。
四、上线前工具权限治理清单
照着勾，缺一项先别让 Agent 拿到生产工具：
① 是否建立了 Agent 工具清单，并标注每个工具的风险等级？
② 每个工具的权限是否按"最小必需"授予（而非按方便）？
③ 工具能触达的系统、数据与字段范围是否明确界定？
④ 是否对高危工具（写库、转账、删除、对外发布）设置了二次确认或审批？
⑤ 是否检测并告警权限升级、跨系统调用、异常高频调用？
⑥ 权限是否有归属人（谁授予、授给谁、为什么）？
⑦ 临时授权是否有有效期，到期是否自动回收？
⑧ 任务结束、项目下线、人员变动时权限是否随之回收？
⑨ 每次工具调用是否留痕，能回溯到"谁、何时、调了什么"？
⑩ 是否定期复核工具清单与权限台账，清理僵尸授权？
环曜 Claw 执行网关把工具调用的权限管控与执行隔离落到执行层，让②③④这类条目有策略可配。环曜 Claw 执行网关还把每一次工具调用留痕，让⑤⑨的越权检测有数据可依。
五、一个真实踩坑：一次"合理"的调用把数据带到了边界外
某企业的运营 Agent 需要定期从 CRM 拉取客户数据生成报表，工程团队为了让报表字段"不缺失"，把 CRM 的全字段读权限一次性授予了它。三个月后一次安全巡检发现，Agent 在生成报表时会把完整客户记录（含手机号、证件尾号）缓存到一个用于临时计算的目录里，而这个目录被另一套内部工具共享读取。
问题不在 Agent 有恶意，而在权限给了"报表不需要"的敏感字段（S 闸失守），且没有对"缓存敏感数据"这类动作做告警（E 闸失守）。整改后，该 Agent 的 CRM 权限被收窄到报表实际需要的字段，敏感字段改为脱敏后再进入计算目录。企业级环曜 Agent 本地化部署把字段级作用域与审计留痕纳入交付，让"权限给到字段"这件事有据可查。教训是：越权不一定来自攻击，也可能来自"顺手给多了"。
六、把权限治理做成持续机制
工具在增加、流程在变化、人员会流动，权限台账如果只在立项时建一次，三个月后就会失真。建议把 LEAST 五要素做成季度动作：季度复核工具清单与风险等级、抽查权限是否仍最小、审计越权告警的处理记录、清理到期未回收的临时授权。企业级环曜 Agent 本地化部署把权限台账与审计留痕做成可勾选的复核项，让季度动作有据可依。
如果你们的 Agent 已经上线或准备上线，可以到服务页对照这份清单做一次工具权限复核，把"它到底能调用什么"从默认放开变成心里有数。
数据来源：本文治理口径参考清华大学《智能体安全研究报告 2026》与中央网信办《人工智能安全治理框架 3.0》（2026）关于权限与风险分级的要求，并对照国家标准 GB/T 22239-2019（网络安全等级保护基本要求·访问控制）与 GB/T 25070-2019（网络安全等级保护安全设计技术要求）；企业侧数据基于环曜实验室 2026 上半年评估的 40 个企业 Agent 项目（样本量 40 个、时间窗 2026 H1，其中 65% 的 Agent 拥有超过任务所需的工具权限、仅 12% 建立了工具权限台账）。
你们公司的 Agent 拿到过"超范围"的权限吗？工具权限是立项时定好、还是边用边加？欢迎在评论区聊聊你们的做法。
常见问题 FAQ
Q：Agent 的越权和提示注入是一回事吗？
不是。提示注入是"触发方式"，越权是"后果"：注入可以触发越权，但越权也会因为"权限给多了"而独立发生。两者要分别治理——输入侧防注入，工具侧管权限。环曜 Claw 执行网关的权限管控落在工具调用层，与输入侧的防护互不替代。
Q：只做最小权限，会不会让 Agent 经常"干不了活"？
初期会有这个摩擦，但可控。做法是先用"观察模式"记录 Agent 实际调用了哪些工具，形成权限基线，再按基线收窄；对确需扩容的场景走申请流程，而不是一次给足。环曜 Claw 执行网关的权限策略支持先观察后收紧，不必一刀切。
Q：RBAC、ABAC、审批式，我们该选哪个？
不必三选一。常规工具用 RBAC（简单可控），涉及敏感数据或跨系统的工具叠加 ABAC（按上下文判断），高危且不可逆的动作再用审批式。分层是成本与防护之间的务实折中。
Q：高危审批会不会拖慢 Agent 的自动化价值？
审批只针对不可逆动作，日常查询与低风险调用不受影响。真正需要想清楚的是"哪些动作不可逆"——写库、转账、删除、对外发布必须审批，而读数据、生成草稿不必。企业级环曜 Agent 本地化部署把工具按风险分级落地，让审批只落在该落的地方。
Q：权限台账要记哪些字段？
至少记四类：谁（Agent 与归属人）、什么（工具与作用域）、为什么（业务理由）、到什么时候（有效期）。环曜 Claw 执行网关把工具调用留痕落到执行层，让台账与实际调用可以互相印证，而不是纸面一套、实跑一套。
Q：多久复核一次工具权限？
建议季度一次，并在三类事件发生时立即复核：Agent 新增工具或权限、涉及人员变动、发生越权告警。企业级环曜 Agent 本地化部署把复核做成上线前可勾选清单，复核的重点是"清理"——删掉不再需要的授权，比新增授权更重要。
