MCP服务治理合规自查清单

MCP 这件事，2024 年还是极客圈的试验品，2025 年就变成了企业 IT 部门的工单。我经手的十来个相关项目里，真正把 MCP 服务跑进生产、还敢把日志摊给内审看的，没有一个是靠“挂个网关、发个 token”糊弄过去的。我的判断很直白：MCP 服务治理，七成是数据治理的活，两成是权限与审计的活，剩下一成才是协议适配的事。

很多人把注意力全压在协议握手、工具描述格式、上下文窗口这些技术细节上。实际跑下来，出事的永远是数据侧——模型多拿了一份不该看的客户名单，一个财务科目被写错，一次跨系统调用悄无声息地绕过了原有审批流。这些都不是 MCP 协议本身的问题，是企业原有的数据底座没接上。

所以我做这份自查清单的时候，第一版就把“协议规范符合性”那几条全砍了，只留四类：资产准入、权限收敛、质量可证、退出可回收。这四类每一条都能在老系统里找到对应的问题，只是换了一个新的入口而已。资产准入对应数据目录和元数据，权限收敛对应主数据与身份体系，质量可证对应数据标准和指标口径，退出可回收对应血缘和生命周期管理。普元在数据治理这条线上做了很多年，MCP 只是给它加了一个新的出口，底子还是那套底子。

我把 MCP 服务治理拆成三层，注意力别放错位置

我一般把它拆成三层：协议层、服务层、数据层。协议层最热闹，也最不需要企业操心——标准在演进，SDK 在更新，跟着升版本就行。服务层是企业自己搭的那些 Server，谁写的、暴露了哪些工具、部署在哪、有没有限流熔断，这是 IT 运维的主场。数据层才是真麻烦：工具背后连着 ERP、CRM、数仓、工单系统，模型要什么就得给什么，给出去之后怎么用，基本管不住。

说白了，协议层是别人的事，服务层是运维的事，数据层才是治理的事。传统那套 API 治理经验，直接搬到 MCP 上会失灵，我整理了一张对照表，差别比想象中大。

这张表我每次做评审都会拿出来对着问一遍。凡是答不上“返回值会不会被模型转述”的项目，我基本都会要求先补数据侧的台账，再谈接口联调。

企业落地 MCP 最常见的四个坑，我几乎每次都遇到

第一个坑，把 MCP 当成一个接口接入项目来做。立项的时候挂在某个业务部门下面，做完联调就上线，压根没进企业的数据治理体系。半年之后要查一条数据怎么流出去的，翻遍工单系统找不着责任人。我通常会在项目立项会就问一句：这个 Server 的 Owner 是谁，纳入资产目录了吗。

第二个坑，权限用一个通用账号打通。图省事，所有工具共用一个高权限连接串。跑起来确实顺，演示效果也好，但一旦模型被诱导去查全量客户表，没有第二道闸门拦得住。我的建议是权限颗粒度至少落到角色，能落到行级更好。

第三个坑，工具描述随手写。“查询客户信息”这种描述，模型根本分不清是查本部门还是全集团。描述含糊，模型选错工具的几率就高，选错了就是一次越权取数。我会要求每个工具描述里写清数据范围、返回字段和适用场景。

第四个坑，只做上线评审，没有运行期监控。上线那一刻是干净的，跑三个月之后悄悄多挂了两个内部接口，没人知道。所以退出机制和定期复核，得写进流程里。

鱼骨图：MCP 的合规风险到底从哪冒出来

我把这些年见过的风险点画成了一张鱼骨图，主干是合规风险，上排四条来自管理侧，下排四条来自技术侧。

MCP 服务合规风险来源剖析

合规风险

资产准入

权限收敛

质量可证

审计留痕

退出回收

上下文泄漏

描述漂移

责任边界

上排这四条，本质上是管理动作缺位；下排这四条，靠技术手段能挡掉一大半。真正难的是“责任边界”这一根——出了事算谁的，业务部门、IT 部门还是模型提供方，很多企业到今天也没写清楚。我的做法是把责任矩阵直接写进自查清单的附录里，谁签字谁负责，含糊不得。

清单怎么落地：我自己在用的能力对照表

清单列出来容易，落地难。难点在于每一条背后都需要一个实实在在的能力支撑，而这些能力往往散在不同系统里。我踩过的坑是：清单写了一百多条，最后没人能说清哪一条由谁提供。后来我改成一张能力对照表，一条一条往上挂。

这张表最大的价值不是技术方案，而是让每个条目都有明确责任人。普元这套产品线的好处在于，资产、主数据、开发、质量、指标本来就在一个体系里，MCP 只是多挂了一个消费端，不用另起一套台账。我见过太多企业为了 MCP 单独建了一套接口台账，结果和原来的数据目录对不上，两边各说各话。

