《受控执行网关：保护 MCP 服务器与工具出口代理》封面图

Google Developer Experts 个人资料图片 Jitendra Gupta

Model Context Protocol (MCP) 中的边界空白

随着 Model Context Protocol (MCP) 迅速成为将 LLM 连接到本地文件系统、SaaS 平台和企业数据库的行业标准，平台工程团队面临一个全新的安全边界。

将自主 AI 代理直接连接到未受监控的 MCP 服务器或外部 API 网关，会带来严重的企业风险：

  • 工具响应中嵌入的提示注入载荷
  • 未经授权的数据泄露
  • 无限制的 API 循环 与失控的递归调用
  • 缺乏协议级检查

为安全地在规模化环境中运行 MCP 服务器和工具执行，企业架构必须引入 受控执行网关——一个位于代理编排器与下游工具执行环境之间的专用出口代理。

受控执行网关的架构

受控执行网关充当所有非人类工具调用载荷的双向安全代理：

  • 入站检查与参数消毒：检查代理生成的传入 JSON-RPC 工具调用请求。验证参数类型，剥离恶意 SQL/命令注入字符串，并在将请求转发到目标 MCP 服务器前验证令牌执行者声明（act）。
  • 出站载荷过滤（数据出口控制）：在上下文注入前扫描下游系统返回的工具输出。阻止隐藏在检索数据中的间接提示注入，并自动编辑敏感 PII 或系统令牌。
  • 速率限制与循环中断：跟踪有状态执行深度。如果代理在单个追踪上下文中持续循环或触发递归工具调用，网关将动态终止执行。

MCP 与工具网关治理的 3 条硬性规则

  1. 协议级双向 TLS 与短期 MCP 令牌：到 MCP 服务器的直接 TCP 或 stdio 连接必须通过双向 TLS (mTLS) 或 OAuth 2.1 范围令牌进行管控。生产环境中禁止使用未经身份验证的纯文本 MCP 传输。

  2. 双向载荷检查：绝不信任来自模型的输入或来自工具的输出。输入必须经过严格的 JSON Schema 参数验证；输出在注入上下文前必须扫描隐藏的提示注入标记和敏感数据泄露。

  3. 集中式出口控制与遥测：所有工具调用必须通过配备 OpenTelemetry 追踪的统一代理层——记录完整的请求-响应对、执行延迟及身份元数据以供审计。

架构师观点

关键洞见：MCP 标准化了 AI 代理与企业系统的交互方式，但如果在标准化连接协议时未建立边界治理，就会为基础设施留下一个未受监控的后门。

对待 MCP 服务器应与面向公众的微服务采用相同的 零信任 安全原则：验证每个参数、检查每个载荷，并将所有出口流量路由通过受控代理。

来源与参考

关于我

我是一名拥有 14 年 IT 行业经验的 企业云与 AI 架构师，致力于帮助企业设计和扩展企业级云、AI 及自动化解决方案。

我目前的工作重点在于 构建企业级 AIOps 平台、加速客户 AI 优先转型之旅、推动 FinOps 落地，以及开发能够产生可衡量业务价值的、面向生产的生成式 AI 应用。

欢迎通过 LinkedIn 或 X（Twitter）@jitu028 与我联系。如需 1:1 架构指导，请访问我的 Topmate。