核心判断：组织无法预审 Agent 未来的每一个决定。可执行的治理路径是控制它能访问什么、按请求判断这次动作是否允许，并持续记录它实际做了什么。
01. 开场
一年前，你公司里大概有十几个 AI agent。今天，可能上千个。每个开发都有一个会写代码、会评审、会提交的编码 agent；分析团队搭了预测 agent，销售上了线索打分，客服自动分单，财务做对账。每个团队都看到机会、都跑得飞快。然后有一天，有人问了一句：现在到底哪些 agent，在碰我们的客户隐私数据？
02. 这个问题，你答不上来
要回答它，你得从几十个系统里把日志一条条拉出来、手动对齐，再祈祷没漏。因为每个 agent，记录方式、认证方式、访问数据的方式都不一样——没有一个地方能一眼看全。
03. 两难：放养还是锁死
也许你走了另一条路：把一切都锁死，不评审到位的 agent 一个都不许上。安全是守住了，但你比对手慢了半年，开发和用户怨声载道，有人甚至跳去了那些“真能用上 AI”的公司。两个极端都不行：放养，制造你测都测不了的风险；锁死，制造另一种风险——一边落后，一边人才流失。
04. 核心判断 · 治理的前提变了
为什么会这样？因为传统治理有个隐含假设：人来做决策，程序去可预测地执行。可 agent 不是这么工作的。它自主，它每一次的选择都可能不同，它还会把一堆工具链在一起，链成你光读代码根本预测不出来的样子。
05. 所以：控访问 + 监行为
于是这期最重要的一句话是：你没办法靠“审查它可能做什么”来治理一个 agent；你只能靠两件事——控制它能访问什么，以及监控它实际做了什么。这和我们讲过的 Agent 安全是一条线的两端：第六期讲的是运行时的沙盒边界，这一期，补上组织级的那张治理平面。
06. 第一部分 · 传统治理为什么接不住
先看看，旧的那套治理，为什么接不住 agent。
07. 它为静态应用而建
传统治理工具，是为静态应用造的。它看得见“谁登录了、调了哪个接口”，但它对 agent 的世界是瞎的——模型调用、工具调用、一个 agent 调另一个 agent，这些它一概看不见。
08. 服务账号这条老路
多数平台，是像管应用权限一样去管 agent：发一个服务账号、塞一把静态凭证、给一片宽泛的权限，就让它跑了。代价有两个：一是丢了问责——出事你不知道是谁、替谁干的；二是圈不住影响范围——一旦失控，波及面收不回来。
09. 要治理的对象，变多了
所以真正要治理的，已经不只是数据了，而是一个 AI 系统会碰到的每一样东西：模型、MCP 服务器、技能，还有智能体本身。这就需要一层统一的执行面：每一次模型调用、每一次工具调用、每一次交互，都先按策略评估、再执行，执行完留下痕迹。Databricks 的做法，是把它那套从二一年就在用的数据治理平台，直接扩展到管这些新对象——这正是下面四根支柱。
10. 第二部分 · 支柱一 · 委派访问
第一根支柱，叫委派访问。一句话：agent 必须在一条清清楚楚的权限边界里干活——它替谁干，以及，它能碰到什么。
11. 身份要端到端地传
关键，是别再用那个共享的服务账号。让身份从头传到尾：从提问的那个用户，一路传到 agent 真正取出的那一行数据。agent 实时继承调用它的用户的权限——你访问不了的那张表，替你干活的 agent，也照样访问不了。
12. 两个身份，都要留痕
而且每一个动作，都对着两个身份记账：真正触发请求的那个用户，和代他行动的那个 agent；记下碰了哪些表、跑了什么操作、什么时候。出事的时候，你能精确说出：这一步从哪来、是谁授权的。
13. MCP 也纳进同一套
外部的能力也一样。把那些 MCP server——比如 GitHub、Jira、Slack——当成普通的受管资源，登记进同一个目录里：权限、凭证、审计，一个地方统一管，而不是每接一个就散一处。
14. 运行时策略：这一次该不该
但光知道“这个 agent 被允许调 GitHub”，并不等于知道“它这一下到底该不该删文件、该不该合并一个 PR”。所以还要一层运行时策略：每次工具调用之前都评一遍——看工具名、看参数、看调用者是谁，然后给出三种结果之一：放行、拒绝，或者要一个人来确认。判成拒绝，这次调用就被拦下。
15. 三层各管一段
再加上模型层的护栏：实时检查进出推理的内容，进来的扫隐私数据、扫越狱注入，出去的查幻觉、查敏感信息，内联在每个请求上跑，而且出错就关、绝不放过。于是三层合起来各管一段：权限管“谁能调什么”，运行时策略管“这一次具体调用该不该过”，护栏管“什么内容能流进流出”。
16. 第三部分 · 支柱二 · 数据即治理
第二根支柱，也是最多人漏掉的一根：AI 治理，本质上是数据治理。
17. 行为由数据决定
有个原则，多数 AI 治理工具都没抓住：一个 agent 的行为，几乎完全由它能访问的数据决定。它能读到什么、那份数据有多新、敏感字段有没有打码——这些根本不是 AI 治理问题，它们是数据治理问题。分开来治，你会得到两个都不完整的系统；合起来治，治理才会自我强化。
18. 审计要完整
具体怎么做？第一，审计必须完整——而且新出的 AI 法规，正让这条变成硬要求：你得能证明你的 AI 系统做了什么、被喂了什么、又产出了什么。所以把每一次模型调用的完整内容——原始的提示、原始的返回、token 数、延迟——都写进表；把每一次访问操作，都进审计日志。
19. 审计要查得动
第二，审计数据有没有用，取决于你查不查得动。把 agent 的运行轨迹，就存成普通的表，用你查别的数据时一模一样的 SQL 去查。出了怪事，要用的数据其实早就在那了：上周哪些 agent 访问了某个服务、每个团队花了多少、有没有哪个 agent 碰过凭证或者隐私数据——再往前一步，你还能把 agent 的行为，直接 join 上业务结果。
20. 数据还得可信
第三，你得知道：agent 当初依赖的那份数据，本身靠不靠谱。完整的审计，只告诉你 agent 访问了什么，不告诉你那数据好不好。配上数据质量监控——盯新鲜度、盯完整度——你就能从“这个 agent 答错了”，升级成“这个 agent 查的那张表，早就被标记成过期了”。
21. 已有的数据治理，自动变成 AI 治理
再加一层数据分类：自动扫描、给敏感列打标——隐私数据、医疗合规、欧盟法规这些——而这些标签，直接喂回访问控制。于是一个打了码的列，不管是哪个 agent、哪个框架来要，它都还是打码的。你已经有的那套数据治理，就这样自动变成了你的 AI 治理。
22. 第四部分 · 支柱三 · 成本也要治
第三根支柱，成本智能。每一次模型调用都有价钱。可大多数企业，根本不知道是谁在把账单往上推、推在了什么用途上、到底有没有产出——直到发票来了，财务对着一个谁都没预料到的数字发愣。
23. 把成本 join 上结果
根因不是流程坏了，是基础设施缺了：没有一个统一的计量层看见所有 AI 流量，没有归因标签，也没有和访问控制并排坐着的预算控制。补上之后，你就能把成本和结果连起来算账：一个 agent 花两百块、带来五万的合格管线，那是捡了便宜；一个 agent 花两百块、对着过期数据空转，那是纯浪费。不把成本 join 上结果，你压根分不出这两者。再设上每月预算阈值和告警，问题就能在变成问题之前被你看见。
24. 第五部分 · 支柱四 · 治理跟着资源走
第四根支柱，开放与互通。每个企业的治理策略，迟早撞上同一道坎：哪天来了个新团队选了别的框架，或者某个厂商出了更好的模型。如果你的治理是焊死在今天这套工具上的，那你就上了跑步机——每换一个框架，就是一次新集成；每换一个模型，就是一套新策略。
25. 框架无关，规则定义一次
破法是：治理不能只活在 agent 那一层，它得活在 agent 要访问的数据和服务里。这样，一个用某框架搭的 agent、和一个用另一个框架搭的 agent，查的是同一套目录、调的是同一批受管资源、走的是同一个网关。框架，是无关的——治理跟着资源走，不跟那段调用它的代码走。规则定义一次，后面来的每个 agent，自动就继承了。
26. 落到你自己的盘子里
这套思路，对我们自己做内容线、做工具链，一样成立。你不可能去预审一个 agent 的每一个动作；你能做的，是给它最小够用的权限，把它能调的工具、能读的数据，全收进一张可审计的平面，每次调用都留痕，再让成本和结果挂上钩。能力放开的同时，边界和留痕必须同步跟上——这跟第六期讲 Agent 安全、第十一期讲上线门禁，是同一条线；这一期，补上的是“组织级治理平面”这一环。
27. 结论
参考资料与延伸阅读
- Databricks AI governance guide
- Unity AI Gateway
- Govern an MCP service
- NIST AI Risk Management Framework
- OpenAI：Running Codex safely
Unity Catalog 与 Unity AI Gateway 作为一种落地案例出现，不构成产品推荐；部分 service policy 能力仍可能处于预览阶段。资料核验日期：2026-08-23。