AI治理：Agent 有了规则，为什么还是不敢放权？

AI治理不只是给模型写一套使用规范。企业让 Agent 进入真实流程前，还要解决身份、最小权限、审批门槛和可追责证据；这也是智能体安全最容易被忽略的部分。

这里说的 AI治理，不是再写一份泛化制度，而是把 Agent 的身份、权限、审批与审计写进真实的执行链。

前几篇我们一直在追问同一件事。

企业要不要急着招 FDE？先看有没有值得工程化改造的业务场景。

AI 已经读完公司所有文档，为什么还是不懂业务？因为它缺的不是更多段落，而是企业自己的对象、关系、规则和权限。

SOP 全喂给 AI，为什么还是干不了活？因为人类靠经验补齐的条件，必须被写成机器能执行、能授权、能验证的工作契约。

走到这里，很多项目会碰上一道更现实的门槛：

Agent 明明已经知道该怎么做，企业还是不敢让它真的做。

它能查订单，能算退款，能生成审批单。可一旦涉及改库存、退钱、发客户邮件，所有人又开始问：

它到底是谁？
它代表谁做这件事？
谁允许它调用这个接口？
它最多能动哪些订单、多少钱、多少次？
发生错误以后，能不能知道是谁批准的？

这不是模型聪不聪明的问题。

这是授权链没有建起来。

会调用工具，不等于有资格完成动作

还是拿退款 Agent 举例。

项目组已经把退款政策、订单系统、支付接口和客服工作台接好了。Agent 可以查到订单状态，也能根据规则算出建议退款金额。

演示看起来很完整。

但“算出 200 元”与“把 200 元退回去”，中间隔着一整套责任边界。

前者是判断或建议，后者是资金动作。

前者错了，客服可以改；后者错了，钱已经离开账户，可能还会触发对账、投诉和合规问题。

如果系统给 Agent 一个权限很大的服务账号，它甚至可能同时拥有查询、写入、退款和导出数据的能力。模型只要选错一次工具，影响就不再是一段文字写错，而是一次真实的业务动作。

图 1｜授权不是一个开关，而是一条从委托到证据的执行链。

OWASP 把这类问题概括为 Excessive Agency，也就是过度代理能力。根因通常不是一个，而是三类叠加：给了太多功能、太多权限，或者太高的自动化程度。OWASP 的建议很具体：只提供任务需要的扩展和功能，尽量不用开放式万能接口，在下游系统执行最小权限，并对高影响动作要求人工批准。

所以第一条原则是：

Agent 能看见什么、能调用什么、能改变什么，必须拆成三张不同的清单。

企业最容易漏掉的，是“它代表谁”

人类员工登录系统时，组织通常知道他的账号、部门和权限。

Agent 却经常被塞进一个公共服务账号里。

这个账号可能有读订单、改状态、创建退款单，甚至直接退款的权限。系统看到的是“服务账号调用了接口”，却看不到：

哪个用户发起了请求；
哪个 Agent 实际执行了动作；
它代表谁在做这件事；
这次调用属于哪一个任务；
权限是临时委托，还是账号本来就一直拥有。

出了问题，日志里只剩一句“系统操作成功”。

NIST NCCoE 在 2026 年发布的 Agent 身份与授权 Initial Public Draft（初始公开草案）里，把身份识别、授权、审计、不可抵赖和提示注入控制放在同一组问题中。它的重点不是发一张“Agent 安全合格证”，而是提醒企业：Agent 一旦接触多个数据、工具和应用，就不能只讨论模型输出是否安全。NIST 原文

IETF 的 OAuth 2.0 Token Exchange 标准，也早就区分了“冒充”和“委托”。委托意味着：用户仍是被代表的主体，Agent 保留自己的行动者身份，只是在用户授权范围内代为执行。令牌可以同时记录 subject 和 actor，留下委托链。RFC 8693没有专门为 Agent 设计，但它提供了一个很重要的工程常识：

代表别人做事，不等于把自己伪装成那个人。

如果每个 Agent 都用一个高权限公共账号，组织就很难做到最小权限，也很难把责任还原给真正的委托人和执行者。

一条完整的授权链，至少有六层

企业不需要先发明一套玄学术语，可以先把一次动作按六个问题拆开：

图 3｜六层授权链：从“谁委托”一直追到“谁批准、如何复盘”。

第一层：谁委托？

是客户本人、客服主管、财务负责人，还是一个定时任务？

