读完这篇文章，你将清楚了解 Model Context Protocol（MCP）是什么、为何它在今年进入了安全团队的风险清单，以及当供应商声称「我们支持 MCP」时，你必须追问的五个问题。
什么是 Model Context Protocol（MCP）？
MCP 是一项开放标准，让 AI 模型通过统一接口连接外部工具、数据源与业务系统。企业不再需要为每一款 AI 工具与每一个系统逐一开发集成，而是把每个系统以 MCP 服务器的形式公开一次，任何支持 MCP 的 AI 客户端便可使用。
可以把它理解为企业 AI 的 USB-C 接口。在此之前，每一条「模型连系统」的通道都是量身定制的工程；在此之后，接口变成标准件，真正的工作转移到另一个问题上：谁有资格插上去。
正因如此，MCP 已经不再只是开发团队的技术议题，而是治理议题。
为何 MCP 突然出现在管理层议程上？
MCP 从开发者话题升级为董事会层面的议题，原因是采用速度超越了控制机制的建立速度。企业 AI 代理如今被期望能读取 CRM、工单系统与文档库，而执行这件事的机制正是 MCP。这项协议在大约十八个月内，由「可选项」变成「承重结构」。
根据 Stacklok 的 2026 年软件报告，受访软件机构中有 41% 已在有限或大规模生产环境中运行 MCP 服务器。这不是试点阶段的数字，而是生产基础设施的数字。
《CIO》杂志形容 MCP「突然出现在每一份管理层议程上」，理由很直接：这项协议决定了你的 AI 代理在你自己的系统版图内能够触及什么。
对一家在香港同时运行 Dynamics、本地人力资源平台与内部文档库的企业而言，MCP 就是决定 AI 助理能否看到员工记录的那一层。这是访问控制决策，而访问控制决策应该掌握在你手上，而不是交给供应商的产品路线图。
MCP 实际如何运作？
MCP 由三个部分组成：用户实际操作的主机应用程序、主机内的客户端，以及一个或多个各自封装了系统或数据源的服务器。客户端向服务器询问可用工具，模型选择其中一项，服务器再对底层系统执行。
有三个概念值得管理层掌握。
--- 工具（Tools）是模型可以调用的行动，例如「创建工单」或「查询发票」。这一类会改变系统状态。
--- 资源（Resources）是模型可以读取的只读数据，例如政策文件或客户记录。
--- 提示（Prompts）是服务器可以提供的可重用指令模板，用于标准化任务的执行方式。
对决策者而言最关键的一点是：一次工具调用，等同软件依据语言模型的判断，在生产系统内采取了一项实际行动。凡是你对「由人执行该行动」所设下的控制要求，理应同样适用于此。
MCP 与一般 API 集成有何不同？
有分别，而分别在于「由谁决定」。传统 API 集成是确定性的：开发人员编写代码，在特定条件下调用特定端点。在 MCP 之下，服务器公布自己能做什么，然后由语言模型在执行当下决定要做哪一项。
这个转变搬动了一个控制点。在传统集成中，逻辑存在于经过审查、有版本控制的代码里；在 MCP 部署中，部分逻辑存在于模型对请求的诠释之中。
实务后果是测试的性质改变了。你不再只是测试端点会否返回正确数据，而是要测试：当请求含糊、带有敌意，或只是由一位下午六点疲累的员工草率写成时，代理是否仍然会选择正确的工具。
这也解释了为何「我们有 AI 集成」这句话几乎没有信息量。真正有用的问题是：模型是否正在自行选择行动？如果是，什么在约束这些选择？关于如何分辨真实代理能力与营销语言，可参考代理漂白（agent washing）的实际样貌。
MCP 真正的安全风险是什么？
这个安全问题是结构性的，而非偶发的。MCP 为了开发便利与不设限的执行方式，标准化了一个非常庞大的攻击面，而且速度远快于多数机构建立相应控制的速度。安全因素目前一直被列为企业采用 MCP 的首要障碍。
对企业领袖而言，有四项风险最为关键。
--- 工具下毒（Tool poisoning）。恶意或已被入侵的服务器，以特定方式描述自己的工具，诱导模型执行用户从未要求的行动。指令以数据形式送达，模型却当成命令执行。
--- 权限过宽。服务器获授的访问权远超任务所需，于是单一次入侵所触及的范围，远不止一个数据集。
--- 传输中的凭证泄露。安全评估发现，相当比例的 MCP 服务器使用明文 HTTP 端点，令 OAuth 令牌、API 密钥与会话元数据暴露于被拦截的风险。
--- 供应链仍未成熟。单是 2026 年首两个月，就有超过 30 个针对 MCP 相关软件的 CVE 被登录。这是年轻生态系统的特征，而非崩坏的信号，但意味着你需要频繁修补。
问题的严重性，可以从「谁在发布指引」看出来。美国国家安全局于 2026 年 6 月就 MCP 安全设计发出网络安全信息文件，云安全联盟（CSA）亦已发布代理式 MCP 安全最佳实践。协议若非承重结构，不会吸引这个级别的关注。
Enterprise-Managed Authorization 改变了什么？
Enterprise-Managed Authorization（EMA）是把 AI 工具访问权交还给机构身份提供商（IdP）的 MCP 扩展规范。它于 2026 年 6 月 18 日成为稳定版规范，对任何负责企业访问控制的人而言，这是目前最重要的发展。
在 EMA 出现之前，每一个 MCP 服务器都会逐一向每位用户索取授权。员工在 IT 部门从未审阅过的界面上按下「允许」，而机构完全没有中央记录可以说明：哪些 AI 代理能触及哪些系统。
EMA 以零接触流程取代这种做法。在单点登录过程中，客户端将用户的身份令牌，换取一个仅限单一目标服务器的授权，所依据的都是成熟标准：OIDC 或 SAML 登录、RFC 8693 令牌交换，以及 RFC 7523 JWT bearer grant。
用白话说：你的身份提供商成为「哪个 AI 代理可以触及哪个系统」的权威，而所依据的，是你早已套用在其他所有应用程序上的同一套政策。
Okta 是首个获支持的身份提供商，通过其 Cross App Access 功能实现。Anthropic 已在 Claude、Claude Code 与 Cowork 全面实现 EMA，Visual Studio Code 亦已在 IDE 内直接支持。微软则已发布指引，说明 Entra ID 与 App Service 目前可以做到什么。
如果你的机构已经在运行条件访问，EMA 意味着你的 AI 代理版图终于可以进入这道防线之内，而不是停留在旁边。
企业应如何评估 MCP 部署？
采用四阶段流程，而非功能核对清单。这套流程之所以有效，是因为每一阶段都会产出下一阶段所依赖的证据；而且若结论是「你尚未准备好」，它会以极低成本让你及早知道。
--- 第一阶段：盘点。列出机构内所有已连接 AI 工具的 MCP 服务器，包括个别团队自行启用、未经审批的部分。大多数机构会对这份清单感到意外。
--- 第二阶段：按影响半径分类。逐一记录每个服务器能读取什么、能改动什么，并把只读资源与会采取行动的工具分开。只能读取公开产品目录的服务器，与能够发出退款的服务器，风险等级截然不同。
--- 第三阶段：把访问决策收归身份系统。通过 EMA 把访问决策由逐人授权界面移至身份提供商，使员工离职时，其 AI 代理的触及范围同步被撤销。
--- 第四阶段：记录并复核「行动」，而不只是「对话」。多数 AI 日志只捕获提示与回应。审计师真正会索取的，是工具调用记录：执行了什么行动、在哪个系统、依据谁的授权。
一家香港金融服务公司走过这个流程时，通常会发现第二阶段才是项目真正证明其预算价值的环节。盘点结果令人不安，但分类工作才是把无边界风险转化为可界定风险的关键。
供应商说「支持 MCP」时，应追问哪五个问题？
「我们支持 MCP」是关于连通性的陈述，不是关于安全性的承诺。以下五个问题，能分辨哪些供应商真正为企业部署做过工程设计，哪些只是开启了一项功能。
--- 你们的客户端是否支持 Enterprise-Managed Authorization？支持哪些身份提供商？如果答案只有逐人授权界面，代表你的访问控制实际上被下放给了员工。
--- 你们的 MCP 工具中，哪些会采取行动而非只读取数据？我可以逐项停用吗？全开或全关的工具权限，不构成治理立场。
--- 你们如何防御来自第三方服务器的工具下毒？要求列出具体缓解措施，而不是接受口头保证。
--- 你们的工具调用审计日志包含什么？保留多久？能否导出到我们的 SIEM？如果日志只存在于供应商的控制台，你的事故响应就取决于他们的客服排队。
--- 你们对 MCP 组件的修补频率如何？2026 年那批 CVE 是怎样处理的？过往在压力下的行为，最能预测未来的行为。
能就五个问题全部给出具体答案的供应商，是真的做过功课；只会回答「企业级」三个字的，并没有。
机构在 MCP 上通常错在哪里？
常见的失败多属组织层面而非技术层面，而且模式相当一致。每一项都可以靠一个及早作出的决定避免，而不是靠事后补救。
--- 影子连接。个别团队未经审核便把 MCP 服务器连上生产系统，因为设置只需数分钟、亦不涉及采购流程。IT 部门往往在事故发生时才发现整个版图。
--- 把代理当成「工时无限的员工」。获授人类权限的 AI 代理，可以每天行使该权限数千次。对人来说显得多余的速率与范围限制，在此变成必要条件。
--- 用聊天机器人时代的治理文件。为「只回答问题的 AI」而写的政策，无法涵盖「会采取行动的 AI」。如果你的 AI 政策完全没有提到工具调用，它的年代早于这个问题。
--- 没有回退路径。机构会规划代理如何行动，却不规划如何撤销它做过的事。撤销程序应在上线前定义，而不是在第一个糟糕的星期中途摸索。
--- 把合规当成后续工序。在香港《个人资料（私隐）条例》之下，个人数据由 AI 代理而非员工移动，并不改变责任归属，资料使用者仍须问责，而私隐专员公署 2026 年的代理式 AI 指引已列明监管机构现时期望看到哪些文件记录。
结论：协议已成定局，治理尚未到位
MCP 已经赢得了集成方式之争。生产环境采用率超过四成、企业授权扩展规范转为稳定版、国家级安全机构开始发布设计指引，这些都说明：问题不再是你的机构会不会用它。
真正未解的问题是：你的 AI 代理连接系统时，是经过你的身份提供商与审计轨迹，还是绕过它们。这是一个只作一次、而且必须及早作出的决定，刻意规划的成本，远低于日后补做的成本。
由盘点开始。它花你一星期，却能告诉你真实的位置在哪里。
科技周期总是回报那些在技术仍然年轻时就建好护栏的机构。懂AI，更懂你 UD相伴，AI不冷。
本文由 UD 企业 AI 团队审阅。
你的机构应由哪里开始？
在把任何一个系统接上 AI 代理之前，你需要对机构现况有一个诚实的评估。UD 团队手把手带你完成每一步，由 AI 准备度评估、身份系统集成，到部署上线与审计设计，28 年服务香港企业的经验，全程陪你走。
