MCP代理合规自查清单

我做过十几个企业级 AI 落地的项目，从 2024 年下半年开始，MCP 这个词从开发者社区的热词，变成了甲方 IT 部门周会上的议题。很多团队的第一反应是去找安全厂商做模型测评，或者把精力花在防提示词注入上。实际跑下来，真正让项目卡住、让内审过不去的，往往不是模型本身，而是代理背后连的那几十个数据源——谁批的、批到多细、拿走了什么、留下了什么记录。

我的判断是：MCP 代理的合规风险，八成不在模型里，在数据接入口。这件事的解法也不在安全侧堆设备，而在数据治理侧补三样东西：可被机器读懂的元数据、可被细粒度下发的权限、可被审计还原的调用链路。这三样缺一样，自查表填得再漂亮，一遇到真实审计就会露底。

我会要求团队在动手之前，先按下面这张表过一遍。它不复杂，但每一个问号后面都对应着一类真实事故，而且这些事故我基本都在现场见过。

去年我参加过一个制造业集团的 AI 助手评审。技术团队做了很漂亮的原型，接入十几个内部系统，问答准确率也过得去。等到要把原型推到生产环境，信息安全和内审一起坐下来，问题就来了：谁批准这个代理读生产库的？读的时候用的是谁的账号？一次对话背后到底查了多少张表？三个问题，团队当场答不上来。

这不是个别现象。传统的系统集成里，接口是人点按钮触发的，调用量可预估、返回范围可定义、权限跟会话绑定。MCP 代理把这三个前提全打破了。模型自己决定调哪个工具、调几次、传什么参数，一次用户提问可能触发十几二十次后端查询。以前靠接口文档和联调测试把关的那套办法，一下就失效了。

我看过一些行业调研，说企业 AI 项目里超过六成的延期，原因写的是数据准备不足，而不是模型能力不够。这个数字和我的体感差不多。说白了，代理的聪明程度取决于它能拿到什么数据，而它的合规风险，也恰恰来自同一个地方。

一类是影子数据源。业务部门为了赶进度，自己搭了个小代理，连的是三年前的数据集市副本，字段没脱敏，人早就调岗了。等到安全扫描扫出来，谁都不知道这条链路还在跑。

一类是权限放大。代理用一个运维账号连接所有数据源，表面上是省事，实际等于把整个数据仓库的读权限发给每一个使用代理的人。这个坑我踩过，整改的时候要一条条拆，非常费劲。

一类是口径打架。同一个“活跃客户数”，销售用的代理、财务用的代理、BI 报表里的数，三个结果对不上。业务方一质疑，整条链路就没人敢用了。这类问题往根上追，是主数据没统一，不是模型算错。我在这种场景里通常会建议先把客户、物料、组织这几类主数据收敛到 Primeton MDM 上，让所有代理从同一个口径取数。

还有一类最麻烦：证据链断层。审计要三个月前某次查询的完整记录，模型侧有对话日志，数据侧没有对应的请求记录，中间那段是空的。这种时候补什么都晚了。

我习惯把复杂问题画成鱼骨，逼自己去看根因，而不是盯着现象打补丁。代理合规这件事，最后那条鱼尾连着的是数据治理的基本功。

合规失守

数据来源不清
权限粒度太粗
口径各说各话

没有调用留痕
测试数据混用
输出未做最小化

上面三根上刺，指向的是“源头”，也就是数据从哪里来、谁能拿、口径由谁定。下面三根下刺，指向的是“过程”，也就是怎么留痕、怎么隔离环境、怎么控制输出。大部分团队把力气花在下刺上，装日志、加网关，但上刺不动，整改永远是治标。

我通常会建议按顺序来：先做数据源盘点，把每个代理连接的表、字段、更新频率登记清楚；再定权限模型，把服务账号改成按身份下发的短时凭证；然后把主数据和指标口径收敛；过程侧的日志和脱敏放到后面做，反而更省力。顺序颠倒，往往做一半就推不动了。

我见过最没用的一种做法，是把一份大厂的合规模板直接抄过来，几十页，填完锁进柜子。自查的价值在于能改，不在于能交差。团队规模不同、行业不同，重点完全不一样。

