模型上下文协议（MCP）：人工智能驱动自动化的安全设计考量

#模型上下文协议（MCP）：人工智能驱动自动化的安全设计考量

为支撑人工智能驱动的分析与自动化而保护相关协议。

执行摘要

模型上下文协议（Model Context Protocol，MCP）已成为在不断增长的人工智能（artificial intelligence，AI）驱动服务生态中实现通信的事实标准。其目的是促进 AI 驱动的生态系统与工作流之间自动共享数据并执行任务，包括模型评估、充实、预处理和任务自动化。随着采用加速，MCP 已出现在商业、金融、法律和软件开发等多个行业的实验性与生产性 AI 部署中。AutoGen Studio、Harvey AI、Agentverse 和 Copilot 只是这些行业中部署 MCP 的若干产品示例。

MCP 的迅速扩散已超过其安全模型的发展。与早期万维网（Web）协议类似，MCP 发布时设计灵活且规范不足，给实现者留下设计自由，同时也给安全使用带来歧义。关键在于，该协议颠倒了一种熟悉的交互模式：MCP 往往不是由客户端向服务器请求数据，而是期望服务器为已连接的客户端查询、有时还执行动作。这种颠倒造成了新的、很大程度上尚未被充分追踪的攻击路径。这些理论上的风险现已具体化：公开实验室和安全研究人员发布了存在漏洞的 MCP 服务器实现，用以说明保护不足的 MCP 多么容易被利用，所提供的例子并非仅仅是假设，而是可以演示的。[1]

一些 MCP 实现允许由恶意行为者控制的输入在没有适当约束的情况下到达执行环境，从而产生通常被视为高严重性的漏洞。其中一类漏洞是任意代码执行（Arbitrary Code Execution，ACE）。在执行用户提供的逻辑或代码的 MCP 环境中，ACE 很容易出现，并且在漏洞管理中通常归入多个常见弱点枚举（Common Weakness Enumeration，CWE）类别（CWE-77、CWE-78、CWE-94、CWE-95）。这些设计倾向表明，必须通过实现上的严格性、适当的编码实践、更清晰的协议规范以及健壮的验证工具，来强制执行默认安全的行为。

本报告概述了从真实部署中观察到的安全关切与模式，并为在高利害或生产环境中采用 MCP 的组织提供可操作的建议。这样做的目的是在支持 AI 增强系统安全创新的同时降低风险。本指南基于 MCP 规范、实现以及当前已知问题，但其设计是可扩展的，并在协议、实现和运行持续演进时保持相关性。

引言

模型上下文协议（MCP）是一种应用层协议，提供一种简单且已达成一致的消息模式和传输格式，目前被许多启用 AI 的系统用于管理服务之间的交互。MCP 最初由 Anthropic 于 2024 年 11 月作为开源框架推广[2]，此后在大量 AI 编排与智能体框架中获得采用。其目的是在多步骤工作流的组件之间传递结构化消息，这些消息通常包含角色、消息内容，以及可选的工具或上下文。

要理解 MCP 的前景与风险，可以考虑一个常见的真实用例：旅行规划。设想请求一名 AI 助手规划一次国际旅行。只需一句只有几个词的提示，它就会确定当前位置、当地时间和最近的国际机场，然后检索签证要求、推荐航班，并汇编完整行程。在幕后，该助手依靠 MCP 跨多个工具和服务快速、灵活地编排这些数据收集任务。

图 1 说明智能体式 AI 旅行助手如何使用 MCP 将该过程的每一步自动化。在此类部署中，用户应用／用户界面（User Interface，UI）作为人机交互的主要入口，收集输入并展示结果。该输入被传递给大语言模型（large language model，LLM），由 LLM 解释用户意图并形成用于执行的结构化请求。MCP 客户端库作为中间件层，将这些由 LLM 生成的请求转换为 MCP 协议消息，并管理连接生命周期。这些消息随后被路由到 MCP 服务器，由服务器充当编排者，将传入请求匹配到已注册的适当能力或工具。最后，各个工具（A、B、C）执行所请求的任务，范围从数据检索到计算处理，并将结果沿链路返回，最终到达用户应用／UI。