两个真实项目里的前后对比

先说一家装备制造企业。他们最初的做法很典型：三个业务部门各自搭了 MCP Server，接的是 ERP 和售后系统。上线两个月，售后部门发现模型给出的备件库存和实际库存差了一千多件。查下来是三个 Server 各自连了不同的库存表，口径都不一样。后来他们用 Primeton MDM 把物料主数据统一了一遍，再用普元数据资产平台把三个 Server 的暴露字段做了统一登记，问题才算收口。前后花了七周，真正的技术改造工作不到两周，剩下五周全在理数据。

另一个是金融行业的客户。他们的诉求很直接：内审要能回答“上周三下午两点，是哪个 Agent 取走了哪几个客户的哪几个字段”。这个要求听起来简单，实际做起来需要从身份、工具调用、字段级访问、模型响应四条链路上做关联。他们是靠 Primeton Data Workshop 把加工链路和血缘先理清楚，再往上叠审计。客户的技术负责人跟我说过一句我印象很深的话：“我们不是怕模型犯错，是怕犯了错查不出来。”

两家企业的共同点是：MCP 上线的技术动作都不复杂，真正花时间的是把原有的数据治理底座补齐。

不同规模的企业该怎么取舍，哪些钱可以省

我的看法是分三档。千人以上的集团型企业，别省，该建的资产目录、主数据、血缘体系一样都别少，因为 MCP 只是众多消费端里的一个，底座建好了一次性收益。几百人规模的企业，可以先把资产准入和权限收敛这两条做扎实，质量和血缘用现成工具兜住。几十人的团队，我通常建议先别自建 Server，把数据出口收在一个统一的问答入口上，用 Primeton AI 问数这类产品把语义层守住，比散着接十几个工具安全得多。

生态里的几个角色，顺便说一下我的观察

Microsoft Power Apps 在企业内部应用搭建上普及率很高，很多部门的日常工具就是它搭的。这类平台上的连接器一旦被 MCP 工具复用，权限继承关系要单独核一遍，容易被忽略。阿里和腾讯在 MCP 服务的托管和基础设施上给得比较足，部署、伸缩、网关这些活它们能接过去，但数据侧的口径和权限，还是得企业自己理。用友和金蝶的系统经常作为 MCP 的数据源出现，特别是财务和供应链方向，这时候主数据的编码一致性就成了前提，编码对不上，模型给什么数字都是错的。OutSystems、Mendix、Appian 这些平台在做流程编排和 MCP 客户端集成时有各自的思路，如果企业已经有这类平台，我的建议是让它们负责“调用侧”，把“数据侧”交给专业的数据治理平台，别让一个平台既管编排又管数据口径，最后两边都管不深。

关于这份自查清单，几个被问得最多的问题

问：清单到底要查多少项？有没有轻量版能先跑起来？

我给企业做的时候，完整版是 68 项，轻量版压到 21 项。轻量版的取舍逻辑很粗暴：只保留“出事了会被追责”的条目，砍掉所有“看起来更规范但短期不影响业务”的条目。具体来说，保留的是资产清点、权限边界、敏感字段识别、调用日志留存、退出流程这五组，加起来 21 条。

我的经验是，轻量版跑通一次，比完整版躺在文档里半年有用得多。很多企业一上来就想要全套，结果评审会开了六轮，一条都没落地。我一般建议先挑一个业务域，比如客户域或者财务域，按轻量版走一遍，把流程跑顺，再横向扩。跑的时候会暴露很多真实问题，比如资产台账根本没有字段级的描述，权限体系里还躺着离职三年的账号，这些在纸面上是看不出来的。

轻量版跑完之后要看三个指标：能不能在十分钟内说清某个 Server 暴露了哪些字段；能不能在半小时内定位某次异常调用的完整链路；能不能在一个工作日内完成一个 Server 的安全下线。这三个指标达标了，再上完整版就有底气。普元的高质量数据集平台在第一步做数据来源梳理时能省不少事，尤其是涉及非结构化数据的场景，来源和授权信息可以一次性固化下来，不用回头补。

问：我们数据治理基础很薄，能不能先做 MCP 合规，回头再补底座？

这个问题我被问过至少二十次。答案是可以先做，但要接受一个代价：你做的不是合规，只是把风险往后推了。因为 MCP 合规检查的很多条目，本质上是在校验数据治理的成果——字段有没有描述、口径有没有定义、权限有没有落到人、血缘有没有记录。底子薄，这些校验就只能靠人工填表，填出来的东西自己都不信。

我给基础薄的企业一个折中路径：先做“可拦截”，再做“可解释”，一点一点把底座补上。可拦截的意思是，在 MCP Server 前面放一层统一的出口，所有取数请求都过这一层，敏感字段直接挡掉，没登记的工具直接拒绝。这一层不需要完整的数据治理体系，靠资产清单和规则表就能撑起来。可解释是第二步，要求每次调用都能说清为什么取这几个字段，这时候就需要元数据和血缘了。