“帮我处理退款”和“自动清理所有退款申请”不是同一类委托。委托人的身份、任务范围和有效时间都要有记录。

第二层：谁执行？

执行者是哪个 Agent、哪个版本、哪个工作流实例？

同一个模型可以被不同 Agent 使用。模型名称不能代替 Agent 身份，更不能代替一次具体运行的身份。

第三层：能调用什么能力？

查询退款资格、计算金额、创建待审批单和正式退款，应该是四个动作，而不是一个“万能退款”接口。

能调用接口，不代表四个动作都开放。

第四层：能作用于哪些资源？

它可以查所有客户，还是只能查当前工单？

可以改任意订单，还是只能改属于当前客服组的订单？

可以读取完整身份证号，还是只能读取经过脱敏的字段？

最小权限不仅是“读还是写”，还包括对象、字段、金额、时间和次数。

第五层：什么条件下允许？

同一个退款动作，在不同条件下风险完全不同。

订单是否已签收？金额有没有超过上限？是否已经重复申请？支付和物流状态是否冲突？当前政策是否仍然有效？

这些条件能写成确定性规则的，就交给规则引擎或业务系统检查，不要让模型每次临场猜。

第六层：谁批准，留下什么证据？

低金额、可回滚的动作可以按策略自动放行；高金额、不可逆或跨系统的动作，必须把事实、规则、风险和建议动作交给责任人确认。

批准不能只留下一个“同意”按钮。至少要记录审批人、策略版本、工具参数、数据来源、执行结果和回滚点。

把六层连起来，才是一条能追责的授权链：

委托主体 → Agent 身份 → 能力范围 → 资源范围 → 条件门槛 → 审批与证据。

真正落地时，别把这六层只画在架构图上。先拿一条退款流程，把它写成一张权限矩阵：

动作	身份/能力	资源范围	放行条件	是否审批	关键证据
查退款资格	`refund-reader`	当前工单对应的订单	订单号和客户身份已匹配	否	数据来源、查询时间
算建议金额	`refund-evaluator`	当前订单和适用政策	商品、签收、时间窗口无冲突	否	政策版本、计算输入
建待审批单	`refund-drafter`	当前订单，金额不超过上限	不直接写支付状态	由客服复核	草稿内容、规则命中项
执行退款	`refund-executor`	单笔订单、一次性调用	金额和状态满足硬规则	高风险时必须人工	审批人、工具参数、流水号

这张表的价值，是把“Agent 很谨慎”改成系统能检查的条件。谁能查、谁能算、谁能创建草稿、谁能真正写钱，每一个动作都可以单独收回。

权限不能只写在提示词里

有些团队会把下面这句话写进系统提示词：

你只能处理低风险退款，超过 200 元必须请求人工批准。

这句话有用，但它不是权限控制。

模型可能忘记，输入可能被注入，工具参数可能被绕过，服务账号也可能拥有更大的真实权限。

NIST 的零信任架构把策略决策和策略执行分开：策略执行点负责启用、监控和终止主体与资源之间的连接，并按最小权限限制可见性和可访问性。NIST SP 800-207

迁移到 Agent 上，就是一句朴素的话：

模型可以提出动作，但真正执行动作的系统必须重新检查。

检查主体是谁、代表谁；检查资源是否在范围内；检查金额、状态、次数和风险；检查是否需要审批；检查令牌是否过期或被撤销。

这叫完整中介。OWASP 也明确建议，授权要在下游系统实施，不能依赖 LLM 自己判断“我有没有权限”。

因此，一个更稳妥的结构是：

模型负责理解意图和生成计划，策略层负责批准或拒绝，业务系统负责执行和记录。

模型越聪明，越不能把它当成唯一的门卫。

从只读到自动执行，先过四道门

企业不必在“完全不让 Agent 做事”和“一次性全自动”之间二选一。

更实际的做法，是把放权拆成四个阶段。

图 2｜能力越强，越要把“自动”拆成可退回的台阶。

阶段	Agent 可以做什么	必须留下什么	进入下一阶段前要证明什么
观察	读取授权范围内的数据、解释政策、指出证据缺口	数据来源、权限边界、答案完整性提示	事实基本准确，能承认自己看不到什么
草稿	生成建议、审批单、客服回复和动作计划	建议依据、规则版本、待确认字段	人能快速复核，失败不会直接改变生产数据
低风险执行	执行可逆、金额低、对象范围小的动作	工具、参数、策略判定、结果状态	影子运行稳定，越权和重复调用能被拦截
高风险协作	准备退款、改订单、发信等高影响动作，由责任人批准后执行	委托链、审批人、风险解释、完整日志、回滚点	业务、安全和审计共同定义门槛