虽然 MCP 简化了把这些多样能力集成到强大智能体工作流中的过程，当前协议规范在关键的安全与隐私保护上仍然不足。随着真实世界的采用加速，尤其是在查询电子健康记录（electronic health records，EHRs）这类高上下文、敏感任务上，设计、实现和运行态势中的缺口正变得更加明显。本报告审视这些风险，并概述在 MCP 能够被安全、有信心地用于安全关键环境之前必须弥补的缺口。

图 1：各 MCP 组件如何交互的示意图

MCP 设计、实现与实践中的安全关切

身份认证、授权和输入验证等传统网络安全原则，在部署 MCP 的环境中仍然是必要的保护措施。然而，智能体式 AI 系统，尤其是以 MCP 为特征的系统，引入了既有网络防御策略未能充分应对的新型系统性风险。关于一般性地保护智能体式 AI 系统的更多信息，请参阅《谨慎采用智能体式 AI 服务》。[3] 对 MCP 系统而言，风险包括动态工具调用（智能体可以在运行时自主调用新工具）、隐式信任关系（一个智能体的输出被另一个智能体在没有显式核验的情况下假定为有效），以及上下文共享（长期存在或相互重叠的上下文窗口可能在任务之间泄漏、混合或错位）。

这些不应被视为可以在接口或端点层打补丁解决的孤立问题。相反，它们要求重做整个生命周期：从协议与智能体行为的设计，到运行时调度与协调，再到与外部服务的集成和长期运行监控。保护 MCP 系统需要把智能体环境视为一个连续体，任一阶段的假设错位或细微不一致都可能传播并叠加为可被利用的条件。

访问控制

将会话关联到身份并非由协议定义，而是由实现者酌情、可选地实现。MCP 组件——包括客户端、服务器、代理和主机——可以被配置为在没有任何必需访问控制措施的情况下访问或处理数据。许多实现完全省略身份认证，而那些包含身份认证的实现往往缺乏任何基于角色的强制，例如在数据库和数据接口中设计并实现的创建、读取、更新和删除（Create, Read, Update, and Delete，CRUD）权限区分。这造成对数据和上下文的访问含糊且不可追踪。

此外，多个 MCP 服务器虽然彼此并不直接连接，却可能接触到由 MCP 客户端自由共享的消息或信息。这种做法增加了数据泄漏或未经核验的任务传播的可能性。¹ MCP 目前缺乏在实例化时交换基于角色的访问控制（Role Based Access Control，RBAC）权限的支持，因而难以在任务或服务之间强制或核验访问边界。

¹ 未经核验的任务传播是指任务在 MCP 服务器或智能体组件之间传递时，没有对其来源、范围或意图进行适当核验的情形。这类传播可能导致越权、敏感上下文泄漏，或无意中激活无关的下游工具。

不安全的上下文或数据序列化

MCP 能够通过序列化机制传输上下文、配置和载荷等结构化对象，而这些机制往往缺乏严格验证或模式强制。相反，这些事项被留作开放问题，由实现者自行完成。包含注释或提示的序列化内容可能为注入技术打开路径，因为它可以包含可执行代码或嵌入的模型调用。如果反序列化以宽松方式发生，并且代码与其他文本（例如数据和注释）之间没有强隔离，这个问题尤其严重。该问题与众所周知的序列化风险（例如 OWASP A08/2017 [4]）相呼应，并对可能嵌入供自然语言解析之内容的应用层协议带来一些较新的影响。

薄弱的审批工作流

