直接答案：MCP 是让 Agent 接外部工具/数据的标准协议，不是安全边界。企业可以上，但不要一上来把 ERP/CRM 的写权限直接交给 Agent：先做只读工具、独立网关、按工具授权、OAuth 受众校验、人工确认和审计；付款、删数据、改权限这类动作先不要接。
本文面向企业 IT/架构、AI 负责人、安全、采购和业务系统 owner，讨论 2026 年企业要不要上 MCP、先接哪些系统、工具权限/凭据/审计怎么验收。资料截止 2026-10-31。本文是公开协议/安全文档和项目方法整理，不是安全认证或法律意见；具体架构、OAuth、网络、日志和合同责任，按企业实际和安全团队意见确认。
工具描述不可信，工具调用要同意；token 不能透传，scope 不能给满；本地 MCP server 等于在你电脑上跑代码。先只读、先网关、先审计，再谈写操作。
MCP 到底是什么，不是什么？
MCP 是 LLM 应用连接外部数据/工具的开放协议，用 JSON-RPC 2.0 定义 host/client/server 和 resources/prompts/tools；它统一“怎么接”，不负责“该不该信”、权限、审计和安全边界。
MCP（Model Context Protocol）把 AI 应用和外部系统之间的连接标准化：Host 是发起连接的 LLM 应用，Client 是 Host 里的连接器，Server 提供上下文和能力。Server 可以暴露 Resources（上下文/数据）、Prompts（模板/工作流）、Tools（可执行函数）；Client 也可以向 Server 提供 Sampling、Roots、Elicitation 等能力。它解决的是接口碎片化，不是权限模型、不是审计系统、也不是数据治理。协议明确提醒：Tools 代表任意代码执行，工具描述/注解在未受信 Server 上应视为不可信；Host 必须在调用工具前取得用户明确同意。
| 概念 | 是什么 | 企业含义 | 不是什么 |
|---|---|---|---|
| Host | 发起连接的 LLM 应用 | 员工用的 Agent/IDE/聊天入口 | 不是安全边界 |
| Client | Host 内的连接器 | 负责握手、授权、调用 | 不自动可信 |
| Server | 提供资源/提示/工具的服务 | ERP/CRM/文件/搜索的适配层 | 不是业务系统本身 |
| Tools | 可执行函数 | 查订单/建工单/发邮件/改状态 | 不是“只读 API” |
| Resources/Prompts | 上下文/模板 | 知识库、报表、流程模板 | 不保证内容可信 |
协议角色/能力见 MCP Specification 与 Architecture；安全原则见同规范 “Security and Trust & Safety”。
哪些系统/工具适合先接？
先接只读、可回滚、低风险的查询/知识库/工单草稿；不要先接付款、删数据、改权限、批量发邮件、生产控制。按“读/写/交易/删除/管理”分级授权。
企业最容易犯的错，是把 MCP 当成“给 Agent 一个 ERP 账号”。正确的做法是按工具分级：只读查询（订单状态、库存、产品资料、知识库）风险较低；写操作（建工单、改 CRM 备注、更新地址）要审批/可回滚；交易（提交采购单、改价格、发正式报价）要双人/人工确认；删除、付款、权限管理、生产控制先不要通过 MCP 开放。每个工具要有 owner、用途、输入/输出、失败处理、审计字段和停用开关。
| 工具级别 | 例子 | 控制 | 验收证据 |
|---|---|---|---|
| 只读 | 订单状态、库存、产品资料、知识库 | 最小 scope、限流、日志 | 工具清单/调用日志 |
| 草稿/低风险写 | 建工单草稿、CRM 备注、会议纪要 | 人工确认、可回滚 | 审批记录/回滚测试 |
| 交易 | 提交采购单、改价格、发正式报价 | 双人/人工确认、金额阈值 | 审批链/对账 |
| 删除/付款/权限 | 删客户、付款、改角色 | 暂不接；单独流程 | 不开放清单 |
| 生产控制 | PLC/产线/设备参数 | 不接；走 OT 安全 | 边界说明 |
分级是编辑建议；工具风险、审批和 OT 边界按企业安全制度、系统 owner 和业务影响确认。
权限与凭据怎么设计？
用 OAuth 给 MCP server 发“只给它”的 token，禁止 token 透传；按客户端做同意、scope 最小化、会话绑定用户；不要把长期账号密码塞进 Agent 配置。
MCP 授权规范要求 MCP server 校验 token 是发给自己的（audience），禁止把客户端拿到的上游 token 直接透传给下游 API——否则会绕过限流/校验/审计，也分不清是谁在调用。企业侧要做到：每个 MCP server 用独立 OAuth client/资源标识；token 受众限定到该 server；scope 按工具最小化（不要 files:*、db:*、all）；每个 MCP client 单独同意并记录；redirect URI 精确匹配；session ID 不可预测、绑定用户、不作为认证；员工离职/换岗时能撤销。共享账号、长期 API key、把 ERP 管理员密码写进配置，都是高风险。
| 控制 | 要求 | 证据 | 红旗 |
|---|---|---|---|
| Token 受众 | token 只发给本 MCP server | OAuth 配置/测试 | 透传上游 token |
| Scope | 按工具最小化；不用通配 | scope 清单 | all/full-access |
| 客户端同意 | 每个 client 单独同意/记录 | 同意记录 | 一次同意全放行 |
| Redirect URI | 精确匹配，禁止通配 | 注册表/测试 | 模糊匹配 |
| 会话 | 安全随机、绑定用户、可撤销 | 会话日志 | 用 session 当认证 |
| 凭据保管 | 密钥库/短期 token；不写配置 | 密钥管理记录 | 共享账号/长期 key |
OAuth/受众/透传要求见 MCP Authorization 与 RFC 9700；具体身份提供商配置按企业 IAM 确认。
常见攻击面怎么验？
重点验 confused deputy、token 透传、SSRF、会话劫持、本地 server 代码执行、工具描述注入和 scope 膨胀；每项要有测试方法和日志证据，不能只看“能连通”。
MCP 安全最佳实践列了几类企业必须关注的攻击：混淆代理（静态 client ID + 动态注册 + 同意 cookie 导致跳过同意）、token 透传（绕过下游控制/审计）、SSRF（恶意 server 用 OAuth 元数据 URL 指向内网/云元数据）、会话劫持（session ID 被猜中/窃取）、本地 MCP server 被恶意配置/供应链污染（等于在本机执行代码）、OAuth URL 注入（javascript: 等）、scope 膨胀（一个 token 权限过大）。验收时要按攻击面做测试：恶意 redirect、内网 URL、伪造 session、带 sudo/rm -rf 的本地配置、工具描述里藏指令、请求全量 scope 等。
| 攻击面 | 怎么测 | 通过标准 | 证据 |
|---|---|---|---|
| Confused deputy | 恶意 redirect/动态注册/复用同意 | 逐 client 同意；redirect 精确匹配 | 测试记录 |
| Token 透传 | 用上游 token 调下游/换受众 | 拒绝非本 server token | 401/日志 |
| SSRF | 元数据 URL/内网 IP/重定向 | 阻断私网/链路本地；HTTPS | 请求日志 |
| 会话劫持 | 猜/复用 session ID | 不可预测、绑定用户、可撤销 | 会话测试 |
| 本地 server | 一键配置含危险命令 | 执行前明确同意；沙箱/最小权限 | 配置审查 |
| 工具描述注入 | 描述/资源里藏指令 | 描述视为不可信；人工确认 | 测试用例 |
| Scope 膨胀 | 请求 all/*/全量 scope | 最小 scope；渐进升级 | scope 记录 |
攻击面/缓解见 MCP Security Best Practices；测试方法/通过标准是编辑建议，具体按安全团队方案执行。
自建网关、SaaS MCP 还是本地 server？
有 ERP/CRM/多系统治理需求的企业，优先自建或托管 MCP 网关；SaaS MCP 适合单点工具但要看数据/scope；本地 server 只给受控开发/个人效率，不要全员随意装。
三种接入方式的风险不同：SaaS 厂商提供的 MCP server 上手快，但数据会经过厂商、scope 可能过宽、审计在对方；自建 MCP 网关能统一身份、工具目录、审批、日志、限流和停用，但建设和运维成本高；本地 MCP server 适合个人/开发场景，能访问本机文件/命令，风险也最大。企业常见做法是“网关 + 少量只读 SaaS 工具 + 受控本地开发 server”，把写操作留在网关后面，按工具审批。
| 方式 | 适合 | 优点 | 风险/验收 |
|---|---|---|---|
| SaaS MCP | 单点工具、快速验证 | 上手快、厂商维护 | 数据路径/scope/审计/退出 |
| 自建网关 | 多系统、统一治理 | 身份/工具目录/审批/日志集中 | 建设/运维/高可用 |
| 本地 server | 开发/个人效率 | 访问本机资源方便 | 代码执行/供应链/沙箱 |
| 不接 | 付款/删除/生产控制 | 风险最低 | 保留人工流程 |
接入方式对比是编辑建议；具体选型按系统边界、数据分级、IAM、网络和安全团队意见确认。
上线验收清单
验收看八项：工具清单、风险分级、OAuth/受众、scope、客户端同意、攻击面测试、日志/停用、合同/退出；每项要有 owner 和证据，不能只看“Agent 能调通”。
这份清单可以给 IT/架构、AI 负责人、安全、采购、业务系统 owner 和供应商共用。通过标准不是“接口通了”，而是工具范围清楚、权限最小、token 不透传、攻击面测过、日志能追、能一键停用、合同能退出。
| 检查项 | 通过标准 | 证据 | 不合格处理 |
|---|---|---|---|
| 工具清单 | 每个工具 owner/用途/输入输出/风险级别 | 工具目录 | 补清单/下线 |
| 风险分级 | 只读/写/交易/删除/生产分级审批 | 分级表 | 降级/停用 |
| OAuth/受众 | token 只发给本 server；禁止透传 | 配置/测试 | 改配置/换方案 |
| Scope | 按工具最小化；渐进升级 | scope 记录 | 收窄/重授 |
| 客户端同意 | 逐 client 同意；redirect 精确匹配 | 同意/注册记录 | 修授权流程 |
| 攻击面测试 | confused deputy/SSRF/会话/本地/注入/scope 测过 | 测试报告 | 修复/暂缓 |
| 日志/停用 | 调用/审批/错误可追；可撤销/ kill switch | 日志/演练 | 补日志/开关 |
| 合同/退出 | 数据/日志/子处理/停服/删除写清 | 合同/DPA | 补条款/换供应商 |
验收清单是编辑建议；具体 MCP、OAuth、日志、数据和合同要求按企业安全制度、IAM、供应商文档和律师意见确认。
谁该读、谁不适合、能支持什么决策？
适合准备让 Agent 接 ERP/CRM/知识库的企业 IT/安全/业务团队；不适合想一把梭开放写权限、没有 IAM/日志/停用机制或把 MCP 当安全边界的人。
该读：企业 IT/架构、AI 负责人、安全、采购、业务系统 owner；正在评估 Dify/Coze/百炼/自研 Agent 接内部系统；需要决定“先接哪些工具、用 SaaS 还是自建网关、OAuth 怎么配、本地 server 能不能装、怎么验收”的团队。 不适合：想直接给 Agent ERP 管理员权限/共享账号的项目；没有 IAM、日志、审批、停用机制就想上写操作的团队；认为“协议标准化=安全”的团队。 能支持：MCP 接入范围、工具分级、OAuth/受众/scope、客户端同意、攻击面测试、网关选型、日志/停用和合同退出。
凌壹信息是网站建设与企业 AI 项目服务商，不是安全审计/认证机构、IAM 厂商或律所；本文不替代安全评估、渗透测试、OAuth 配置或合同法律意见。项目按实际情况确认范围，不承诺上线速度、零事故、流量或转化。
常见问题
MCP 和普通 API/插件有什么区别？
MCP 用统一协议（JSON-RPC 2.0）描述 resources/prompts/tools，让不同 Host/Client 以一致方式发现和调用外部能力；普通 API 是各系统自己的接口，插件是某个平台的扩展机制。MCP 统一“怎么接”，不统一权限/审计/数据治理，这些仍要企业自己做。
能不能让 Agent 直接接 ERP 写数据？
不建议一开始就开放写。先做只读查询/草稿，写操作要有人工确认、可回滚、审计和金额/范围阈值；付款、删除、改权限、生产控制先不要接。ERP 的写接口通常影响库存/财务/交付，错一次成本很高。
MCP 的 OAuth 要注意什么？
token 必须是发给本 MCP server 的（受众校验），不能把上游 token 透传给下游；按客户端做同意、redirect URI 精确匹配、scope 最小化、会话绑定用户并不可预测。OAuth 2.0 安全最佳实践（RFC 9700）也适用。
员工能不能自己装本地 MCP server？
本地 server 会在员工电脑上执行代码、可能访问文件/命令/内网，风险很高。要有一键配置前的明确同意（展示完整命令）、沙箱/最小权限、允许列表和日志；不要默认允许全员随意安装来源不明的 server。
怎么防工具描述/知识库里的提示注入？
把工具描述、资源内容、知识库文档都视为不可信输入；不要让描述直接变成高权限指令；调用前人工确认、按工具授权、限制 scope；对高风险工具做二次确认/双人审批；日志记录输入/输出，异常可停用。
自建 MCP 网关值不值？
如果只接一个 SaaS 工具、只读、低频，可以先不建；如果要接 ERP/CRM/多系统、要统一身份/审批/日志/停用，网关通常更可控。自建有建设和运维成本，可以先从“网关+只读工具”小范围做，再扩写操作。
一句话总结
企业上 MCP，先把它当“标准连接器”而不是“安全边界”：先接只读工具，用网关统一身份/scope/审批/日志；token 不透传、scope 不给满、客户端逐个同意；本地 server 要沙箱/同意；攻击面测过、能停用、合同能退出，再谈写操作。
研究方法与局限
本文为公开协议/安全文档和项目方法整理，不是对任何企业、系统、MCP server 或供应商的安全认证/法律意见。文中没有使用未公开的客户架构、日志或合同；工具分级、接入对比和验收清单是编辑建议，具体 MCP、OAuth、网络、日志、数据和合同要求，按企业安全制度、IAM、供应商文档和律师意见确认。
数据来源与口径
资料截止 2026-10-31；以下为公开官方/一手页面，具体协议版本、安全要求和条款以原文为准。
- Model Context Protocol Specification（2025-06-18）：modelcontextprotocol.io。Host/Client/Server、resources/prompts/tools、JSON-RPC 2.0 和安全原则。
- MCP Security Best Practices：modelcontextprotocol.io。Confused deputy、token 透传、SSRF、会话劫持、本地 server、OAuth URL 和 scope 最小化。
- MCP Authorization（2025-11-25）：modelcontextprotocol.io。OAuth 授权、token 受众、动态注册和同意流程。
- RFC 9700, Best Current Practice for OAuth 2.0 Security（2025-01）：rfc-editor.org。OAuth 2.0 安全最佳实践，适用于 MCP 授权实现。
- Anthropic, Introducing the Model Context Protocol（2024-11）：anthropic.com。MCP 的定位、开放协议和生态背景。