这套路径的关键不是“多审批几次”，而是让每一级放权都有进入条件和退出条件。

如果 Agent 在观察阶段经常把“没有权限看到”说成“系统里没有”，就不应该进入自动执行。

如果它在草稿阶段经常漏掉审批所需字段，就不应该让它自动创建正式单据。

如果低风险执行阶段出现重复调用或参数越界，就应该收回权限，回到影子运行。

权限扩大必须由运行证据触发，而不是由一次演示触发。

OpenAI 的 Agent 构建指南也建议按读写能力、可逆性、账户权限和财务影响给工具分级，并对高风险动作和失败阈值设置人工介入。官方指南

审计不是把聊天记录存下来

很多系统说自己“可审计”，实际只是保存了用户和 Agent 的对话。

这还不够。

真正需要复盘一次退款动作时，至少要能回答：

谁发起了任务，原始委托是什么？
哪个 Agent、哪个版本、哪个工作流实例执行了它？
Agent 读取了哪些数据，分别来自什么系统，是什么时间点？
当时使用的是哪版政策、规则和 Ontology？
它调用了哪些工具，传入了什么参数，调用了几次？
策略层为什么放行或拒绝，是否发生降级或重试？
谁批准了高风险动作，批准时看到的事实是什么？
最终系统状态是什么，能不能回滚？

这也是为什么研究 Agent Audit 时，审计对象不只是模型，而是工具代码、部署配置、凭证和 MCP 配置。作者在一个 22 个样本、42 个标注漏洞的基准上测试了安全分析系统，但这个规模不能用来推算企业总体漏洞率；它真正提醒的是，上线评审不能只做 prompt review。Agent Audit

还有一种更隐蔽的审计失败。

系统确实把不该看的材料过滤掉了，Agent 却没有告诉用户“我的答案只基于授权范围内的证据”，而是拼出一段听起来完整的结论。

Partial Evidence Bench 把这种现象单独拿出来评测。研究显示，静默过滤可能导致危险的“假完整”；显式报告证据缺口，才能避免把“我没看到”说成“没有这回事”。论文原文

所以，合格的 Agent 不只要会说“这是结论”，还要会说：

“这是我在当前权限和证据范围内能确认的结论，下面这些信息我没有权限看到。”

承认边界，不是能力不足，而是企业系统最需要的诚实。

但审计也不是“记录越多越安全”。

NIST SP 800-53 的审计控制要求组织根据安全、隐私和审计目标选择事件，定期复查日志集合，同时提醒审计记录本身可能暴露个人信息。NIST SP 800-53

换句话说，企业要记录的是足以还原责任链的事件，不是把所有客户原文和身份证号永久堆进日志库。一个够用的 Agent 动作事件，至少可以长这样：

task_id / request_id
委托主体 / Agent 身份 / 运行版本
动作 / 资源 / 字段范围
策略版本 / 判定结果 / 审批人
工具参数摘要 / 数据来源摘要
执行状态 / 重试次数 / 回滚编号

敏感字段应脱敏或只保存不可逆摘要，日志读取本身也要有权限和留痕。否则你为了追责 Agent，又造出一个谁都能查的隐私数据库。

不要把授权判断完全交给模型

有人会说：现在的模型已经很强，让它根据任务自己生成最小权限策略，不就行了吗？

问题是，最小权限不是一句“尽量少给”就能解决的。

2026 年的 AuthBench 用 120 个现实终端任务测试编码 Agent 的权限边界推断。研究发现，模型会同时出现两种错误：遗漏完成执行链所需的权限，又授予没有必要的敏感访问；增加推理时间也不能自动消除这种错配。AuthBench

另一篇关于工具调用前授权的研究，把问题称为 pre-action authorization：在每一次工具调用真正执行前，用声明式策略同步判断，并生成可验证的审计记录。Open Agent Passport

这条思路也在继续往“工具中间过程”推进。MiniScope 试图从工具调用之间的关系构造权限层级，在合成评测中报告了 1—6% 的延迟开销；ToolPrivacyBench 则专门检查多步任务里，Agent 有没有把不必要的私密信息传给中间工具。MiniScope ToolPrivacyBench

