“MCP能不能替代企业权限系统”这句话我第一次听到是在上个月一家制造企业碰头会上。当时他们把AI工作台接到了MES和ERP上车间主任的浏览器里多了一个可以“直接改工单状态”的对话框。信息部门负责人半开玩笑半认真地说既然AI都能把活干了那还搞什么权限审批别折腾了。我当时直接回了一句“你别急着把这句话写进周报里。”MCP这种协议解决的是“AI怎么去调用工具”不是“谁有资格调用工具”。两者看着都是“连接”实际差着一个身份体系、一套授权模型外加一整套审计逻辑。今天就把这层事儿彻底捋清楚。1. 先弄清楚AI工作台接ERP和MES到底在接什么1.1 从“知道”到“操作”两种接法的本质区别很多团队把“接入”想得太简单以为AI工作台连上ERP的API再给MES发几个请求就算“对接”了。实际上制造业里这两个系统承载的是完全不同的业务语义ERP管的是资源计划和财务核算销售订单、采购单、物料清单、成本分摊都在里面MES管的是现场执行工单派工、报工、设备状态、质量判定、批次追踪一环扣一环。把AI工作台接到这些系统上有两种截然不同的层次。第一种是“只读型接入”AI帮用户查工单进度、汇总报表、解释异常原因这种接入权限问题很小相当于给系统加了个高级查询界面。第二种是“写操作型接入”AI能帮你创建销售订单、释放生产工单、改完工数量、做质量放行。麻烦来了这些操作原本在ERP和MES里都是要走流程的有审批链、有职责分离、有数据权限范围。一旦AI工作台能直接触发这些动作它实际上就成了一个“特权操作员”。我参与过不少此类集成90%的翻车现场都出在第二种。业务方诉求特别简单“我们想让领导在群里用一句话搞定审批和派工。”技术方一听就觉得MCP天生合适工具调用、上下文携带、会话往返全都现成的。但没人想清楚一个关键问题当领导在AI对话框里说“把工单WO-240815-03改成已完工”的时候系统凭什么相信“这个人”就是有权限做这个动作的人这个“凭什么”就是权限系统的事。1.2 MCP热潮下的流行误解MCP全称Model Context Protocol模型上下文协议。它是在模型和外部工具之间建立的一套标准化对话方式客户端把模型想调用的工具名、参数传过去服务器执行完回传结果。打个比方MCP就像给AI装上了“手”让模型不仅能“想”还能“动”把大模型从聊天窗口拽进业务流程里。但问题恰恰出在这个“动”上。很多技术文章、厂商分享都在强调“让AI去操作ERP”“AI一键访问MES”话术传着传着非技术背景的管理层就形成了一个错觉既然AI工作台已经能调用业务系统了那是不是连传统那套繁琐的账号、角色、审批都不用管了反正AI比人靠谱。这个误解太危险了。MCP定义的是“客户端与服务器之间如何通信”它压根不关心“此刻操作的人是谁”。协议里没有用户身份字段没有角色属性没有权限校验节点更没有任何审计约定。它只负责两件事告诉模型“有哪些工具能用”以及“怎么把结果送回去”。至于这个工具背后是不是违了权MCP不管也不该由它来管。一批新入行的工程师也容易在“技术兴奋感”里犯错。他们调试MCP工具时发现一个工具调用就能修改MES数据库里的状态觉得“权限也就这样”“只要模型不犯错就行”。事实上工具调用成功代表的是“连接是通的”不代表“操作是合法的”。你要给AI工作台配的是一个能定义“谁能操作、能操作哪些数据、操作到什么程度”的完整外围体系。2. MCP的边界在哪里它管不了“谁能碰什么”2.1 企业权限体系自带的东西MCP一件都没有你可以把企业权限系统想象成一栋大楼的门禁体系大门看门禁卡楼层看门禁卡房间还要看门禁卡进机房要单独授权操作财务系统要走二次审批。这套体系包含几个核心组件身份库解决“你是谁”认证机制解决“你怎么证明是你”授权模型解决“你能进哪间房、动哪台设备”职责分离解决“不能既当运动员又当裁判员”审计追踪解决“出事后倒查谁在什么时间干了什么”。ERP和MES的权限体系比普通软件更严格因为它们背后是实打实的业务账。一个销售订单被误删可能引发交货违约一个工单被提前报工可能直接扭曲成本核算一个批次被错误放行涉及产品质量追溯问题。这些系统的权限设计从来不只是“防外人”更是防内部流程失效。MCP有什么它只是一套消息格式和调用约定。它告诉你协议握手怎么发、工具列表怎么列、请求响应怎么封装。它根本不区分调用者是一个操作员、一名车间主管还是一个AI代理本身。你用MCP连上一台MES服务器只要服务器端允许匿名调用或者密钥放行了那它就是能执行。这相当于大楼门禁全部失效只剩房间里装了个摄像头能看到谁进来了但拦不住不该进来的人。2.2 一张表看明白MCP协议和权限系统的分工能力维度MCP协议企业权限系统工具发现支持向模型暴露工具清单不负责一般通过接口清单或菜单权限控制身份认证无客户端连接即建立会话完整多因素认证、单点登录、证书体系授权决策无工具是否可用由服务器自行判断完整支持角色、数据范围、分级审批职责分离无工具可被任意客户端调用支持创建与审批分离、双人复核数据权限无参数传什么就处理什么支持按组织、工厂、客户区间隔离数据审计追溯无法标识业务用户只能记录“客户端调用”完整用户、终端、时间、操作前后值全记录这张表你不用背下来记一个核心就行MCP解决工具通不通权限系统解决人能不能碰。两者根本不在一个维度。你不可能因为装了一套USB标准就取消写字楼的门卫和工牌。2.3 为什么“模型知道”不等于“模型被授权”还有一个更隐蔽的误区我管它叫“AI知识幻觉”。不少企业管理者觉得AI工作台里装了ERP和MES的MCP服务器之后模型“知道”了业务流程就等于模型“有权”执行这些流程。这个想法必须纠正。举个很简单的例子。AI工作台接入了MES的查询工具模型通过这个工具读到了车间所有工单信息包括不合格品批号、设备故障记录、人员工时。这时候你的AI工作台负责回答班长提问“这批不良品原因是什么”它答得头头是道。但同一个模型如果被别人接手问“你们生产线的物料齐套率是多少”它也能答。模型输出内容的范围取决于它调用的工具能拉回什么数据而不是取决于提问人有没有权限看这些数据。这就是典型的“信息越权”。传统权限系统里数据按照角色隔离一个班组长看不到他管辖范围之外的成本数据因为查询接口会拦截。但当AI工作台通过MCP服务器去调数据时服务器为了“提高AI回答效率”往往会把工具设计成“全量数据可见”。你以为是在给AI增加能力实际上是给所有人都开了一扇全数据查看的后门区别只是这个“后门”伪装成了对话框。我见过最离谱的案例是一家工厂的信息科为了让AI工作台“懂计划”把整套BOM、工艺路线、在制订单、库存成本明细全部放进了工具描述和上下文窗口里。结果一线员工通过对话问一句AI就能说出公司毛利润和管理口径的成本分摊。这种越权在传统界面里绝对不会发生因为报表系统有权限项但一到AI工作台这里全部穿透了。所以必须重申模型知道得多不等于它可以操作得多MCP把数据递到你眼前并不能替权限系统判断这个数据该不该让你看见。3. 可落地的集成方案把权限留在网关让AI只当接口3.1 推荐的架构AI工作台 → 受控MCP网关 → 企业连接器既然MCP不能替代权限系统那正确的集成姿势是什么我的建议非常明确让MCP老老实实做它的“传输协议”把权限逻辑集中放在网关层。架构分三层。第一层是AI工作台也就是用户面对的那个对话框第二层是受控MCP网关它不是直接对接业务数据库而是把所有MCP工具请求都拉到统一入口第三层是企业连接器负责把网关的请求翻译成ERP或MES能懂的API调用。关键点在于MCP工具暴露给模型的只是“接口外壳”真正的权限判定放在网关后面的企业连接器里做。这样设计有三个直接好处。第一AI工作台无论如何换模型、换版本权限逻辑不受影响网关和连接器像防火墙一样挡在前面。第二模型看不到底层数据库连接信息既不会有注入风险也不会因为提示词泄露工具内部配置。第三权限变更只需改网关和连接器侧的角色映射不用重新训练模型也不用重新配置每个MCP服务器。我接触过一些快消品的制造企业他们的AI工作台想接ERP直接调用了原厂的开放接口结果出了一个很尴尬的问题每个MCP服务器都持有连接ERP的高权限账号等于钥匙散落各处。后来改成统一网关方案MCP服务器只保留“调用网关”的权限具体能摸到哪些ERP数据由网关内审险规则决定问题才解决。3.2 权限映射怎么做从角色、数据范围到审批流很多人问我“那网关里的权限该怎么设计是不是做个用户和角色的绑定就行”实际操作远比绑定复杂。我把需要梳理的权限项归纳成四类直接照着做即可。第一类是功能级权限也就是“你能不能做这个动作”。比如“创建销售订单”和“创建生产工单”要分开MES里“派工”和“报工”要分开“质量放行”和“工单关闭”也要分开。第二类是数据级权限也就是“你能碰哪块数据”。例如一个车间主管只能操作自己车间的工单一个销售只能看自己负责的客户和订单ERP里一个工厂的库存数字对另一个工厂的人必须不可见。第三类是审批级权限也就是“做了动作要不要别人确认”。很多复杂业务需要两级审批班组长提交车间主任确认计划部再释放。第四类是特例权限也就是“临时紧急授权”这种授权必须带失效时间比如机房管理员临时开放一个窗口24小时后就收回。我建议用一张权限矩阵表把这几类列清楚横轴是业务流程节点纵轴是角色交叉处填上“仅看、可提交、可审批、可释放”等动作词。这张表做完再把它落到网关上。别想着一次性做到百分之百精细边界明确、能落地就行。初期可以先用“按角色按工厂”粗粒度控制跑通后再细化到具体单据类型。3.3 一个真实配置示例MCP工具与角色绑定的具体写法光讲概念不够我直接拿一个常见的“修改MES工单状态”工具当例子。假设你在AI工作台里配置了一个MCP工具叫update_work_order_status它能修改工单状态。如果你的MCP服务器直接调用MES接口那就等于让AI拥有改工单的超能力。正确做法是网关拦截再做校验。我在系统里通常这样描述这个工具工具名仍然是update_work_order_status参数包括work_order_id、target_status、remark。但网关收到调用后不是直接执行而是先查当前用户身份再走权限判断。伪代码如下function updateWorkOrderStatus(user, workOrderId, targetStatus): // 1. 身份确认 operator identityManager.getUser(user.sessionToken) if operator is null: return 未登录或会话过期请重新认证 // 2. 功能级权限检查 if not permission.hasPermission(operator, WorkOrder.UpdateStatus): return 当前角色没有修改工单状态的权限 // 3. 数据级权限检查 order mesClient.getWorkOrder(workOrderId) if order.plantId not in operator.dataScope: return 无权操作该工厂的工单 // 4. 审批流检查 if targetStatus in [completed] and not approval.isApproved(order, 工单完工): return 工单完工需要车间主任审批当前操作未获准入 // 5. 操作记录 auditLogger.log(operator.id, updateWorkOrderStatus, workOrderId, targetStatus, timestamp) // 6. 执行并返回 return mesClient.executeUpdate(workOrderId, targetStatus)你可能会问这套逻辑是不是绕远了直接让MCP工具自己判断不行吗我劝你千万别写进MCP工具实现里。原因有两条第一MCP服务器可能被多个客户端复用权限逻辑耦合在工具里会导致改权限就得重发服务第二MCP工具代码通常由不同小组维护权限逻辑散落在各个工具里审计时根本没法集中追溯。放到网关统一管控等于把审批、校验、日志集中成一个关卡管理成本和出错概率都会低很多。还有个小提示AI工作台在给用户返回结果时也要把网关的拦截信息原样带回去。比如上面第4步没有权限网关返回“需要审批”时AI应该回复“工单已提交待审批请让车间主任确认”而不是自作聪明地说“无法操作”更不要装作没看见。这个细节要在提示词和系统设计里一起约束否则业务用户会以为AI出故障了。4. 实施中常见的坑与排查手册4.1 越权、绕行、审计断层三个最典型的“事故现场”得多说一句AI工作台接入ERP和MES后出现的权限问题和传统软件权限问题长得不一样。传统系统越权通常是账号密码泄露AI工作台却会平白多出这些情况。第一个事故现场绕过界面直接调用MCP工具。有些员工发现AI工作台和业务系统的登录态是分离的。业务系统半天没操作自动退出但AI工作台这边还挂着会话于是MCP服务器带着残留的令牌直接调ERP接口。结果就是操作动作有效但业务系统审计日志里找不到对应的“人”只有一串服务账号的ID。处理办法是网关层必须强制会话同步和超时回收一旦打开AI工作台超过15分钟没有业务操作立刻要求重新登录。第二个事故现场提示词让权限检测形同虚设。我见过一些MCP工具设计得很“聪明”比如工具参数里带一个forcetrue或者ignorePermissiontrue本意是给管理员提供紧急通道。结果员工通过AI对话框用自然语言描述“绕过审批直接完成”模型自动把这类参数填了。这事真发生过事后追责时模型“一脸无辜”但改数据的事实已经发生。我的建议是网关层直接过滤掉这类参数或者压根不把它们暴露在工具描述里。第三个事故现场审计日志断链。传统系统里审计记录是这样一条链用户A在14:32登录操作了销售订单SO-10086改动了价格。AI工作台里日志变成模型代理B在14:32调用update_sales_order参数为so_id10086。中间用户A去哪了丢了。这不是代码bug是设计缺陷。日志里必须记录三个身份业务用户、AI会话ID、MCP工具调用ID三者关联才完整。缺失任何一个事后排查基本抓瞎。4.2 安全配置自查清单直接抄作业版下面这份自查清单是我在多次实施中反复调整出来的不保证覆盖所有系统但照着做至少能避开80%的坑。你可以直接拿去当项目验收标准。【身份】AI工作台是否严格使用企业统一身份认证有没有允许本地账号绕过【会话】MCP网关会话是否绑定用户令牌失效时间是否设为15分钟或更短【工具暴露】工具列表是否只暴露当前角色可用的工具是否隐藏了全部内部附件和说明【参数校验】网关是否校验了所有传入参数是否存在force、ignorePermission之类危险参数【数据范围】企业连接器是否按工厂、组织、客户等维度过滤数据是否做过黑盒测试【审批流】每个写操作是否都校验了审批链是否允许“人工审批但AI代填”【审计】日志是否完整记录用户、会话、工具、参数、结果、时间六要素是否不可篡改【密钥管理】MCP服务器和连接器之间的密钥是否定期轮换是否存在写死在代码里的连接串【灰度方案】是否先在小范围角色和工厂试点有没有一键停用AI写操作的应急开关【权限复核】是否定期复查权限矩阵每个AI工具调用是否有月度权限对账每次答“否”的项基本就是你必须马上处理的隐患。别杠“哪有那么严重”项目上线前多花三天总比上线后数据错了再花三周返工强。4.3 我对“权限下沉到MCP”方案的结论个人经验最后聊点个人经验。早些年我做过一个技术选型把权限规则直接编码在MCP服务器里当时图省事以为既然工具就几个,直接在每个工具函数开头加上if判断不就完了。结果第一个版本刚上线一周就出问题。仓库主管换岗后旧角色没有及时清理他仍然能通过AI工作台调用MES的入库工具。如果权限集中在网关这个问题一到换岗交接就能被权限复核流程发现。散在工具里查了三天才定位到一个MCP服务器的缓存没刷新。另一件让我记忆深刻的事是给一家装备制造企业搭建AI工作台时业务部门总催着要“一步到位”。他们恨不得所有角色都能在对话框里呼来唤去。我坚持在网关层做了两档权限普通操作档只允许查询和提交审批释放档单独给中层以上。上线第一个月有个班组长尝试通过AI直接关闭工单被网关拦截提示“待车间主任审批”他不但没抱怨反而觉得这样流程更清晰。这给了我很深的体会权限不是阻碍AI价值的绊脚石它反而是AI工作台能长跑的前提。所以我最后的建议是把MCP当成AI工作台和业务系统之间的一根数据线它负责稳、快、准地传递动作而权限系统是那把锁它决定哪个动作能被谁触发、能在什么范围内生效、会留下什么痕迹。两件事各司其职AI工作台才不会从效率工具变成事故工具。每次有人再跟你说“MCP能替代企业权限系统”你都可以问问出了事你打算拿谁去扛 
长河君 · 2026/10/28 8:04:53 · 阅读 1.2k MCP不能替代企业权限系统：AI接入ERP/MES的权限边界与网关架构
“MCP能不能替代企业权限系统”这句话我第一次听到是在上个月一家制造企业碰头会上。当时他们把AI工作台接到了MES和ERP上车间主任的浏览器里多了一个可以“直接改工单状态”的对话框。信息部门负责人半开玩笑半认真地说既然AI都能把活干了那还搞什么权限审批别折腾了。我当时直接回了一句“你别急着把这句话写进周报里。”MCP这种协议解决的是“AI怎么去调用工具”不是“谁有资格调用工具”。两者看着都是“连接”实际差着一个身份体系、一套授权模型外加一整套审计逻辑。今天就把这层事儿彻底捋清楚。1. 先弄清楚AI工作台接ERP和MES到底在接什么1.1 从“知道”到“操作”两种接法的本质区别很多团队把“接入”想得太简单以为AI工作台连上ERP的API再给MES发几个请求就算“对接”了。实际上制造业里这两个系统承载的是完全不同的业务语义ERP管的是资源计划和财务核算销售订单、采购单、物料清单、成本分摊都在里面MES管的是现场执行工单派工、报工、设备状态、质量判定、批次追踪一环扣一环。把AI工作台接到这些系统上有两种截然不同的层次。第一种是“只读型接入”AI帮用户查工单进度、汇总报表、解释异常原因这种接入权限问题很小相当于给系统加了个高级查询界面。第二种是“写操作型接入”AI能帮你创建销售订单、释放生产工单、改完工数量、做质量放行。麻烦来了这些操作原本在ERP和MES里都是要走流程的有审批链、有职责分离、有数据权限范围。一旦AI工作台能直接触发这些动作它实际上就成了一个“特权操作员”。我参与过不少此类集成90%的翻车现场都出在第二种。业务方诉求特别简单“我们想让领导在群里用一句话搞定审批和派工。”技术方一听就觉得MCP天生合适工具调用、上下文携带、会话往返全都现成的。但没人想清楚一个关键问题当领导在AI对话框里说“把工单WO-240815-03改成已完工”的时候系统凭什么相信“这个人”就是有权限做这个动作的人这个“凭什么”就是权限系统的事。1.2 MCP热潮下的流行误解MCP全称Model Context Protocol模型上下文协议。它是在模型和外部工具之间建立的一套标准化对话方式客户端把模型想调用的工具名、参数传过去服务器执行完回传结果。打个比方MCP就像给AI装上了“手”让模型不仅能“想”还能“动”把大模型从聊天窗口拽进业务流程里。但问题恰恰出在这个“动”上。很多技术文章、厂商分享都在强调“让AI去操作ERP”“AI一键访问MES”话术传着传着非技术背景的管理层就形成了一个错觉既然AI工作台已经能调用业务系统了那是不是连传统那套繁琐的账号、角色、审批都不用管了反正AI比人靠谱。这个误解太危险了。MCP定义的是“客户端与服务器之间如何通信”它压根不关心“此刻操作的人是谁”。协议里没有用户身份字段没有角色属性没有权限校验节点更没有任何审计约定。它只负责两件事告诉模型“有哪些工具能用”以及“怎么把结果送回去”。至于这个工具背后是不是违了权MCP不管也不该由它来管。一批新入行的工程师也容易在“技术兴奋感”里犯错。他们调试MCP工具时发现一个工具调用就能修改MES数据库里的状态觉得“权限也就这样”“只要模型不犯错就行”。事实上工具调用成功代表的是“连接是通的”不代表“操作是合法的”。你要给AI工作台配的是一个能定义“谁能操作、能操作哪些数据、操作到什么程度”的完整外围体系。2. MCP的边界在哪里它管不了“谁能碰什么”2.1 企业权限体系自带的东西MCP一件都没有你可以把企业权限系统想象成一栋大楼的门禁体系大门看门禁卡楼层看门禁卡房间还要看门禁卡进机房要单独授权操作财务系统要走二次审批。这套体系包含几个核心组件身份库解决“你是谁”认证机制解决“你怎么证明是你”授权模型解决“你能进哪间房、动哪台设备”职责分离解决“不能既当运动员又当裁判员”审计追踪解决“出事后倒查谁在什么时间干了什么”。ERP和MES的权限体系比普通软件更严格因为它们背后是实打实的业务账。一个销售订单被误删可能引发交货违约一个工单被提前报工可能直接扭曲成本核算一个批次被错误放行涉及产品质量追溯问题。这些系统的权限设计从来不只是“防外人”更是防内部流程失效。MCP有什么它只是一套消息格式和调用约定。它告诉你协议握手怎么发、工具列表怎么列、请求响应怎么封装。它根本不区分调用者是一个操作员、一名车间主管还是一个AI代理本身。你用MCP连上一台MES服务器只要服务器端允许匿名调用或者密钥放行了那它就是能执行。这相当于大楼门禁全部失效只剩房间里装了个摄像头能看到谁进来了但拦不住不该进来的人。2.2 一张表看明白MCP协议和权限系统的分工能力维度MCP协议企业权限系统工具发现支持向模型暴露工具清单不负责一般通过接口清单或菜单权限控制身份认证无客户端连接即建立会话完整多因素认证、单点登录、证书体系授权决策无工具是否可用由服务器自行判断完整支持角色、数据范围、分级审批职责分离无工具可被任意客户端调用支持创建与审批分离、双人复核数据权限无参数传什么就处理什么支持按组织、工厂、客户区间隔离数据审计追溯无法标识业务用户只能记录“客户端调用”完整用户、终端、时间、操作前后值全记录这张表你不用背下来记一个核心就行MCP解决工具通不通权限系统解决人能不能碰。两者根本不在一个维度。你不可能因为装了一套USB标准就取消写字楼的门卫和工牌。2.3 为什么“模型知道”不等于“模型被授权”还有一个更隐蔽的误区我管它叫“AI知识幻觉”。不少企业管理者觉得AI工作台里装了ERP和MES的MCP服务器之后模型“知道”了业务流程就等于模型“有权”执行这些流程。这个想法必须纠正。举个很简单的例子。AI工作台接入了MES的查询工具模型通过这个工具读到了车间所有工单信息包括不合格品批号、设备故障记录、人员工时。这时候你的AI工作台负责回答班长提问“这批不良品原因是什么”它答得头头是道。但同一个模型如果被别人接手问“你们生产线的物料齐套率是多少”它也能答。模型输出内容的范围取决于它调用的工具能拉回什么数据而不是取决于提问人有没有权限看这些数据。这就是典型的“信息越权”。传统权限系统里数据按照角色隔离一个班组长看不到他管辖范围之外的成本数据因为查询接口会拦截。但当AI工作台通过MCP服务器去调数据时服务器为了“提高AI回答效率”往往会把工具设计成“全量数据可见”。你以为是在给AI增加能力实际上是给所有人都开了一扇全数据查看的后门区别只是这个“后门”伪装成了对话框。我见过最离谱的案例是一家工厂的信息科为了让AI工作台“懂计划”把整套BOM、工艺路线、在制订单、库存成本明细全部放进了工具描述和上下文窗口里。结果一线员工通过对话问一句AI就能说出公司毛利润和管理口径的成本分摊。这种越权在传统界面里绝对不会发生因为报表系统有权限项但一到AI工作台这里全部穿透了。所以必须重申模型知道得多不等于它可以操作得多MCP把数据递到你眼前并不能替权限系统判断这个数据该不该让你看见。3. 可落地的集成方案把权限留在网关让AI只当接口3.1 推荐的架构AI工作台 → 受控MCP网关 → 企业连接器既然MCP不能替代权限系统那正确的集成姿势是什么我的建议非常明确让MCP老老实实做它的“传输协议”把权限逻辑集中放在网关层。架构分三层。第一层是AI工作台也就是用户面对的那个对话框第二层是受控MCP网关它不是直接对接业务数据库而是把所有MCP工具请求都拉到统一入口第三层是企业连接器负责把网关的请求翻译成ERP或MES能懂的API调用。关键点在于MCP工具暴露给模型的只是“接口外壳”真正的权限判定放在网关后面的企业连接器里做。这样设计有三个直接好处。第一AI工作台无论如何换模型、换版本权限逻辑不受影响网关和连接器像防火墙一样挡在前面。第二模型看不到底层数据库连接信息既不会有注入风险也不会因为提示词泄露工具内部配置。第三权限变更只需改网关和连接器侧的角色映射不用重新训练模型也不用重新配置每个MCP服务器。我接触过一些快消品的制造企业他们的AI工作台想接ERP直接调用了原厂的开放接口结果出了一个很尴尬的问题每个MCP服务器都持有连接ERP的高权限账号等于钥匙散落各处。后来改成统一网关方案MCP服务器只保留“调用网关”的权限具体能摸到哪些ERP数据由网关内审险规则决定问题才解决。3.2 权限映射怎么做从角色、数据范围到审批流很多人问我“那网关里的权限该怎么设计是不是做个用户和角色的绑定就行”实际操作远比绑定复杂。我把需要梳理的权限项归纳成四类直接照着做即可。第一类是功能级权限也就是“你能不能做这个动作”。比如“创建销售订单”和“创建生产工单”要分开MES里“派工”和“报工”要分开“质量放行”和“工单关闭”也要分开。第二类是数据级权限也就是“你能碰哪块数据”。例如一个车间主管只能操作自己车间的工单一个销售只能看自己负责的客户和订单ERP里一个工厂的库存数字对另一个工厂的人必须不可见。第三类是审批级权限也就是“做了动作要不要别人确认”。很多复杂业务需要两级审批班组长提交车间主任确认计划部再释放。第四类是特例权限也就是“临时紧急授权”这种授权必须带失效时间比如机房管理员临时开放一个窗口24小时后就收回。我建议用一张权限矩阵表把这几类列清楚横轴是业务流程节点纵轴是角色交叉处填上“仅看、可提交、可审批、可释放”等动作词。这张表做完再把它落到网关上。别想着一次性做到百分之百精细边界明确、能落地就行。初期可以先用“按角色按工厂”粗粒度控制跑通后再细化到具体单据类型。3.3 一个真实配置示例MCP工具与角色绑定的具体写法光讲概念不够我直接拿一个常见的“修改MES工单状态”工具当例子。假设你在AI工作台里配置了一个MCP工具叫update_work_order_status它能修改工单状态。如果你的MCP服务器直接调用MES接口那就等于让AI拥有改工单的超能力。正确做法是网关拦截再做校验。我在系统里通常这样描述这个工具工具名仍然是update_work_order_status参数包括work_order_id、target_status、remark。但网关收到调用后不是直接执行而是先查当前用户身份再走权限判断。伪代码如下function updateWorkOrderStatus(user, workOrderId, targetStatus): // 1. 身份确认 operator identityManager.getUser(user.sessionToken) if operator is null: return 未登录或会话过期请重新认证 // 2. 功能级权限检查 if not permission.hasPermission(operator, WorkOrder.UpdateStatus): return 当前角色没有修改工单状态的权限 // 3. 数据级权限检查 order mesClient.getWorkOrder(workOrderId) if order.plantId not in operator.dataScope: return 无权操作该工厂的工单 // 4. 审批流检查 if targetStatus in [completed] and not approval.isApproved(order, 工单完工): return 工单完工需要车间主任审批当前操作未获准入 // 5. 操作记录 auditLogger.log(operator.id, updateWorkOrderStatus, workOrderId, targetStatus, timestamp) // 6. 执行并返回 return mesClient.executeUpdate(workOrderId, targetStatus)你可能会问这套逻辑是不是绕远了直接让MCP工具自己判断不行吗我劝你千万别写进MCP工具实现里。原因有两条第一MCP服务器可能被多个客户端复用权限逻辑耦合在工具里会导致改权限就得重发服务第二MCP工具代码通常由不同小组维护权限逻辑散落在各个工具里审计时根本没法集中追溯。放到网关统一管控等于把审批、校验、日志集中成一个关卡管理成本和出错概率都会低很多。还有个小提示AI工作台在给用户返回结果时也要把网关的拦截信息原样带回去。比如上面第4步没有权限网关返回“需要审批”时AI应该回复“工单已提交待审批请让车间主任确认”而不是自作聪明地说“无法操作”更不要装作没看见。这个细节要在提示词和系统设计里一起约束否则业务用户会以为AI出故障了。4. 实施中常见的坑与排查手册4.1 越权、绕行、审计断层三个最典型的“事故现场”得多说一句AI工作台接入ERP和MES后出现的权限问题和传统软件权限问题长得不一样。传统系统越权通常是账号密码泄露AI工作台却会平白多出这些情况。第一个事故现场绕过界面直接调用MCP工具。有些员工发现AI工作台和业务系统的登录态是分离的。业务系统半天没操作自动退出但AI工作台这边还挂着会话于是MCP服务器带着残留的令牌直接调ERP接口。结果就是操作动作有效但业务系统审计日志里找不到对应的“人”只有一串服务账号的ID。处理办法是网关层必须强制会话同步和超时回收一旦打开AI工作台超过15分钟没有业务操作立刻要求重新登录。第二个事故现场提示词让权限检测形同虚设。我见过一些MCP工具设计得很“聪明”比如工具参数里带一个forcetrue或者ignorePermissiontrue本意是给管理员提供紧急通道。结果员工通过AI对话框用自然语言描述“绕过审批直接完成”模型自动把这类参数填了。这事真发生过事后追责时模型“一脸无辜”但改数据的事实已经发生。我的建议是网关层直接过滤掉这类参数或者压根不把它们暴露在工具描述里。第三个事故现场审计日志断链。传统系统里审计记录是这样一条链用户A在14:32登录操作了销售订单SO-10086改动了价格。AI工作台里日志变成模型代理B在14:32调用update_sales_order参数为so_id10086。中间用户A去哪了丢了。这不是代码bug是设计缺陷。日志里必须记录三个身份业务用户、AI会话ID、MCP工具调用ID三者关联才完整。缺失任何一个事后排查基本抓瞎。4.2 安全配置自查清单直接抄作业版下面这份自查清单是我在多次实施中反复调整出来的不保证覆盖所有系统但照着做至少能避开80%的坑。你可以直接拿去当项目验收标准。【身份】AI工作台是否严格使用企业统一身份认证有没有允许本地账号绕过【会话】MCP网关会话是否绑定用户令牌失效时间是否设为15分钟或更短【工具暴露】工具列表是否只暴露当前角色可用的工具是否隐藏了全部内部附件和说明【参数校验】网关是否校验了所有传入参数是否存在force、ignorePermission之类危险参数【数据范围】企业连接器是否按工厂、组织、客户等维度过滤数据是否做过黑盒测试【审批流】每个写操作是否都校验了审批链是否允许“人工审批但AI代填”【审计】日志是否完整记录用户、会话、工具、参数、结果、时间六要素是否不可篡改【密钥管理】MCP服务器和连接器之间的密钥是否定期轮换是否存在写死在代码里的连接串【灰度方案】是否先在小范围角色和工厂试点有没有一键停用AI写操作的应急开关【权限复核】是否定期复查权限矩阵每个AI工具调用是否有月度权限对账每次答“否”的项基本就是你必须马上处理的隐患。别杠“哪有那么严重”项目上线前多花三天总比上线后数据错了再花三周返工强。4.3 我对“权限下沉到MCP”方案的结论个人经验最后聊点个人经验。早些年我做过一个技术选型把权限规则直接编码在MCP服务器里当时图省事以为既然工具就几个,直接在每个工具函数开头加上if判断不就完了。结果第一个版本刚上线一周就出问题。仓库主管换岗后旧角色没有及时清理他仍然能通过AI工作台调用MES的入库工具。如果权限集中在网关这个问题一到换岗交接就能被权限复核流程发现。散在工具里查了三天才定位到一个MCP服务器的缓存没刷新。另一件让我记忆深刻的事是给一家装备制造企业搭建AI工作台时业务部门总催着要“一步到位”。他们恨不得所有角色都能在对话框里呼来唤去。我坚持在网关层做了两档权限普通操作档只允许查询和提交审批释放档单独给中层以上。上线第一个月有个班组长尝试通过AI直接关闭工单被网关拦截提示“待车间主任审批”他不但没抱怨反而觉得这样流程更清晰。这给了我很深的体会权限不是阻碍AI价值的绊脚石它反而是AI工作台能长跑的前提。所以我最后的建议是把MCP当成AI工作台和业务系统之间的一根数据线它负责稳、快、准地传递动作而权限系统是那把锁它决定哪个动作能被谁触发、能在什么范围内生效、会留下什么痕迹。两件事各司其职AI工作台才不会从效率工具变成事故工具。每次有人再跟你说“MCP能替代企业权限系统”你都可以问问出了事你打算拿谁去扛