尽管 MCP 文档为实现者提供了一些建议的安全指南，文档仍指出：“MCP 本身无法在协议层强制这些安全原则。”[5] 许多 MCP 实现对账户访问要求最终用户同意（例如允许 MCP GitHub 服务器访问用户的 GitHub 账户），并额外要求通过肯定确认来授权一项动作（例如在弹出消息上点击“yes”或“allow”），但一些实现不支持把此类审批编码固化。[6] 即使实现了工作流审批，对已经受信任或已连接的 MCP 服务器，其能力或数据访问的变更也常常可以在没有审批的情况下作出。最终用户往往不知道这些变更，无论变更是恶意还是善意，也不会被提示作出知情同意以接受这些变更。这一关切与访问控制问题密切相关。在已建立的、连接了 MCP 的 AI 系统中，MCP 服务器行为的变化可能不被注意，因为服务器可以在后台持续进行小幅改进。结果是，一项先前良性且已获批准的 AI 服务，后来可能按需访问敏感资源，而不触发任何审查。

令牌或会话安全

MCP 实现经常（并且往往只是可选地）依赖 OAuth 风格的持有者令牌或会话标识符进行访问授权[7]，但正如其标准文档所述：

• MCP 中的授权是可选的（并非每个实现都使用它）
• MCP 服务器依赖 OAuth 2.1 所定义的持有者令牌，但没有规定协议级的令牌生命周期管理（即刷新、撤销和重用控制）。
• 过期与轮换在一些草案中被推荐为最佳实践，但核心 MCP 规范并不强制任何生命周期管理要求。

这些缺口可能导致消息重放或对有效会话的未授权重用。在会话劫持的情况下，恶意行为者可以冒充合法客户端、注入恶意提示，或在不被检测的情况下与 MCP 服务器交互。令牌透传和生命周期处理中的已知弱点已在规范本身中被指出（MCP 安全最佳实践 [8]、生命周期指南 [9]），但许多细节仍未规定，从而允许不安全的实现。[10] 例如，幂等性——多次执行一项操作而不使结果超出初次应用之外发生变化的能力——并不由 MCP 直接强制。相反，它被留给底层的 JavaScript 对象表示法远程过程调用（JavaScript Object Notation – Remote Procedure Call，JSON-RPC）和消息队列规范。这意味着确保幂等行为的责任落在客户端协议上，并且常常可能没有被正确实现，或被完全忽略。

错误配置与不良实现

由于开源 MCP 框架和仓库易于获得，开发者可以在没有充分理解安全影响的情况下迅速部署 MCP 服务器。例如，一个旨在为某地点提供天气相关信息的简单实现，可能在没有限制的情况下被部署，后来又被改用于访问或处理敏感数据（例如该地点的用户或资产信息）。另一个例子是，相同的模型接口和消息结构可能跨任务复用，但 MCP 服务器往往缺乏任务或数据隔离，从而造成无意的数据暴露机会。MCP 以当前形式并不提供隔离这些服务的方法，以支持适当的隐私和安全。

不一致的行为

MCP 实现在如何解释或响应序列化上下文、消息或服务器任务方面差异很大。部署之间的这种行为不一致可能引入不可预测且可被利用的缺口，尤其是当一个组件所作的假设被另一个组件违反时。即使是上下文塑造或响应时序上的简单差异，也可能导致发散的结果、安全盲区或防护措施失效。例如，被设计用于协助旅行的智能体式 AI，可能根据上下文历史对用户提示作出不同解释。一个 AI 智能体可能把该请求关联到早先一封关于度假计划的电子邮件，而另一个则可能把它当作新查询。这种由对先前上下文的概率性解释所驱动的分歧，可以被恶意行为者利用：该行为者预先调教智能体，使其到达特定或不安全的结果。这些非确定性行为问题代表一种相对新的挑战——往往处于传统信息安全实践范围之外——要安全地采用较新的 AI 技术，就需要考虑这些问题。

缺失或薄弱的审计日志