它们共同提醒一件事：任务最后成功，不代表权限使用正确。评测要同时看最终结果、每次工具参数、数据流向和后端审计日志。

它不是说每家公司都要照搬某个论文原型。

更重要的启示是：

Agent 可以参与计划，但不能独自定义自己的权限。

权限应该由业务负责人、安全团队和系统策略共同定义，再由执行点强制检查。模型的作用，是把自然语言需求翻译成结构化计划，解释为什么需要某个动作，发现缺少的信息，并在超出边界时请求人接管。

授权不是安全团队一个人的流程

如果权限矩阵只由安全团队填写，最后很容易变成一份没人愿意用的合规表。

业务负责人最清楚一次错退、错发和错改的代价；工程团队知道工具真实会写入什么；安全和身份团队负责令牌、策略和最小权限；审计与合规团队关心证据能不能复盘；一线员工则知道什么情况必须马上接管。

NIST AI RMF 把这件事拆成 Govern、Map、Measure、Manage 四个持续循环，并明确要求定义人类—AI 配置中的角色、人工监督、风险容忍度、测试和生产监控。NIST AI RMF Core

这给企业一个很实用的分工表：

角色	必须回答的问题	不能把什么甩给 Agent
业务负责人	错一次的代价、可接受的自动化范围是什么？	“你自己看着办”
产品/工程	每个动作的输入、输出、副作用和幂等性是什么？	“接口能调就算完成”
安全/身份	谁委托、谁执行、令牌和资源范围怎样收窄？	“公共账号先跑起来”
审计/合规	哪些事件必须留证，谁可以查看和复核？	“把所有聊天记录都存下来”
一线操作	哪些异常必须停手，接管时需要什么上下文？	“特殊情况请人工处理”

中国网信办 2026 年发布的《智能体规范应用与创新发展实施意见》，也把安全、可靠、可信贯穿研发、部署和推广全过程，并提出研究权限管理、行为控制、风险监测和人机协同审核。官方文件

这不是要求所有企业马上建一套庞大的治理委员会，而是提醒我们：Agent 放权本质上是业务责任、技术策略和运行证据的共同决策。

企业现在就能做的 8 个动作

如果团队还没有准备好建设完整的 Agent 权限平台，可以先把一条业务流程做小：

给 Agent 单独的身份。 不要直接复用一个长期高权限公共账号。
拆分工具。 查询、计算、创建草稿、正式写入使用不同接口。
写资源范围。 明确它能看哪些对象、字段、金额、时间窗口和次数。
把硬条件下沉。 金额、日期、状态、次数和权限交给规则或业务系统校验。
设置风险分级。 读、写草稿、可逆写入、不可逆动作不要用同一套门槛。
设计人工接管。 缺数据、规则冲突、超金额、重复申请、连续失败时必须停下来。
记录动作证据。 保存委托人、Agent、工具、参数、策略版本、审批、结果和回滚信息。
用真实失败决定扩权。 先影子运行，再低风险放行；每次扩权前复盘越权、误判和重试。

这八件事看起来不像“训练模型”，却决定了 Agent 能不能进入生产。

企业真正买到的，也不是一个会自动点按钮的数字员工。

而是一套能够说明“谁在什么条件下，以什么身份，依据什么规则，做了什么动作，并且出了问题可以追溯”的执行系统。

最后，先别问 Agent 敢不敢做

很多企业问：“什么时候可以让 Agent 自动退款？”

我更建议先换一个问题：

这一次动作的授权链，是否已经比模型的自信更可靠？

如果委托人不清楚，Agent 身份不清楚，资源范围不清楚，审批门槛不清楚，日志也不能还原全过程，那么模型越会做事，风险越大。

反过来，如果身份、能力、资源、条件、审批和证据都能被系统检查，企业就不必把自动化理解成一次性放权。

先让它观察，再让它写草稿；先让它做低风险、可回滚的动作，再讨论高影响操作。每一级权限，都用真实运行证据换回来。

这就是 Agent 进入生产前真正要补的那一层：

不是更多提示词，而是更清楚的授权。

上一篇我们讨论了怎样把 SOP 写成工作契约。下一篇可以继续追问：权限已经给了，企业怎样用评测和运行证据决定要不要继续扩大？

这里是第四生产力，专注企业级 AI 工程实践。

本文依据与延伸阅读（精选）

本文正文中的关键事实和判断，主要依据以下标准、官方文件与研究；完整资料清单保留在项目研究底稿中。