在 AI 编程与企业智能体快速接入外部工具的浪潮中，Model Context Protocol（MCP）正成为新的连接层。它让模型能够调用工具、读取上下文、执行命令，也把原本分散在应用侧的能力集中到协议层。但伴随规模扩大，安全问题开始从“潜在风险”变成“现实漏洞”。一个由开发者社区持续披露的安全问题清单显示，MCP 相关攻击并非只存在于理论推演中，而是已经涉及工具描述注入、数据外泄、远程代码执行以及官方服务组件缺陷等多个层面。
与此同时，一种新的防护思路正在出现：不再只检查单次请求是否合法，而是把多轮对话与工具调用当作完整链路来分析，识别那些单看每一步都正常、但连续起来构成权限升级或数据泄露的攻击行为。这种“链路分析”正在成为 MCP 安全网关的重要能力。
MCP 快速普及后，安全机制仍显薄弱
根据素材披露的时间线，MCP 于 2024 年 11 月推出。到 2026 年 9 月，相关实现数量已超过 30,000 个。作者将其增长速度与 Docker 早期发展对比，认为其扩张速度更快。但在快速普及背后，安全问题并未同步得到解决。
素材指出，当前大量 MCP 实现并未部署统一的安全网关。MCP 规范中虽然包含安全章节，但更多是原则性描述，而不是可直接落地的防护工具。作者统计称，规范安全指南中使用了 23 次“SHOULD”，但只有 4 次“MUST”。这意味着很多安全要求仍停留在建议层面，具体如何实现、是否实现，往往取决于服务器开发者自身。
更关键的是，规范提出服务器“必须”做某些事情，却没有给出对应实现路径。没有统一库，没有现成中间件，也没有默认安全层。每个 MCP 服务器实现者只能自行构建安全能力，或者在某些场景下直接跳过。这种状态让 MCP 生态在快速扩展的同时，也暴露出明显的安全真空。
已披露漏洞指向多类攻击面
素材列举了 2025 年以来多个安全团队和厂商披露的 MCP 安全问题，覆盖工具描述、输出内容、会话上下文、供应链库以及官方组件等多个环节。其共同特点是：攻击不再局限于传统代码漏洞，而是利用模型、工具与客户端之间的信任关系。
- 2025 年 4 月，Trail of Bits 披露 MCP 服务器可以通过工具描述注入提示词，在工具被调用之前影响 AI 行为。攻击者不需要用户真正调用恶意工具，只要工具被安装，就可能产生影响。
- 同期，Simon Willison 指出 MCP 存在提示注入问题，包括工具投毒、工具定义在安装后变化、工具影子化等风险。素材还提到一个名为 whatsapp-mCP 的案例，可能导出完整消息历史。
- Trail of Bits 还提到，MCP 服务器能够访问完整对话上下文。恶意服务器可能读取用户输入内容并将其发送到外部。
- 2025 年 5 月，Invariant Labs 披露 GitHub MCP 被利用，攻击并非依赖 GitHub 自身漏洞，而是利用 MCP 服务器与客户端之间的信任关系访问私有仓库。
- CyberArk 在同月指出，工具输出也可能包含提示注入。即使工具本身可信，其返回的数据仍可能携带对抗性指令。
- 2025 年 6 月，Asana 披露其 MCP 服务器存在数据暴露漏洞；Cato Networks 则展示了一种被称为“Living Off AI”的概念验证攻击，利用合法 MCP 工具作为攻击载体，目标是 Atlassian 的 MCP 服务器。
- 2025 年 7 月，一个被广泛使用的 MCP 远程传输库 mcp-remote 被披露存在远程代码执行漏洞，修复前下载量超过 437,000 次。同期，Anthropic 自家 Slack MCP 服务器也被指存在数据外泄漏洞。
- 2025 年 8 月，Cursor 被描述为可通过 Jira MCP 遭劫持。攻击者提交包含恶意指令的 Jira 支持工单，影响连接 MCP 的 Cursor 编辑器。
这些案例表明，MCP 的风险并不只来自某个单独的恶意工具，也可能来自工具输出、会话记录、远程传输、支持工单内容，甚至官方组件本身。对于 AI 编程工具和企业智能体而言，一旦 MCP 通道被利用，影响可能从代码仓库扩展到对话历史、内部数据和执行环境。
链路分析如何识别多轮权限升级
素材作者表示，其团队过去数月一直在构建 AI 安全网关，并重点解决一种更隐蔽的攻击类型：多轮权限升级攻击。这类攻击的特点在于，每一次单独请求看起来都没有明显恶意，但跨越多轮后形成的模式才是攻击本身。例如，攻击者可能先进行看似普通的查询，再逐步诱导更高权限操作，最终触发敏感数据访问或命令执行。
如果只检查单次请求，传统防护很容易放行这类行为。因为每一步都可能符合格式要求，也没有命中已知恶意关键词。链路分析的意义在于，将多个回合的调用记录组合起来观察，识别其中的递进关系、风险变化和行为序列。
素材中提到的 AegisGate 平台内置了一个 MCP 服务器，并在其中设置了 7 项防护机制，用于落实规范中的 4 个“MUST”，并进一步扩展安全边界。其中，最核心的一项能力是工具调用链分析。每次工具调用都会被记录到链分析器中，系统会追踪 20 个回合，并设置 30 分钟 TTL。它会检测三种模式，素材虽未完整列出全部模式细节，但明确提到系统会在检测到攻击链后的第 2 次调用时阻断。作者称，在 8,100,000 次良性请求中，该机制的误报率为 0%。
这类设计的价值在于，它不是等待某个危险动作真正执行后再拦截，而是在攻击链刚开始展开时介入。对于多轮诱导、逐步提权、跨工具组合利用的场景，这比单纯的输入过滤或单点权限判断更接近真实威胁模型。
从会话限制到命令校验，安全网关开始补齐基础设施
除链路分析外，素材还描述了多项 MCP 安全网关的基础能力。其一是会话管理。系统会跟踪每个层级的并发 MCP 会话，并强制执行 MaxConcurrentMCP 限制。当达到上限时，返回 max_sessions_reached 的 JSON-RPC 错误。这主要用于防止会话耗尽型拒绝服务攻击。
其二是基于风险等级的工具调用控制。每一次工具调用都会对照分层风险矩阵进行检查。素材提到，shell_command 被归为 Critical 风险，在 Community 和 Developer 层级被阻止；database_query 被归为 High 风险，在 Community 层级被阻止。工具在注册时会绑定风险等级和数据类型，授权检查发生在工具执行之前。
其三是 STDIO 命令校验。素材认为这是其他方案中较为少见的能力。由于 MCP 的 STDIO 传输方式在设计上会执行操作系统命令，作者团队会对每条命令进行白名单校验，规则为 ^[a-zA-Z0-9/._-]+$，并拒绝管道符、分号、命令替换、重定向、通配符、环境变量展开和后台执行等 shell 元字符。作者称，该机制直接回应了 OX Security 关于“所有 AI 供应链之母”的安全提示，以及 Anthropic MCP SDK 中 STDIO 设计相关风险。该防御实现约 200 行 Go 代码。
此外，系统还包括按客户端地址进行的速率限制。该机制采用滑动窗口桶，并支持配置 RPM。素材提到，Developer 层级为 500 RPM，Enterprise 层级可配置，用于在不影响正常使用的情况下防止滥用。响应侧也有 MCP 消息扫描能力，用于检查返回内容中的风险。
这些能力共同构成了一个更完整的 MCP 安全网关框架：不只是看工具是否可信，也不只是看输入是否危险，而是同时管理会话、权限、命令、速率和响应内容。对于 AI 编程工具来说，这种防护尤其重要，因为开发环境往往连接代码仓库、终端、项目文档和内部系统，任何一处被绕过都可能造成连锁影响。
MCP 的价值在于让模型更顺畅地接入真实工作系统，但它也把模型安全、供应链安全和应用安全压缩到了同一个协议层。当前披露的问题说明，仅靠规范文本难以自动形成安全边界。随着 MCP 在 AI 编程和企业智能体中的使用继续增加，安全网关、链路分析和调用前授权可能会成为基础设施的一部分。对开发者而言，真正的挑战不是是否使用 MCP，而是在接入 MCP 时，是否已经为多轮交互、工具输出和跨系统信任关系建立足够的防护。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/duo-lun-qing-qiu-li-de-yin-xing-gong-ji-an-quan-wang-guan
