MCP（Model Context Protocol）让 Agent 用较统一的方式发现资源、读取上下文和调用工具。它解决的是连接接口问题，不自动解决企业身份、授权、数据边界、软件供应链和责任归属。
把一个 MCP Server 接到 Agent 上，本质上相当于给一位数字执行者安装新的软件并授予一组能力。企业不能只验证“能否连接”，还要回答谁维护、能访问什么、以谁的身份、如何升级、出错后如何追责。
建立 MCP 注册中心
每个允许进入生产的 Server 都应有唯一标识、业务所有者、技术所有者、代码或供应商来源、版本、工具清单、数据范围、网络目的地和风险等级。
个人本地实验可以在隔离环境进行；连接生产数据和企业账号的 Server 必须从允许清单安装。禁止 Agent 根据网页提示自动下载或启用未知 Server。
分离三类身份
第一类是用户身份，代表员工自己能做的动作。第二类是岗位或服务身份，用于明确授权的后台任务。第三类是平台管理身份，只用于配置和运维，不应暴露给 Agent。
优先使用用户委托和短时令牌。若必须使用服务身份，要限制租户、对象、动作、网络、时间和调用额度，避免一把长期密钥连接所有系统。
OpenAI 公开的 Codex 安全运行方法 也把 MCP 凭证、网络策略、审批与活动日志放在统一控制面中。企业应把这看作最低工程要求，而不是特定产品功能。
工具描述不能决定真实权限
MCP 工具的名称和描述是给模型理解的语义信息，真正授权必须由后端策略执行。即使工具写着“只读查询”，服务端也应以数据库账号、API scope 或策略规则强制只读。
对删除、付款、发布、权限修改和外部发送等动作，参数需要在模型之外再次校验，并触发人工审批或双重授权。
把返回内容视为不可信输入
MCP Server 返回的网页、文档和第三方数据可能包含提示注入。系统应保留来源标签，限制内容影响范围，并避免读取工具与高风险写入工具共享无限权限。
敏感数据还要经过输出策略，防止 Agent 把从内部系统读取的内容发送到外部工具。
对升级实施供应链治理
Server 更新可能增加工具、扩大网络访问或改变凭证处理。生产版本应固定，升级前检查变更记录、依赖、签名或来源，并运行功能、安全和回归评测。
对于开源 Server，开源代码只提供可审查性，不代表已经安全。企业仍要验证实际构建产物、依赖和部署配置。
审计应回答五个问题
- 谁让哪个 Agent 发起了调用；
- Agent 使用了哪个 Server 和精确版本；
- 以什么身份和权限执行；
- 输入、策略判断和外部结果是什么；
- 是否经过审批，最终是否达到业务目标。
审计记录应能关联到具体任务，而不是只保存零散 API 日志。这样事故调查、成本核算和质量评测才能使用同一条证据链。
企业落地顺序
先开放只读、低敏感、可回滚的工具；再增加用户委托身份和审计；之后引入受限写入与审批；最后才允许无人值守的后台触发。每增加一种能力，都要明确失败和撤销路径。
MCP 会成为 Agent 生态的重要连接层，但企业的长期资产应是自己的工具目录、身份策略、数据分类、评测集和审计体系。协议可以统一，治理责任不能外包给协议。