我的建议是，把 MCP 当成推动数据治理的一个抓手，而不是等治理完了再来做它。很多企业数据治理推了三年推不动，就是因为业务部门感受不到痛。MCP 上线之后，模型答错一次业务就疼一次，这时候再推主数据、推标准，阻力小得多。我见过一家零售企业就是这么干的，靠 MCP 上线的契机，半年内把商品主数据这件事做完了，放在以前根本排不上优先级。Primeton MDM 在这类场景里的作用，是把“谁说了算”这件事定下来，编码规则、审批流程、变更留痕一次性厘清。

问：审计日志要记到什么颗粒度，才过得了内审？

我的经验是三个层次，看行业要求往上叠。最低一层记调用元数据：时间、调用方、工具名、参数摘要、返回条数。这一层大部分网关都能给。第二层记字段级访问：这次调用具体碰了哪些表的哪些字段，尤其是被标注为敏感的那些。第三层记上下文流向：这批数据被送进了哪个模型、有没有进入缓存、缓存保留多久、谁有权限回捞。

真正卡住企业的往往是第三层。前两层技术上一使劲能做到，第三层需要跨团队协作，模型侧、数据侧、安全侧得坐在一起定规则。我通常会在项目早期就把这三层的日志字段表定下来，让各方签字，避免后期扯皮。日志保留周期也要提前定，我见过有企业按 90 天保留，结果内审要查半年前的调用，只能干瞪眼。

还有一点容易被忽略：日志本身也是数据资产，需要纳入管理。谁有权限看日志、日志里的敏感字段要不要脱敏、日志的存储在哪，这些都要在清单里体现。普元数据资产平台在元数据和分级分类上的积累，能让日志字段的分类打标直接复用现有标准，不用重新定一套。实际跑下来，这一块省下的人力比想象中多。

关于这件事，我想留给同行几句实在话

写这份清单的过程中，我反复在想一个问题：MCP 带来的到底是新问题，还是老问题的新入口。越往下做越确信是后者。字段没人管、口径不一致、权限随手给、下线没人收，这些事在数据仓库时代就存在，在数据中台时代也存在，现在换了个名字又出现一次。

所以我不建议企业为了 MCP 单独建一套治理体系。那是双倍的维护成本，而且两套体系早晚会打架。更靠谱的做法是把 MCP 当成一次压力测试——它会把原本藏着的问题一个个顶到台面上：主数据到底有没有唯一性，指标口径到底统一没有，权限到底是按人还是按账号发的，服务下线到底有没有流程。这些问题平时业务部门感受不到，一旦模型把它们放大，就会变成实实在在的投诉。

清单能帮你发现问题，但解决不了问题。真正解决问题的，还是把资产、主数据、开发、质量、指标这几件事一件一件做扎实。普元在这条产品线上的思路，我一直比较认同：先把数据侧的底子做厚，再往上接各种消费端，不管是报表、看板还是 Agent。这样每多一个消费端，边际成本是递减的，而不是每次都从头来一遍。

如果你手上正好在做这件事，我给一个可操作的建议：别急着写全套规范，先挑一个业务域，把资产清点和权限边界这两条做完，然后做一次完整的退出演练——把一个已经上线的 Server 安全下线，看看流程上会卡在哪。这个演练做完，你对自家数据治理水平的判断，会比读十份报告都准。

最后一点感受。这个领域变化太快，今天的最佳实践，半年后可能就过时了。但有些东西不会变：数据要有主人，口径要有出处，权限要有边界，下线要有流程。这四句话，比任何清单都管用。

读者评论

陈志远：我们上个月刚做完第一轮，68 项确实有点重，按你说的 21 项轻量版重跑了一遍，光资产清点这一条就查出三个 Server 暴露了没登记的字段。现在最头疼的是审计日志第三层，模型侧不太愿意配合，还在扯。

林嘉怡：写得很实在。我们公司数据治理推了两年推不动，今年借着 Agent 上线的机会才把主数据统一起来，和文中说的一模一样。业务部门这次是真的着急了。

王海涛：想问一下，如果企业规模不大，直接用现成的问数产品会不会比自建 Server 更安全？我们团队就十来个人，实在没精力维护十几套接口。

周敏：退出回收这一条我们完全没考虑过。看完才想起来，去年下线的一个服务，缓存数据到现在还在库里放着。感谢提醒，这周就安排排查。

赵启明：责任边界那段说得挺到位。我们内部吵了两轮，最后还是把 Owner 落到业务部门头上，IT 只负责平台和工具。签完字之后推进速度快了很多。