简介

模型上下文协议（Model Context Protocol，简称 MCP）为 AI 应用连接外部能力和数据定义了一种结构化方式。其核心组件包括主机应用、一个 MCP 客户端以及一个或多个 MCP 服务器。主机是用户直接交互的产品，例如 IDE 或助手应用。通常，主机会为每个服务器创建独立的客户端连接，以确保协议状态、能力和故障始终与正确的服务器关联。

MCP 服务器通过协议操作公开各种能力。工具是可执行的操作，可以查询服务、修改记录、发送消息或执行其他具有副作用的操作。资源表示客户端可以检索的数据，而提示词则提供可复用的 prompt 模板或交互模式。这些类别在架构设计上很有用，但不应仅仅因为某项内容经由 MCP 传递就将其视为可信。生产环境的安全性取决于每个组件的所有者、每条连接传输的数据，以及某项操作能够行使的权限。

请求流程与组件职责

一次典型的交互始于主机通过受支持的传输方式与 MCP 服务器建立会话。客户端和服务器初始化协议会话，并交换双方支持的能力。随后，主机可以发现可用的工具、资源或提示词，并决定应如何在用户体验或模型上下文中呈现这些能力。具体传输方式可能因本地部署和远程部署而异，但信任问题保持不变。

当模型提出工具调用时，主机或客户端负责在转发请求之前，依据产品的交互和授权策略对请求进行处理。服务器会再次验证请求，并使用自身的凭据和运行时权限执行操作。结果经由服务器和客户端返回主机，主机可以将其展示给用户，或添加到模型上下文中。这种重复验证是有意设计的：客户端策略可以减少不安全的请求，而服务器端验证则能在其他客户端或格式错误的消息到达服务器时保护服务器。

资源读取遵循相关的路径，但风险特征有所不同。服务器解析所请求的资源，并返回内容或元数据。只读并不意味着无害：资源可能包含机密信息、恶意指令、个人数据或已经过时的内容。主机必须保留数据来源信息，并在呈现或使用这些内容之前应用访问控制。

开发环境中的信任边界

第一道边界位于用户与宿主应用程序之间。宿主会接收自然语言请求、工具结果、资源内容，以及可能来自外部系统的指令。生产环境中的宿主不应假定检索内容中的每条指令都代表用户意图。它需要制定明确的确认规则，尤其是在某项操作会修改数据、联系第三方、花费资金或暴露机密信息时。

第二道边界位于宿主的 MCP 客户端与服务器之间。服务器可能是从软件包安装的本地进程、由内部单独管理的服务，也可能是由另一个团队运营的远程服务。这些部署方式会改变身份验证、隔离和更新模型。本地进程仍可能读取文件、继承环境变量、访问网络目标或执行存在漏洞的依赖项。远程服务器仍可能接收敏感参数，并返回会影响模型的内容。

第三道边界位于 MCP 服务器与其下游系统之间。服务器可能调用数据库、云 API、文件系统、工单系统或 shell 命令。MCP 身份验证不会自动授权这些下游操作。服务器应使用权限范围严格受限的服务身份、明确的目标控制、超时设置、速率限制以及针对具体操作的授权。即使服务器的 MCP 接口只暴露少数几个工具，只要它能够发出不受限制的管理请求，就仍然是高影响组件。

生产环境中的身份与授权

身份验证回答的是谁在连接；授权回答的是该身份可以执行什么操作。在生产部署中，应尽可能分别识别宿主或用户上下文，以及 MCP 服务器。避免让所有客户端和服务器共用一个凭据。分离身份有助于凭据撤销、事件调查、速率限制和最小权限控制的实施。远程部署还需要安全传输机制，以及明确的凭据处理方式；凭据不应放入工具参数中，也不应在工具结果中返回。

能力协商有助于实现兼容性，但它不是授权决策。服务器声明支持工具，并不意味着特定用户可以调用所有工具。授权应针对所请求的操作、目标、租户和数据分类进行评估。例如，用户可能被允许读取项目资源，但无权删除项目，即使这两种能力都由同一服务器提供。

工具 schema 有助于约束输入，但 schema 并不是完整的安全策略。服务器应验证类型、范围、长度、标识符以及字段之间的关系。它应拒绝意外的目标、不安全的文件路径、无效的租户引用，以及超出调用方权限范围的请求。对于高影响操作，宿主可以要求用户明确批准，并在执行前显示目标、预期效果和重要参数。批准应绑定到具体操作，而不应被视为永久权限。

运营控制与故障处理

生产环境运行需要覆盖完整请求路径的可观测性。记录发起请求的身份、处理请求的服务器、选定的工具或资源、授权结果以及下游结果。对机密信息和不必要的个人数据进行脱敏。使用请求标识符关联客户端、服务器和下游日志，同时要认识到日志本身也会成为敏感资产，需要访问控制和保留规则。

应针对部分故障进行设计。服务器可能不可用，下游 API 可能超时，响应可能超过大小限制，或者工具可能在产生副作用后返回错误。宿主应清晰传达不确定性，并且没有明确策略时，不应自动重试非幂等操作。服务器应使用有界超时、受控并发、响应大小限制和可预测的错误处理方式。对于开销较大或脆弱的依赖项，可能适合使用熔断器或速率限制。

应将更新和配置视为信任模型的一部分。固定或审核服务器版本，验证部署制品的来源和完整性，在源代码之外管理机密信息，并限制本地进程继承的环境。使用格式错误的输入、未经授权的目标、超大结果、资源中的 prompt injection 以及下游故障测试工具行为。安全审查应检查运行时的实际权限，而不仅仅是 MCP 服务器公开的名称和描述。

常见错误与实用审查

一个常见错误是把工具描述视为安全契约。工具描述有助于发现功能，但遭到入侵或维护不善的服务器，可能会用无害的语言描述危险操作。应审查实现方式、身份权限、网络目标、数据流以及审批行为。对 prompt 模板和资源元数据也应采取同样的谨慎态度：它们可以影响模型行为，但不能确立权限。

另一个错误是把本地开发环境当作生产环境的信任模型。开发人员通常会运行一个具有广泛文件系统访问权限、个人凭据、无限制出站网络访问权限以及详细日志记录的服务器。生产环境应将这些默认设置替换为专用的运行时身份、受限工作目录、最少化的环境变量、明确的出口规则以及受控的数据处理流程。应使用生产环境实际授予的权限来测试部署。

在审查过程中，应从用户请求到下游影响，跟踪一个具有代表性的读取操作和一个具有代表性的写入操作。对于每个步骤，明确其身份、输入验证、数据分类、审批要求、超时设置、审计事件和故障处理行为。如果任何步骤都无法被准确说明，则该边界尚未完成可操作化定义。这种方法能够产生具体的整改工作，而不是依赖“该 MCP 服务器可信”这一笼统说法。

总结

MCP 将宿主体验与服务器提供的功能分离开来，但不会消除它们之间的安全边界。宿主管理用户交互和客户端会话；服务器验证请求并实现工具、资源和 prompt；下游系统仍然是彼此独立的权威主体，各自拥有独立的权限和故障模式。

对于生产环境，应重点关注明确的身份、最小权限、服务端验证、对高影响操作进行用户审批、谨慎处理检索内容、有界执行以及有用的审计跟踪。能力协商支持互操作性，而授权决定实际可以执行的操作。实践目标不是将 MCP 作为一个整体予以信任或不信任，而是记录每个边界，并针对跨越边界的数据和权限应用适当的控制措施。