虽然 MCP 规范包含日志记录的基本指导，它把定义并实现全面审计要求留给实现者。结果是，许多实现要么完全省略日志，要么只记录最少的运行元数据。在 MCP 服务器这样后果重大的环境中，健壮的审计日志和告警是必要的。日志应捕获跨会话的可追踪动作序列，在可用时包含来自超文本传输协议（hypertext transfer protocol，HTTP）头部的来源信息，并原生支持检测协议异常，例如重复或畸形请求、授权失败或 RBAC 违规。没有这些可追踪的审计日志，事件响应和问责会变得显著更加困难，在多租户环境中尤其如此。

拒绝服务与基于疲劳的技术

MCP 服务器，尤其是那些承担类智能体功能的服务器，可能易受提示风暴、畸形输入或递归任务请求的影响，从而导致拒绝服务（denial-of-service，DoS）状况。一些对手利用“迟滞”，通过合法但过于复杂的任务耗尽服务器资源，在更广泛的系统工作流中造成延迟和中断。这些技术可能难以与有效的高负载状况区分，从而使检测进一步复杂化。虽然这些并非 MCP 所支持的智能体所独有，如果管理不当，MCP 会为此类资源耗尽技术敞开大门。[11]

真实世界中的 MCP 安全问题示例

随着 MCP 实现不断出现，一些关键的设计与运行问题正在真实部署中暴露出来。以下有问题的 MCP 实现示例揭示：未经检查的假设、隐式信任边界和集成上的捷径如何导致安全问题。在许多情况下，恶意行为者可以以出乎意料或有害的方式操纵合法功能。

安全的缺乏进一步削弱对 MCP 的信任。以下是已在真实世界中被识别和／或被利用的、与 MCP 相关的安全风险示例。

开放 MCP 智能体中的工具参数注入

有观察表明，开源 MCP 智能体在未净化的工具参数经由畸形 MCP 消息传入、并使用简单工具执行之后，暴露了敏感的 MCP 服务器数据。缺少上下文验证和日志，使恶意行为者能够使用合法接口运行任意命令。[12]

工具调用路径混淆

一些 MCP 编排器会自动从公共注册表或本地模块解析工具名称。这使恶意行为者能够利用命名冲突或操纵配置，诱使系统加载由行为者控制的代码。“命名冲突”是指软件系统中的一类漏洞：来自不同来源（例如公共注册表与本地模块）的名称相似的工具可能被不可预测地解析，从而使恶意行为者通过注入的名称运行恶意代码，或迫使系统采取被操纵的回退行为。近期安全研究表明，MCP 客户端往往缺乏指定唯一工具标识符或严格解析策略的能力，从而导致工具名称冲突：来自外部服务器的恶意数据或响应可以覆盖合法功能并劫持执行流。[13]

基于 GitHub 的 MCP 工具中不受限制的私有／公共仓库访问

使用 GitHub MCP 服务器时，用户向 MCP 工具授予不加区分的总体访问权，使其代表用户行动。结果是，这些工具可能在仓库级别获得不受限制的读写访问，覆盖私有和公共仓库，而不是与特定仓库或操作相绑定的窄范围权限。这种缺少细粒度授权控制的情况，使恶意或已被攻陷的工具能够从私有仓库读取敏感内容，并在用户没有明确知晓或意图的情况下将其写入或发布到公共仓库。[14]

经由消息平台的利用

带有 MCP 扩展的 WhatsApp

存在一个受信任的第三方 MCP 智能体，用于 WhatsApp——一种流行的消息应用——以增强聊天能力。研究人员演示：在智能体系统内引入一个恶意 MCP 服务器，可以胁迫 MCP 客户端在没有用户通知或批准的情况下，直接从 WhatsApp 服务器暴露 WhatsApp 消息数据。该技术之所以奏效，是因为：a）MCP 客户端同时连接到恶意 MCP 服务器和受信任的 MCP 服务器；b）恶意 MCP 服务器的工具描述通过一个被恶意设计的 MCP 工具操纵了 MCP 客户端的行为。此外，为了更好地隐藏对该技术的利用企图，恶意 MCP 服务器在安装时宣传一条良性指令，并在 MCP 服务器第二次被使用后切换为恶意指令。[15]

