MCP 连接器接入企业系统，权限应该放在哪一层

一个MCP服务暴露了“查询订单”工具，不代表所有员工都能查全部订单。源系统先限制账号能力，连接器再限制工具和字段，嘟哩按组织与项目授权，任务执行时校验用户，结果保存前再次检查目标空间。每条结论都要保留业务对象、时间、来源和权限范围，失败或冲突时明确提示，并停止未经确认的写入。

企业接入一个MCP服务后，AI马上多了“查询订单”“创建工单”“更新项目”这些工具。演示看起来顺畅，安全负责人会继续问：工具背后使用谁的账号，普通员工和主管得到的数据是否一样？

MCP标准化了工具发现和调用，不会自动替企业设计权限。权限要分层，每层解决不同问题。

用户在项目里没有客户合同权限，AI 却通过一个管理员连接器读到了它

实施人员为了快速打通 CRM，用系统管理员账号创建了 MCP 连接器。普通项目成员让 AI 整理客户交付风险时，连接器按管理员身份返回了合同金额和付款记录。从源系统看，调用是合法的；从当前用户权限看，这是一次越权。

MCP 连接器不会自动继承企业所有业务权限。只要连接器使用的源身份高于发起人，就必须在工具调用前再做一次业务范围和任务授权校验。否则“能接入更多系统”会同时变成“能绕过更多权限”。

第一层是源系统权限

ERP、项目或数据库本身应限制账号可访问的组织、项目、表和动作。能使用用户级授权时，优先以发起人身份调用；只能使用服务账号时，账号本身遵循最小权限。

不要给连接器一个超级管理员账号，再期待上层永远过滤正确。源系统是最接近数据的最后防线。

第二层是连接器工具范围

MCP服务只暴露经过批准的工具和字段，区分只读与写入，对查询量、时间范围和批量动作设限。凭据、环境、维护人和版本由管理员管理。

开发、测试和生产使用不同配置。连接器升级后重新验证工具清单，避免新增能力被默认开放。

第三层是平台组织和业务权限

嘟哩根据部门、岗位、项目和应用权限决定谁能使用某个连接器或技能。能调用“项目查询”不等于能查看所有项目，业务对象范围继续受嘟哩项目和源系统约束。

管理员可以给测试团队开放缺陷读取，不开放生产数据写入；给电商运营开放商品查询，不开放成本字段。

第四层是当前任务授权

Agent执行时显示即将调用的工具、输入范围和账号。低风险查询可以预授权，高风险写入需要人工确认。任务范围改变时重新授权，不能拿一次确认无限扩张。

第五层是输出权限

AI查到的数据生成报告后，保存到哪个项目、发给哪个群还要再次校验。来源有权限，不代表目标空间所有人都有权查看。

输出尽量保留来源标识和数据时间。敏感字段可在展示层脱敏，但不能把脱敏当作源系统授权的替代。

审计要串起五层

记录发起人、任务、工具、连接器、源系统身份、输入范围、返回摘要、确认人、输出位置和结果状态。日志既要能追溯，也要控制正文留存，避免形成新的敏感数据仓库。

连接器失败或权限不足时，AI明确说明缺失，不用旧缓存生成确定答案。能安全失败，是企业连接能力的重要标准。

一次调用要同时通过五层权限

层级	这一层管什么	“读取客户风险”示例
源系统	连接账号在 CRM 里有哪些权限	技术账号可读客户基本资料，不可读付款明细
连接器工具	MCP 服务对平台暴露哪些读写动作	只开 customer.read 和 risk.list，不开删除与导出
嘟哩业务	当前用户对客户、项目和部门的可见范围	只允许查所属交付项目关联客户
当前任务	这次任务是否被允许调用工具、参数范围是什么	只读当前项目客户 ID，不允许自由搜索全库
输出与写入	结果能给谁看、能写到哪里、是否需人工确认	金额字段脱敏，生成项目风险草稿，人工确认后写入

这五层的交集才是实际可执行范围。源系统账号是管理员，不代表嘟哩里的每个用户都得到管理员权限；反过来，嘟哩允许用户查项目，也不代表源系统会返回无权字段。任何一层拒绝，系统都应停止并记录具体原因。