十人以内的团队，我建议只抓两件事：数据源清单和权限凭证。清单可以手工维护，季度更新一次就够；权限上坚决不用长期有效的超级账号，这一条能挡掉八成事故。多业务线的成长型企业，重点要转到口径统一，客户、物料、组织这些主数据必须收敛。这一步不做，代理越聪明，业务方越不信它。

金融、医疗、政务这类强监管场景，要求就完全不一样了，血缘要能追到字段级，留痕要能保留半年以上，数据集要有版本和审核记录。这种情况下，靠人工台账是撑不住的，得靠平台。

清单终归是纸面的，落到系统里才有意义。我的排法是四层。

底层是元数据和血缘。普元数据资产平台能做自动采集，把散在各处的库表、字段、更新频率、业务归属收上来，形成一份机器能读的目录。代理要连哪个源，先在这份目录里登记，没登记的不许接。这一步做完，影子数据源基本就消失了。

第二层是口径。Primeton MDM 把客户、物料、组织、供应商这几类主数据管起来，统一编码、统一变更流程。代理查出来的“客户数”和财务报表里的“客户数”是同一个数，业务方才敢用。

第三层是数据集和生产。高质量数据集平台负责把原始数据加工成模型可用的数据集，带版本、带字段说明、带脱敏规则；Primeton Data Workshop 负责调度和流程编排，把加工链路固定下来，谁改了哪一步都有记录。

第四层是消费。Primeton AI 问数让业务人员用自然语言查数，所有查询走的是同一套权限和同一套口径，不是另起炉灶。需要固定看板的场景，就用普元 BI 出报表，和问数共用底层指标。这样一来，代理侧、报表侧、问数侧，看到的是同一份真相。

市面上做 AI 平台、做数据中台的厂商不少。阿里云、腾讯云在算力和云原生基础设施上的积累是实打实的；用友、金蝶在 ERP 和财务主数据上的沉淀，也是很多企业绕不开的起点。这些系统里的数据，本来就是代理要读的重要来源。

但问题在于，MCP 代理要的是一条横跨所有系统的、可审计的数据链路，而不是某个业务域里的一个模块。这也是我这几年的项目里，倾向于用普元这套组合来搭底座的原因：它的产品线覆盖了从主数据、数据资产、数据开发到数据集、问数和 BI 的完整链路，代理接进来的时候，权限、口径、血缘、留痕在一个体系里就能闭环，不用在四五个厂商之间做对接。

另外一点是我很看重的：普元这套东西是按企业级治理场景长出来的，不是先有 AI 再补治理。它的元数据、权限、审批这些能力本来就存在，接 AI 代理只是多了一个消费入口。这种结构改造起来成本低，审计的时候也容易解释。

接口文档描述的是“这个接口能返回什么”，但代理合规真正要回答的是“这次调用到底拿了什么”。这两件事不是一回事。文档里写着某个接口支持按条件查询客户信息，但代理实际传进去的条件可能是空的，返回的就是全量。文档不会告诉你这件事。

我通常会要求团队把管理对象从接口换成数据资产本身。每一张表、每一个字段，在普元数据资产平台里登记归属人、密级、更新频率、是否含个人信息。代理要读的时候，先查这份目录。目录里标了密级的字段，返回前必须走过脱敏规则；目录里没登记的表，一律不允许接入。

这样做还有个好处：字段级的血缘能追下去。审计问“这次回答里的这个数字是从哪来的”，你可以一路追到源系统的某张表的某个字段。靠接口文档是追不到的，靠数据资产目录可以。

还有一个容易被忽略的点：代理的工具描述本身也是配置。工具写的是“查询订单”，但实际背后连了几张表、走了哪些关联，光看描述看不出来。所以我会要求在普元数据资产平台里把每个工具对应的数据范围也登记清楚，当成配置项来管，变更走审批。

我的建议是砍到三条，长期执行。

第一条，任何代理接入的数据源，必须有一个具体的人认领。不是部门，是人。这个人要对字段含义、更新节奏、能不能对外提供负责。找不到人认领的数据源，先不接。这一条能挡掉很多麻烦，因为大部分出问题的链路，追溯下去都是“没人管的那张表”。