为下游自动化投毒输出

MCP 智能体产生过这样的输出：如果下游智能体或系统盲目信任这些输出，它们可能被误解释为可执行提示而非被动内容，从而促成操纵、提示注入或数据渗出。该风险包括对工具元数据的语义操纵、嵌入输出中的隐藏指令，以及可以影响后续智能体如何解释并据较早结果采取行动的级联提示注入。此类漏洞可能出现在多智能体工作流中：一个智能体的输出成为另一个智能体的输入，使恶意内容得以传播，并在链式 MCP 过程中导致未授权行为、数据渗出或控制流劫持。近期关于 MCP 中语义投毒和工具投毒的研究强调，这类威胁是系统性的而非孤立的，表明被攻陷的描述符、工具输出或共享上下文可以在许多智能体流水线中颠覆预期运行。[16]，[17]，[18]

远程代码执行漏洞

在 MCP Inspector 工具链中执行 CVE-2025-49596

MCP Inspector 中披露了一个漏洞（CVE-2025-49596）。该产品用于测试开发中的 MCP 服务器。检查器工具接受未经验证的输入，使恶意行为者能够通过精心构造的消息触发远程代码执行。该问题已在 0.14.1 版本中修复，凸显了当 AI 工具链忽视安全卫生时，众所周知的安全弱点如何可能再次出现。[19]

建议

要安全地采用 MCP，组织必须超越协议中提到的建议，采用超出该文档范围的有意安全控制。以下一些建议针对构建 MCP 客户端或服务器实现的开发者，但大多数可以使用标准软件实践来集成，例如反向代理、中间件防火墙，或应用沙箱与遏制框架。关键是使 MCP 运行与已确立的安全计算实践保持一致，同时不扼杀使其具有吸引力的灵活性与能力。

尽可能选择受支持的 MCP 项目

MCP 项目文档已指出，许多流行服务器不再被积极维护。[20] 其中一些已归档的服务器与数据和文件系统、开发工具、万维网和浏览器自动化、生产力服务以及专用工具交互。MCP GitHub 页面也维护一份参考实现列表，有助于识别提供可靠集成的项目。[21] 如果组织有代码审计流程，应使用最严格的审查配置将其应用于 MCP 服务器项目，在评估较新的集成时尤其如此。在可能时，在本地部署并维护 MCP 服务器或客户端，并利用 MCP Registry 服务[22] 等能力登记它们，使其可供内部使用。

为边界而设计

安全始于对数据及相关处理环境的有意分离。组织必须清楚定义 MCP 组件之间的信任边界，包括智能体、插件、模型和最终用户。这些组件应被视为处于不同的信任区，各自有自己的假设和控制。例如，来自面向用户的插件的数据不应被有特权的后端模型盲目接受。

此外，动态工具发现[23] 是 MCP 灵活性的标志，除非能与来源核验或授权检查相结合，否则应谨慎对待。一种可操作的策略是使工具和模型与数据分类区对齐。可公开获得的工具可以分组处理公开数据集（例如天气数据），而与敏感或受监管信息（例如国家安全信息、受控非密信息、健康记录、财务信息等）交互的工具，其访问应被显式控制并隔离。在处理私有数据时，始终优先使用 MCP 服务器的本地实例，以降低数据泄漏风险。

为保护 MCP 环境，对发往外部实体的连接使用过滤型出站代理（例如 Squid、tinyproxy）或企业数据防泄漏（data loss prevention，DLP）解决方案，并配以特定的资源 URL 和访问方法。除代码限制之外，这可以进一步防止从 MCP 环境发生任何非预期的数据泄漏或渗出。

