AI 工作台连上了 MCP，工具列表也拉得回来，演示时能查出一条真实数据。真要把这项能力交给业务部门日常使用，安全与内控还是会问同样几个问题：这次调用算谁的？能查到哪些订单？写操作会不会在没人确认的情况下完成？出了问题怎么查？员工离职后旧会话里的工具还能用吗？MCP 为工具发现、调用和 HTTP 传输授权提供机制；但员工身份如何映射到业务系统、能看到什么、写入是否需要确认、记录留多久、授权怎么收回去，仍需企业配置与验收。这篇文章把协议层与企业治理层的职责分开，给出连通之后需要补上的五件事和一份自查清单，供架构与安全团队判断自己的 MCP 落地还缺哪一段。
MCP 提供工具调用的标准接口。工具接上了，只说明链路通；身份、权限、确认、审计、撤权这五件事，仍然要企业自己补齐。缺一件，就会在真实业务场景里卡住。
工具列表拉到了，业务为什么还是不敢用
设想一次内部评审：IT 团队把接口和数据库视图发布成 MCP Tool，AI 工作台能看到工具清单，测试时也查回了订单。准备交给业务部门试点时，安全负责人追问前面五个问题。如果答不上来，试点就应先收窄到只读查询。这里是方法示例，不代表客户项目。
安全负责人追问的是业务侧必须回答的边界。工具能被调用，和这次调用代表谁、能触达哪些数据、会不会产生写操作、事后能不能还原，本来就是两件事。前者由协议解决，后者由企业的治理层解决。两层混在一起，最自然的做法就是把治理问题当成技术问题，用一句「接口都通了」回答。等到一个跨系统、跨岗位的真实场景进来，会发现卡住的地方全在接口之外。
MCP 管调用，企业管边界
把职责拆开看，这两层各自负责什么、缺了会怎样，清楚很多。
| 维度 | MCP 协议层负责 | 企业治理层负责 | 缺失后的表现 |
|---|---|---|---|
| 工具发现 | 以统一方式暴露工具清单与参数 | 决定谁能看到哪些工具（按员工、用户组或组织授权） | 若未另行授权，工具可见范围可能过宽 |
| 调用通道 | 统一调用方式与返回结构 | 每次调用前重新校验授权 | 撤权之后旧会话仍可发起调用 |
| 调用者身份 | 传递调用身份信息 | 把 AI 用户映射到目标系统员工个人账号 | 说不清这次调用代表谁，责任无法归属 |
| 数据范围 | 不定义数据可见范围 | 由目标系统对功能权限与数据权限作最终判断 | 只看得到工具，看不到数据边界 |
| 写操作 | 不替企业决定写入确认策略 | 新增、修改、删除、审批默认要求员工确认 | 自动化范围失控，写入无人负责 |
| 记录与回收 | 不替企业制定业务审计留存与撤权流程 | 记录调用并支持查询导出；撤权在服务端阻断执行 | 事后无法定位，离职权限收不回来 |
右列的企业业务规则需要在产品与目标系统中配置和验收。MCP 规范包含可选的传输层授权，但不会替企业决定岗位数据范围、写入确认、审计留存和业务撤权流程。星云 PLUS AI 系统连接器做的事，是把企业已有的数据、接口、业务页面、Skill 和 Agent 发布成可授权、可确认、可审计的业务能力，对外执行面统一为 POST /mcp，现行固定协议版本为 2025-06-18。
连通之后要补的五件事
把调用映射到真实员工。支持自定义认证，将 AI 用户映射到目标系统员工个人账号。传一个公共高权限账号更好配置，欠下的是责任归属：所有操作都归到同一个账号，审计里分不出谁做了什么，员工离职也收不干净。AI 应该代表具体员工办事。
让权限判断发生在两层。连接器先判断当前员工能否调用某项能力，回答的是「这个人和这项能力之间有没有授权」；目标系统再对功能权限和数据权限作最终判断，回答的是「这次查询能返回哪些行、哪些字段」。AI 不会获得员工个人账号之外的额外权限。
给关键操作划一条确认线。查询、校验、预填可以自动完成；新增、修改、删除和审批默认要求员工确认。企业可以按具体业务能力配置「必须确认」或「允许自动执行」。审批一张付款单和更新一条备注，风险本来就不一样，用同一个开关处理迟早出偏差。
让每次调用可查、可导、可溯源。记录员工与 AI 身份、调用入口、业务能力、目标系统、时间、耗时、结果和输入输出摘要，并支持查询与导出。审计保存期限由企业自己配置，不写死天数。有了这份记录，才能把「AI 说过什么」推进到「谁用什么能力对哪个系统做了什么」。
让撤权落在服务端。撤权之后，后续调用被拒绝，尚未返回的调用被中止。只把入口从界面上拿掉，不算撤权。客户端是否缓存着旧工具列表，不应该成为撤权是否生效的变量。
这五件事分成两组：前两件决定调用是否合法，后三件决定出问题之后能不能交代清楚。哪一件都可以先做，但一件都不做就开放给业务，风险只是被推迟暴露。
自查：你的 MCP 落地缺哪一段
下面五个问题不需要看架构图。答不上来的那一条，就是当前缺的那一段。
| 自查问题 | 如果答不上来 | 缺的那一段 |
|---|---|---|
| 这次调用代表哪一个员工？ | 说明调用身份是共享的或缺失的 | 身份映射 |
| 同一个人换了岗位，能查到的单据范围会变吗？ | 说明数据范围没有跟随员工权限 | 两层权限 |
| 一个写操作会不会在没人点确认的情况下完成？ | 说明确认策略没有按能力配置 | 关键操作确认 |
| 上周某次返回错误的调用，能查到它的输入输出摘要吗？ | 说明记录只到对话层 | 调用审计 |
| 员工今天离职，他缓存里的工具明天还能用吗？ | 说明撤权只做了界面层 | 服务端撤权 |
前两问决定「能不能放开给业务用」，后三问决定「出事之后能不能说清楚」。两组问题通常不会同时暴露。往往是试点范围从只读扩展到写入时，后三问才一起冒出来。
几条容易被含糊过去的边界
连通不等于可用。 工具订阅成功、列表拉得到，只说明链路通。能不能真正调通业务能力，还要看授权配置、身份映射和目标系统状态，这两件事要分别确认。
页面预填不等于提交成功。 AI 在原业务页面里提取、校验并填好字段之后，是否真正生效，以页面回执或目标系统的结果为准。
「权限不足」要看是哪一层给的。 同一个错误提示，可能来自连接器侧未授权、目标系统功能权限不足、数据权限受限或账号状态异常，四者的排查方向完全不同。日志里区分清楚，能省掉一轮来回。
这是有边界的表述。 部署形态、接入方式与兼容范围需要结合企业现有网络、系统条件和运维边界评估，具体范围以项目评估为准。
验收时看什么
治理层做没做到位，五个动作就能看出来，都可以在实际产品能力演示中核对。演示使用演示或脱敏数据，不代表任何客户的上线成果。
- 用两个不同岗位的员工账号发起同一次查询，确认返回的数据范围不同，并且差异来自目标系统的数据权限判断。
- 让 AI 在原业务页面里预填一张单据，确认预填完成后没有自动提交，提交动作由员工本人触发。
- 从审计里检索一次调用，确认能找到员工、入口、能力、目标系统、时间与结果，而不只是对话记录。
- 撤权之后不刷新客户端直接发起调用，确认被服务端拒绝；对一项耗时较长的查询在调用进行中撤权，确认未完成调用被中止。
- 换一个 AI 入口发起同一项业务能力，确认身份、权限与审计记录的口径一致。
前两项通常在首个场景联调时就能查清。后三项偏配置与流程核查，要连上审计和授权管理一起看。
结语
MCP 让企业不必为每个 AI 入口重做一遍对接，这是它的价值。接入方式统一之后，决定 AI 能不能进入真实业务的，是企业自己划的治理边界。把「不换系统、沿用员工权限、关键操作人确认、调用审计」这条链路走完，AI 才能从「能调工具」走向边界清晰的业务办理。
下一步可以先缩小范围。先选一项边界清晰的只读查询，把身份映射、两层权限和调用审计跑通，再扩展到写操作与审批环节。具体接入范围、部署形态与实施周期，以项目评估为准。
常见问题
已经有 MCP Server 了，还需要连接器做什么？
MCP 规范工具发现、调用和可选的传输层授权方式，业务系统仍需要明确调用者身份、数据范围、写入确认、审计与撤权。两者解决的问题不同：一个负责「接得上」，一个负责「管得住」。如果团队已经自己把这几件事补齐，也可以直接基于标准 MCP 客户端接入。
标准 MCP 客户端能直接用吗？
可以。已发布并已授权的能力通过统一 MCP 服务供 WorkBuddy、DeepSeekHarness 和标准 MCP 客户端使用。不同入口的身份映射与审计口径需要统一，否则同一项能力在不同入口会得到不同的可追溯程度。
这五件事是产品自带还是要企业自己开发？
都属于连接器的配置与治理范围，不需要为每套业务系统重写一遍。能覆盖到什么程度，取决于目标系统的接口能力、账号体系和权限模型。有完整接口的可以走 RESTful 接口，只有数据库的可以从只读查询开始，只有业务页面的可以复用原页面。是否需要补充接口，以系统评估为准。
了解产品能力，可参阅AI 系统连接器与安全与治理。相关阅读：连接器授权与数据权限、工具可用性验收。
从一个只读场景开始评估
带上员工角色、目标系统和预期结果，核对身份映射、两层权限与审计记录。
预约连接评估