审计日志要能还原一次决定

日志不只记“调用了 CRM 工具”，还要记发起人、AI/技能版本、连接器身份、工具与参数范围、五层权限判定、返回字段、脱敏、写入目标和人工确认人。验收时分别使用有权、无权和权限刚被回收的账号运行同一任务，检查缓存和历史结果是否仍可以绕过新权限。

MCP 权限验收要模拟三种账号

同一个“读取客户风险”任务，用管理员、普通项目成员和刚被移出项目的成员分别执行。若三个人拿到同样结果，连接器权限就没有真正继承业务边界。

环节	要记录什么	通过标准
源系统	连接账号、接口权限、字段范围	不使用无限管理员账号
嘟哩业务	组织、项目、客户、资料权限	只能读当前用户可见对象
任务授权	本次目标、参数、工具、确认人	不能自由扫全库
输出	脱敏、保存位置、可见范围、写入确认	结果不扩大权限

MCP 连接器的价值是把企业系统接进 AI，不是绕过企业权限。嘟哩要把源系统权限、连接器权限和业务权限做交集。

怎么验收

验收日志要能还原一次调用：谁发起、用哪个工具、传了什么参数、返回哪些字段、为何拒绝或允许。缺日志就不能上线高权限连接器。

真正落到产品页面时，要看到这些东西

安全负责人进入连接器权限中心时，第一眼应该看到一次 MCP 工具调用的当前状态，而不是一段功能介绍。入口动作也要直接：先确认作用域和权限交集，再允许 AI 调用工具。用户每做一步，系统都要把输入、确认人、状态和产物留下来，后面 AI 才有可靠上下文。

页面区域	业务字段	系统状态	AI 动作
源系统	连接账号、接口权限、字段范围	当前状态、责任人、来源链接、更新时间	AI 检查“不使用无限管理员账号”，并给出缺口待办
嘟哩业务	组织、项目、客户、资料权限	当前状态、责任人、来源链接、更新时间	AI 检查“只能读当前用户可见对象”，并给出缺口待办
任务授权	本次目标、参数、工具、确认人	当前状态、责任人、来源链接、更新时间	AI 检查“不能自由扫全库”，并给出缺口待办
输出	脱敏、保存位置、可见范围、写入确认	当前状态、责任人、来源链接、更新时间	AI 检查“结果不扩大权限”，并给出缺口待办

一天的真实使用路径可以这样设计：早上先打开看板看今日待确认事项；上午补齐缺失资料或接口数据；下午让 AI 生成分析、脚本、用例、风险或方案；执行前由负责人确认关键动作；晚上把结果、问题和下一步沉淀到同一个项目。这样用户不会觉得自己在“找 AI 聊天”，而是在推进一件有开始、有负责人、有产物、有复盘的工作。

产品里还要保留两个不太讨好、但很重要的状态：一个是“资料不足，不能判断”，另一个是“超出当前范围，建议拆分或延期”。这两句话会让页面看起来没有那么神奇，却能减少错误决策。企业场景里，靠谱比炫技更值钱。

边界说明

连接器接入能力取决于源系统接口、账号权限和审计支持。嘟哩要做的是统一任务授权和输出治理，不应绕过源系统权限。

读者真正会感受到的变化

以前大家只关心连接器能不能读到数据；现在先看源系统权限、嘟哩业务权限、任务授权和输出范围的交集。AI 能接入更多系统，但不会因为连接账号权限高，就默认替每个用户读全库。这段体验变化要在试点中被记录下来：用了几个入口、问了几个人、返工发生在哪一步、最终产物是否能被下一次复用。只有这些细节存在，文章里的方案才不是概念说明，而是能被团队带回去照着检查的工作方法。

常见问题

MCP协议是否自带企业权限模型？

不能把协议支持工具调用等同于完整企业授权，实际权限仍需源系统、服务和平台共同实现。

服务账号和用户授权哪种更好？

用户授权边界通常更细，服务账号便于集中运维。选择取决于源系统能力，并需补充最小权限与审计。

AI只读查询还需要确认吗？

低风险查询可预授权，高敏或大范围查询仍可能需要确认、限额和审计。