验证参数

在 MCP 这样可组合、可扩展的系统中，参数验证至关重要。参数验证的概念超出简单地验证输入，旨在理解执行环境的上下文和配置。例如，在一个连接了 MCP 的智能体式数学解释器 LLM 中，恶意行为者可能操纵 “context” 参数以触发非预期的文件输入／输出行为，尽管数学输入和输出本身看起来可能有效。对安全至关重要的是，每一次工具调用或模型执行请求都要根据明确定义的模式、预期范围，以及数据将被处理的预定上下文或配置来验证其输入。这包括检查畸形输入、缺失字段和过大的尺寸——其中任何一项都可能触发不稳定行为，或被用于提示注入或 DoS 技术。

当数据来源含糊或可能由用户提供时，应显式阻止或限制参数转发。否则，原本针对一个组件的输入可能被另一个组件误解释或不适当地复用，导致级联的非预期结果、失败或数据泄漏。

约束并沙箱化工具执行

把经由 MCP 触发的任何工具执行都视为潜在的高风险动作是审慎的。为降低暴露，应施加约束以限制访问并防止误用。无论插件是在运行 shell 命令、发出数据库查询，还是调用外部 API，它都应在严格的资源和权限边界内运行。在操作系统层，应使用 AppContainers（Windows）、seccomp、AppArmor 或 SELinux 等安全框架，隔离每个工具的执行上下文。工具也应被沙箱化，以便在发生攻陷时阻止横向移动或权限提升。同样重要的是，MCP 智能体进程本身应遵循最小权限原则：如果服务器不需要访问敏感文件系统、模型或数据文件，或内部网络，这些访问路径应在运行时被显式拒绝。

签名并核验 MCP 消息

绝不应假定消息的真实性与机密性，在处理敏感数据或作出安全关键决策时尤其如此。MCP 目前依赖传输层加密（例如 TLS）。协议本身无法强制或核验加密，也不感知消息完整性。然而，可以使用现代库现成具备的能力，在 JavaScript 对象表示法（JavaScript Object Notation，JSON）载荷内直接用密码学签名扩展该标准，以保护敏感消息。对于会话保护，有时限的签名可以在需要时提供额外保证。MCP 消息应包含过期时间戳和重放保护元数据，以防范延迟或重复的消息，这是分布式或事件驱动系统中的已知风险。OWASP 应用安全验证标准（Application Security Verification Standard，ASVS）V7 会话管理中的建议在此可以直接适用。与应用安全中众所周知的 OWASP 指南相一致，MCP 消息应以密码学方式把请求绑定到时间和上下文，以防止篡改、有意的重放技术，以及非预期的重复执行错误。

过滤并监控输出流水线与链式执行

来自工具和模型的输出绝不应被视为被隐式信任，即使它们来自先前已审查的组件。每一项输出都必须被视为流水线下一阶段的不可信输入，因此在被处理或展示之前要经过审查。过滤应包括内容长度检查、不允许的关键词扫描、速率限制，以及特定于应用的策略强制。

由于 LLM 和智能体经常生成看起来良性、但携带隐藏逻辑或提示操纵的文本，输出过滤应包括对间接提示注入或工具链转向企图的检测。在多组件 MCP 流水线中，这包括在把每个 MCP 工具的输出传递给下一个之前进行记录和检查，以识别可能改变下游行为的注入提示或代码元素。就检查而言，具备 MCP 感知能力的安全代理仍然有限且仍在成熟，但可能提供部分缓解。然而，鉴于其处于开发早期，使用时应谨慎，在处理敏感数据时尤其如此。

为日志与检测进行检测仪表化

对 MCP 环境而言，健壮的可观测性是必要的。所有工具和模型调用都应被记录，包括确切参数、所涉身份，以及（在可行时）结果或输出的密码学散列。这些日志构成发生入侵或异常时取证响应的骨干。

