一家制造企业的IT负责人跑来找我聊了个挺有意思的事他们刚把AI工作台通过MCP接入ERP和MES产线主管用自然语言就能查工单、看报工、问库存效果确实不错。但聊到权限的时候他问了一句既然MCP这么方便能不能干脆用它把企业权限系统替代掉当时我一愣然后花了半小时跟他讲清楚为什么这条路走不通。这个疑问其实非常典型。MCP出来之后很多做企业集成的朋友第一反应是以后接系统不就一个MCP Server搞定然后把权限这层老古董想当然地省了。这篇文章我想把这笔账算清楚AI工作台接ERP、MES时MCP到底在哪个环节起作用为什么它天生做不了权限系统以及真正应该怎么设计权限边界。看完你就能明白MCP解决的是AI够不够得着工具的问题企业权限系统解决的是你有没有资格碰这些数据的问题两件事差着整整一个治理层。1. 先搞清楚AI工作台借助MCP接入ERP/MES时技术链路长什么样1.1 MCP在企业集成里的真实身份连接器不是裁判MCP全称Model Context Protocol模型上下文协议本质上是给AI应用和外部工具之间定的一套标准化接口。你可以把它理解成一条通用数据线AI工作台客户端和ERP/MES系统服务端各插一头约定好格式数据就能流转起来。它解决了过去最大的痛点每个系统一个私有APIAI接一个系统要写一套适配代码接十个系统要维护十套集成成本居高不下。但这里有个关键点需要先明确MCP协议约定的是客户端怎么发现服务端提供的工具、怎么发起调用、怎么返回结果它管的是连接和调用格式。协议层面没有定义什么用户能调什么工具这件事。这就好比快递公司约定好了面单格式、收发货流程但面单上填谁的身份证号、谁有权拆包裹那是仓库管理系统的职责快递公司管不着。在企业集成的语境里MCP Server通常部署在ERP/MES周边把一个具体的业务能力包装成AI可调用的工具。比如把MES的查询工单进度接口包装成mcp_tool_query_wo_progress把ERP的查询库存台账包装成mcp_tool_query_inventory。AI工作台通过MCP协议看到这些工具的名字和入参格式然后按需调用。到这里为止一切正常但很多人恰恰是在写MCP Server这一步开始犯迷糊为了图省事直接在Server里塞了一个ERP超管账号的API Key。1.2 一条典型链路AI工作台到ERP/MES的调用全貌我们先画一条完整的技术链路后面所有问题都在这条链路上展开。企业内部的AI工作台不管是自研Agent、开源框架还是商业产品作为MCP客户端通过配置好的MCP Server地址发起请求MCP Server收到请求后解析出工具名和参数再调用ERP或MES对外开放的API业务系统接到API请求后执行查询或操作把结果原路返回最后AI工作台把结果组织成自然语言回复给用户。这条链路上有一个非常重要的点真正的数据访问发生在MCP Server调用ERP/MES API这一步。也就是说权限裁决的关键位置在业务系统这一侧在ERP/MES的API网关里在它们自己的权限模型里而不是在MCP协议里。MCP Server只是中间搬运工它手里那个API Key决定了这台服务器能调多少东西但决定当前这个提问的用户能不能看这批数据的必须是业务系统基于用户身份做的判断。这就是整个问题的分水岭如果你在MCP Server里配了一个拥有全部权限的API Key相当于给所有用AI工作台的员工发了一把万能钥匙。钥匙本身能开所有门至于开门之后该不该看里面的文件AI不知道也不会去判断。我见过不少集成项目把权限寄托在AI只调工具、不乱调的假设上这等于把安全交给运气早晚出事。2. 为什么MCP天然做不了权限系统2.1 MCP协议栈的设计里没有终端用户MCP协议里最重要的几个概念是Client、Server、Tool、Resource、Prompt你翻遍整个协议规范找不到一个叫终端用户身份的一等公民。协议层的Session通常只区分哪一个MCP客户端实例连接了服务端客户端后面是张三还是李四协议本身不关心。这是一条硬性设计边界也是一条安全边界但很多人没意识到。举个更直观的例子一个AI工作台可能供全公司100个人使用但这100个人通过MCP连接同一个Server时从Server视角看连接方只是同一个Client实例。如果Client直接把当前用户的身份塞进参数里传给MCP ServerServer也没有义务去验证这个身份是真的、有没有被篡改。因为协议不做身份断言它只做数据搬运。你想在MCP层做细粒度权限等于在一个没有用户概念的水管里装水表管道本身连水表接口都没留。我在实际项目里验证过这个限制。去年有个团队想做一个基于MCP的资源级授权在Server端维护一份用户清单每个工具调用前查一下发起IP是不是在白名单里。听着能跑但实际上漏洞百出同一台跳板机的用户可以共用IPAI Agent的代理解析可能被诱导调用敏感工具。最终结论还是得回到企业权限系统MCP层根本不该承担身份识别和授权裁决的职能。2.2 工具注册列表和角色权限表完全是两种东西MCP Server会暴露一个工具列表每个工具用JSON Schema描述名称、描述、参数、返回结构。有人看到这个列表就觉得这不就是权限表吗反正服务器上定义了哪些工具AI就只能调哪些工具那不就能控制权限了这是典型的混淆。工具注册列表描述的是接口长什么样、有什么能力它是系统能力目录不是访问控制清单。角色权限表描述的是某个角色对某个资源有什么操作权限它是人员资格的集合。你在一个MCP Server里定义了100个工具好比一个图书馆里摆了10万本书书在书架上不等于任何人都能借走每一本书能不能借得看借书证的等级和馆藏的管控规则。更进一步同一个工具在不同用户面前应该返回不同结果。比如ERP里的查询销售订单工具销售总监和跟单员能看的字段可以天差地别跟单员还可能只能看到自己负责区域的数据。这种差异如果按工具粒度控制根本无法表达。你得在工具之下再做一层按用户身份过滤行级数据、按角色隐藏敏感字段、按组织关系隔离数据域这些恰恰是企业权限系统最擅长做的事情MCP工具列表完全做不到。2.3 AI能自己决定调什么但决定不了你有没有资格调还有一层更微妙的误判既然AI Agent能根据用户问题自主决定调哪个工具是不是说明它理解该给用户什么信息这里必须清醒一点AI的自主性和数据授权完全是两码事。AI判断用户想知道A车间的完工率是意图理解它判断不了用户是A车间的操作工还是集团总裁该不该看这个完工率。意图理解和数据授权隔着一条合规和审计的鸿沟。换句话说AI是这个链条上最不擅长做权限判断的节点。它的优化目标是准确回答用户它的天性就是要满足提问者。你让一个以有求必应为目标的模型去执行该拒绝就拒绝的权限策略等于让厨师去当海关关员专业技能再强也不顶用。真正靠谱的做法是让AI把请求完整地传给业务系统让权限系统对业务系统说不然后AI把拒绝翻译成自然语言反馈给用户。权限决策留在企业权限系统里AI只负责转达和表达。3. 企业权限系统到底在管什么以ERP/MES为例3.1 功能权限之外还有数据权限和字段权限很多人理解的权限就是谁能登录ERP、谁能点某个菜单这叫功能权限。但企业权限系统的真正复杂度在数据层。同一个ERP里分公司A的财务不应该看到分公司B的账这是数据权限同一个销售订单报表里普通业务员不该看到毛利率字段产品经理不该看到客户联系方式这是字段权限。权限系统要对数据做分层过滤这一层是MCP工具列表完全够不着的。拿MES举例MES系统通常按工厂、车间、产线、工序组织数据。一个操作工登录MES,看到的是自己所在车间的在制品状态一个计划员能看整个工厂的排产集团层的人才能跨工厂看全局。如果AI工作台通过MCP调MES的工单接口而你在这个接口后面不加数据权限过滤结果就是任何能打开AI工作台的人都能问出全集团所有工厂的工单进度产线员工的账号也能看到总裁级的数据范围。这不是危言耸听我在客户的MES集成测试里就真实复现过这种越权。再补一个ERP里很典型的场景热词里有朋友在搜Oracle ERP的PAC成本法。PACPeriod Average Costing周期平均成本法下成本计算和分摊逻辑非常敏感成本数据往往是企业级保密数据。同样一个查询物料成本接口成本会计能看到单位成本和差异分析普通仓管连成本字段都不该在返回报文里出现。这种按字段粒度的控制靠MCP Server加几个参数是根本没戏的。3.2 职责分离系统权限背后是内控要求企业权限系统还有一个很多人忽略的硬约束职责分离英文叫Separation of Duties简称SoD。这是审计和内控的基本要求核心思想是一个人不能同时拥有互相冲突的权限。最经典的场景就是采购和付款下单的人不能同时审批付款因为如果一个人既能创建采购订单又能审核付款他就可以虚构供应商、伪造采购、把钱打给自己人。ERP系统里对这类冲突权限有专门的检测规则管理员定期跑SoD报告。如果MCP把AI接进来问题会更复杂。AI工作台天然是一个全能执行器同一个对话里它可以先查询采购单、再发起付款审批、还能查看供应商银行账号。假如MCP Server背后的API Key没有做职责分离隔离AI就变成一个有史以来最高效的内控绕过工具。你不用担心人有没有权限冲突AI通过一个超权限的API Key把冲突权限全串起来了。我见过一个真实案例某企业给AI工作台开通了MES报工接口和ERP生产订单接口初衷是让AI帮班长快速录入报工数据。但API Key权限过大AI不仅能报工还能改工艺参数、能下生产订单、能查成本。一旦出问题责任根本说不清楚。这就是权限系统存在的意义不是为了让流程变慢而是为了让每一个操作具备可追溯的资格边界和义务边界。3.3 审计和合规是权限系统存在的硬理由最后一条硬理由叫审计和合规。制造企业面临各种内审、外审、体系审核每次有重大操作都要能回答一个问题谁在什么时间用什么账号对哪笔数据做了什么操作企业权限系统配合审计日志把这个问题回答得清清楚楚。MCP这一层很难给你这个答案。MCP Server的日志里记录的是工具调用时间、工具名、参数、返回状态它不太容易记录终端用户的工号、登录设备、在业务流程中处于哪个节点。即使你让MCP Server打日志日志里也缺一个可信的身份字段。更麻烦的是如果权限决策不是按真正的用户身份做的审计追踪到一半就断了你知道AI工作台调了查询供应商报价这个工具但你不知道是哪个用户在什么理由下查询的这个日志就失去了审计价值。从这个角度说企业权限系统不是可选的它是企业数字化的基础设施。MCP这类协议解决的是效率问题权限系统解决的是责任问题。效率再高责任不能丢。丢了责任企业连正常经营都站不住脚。4. 踩坑实录MCP接入权限系统时最容易翻车的4个场景4.1 共享API Key引发的越权事故先说最经典的坑MCP Server里配置一个共享服务账号的API Key整个公司所有的AI工作台请求都走这个账号。表面上省事实际上是把所有用户的权限边界全部抹平。举个例子一线操作工用AI工作台问MES今天的产出多少系统返回的是全厂的产出数据因为MCP Server背后的服务账号能看到全厂数据所以所有用户看到的都是全厂数据。这种事故的可怕之处在于它不是偶发故障而是结构性漏洞。你没法通过改某个用户的权限来修复因为所有请求已经混在一个池子里了。我遇到过一个更极端的MCP Server用的服务账号竟然有ERP的接口维护权限AI在工作台里被引导调用了创建接口的工具直接生成了一张错误的采购申请单事后追责怎么也查不到具体是谁让AI干的。4.2 身份链断裂系统知道是AI不知道是谁第二个坑是身份链断裂。MCP调用链路的尽头ERP和MES系统看到的是一个服务账号在调用API它们无从得知真正的请求者是哪个终端用户。业务系统想按用户维度做数据隔离结果传过来的身份字段是mcp-server-robot所有用户都变成同一个机器人。后果很直观你没法在MES里配置某个用户只能看某个车间因为MES根本识别不出终端用户。这个问题的根子是MCP协议默认不传递终端用户身份你需要自己在应用层做上下文注入把当前登录用户的工号、部门、角色一路透传到业务系统的API请求头里。不做这一步所谓的AI工作台对ERP/MES来说就是一堆无差别的机器人请求。4.3 MCP Server成了明晃晃的权限黑洞第三个坑是MCP Server自己变成权限黑洞。很多团队把MCP Server当成一个常规微服务部署在默认网络区域暴露了不必要的端口安全组开得过于宽松日志没有集中收集密钥管理靠配置文件写死。结果MCP Server从集成组件变成了攻击面一旦被攻破攻击者等于拿到了一个业务系统后门。我见过一个工厂的MCP Server部署在一台无域控、无加固的Windows机器上跑着Administrator权限配置文件里明文存着好几个系统的连接字符串。当时测试的温控工程师只要打开这台机器的桌面就能看到全厂所有生产系统的账密。这个级别的安全隐患跟MCP协议本身没关系但确实是接入AI工作台这个动作带进来的很多企业做完集成后根本没有对MCP Server做等保加固和访问控制。4.4 日志链断裂出事后找不着人第四个坑是审计追溯。MCP调用日志和业务系统操作日志如果不做关联出事之后根本还原不了现场。MCP Server的日志里有一个工具调用时间、有一个请求参数ERP系统日志里有服务账号的API访问记录但两个日志系统之间没有任何traceId贯穿你无法把AI工作台某次提问和ERP里某笔生产订单被修改对上号。我处理过一次客户投诉的数据泄露排查疑似有员工通过AI工作台导出了竞品分析数据但审计时发现MCP日志里只有一条工具调用成功的笼统记录连参数详情都没有更不用说当时是哪个用户在提问。最后只能靠人工访谈排查白白花了两周时间。如果一开始就在MCP调用链里埋好统一的请求ID和用户身份字段这个排查五分钟就能定位。5. 正确姿势MCP做连接权限系统做裁决5.1 权限下放业务系统才是真正的裁决点既然MCP做不了权限那正确做法就很清晰了MCP Server只做协议转换和请求转发权限裁决永远下放到ERP/MES业务系统本身。MCP Server手里不应该握有能查一切的超管Key它持有的应该是业务系统里一个经过严格裁剪的、与具体工具能力一一对应的服务账号。这里有一个实操原则MCP Server里的服务账号权限必须小于等于这个Server暴露的所有工具所需的最小权限集合。比如Server暴露了查询工单进度和报工录入两个工具那服务账号在MES里只需要分配这两个菜单的对应接口权限别的权限一律不给。这样即使MCP Server被人为攻破或者被越权调用攻击面也被限制在已经暴露的工具范围内不至于整个ERP数据裸奔。5.2 把用户身份上下文一路传到底权限要准身份必须先到位。正确做法是在AI工作台入口完成用户认证认证成功后把用户身份工号、部门、角色、区域塞进MCP调用链的上下文里通过MCP请求扩展字段一路传给MCP Server再由MCP Server转换成业务系统API的身份请求头。这个链条里要注意一个安全细节MCP Server不能盲目信任AI工作台传过来的用户身份它应该把用户身份基础设施里签发的认证凭证比如短效token或JWT一并带上业务系统收到请求后需要验签和校验有效期。这样身份信息在链路里是可信的、可追溯的而不是客户端说谁就是谁。我见过有的团队直接让AI工作台把用户名作为普通参数传给MCP Server业务系统也照单全收这就是典型的逻辑漏洞任何人改个参数就能冒充别人。5.3 MCP Server侧的工具级最小权限MCP Server这一层也不是彻底放弃管控它应该做工具级的最小权限控制每个用户角色在MCP Server上可见的工具列表不同未授权工具直接不暴露。这层控制不是替代企业权限系统而是给业务系统减负在入口处就过滤掉明显越权的请求。举个例子操作工角色的MCP工具列表里只有查询本车间工单和提交报工车间主任多一个查询全部工单和一个发起返工集团高管多一个跨厂查询工时效率。这些工具清单可以和企业的角色主数据联动角色调整了工具清单跟着变。你可以在MCP Server里维护一张角色-工具-业务系统权限点的映射表每次发布新工具先过一遍映射关系确认无误再上线。5.4 审计日志统一收口再一个绕不开的环节日志。MCP Server、AI工作台、业务系统三方日志必须做统一收口。最直接的做法是引入一个全局traceIdAI工作台发起一次请求时生成贯穿MCP调用链一路透传到业务系统的响应头里三个系统都按这个traceId记录日志。日志里必须包含用户工号、工具名、参数摘要、业务系统返回状态、响应时长、统一的时间戳。这个设计看起来费一点功夫但排查问题的效率能翻好几倍。有一次客户那边反馈AI工作台报工重复我第一反应是让运维把traceId拉出来一秒定位到是MCP Server的超时重试机制导致同一条报工提交了两次。没有统一日志的话这种问题通常要前后端扯皮半天。审计人员来检查的时候你直接按traceId导出一串完整调用链清晰得很。5.5 从零落地一套可以直接照搬的步骤最后给一套可以照着做的落地步骤适用于大多数用AI工作台接ERP/MES的企业第一步梳理AI工作台要暴露的用例清单精确到哪个角色、要通过AI完成什么业务动作、涉及ERP/MES的哪些接口。 第二步针对每个用例在业务系统里创建独立的API服务账号权限用最小集每个账号对应一段明确的业务场景不要复用。 第三步在MCP Server里为每个接口建立工具定义同时建立角色-工具映射表明确谁的工具列表里有什么。 第四步改造AI工作台的认证模块和MCP客户端让用户身份以安全凭证形式贯穿调用链凭证需要被业务系统验证。 第五步在AI工作台、MCP Server、业务系统三层统一接入traceId日志测试阶段全链路演练权限隔离和越权阻断。 第六步上线后定期复核服务账号权限每三个月做一次工具清单和角色映射的对照检查防止权限随人员变动逐渐失控。6. 给企业集成者的实操建议和自查清单6.1 不同规模企业怎么选式如果你是在小微企业做AI集成系统少、用户少、流程短第一版可以用简化方案MCP Server持有业务系统的最小权限KeyAI工作台只做只读类查询暂不做写操作。这种模式先把价值跑出来坏人风险相对可控。但我要提醒一点就算规模小也不要让MCP Server持有超管Key哪怕只有一个员工在用也不行。安全习惯是从小就养成的权限收敛从一开始就要做不要等出事再补。中大型企业尤其是制造集团建议认真做身份上下文传递和审计收口。这块的投入不是可有可无而是安全底线。集团型企业里数据跨法人、跨工厂、跨成本域权限模型本来就很复杂AI一旦接进去如果没有严格的权限透传一次越权查询就可能把整个集团的敏感数据暴露给一个车间操作工。这种场景下不要急着让AI什么都干先把权限边界画清楚再一点点放开。6.2 上线前自查清单这里列一份自查清单你可以直接在项目上线前对照检查是否所有MCP Server的服务账号都按最小权限配置杜绝超管Key是否测试过无权限用户通过AI工作台直接调用敏感工具的越权场景用户身份是否以可信凭证全程透传到业务系统业务系统是否验证AI工作台发起的写操作报工、审批、下单是否有事前的二次确认三类日志AI工作台、MCP Server、业务系统是否有统一traceId关联是否定义了MCP Server的部署网络安全策略是否明确哪些IP可访问是否有工具清单的定期复核机制人员角色变化时工具权限能否同步我在好几个客户项目里都是用这份清单做上线检查的每次都至少能查出两三条问题。最常见的还是服务账号权限过大和日志链路缺失这两项几乎成了行业通病。6.3 常见问题速查表问题排查方向推荐方案用户通过AI工作台看到了自己不该看的数据检查MCP Server服务账号权限范围、业务系统数据权限配置、身份透传是否生效服务账号最小化身份落到业务系统的数据权限维度不同用户调用同一工具返回相同结果检查MCP Server是否只用了单一共享账号没有传递用户身份在调用链上传可信身份凭证启用业务系统的行级过滤AI工作台能调出工具列表里不存在的接口检查MCP Server是否被绕过或API Key权限过宽收紧服务账号工具发布前做权限映射评审出事之后查不到是哪个用户发起的请求检查三方日志是否有统一traceId和用户字段建立全局traceId贯穿机制日志集中存储MCP Server被探测扫描到非预期端口检查网络安全组、服务器加固状态限制入站来源部署在受控网络区域开启等保加固人员离职后仍能通过AI工作台访问系统数据检查身份认证和角色同步机制对接统一身份源离职立即吊销用户凭证角色映射同步更新最后说点我自己的体会。MCP是个好东西它把AI和业务系统之间的连接成本打下来了让AI工作台不再只是聊天的玩具而是真能伸手干活的生产力工具。但它好就好在做好连接这件事上一旦越界去管权限你得到的不是一个更聪明的权限系统而是一个更危险的漏洞。每次做这类集成我都会提醒团队的伙伴们先定身份再定权限最后才谈智能。顺序反了后面全得返工。我也建议做企业管理软件的朋友们别焦虑AI不会代替ERP和MES也不会代替权限系统它会成为这些老系统的新入口而权限这层始终是入口前面的那道闸机——它必须还在。