把 MCP 当成"数据库连接器"是内网落地最常见的错。不少团队给 Agent 开一个高权限账号，让模型自己决定查哪张表，演示阶段跑得通，进生产第一周就撞上三件事:越权、查不到、查到了不敢用。
MCP 定义的是"模型如何发现与调用工具"，它没有定义企业级权限模型，剩下的边界要企业自己补。下面按内网实际施工顺序,讲清服务形态、授权、审计、网关与端侧切分。
一、落地形态:MCP Server 是包在内部系统前面的适配层
Anthropic 开源 MCP 时的定位很明确:它提供一套通用开放标准,把 AI 系统与数据源连起来,用单一协议替代碎片化集成。注意这句话的重心是"替代集成",不是"开放数据"。
所以内网里正确的形状是:Agent 客户端只认识工具目录,不认识数据库连接串。MCP Server 落在内部系统前面,把"查我负责的工单"这类业务动作翻译成一次受控的 API 调用。MCP 从有状态的双向协议变成了无状态的请求/响应协议,这版规范的正式版本号是 2026-07-28,官方把它称为一次"无状态内核"的升级。
反面清单通常就三条:
- 不让模型直连数据库、缓存或消息中间件;
- 不给 MCP Server 一个万能服务账号,工具内部必须换成具体调用人的身份;
- 不把整套 REST API 自动"工具化",只暴露确实需要模型决策的那几个动作。
工具就是权限的白名单单元。把"读列表"和"删记录"塞进同一个工具,等于一开始就放弃最小权限。适配层做对只是其中一环,整条链路上的工程闸门可以对照AI 软件开发工程化实战：从 Demo 到生产的六道关卡逐项检查。
二、权限:按人授权,而不是按 Agent 授权
这版规范有个容易忽略的细节:每个请求自带协议版本、客户端身份和客户端能力，都放在 _meta 里。协议层能告诉网关"是哪个客户端、带哪些能力",但终端用户的身份不在其中——它必须由企业自己的鉴权链路注入。
这就是"按 Agent 授权"必然出问题的原因:一个共享服务身份会把所有人的操作混成同一个主体,平时看不出差别,出事时审计直接失效。
建议按三层拆:
- 用户身份层:SSO 或 OAuth 换来的短时凭据,绑定具体的人;
- 数据域层:这个人属于哪个组织、能看哪个租户的数据;
- 工具 scope 层:能调用哪些工具、哪一类动作。
三层都必须在 MCP Server 或网关侧校验。只在客户端过滤没有意义,客户端是用户可以改的。
权限矩阵只写维度,取值由企业自己填
| 维度 | 典型取值 | 维护方 | 校验点 |
|---|---|---|---|
| 发起人身份 | SSO 个人账号 / 受控服务账号 | IAM | 网关 |
| 数据域 | 组织 / 租户 / 项目 | 业务系统 | MCP Server |
| 工具标识 | 具体工具名 | 平台团队 | 网关 |
| 动作级别 | 读 / 写 / 删除 / 审批 | 平台团队 | 网关 |
| 数据敏感度 | 公开 / 内部 / 敏感 | 数据治理 | MCP Server |
| 运行环境 | 生产 / 预发 / 测试 | 运维 | 网关 |
| 审批要求 | 免审 / 单人 / 双人 | 风险合规 | 网关 + 审批流 |
"动作级别"和"审批要求"必须联动:删除、批量导出、改价这类写操作走双人复核,读操作免审。矩阵里不填具体数字是有意的——取值取决于你的系统清单,抄别人的阈值只会把风险抄进来。
人在环不必自己造轮子。规范里的 Multi Round-Trip Requests 就是为此设计:工具调用中途需要确认或缺少参数时,服务端返回 input_required,客户端带着答案重试原调用。审批评审可以直接挂在这个往返里,不必在应用层再拦一道,也不会让模型绕过确认。
三、审计:一次工具调用要能还原五段痕迹
"日志有没有写"和"出事能不能还原"是两件事。要还原一次工具调用,至少留五段:
- 谁发起:用户、客户端标识、会话;
- 调了什么:工具名与动作级别;
- 入参:脱敏后的参数快照;
- 出参:结果摘要与条数,失败则记错误类型;
- 是否被采纳:模型最终答复有没有引用这次结果。
排查时倒着走最快:从一句错误答复,回溯到它引用了哪次工具返回,再回溯到当时的入参与授权判定。
和等保、内审对接时,几个常被漏掉的点:
- 入参里的手机号、证件号、地址要在落库前脱敏,但保留可回溯的哈希,否则复核时对不上;
- 日志不可篡改:写只追加存储,业务侧没有删除权限;
- 审计员账号只读,且要能按"人"和按"工具"两个维度检索,内审问的通常是"这个人用过哪些工具";
- "结果未被采纳"要单独记:调了工具但答复没用它,和采纳后答错,责任完全不同。
四、网关:一个出口,而不是每个系统各写一套
这版规范让网关设计简单了一截:方法名与工具名放在 Mcp-Method 和 Mcp-Name 两个 HTTP 头里,网关可以直接基于头部做路由与鉴权,不必解析 JSON 正文。协议无状态之后,任意请求能落在普通轮询负载均衡后的任意实例上,不再需要粘性会话。
这两点合起来意味着:限流、熔断、脱敏、审计采集都可以收拢到一个统一出口,而不是让每个业务系统重复实现一遍校验逻辑。
网关至少要承担:身份换成内部凭据、scope 校验、按"用户 × 工具"维度限流、超时、失败降级、敏感字段脱敏、审计落库。两个坑值得先说:
- 限流按 IP 没意义。同一个出口 IP 后面是几百个用户,按用户加工具限流才能拦住某个 Agent 反复重试把内部系统打挂;
- 工具超时要返回明确失败,不要返回空结果。空结果会被模型当成"事实"写进答复,比报错难查得多。
还有一个新出现的坑:工具目录现在支持缓存提示,客户端可以缓存列表结果。缓存 key 必须包含用户与权限维度,否则 A 看到的工具清单会被 B 复用,越权就从缓存里漏出去了。
五、Web 端与移动端共用工具层怎么切
共用的是工具定义与权限判定,不是传输链路。两条底线:
- 移动端不持有内部凭据。写进 App 包里的 token 等于公开,移动端只走 BFF 聚合接口,由服务端换内部凭据;
- 端侧差异放渲染层,不放工具层。同一个"查审批"工具,PC 返回完整列表、手机返回摘要,由 BFF 裁剪字段,工具本身不改。
这样切的好处是权限只有一份实现,不会出现"PC 端拦了、App 端忘了"的缺口。代价是 BFF 要做字段裁剪,不能直接把内部响应透传出去。移动端这条线的坑和 Web 端不太一样,移动端 AI Agent 工程化实战：安卓与 iOS 的三道坎里有更细的拆解。
移动端要额外加固的是设备侧:短时 token 加设备绑定,高危操作再触发一次 input_required 确认,避免手机丢失后被重放。这类重放攻击在无状态协议下更容易发生,因为网关不能靠会话状态识别"这不是同一个客户端"。
六、和 A2A、自定义协议怎么共存
判断标准只有一条:这一层解决的是"模型与工具"还是"Agent 与 Agent"。MCP 的边界在工具,不在协作编排。
- 该用 MCP:多个客户端要复用同一批工具、希望工具目录可被发现、需要统一授权入口;
- 不必用 MCP:高频内部 RPC 批处理、强事务场景、大文件或流式二进制。这些直接走现有内部接口,在 MCP Server 里包一层薄壳调用即可;
- 一个内部系统只保留一个入口。同时开 MCP 入口和自研入口,权限判定迟早不一致,而这种不一致往往在事故复盘时才被发现。
跨 Agent 的协作、任务分派、长时异步作业,交给 A2A 这类协议或你自己的编排层,不要让工具协议承担它没定义的能力。两套协议的边界划分在A2A 协议与 MCP：企业智能体互操作该押注哪套标准里单独展开过。
常见问题
MCP Server 需要给每个业务系统单独部署一个吗?
按权限边界划,不按系统数量划。边界是"谁能看到什么数据":同一数据域内的几个系统可以共用一个 Server,跨域必须分开,否则一个 Server 的凭据会同时够到两个域。
MCP 协议本身能保证权限安全吗?
不能。协议规定了授权流程与传输方式,但工具级 scope、用户身份注入、数据域过滤都要企业自己实现。规范外的企业级授权扩展可以借用,但落地时仍以你内部 IAM 为准。
内网要不要把 MCP 端口暴露到公网?
不需要。网关部署在内网,移动端通过 BFF 与受控入口访问聚合接口,内部 Agent 与 MCP Server 之间走内网专线或 VPN。
协议无状态之后,还需要自己管会话吗?
协议层不再有会话,但业务需要跨调用状态时,让工具签发一个显式 handle,由模型作为参数回传。这比把状态藏在传输层更好——模型能看见 handle,也能在工具间传递它。
审计日志要留多久?
按行业监管与内审要求定,不要按开发便利定。定完再倒推存储方案,而不是先选存储再补留存策略。