在可能时，该遥测应集成到组织现有的安全监控基础设施中——例如安全信息与事件管理（Security Information and Event Management，SIEM）系统、威胁检测流水线或合规仪表盘。这种集成使开发者能够告知安全团队识别可疑模式的合理方法，例如非预期的工具调用或异常的消息流，同时尽量减少误报。

跟踪并修补与 MCP 相关的漏洞

随着 AI 集成层迅速演进，MCP 框架、工具和模型中的新漏洞很可能出现。为保持领先，建议组织建立正式流程来监控与 MCP 相关的漏洞，无论是通过常见漏洞与暴露（Common Vulnerabilities and Exposures，CVE）、供应商公告，还是开源问题跟踪器。这包括订阅相关安全源，并通过专门的威胁情报资源保持知情，开发者和系统集成团队越来越多地使用这些资源来评估项目风险。

在内部，组织应维护所有已部署 MCP 智能体和工具的清晰清单，以及版本、补丁历史和已知安全关切。维护良好的登记册能够在漏洞被披露时加快分诊并协调缓解工作。

最终，对新识别风险作出快速响应的能力，对安全使用 MCP 至关重要。通过投资于系统性的漏洞跟踪，组织将降低其暴露和被攻陷的风险。

扫描本地网络以发现开放或存在漏洞的 MCP 服务器

作为基线安全卫生的一部分，建议组织定期扫描其网络，以便在不安全或未授权的 MCP 服务器被利用之前将其识别出来。MCP 服务器，尤其是处于开发中或在没有加固配置的情况下部署的服务器，可能在没有适当身份认证、授权、限制或监控的情况下，在本地或公共网络上可被访问。安全团队应主动扫描此类实例，以便在它们被内部或外部威胁滥用于恶意活动之前识别并缓解风险。已有大量 MCP 安全扫描工具，例如 MCP Scanner、Ramparts、CyberMCP 和 Proximity，可用于检测企业网络中的若干类开放服务，包括：

• 未认证的 MCP 服务器：无需登录或授权即可访问的实例。
• 存在漏洞的 MCP 服务器：带有已知安全缺陷或过时版本的部署。
• 未授权的 MCP 部署：在已批准的变更控制之外安装或运行的服务器。
• 不受管制的互联网连通性：具有开放入站或出站流量路径的 MCP 服务。

MCP 服务器可能动态改变端口，因此周期性扫描和差异报告对于检测新的或被修改的服务是有价值的。这些报告为网络管理员和安全团队提供审计变更、调查异常，并在整个 MCP 环境中强制安全策略所需的可见性。

结论

MCP 代表智能体式 AI 的一个有前景、但仍在成熟的基础，使跨模型与系统的编排和自动化获得新能力。然而，这种能力伴随着重大且仍在演进的安全关切，从序列化风险和提示注入，到不透明的更新机制和脆弱的过滤能力。安全专业人员开始对这些议题提出关切，正如 Docker 对 MCP 相关风险的探讨等近期分析所示，为该主题带来了亟需的可见性。[24] 来自 OASIS CoSAI 等组织的并行工作，也阐明了 MCP 系统中围绕范围控制、信任边界和智能体误用的密切相关切。[25]

虽然 MCP 作为智能体系统的使能层具有真实前景，其当前安全态势仍然不均衡，并且高度依赖实现纪律，而非协议保证。因此，采用者应谨慎推进，借鉴先前分布式和基于插件的生态系统的经验，同时对 MCP 引入的新型集成与自动化模式施加更高审查。实现者、安全研究人员和标准组织之间持续的协作，对于为 AI 基础设施建立更健壮、更可信的基础至关重要，对国家安全和其他高保证环境尤其如此。

PRIMARY_SOURCE: https://media.defense.gov/2026/Jun/02/2003943289/-1/-1/0/CSI_MCP_SECURITY.PDF