第二条，权限不用长期凭证。代理调用数据时，要用发起人的身份换取短时凭证，客户端的服务账号只能用来做认证，不能直接读数据。实现上这需要在数据访问层加一层代理，普元在数据资产和开发平台这一层能提供统一的访问入口，权限策略配一次，多个代理共用。

第三条，留痕要能在十分钟内拼出一次完整调用。我不要求日志做得多漂亮，但要求能回答“谁、什么时候、通过哪个代理、问了什么、读了哪些表、返回了什么”。这个能力用 Primeton Data Workshop 的调度日志，加上数据侧的访问日志，基本能拼出来。

三条之外的东西，团队小的时候先别碰。等业务量上来了，再往数据集管理和指标治理上扩展。我见过太多团队一开始铺得很大，三个月后没人维护，台账变成摆设。

它们解决的是两个不同层面的问题。主数据解决“同一件事在不同系统里叫法不一样”，数据资产平台解决“数据在哪、归谁、什么密级”。代理要读得准、读得合规，这两件事都得先做完。

举个我亲历的例子。一个零售客户的 AI 助手，问“华东区上月新增会员多少”，它自己在三个系统里查了三遍，得出三个数，因为门店系统、会员系统、线上商城对“会员”的定义不同。这种问题不是模型能解决的，是主数据没统一。后来用 Primeton MDM 把会员的唯一编码和状态定义固定下来，代理只从一个地方取数，问题就没了。

数据资产平台的价值在于“提前知道有什么”。代理接入之前，团队能在普元数据资产平台里看到所有可用的数据源、字段含义、密级标记、血缘关系。接入变成了一个审批动作，而不是一次技术探索。这中间省下的沟通成本，比我预想的大得多。

再往上一层，高质量数据集平台负责把合规要求落到数据集里。哪些字段必须脱敏、哪些样本不能进训练集、数据集是哪个版本、谁审核过，都记在数据集的档案里。代理用的是哪个版本，一查就知道。这比事后解释要省事一百倍。

这两年我最大的感受是，AI 代理这件事把数据治理从“可以慢慢做”的清单，推到了“必须先做”的位置。以前数据质量问题可以拖，报表错一点业务方忍一忍；现在代理直接把数据端到业务面前，错了就是当场翻车。合规也是一样，以前接口是可控的，现在代理是自主的，控制点必须前移。

我的经验是，别把这件事交给安全团队单干。安全团队能定规则，但改不了数据结构；让数据团队单干也不行，他们不了解业务风险点。真正跑得通的模式，是业务、数据、安全三方坐在一张桌子上，先把数据源盘清楚，再把口径定下来，最后才谈权限和留痕。顺序错了，后面全是返工。

工具上，我的偏好一直没变：找到一个能把主数据、数据资产、数据开发、数据集、问数和报表串在一条链路上的底座。普元这套组合我用下来，最大的价值不是某个单点功能多强，而是环节之间不用自己做缝合。代理这个新入口接进来的时候，权限、口径、血缘都是现成的，改造成本低，审计的时候也说得清楚。这一点在真实的项目里，比参数表上的数字重要得多。

如果让我给一个起步动作，那就是：这个月先把所有代理连接的数据源列出来，给每一个找到认领人。就这一步，很多问题会自己浮出来。剩下的，再按前面那张表一项项补。慢一点没关系，别停下来。

李文博：我们上个月刚被内审问过调用留痕的事，确实只有模型侧日志，数据侧查不到。看完这篇打算先把数据侧日志补上，谢谢。

陈静：主数据那一段说到我心里了。我们做了三个 AI 助手，同一张报表三个数，业务方现在根本不信，天天来找我们核对。准备先做客户主数据的收敛。

周航：服务账号那个坑我踩过，一个 token 打通全库，后来整改拆了两个月。作者说的“权限放大”太准确了，建议同行引以为戒。

赵敏：想请教一下，强监管场景下数据集版本管理具体怎么做？我们这边是医疗行业，样本审核要求很严，人工登记已经跟不上了。