影子 MCP：你的安全团队从未听说过的工具服务器已经在工程师的笔记本电脑上运行了

你的安全团队拥有公司信用卡上每一项 SaaS 订阅的完整清单、每一个获得管理员授权的 OAuth 应用，以及连接到公司 Wi-Fi 的每一台设备。然而，对于你的高级工程师笔记本电脑上当前绑定到 127.0.0.1 的七个进程，他们却完全视而不见——一个带有长期 Staging API 令牌的“部署助手”，一个订阅了包含客户数据的 Slack 频道的“工单分类器”，以及一个拥有生产分析数据仓库读取权限的“发布说明生成器”。这些都不在供应商名单上。它们不会出现在 SSO 日志中。所有这些都在利用工程师现有的凭据运行，执行着从未经过审批的操作。

这就是影子 MCP（Shadow MCP），它是企业中增长最快的未管理授权面。模型上下文协议（Model Context Protocol）使得将任何工具接入任何 LLM 的成本变得极低，而工程师们——天性使然——首先接入了那些最显而易见的工具。Saviynt 的 CISO AI 风险报告指出，75% 的 CISO 已经发现其生产环境中运行着未经授权的 AI 工具。GitHub MCP 服务器在 2026 年初的周安装量突破了 200 万次。Postgres MCP 服务器允许 LLM 对开发者能接触到的任何数据库执行 SQL 提示词，其周安装量已超过 80 万次。这些数字中没有一个代表企业的 IT 决策。

大多数安全项目仍在沿用的心理模型是为另一种产物构建的。影子 IT 是出现在报销单上的 SaaS 订阅，是财务审计在核对信用卡账单与资产清单时发现的供应商。采购、CASB 和 SSO 是三道筛子，它们共同拦截了大部分关键威胁。而影子 MCP 在设计上就绕过了这三者。这里的产物不是供应商，而是笔记本电脑上的一个 Python 进程。流量不是流向 SaaS 端点的出口流量，而是指向 localhost 的 JSON-RPC 调用。凭据不是新的 SSO 授权，而是工程师现有的生产环境只读令牌——这与他们在 Jupyter Notebook 中使用的是同一个令牌，只是现在被重新用作长期运行的 Agent 循环的身份验证。财务部门无从发现，CASB 无法检查，SSO 日志除了记录多年前为完全不同的目的而批准的原始令牌发放外，没有任何新的记录。

产物是回环套接字，而非供应商

在资产管理的语境下，影子 MCP 服务器看起来并不像应用程序。它们通常是开发者在某个下午凭感觉编写（vibe-coded）的短脚本，由开发者的 IDE 插件或 pipx 调用启动，并绑定到回环接口（loopback interface）的一个高位端口。它们暴露了 LLM 可以调用的工具，而这些工具会扇出到开发者机器可以触及的任何地方——内部 API、生产数据库、Slack 工作区、GitHub 仓库以及公司 VPN。EDR 不会标记它们，因为它们不是恶意软件。MDM 不会编目它们，因为从注册表角度看它们并非安装的软件。CASB 看不到它们，因为流量出口是内部 CIDR 范围，而不是供应商的公共 IP。

实际存在的可见性表面非常狭窄且未被充分利用。终端遥测可以列出每一个绑定到 TCP 套接字（包括回环地址）的进程，这份清单是了解公司设备上运行着哪些 MCP 服务器最接近真相的依据。对开发者主机进行的网络出口监控——不是在公司边界（那里的流量看起来只是正常的 VPN 流量），而是在主机本身——可以检测出 Agent 循环在数小时内每隔 30 秒调用同一个内部 API 的异常节奏。这两者在技术上都不难实现，但大多数公司都没有去做，因为安全团队运行的威胁模型上次更新还是为了应对 SaaS 影子 IT，那时的答案是“扫描信用卡账单”。

凭据复用是常态，也是问题所在

每一个影子 MCP 服务器都运行在某人已有的凭据之上。这并非偶然——这正是开发者选择 MCP 而不是构建服务的原因。其核心意义在于他们不必为申请新凭据而提交工单。他们拿着为临时分析而发放的生产环境只读数据库令牌，将其粘贴到 LLM 客户端启动时读取的配置文件中，现在，同一个令牌正被一个 Agent 循环使用，只要笔记本电脑开着，它每分钟就会发出 30 条查询。当令牌被用于 Notebook 会话时，审计轨迹非常清晰——工程师坐在键盘前，每隔几分钟进行一次查询；而现在，审计轨迹变成了噪音。当需要回答“在报告客户数据泄露的那天，该用户运行了哪些查询”这一取证问题时，原本只需过滤几行 SQL 的操作，现在变成了在百万行毫无信号的干草堆中捞针。

这并非假设。OWASP MCP Top 10 (MCP09:2025) 将影子服务器列为一个单独的类别，正是因为凭据复用这一失败模式在各种部署中具有一致性。三分之二的开源 MCP 服务器在发布时携带的安全实践被 OWASP 项目评为“差”——大约 43% 存在 OAuth 流程缺陷，另有 43% 存在命令注入漏洞。即使是那些构建良好的服务器，也会继承凭据所拥有的任何权限。令牌不知道它正被 Agent 使用。下游 API 不知道它正被循环调用。唯一能识别出这种新使用模式的地方是运行 MCP 服务器的笔记本电脑，而那正是唯一没人关注的地方。

混淆代理桥接并不像数据外泄

影子 MCP 中的数据外泄风险并非显而易见。没有人会从公司笔记本电脑将客户表上传到 Pastebin —— 这会触发大楼里的每一条 DLP 规则。风险在于混淆代理（confused-deputy）桥接：一个 LLM 拥有一个从生产环境读取数据的工具，以及另一个向个人 Notion、个人电子邮件或个人 GitHub gist 写入数据的工具。这两个工具本身都不是恶意的。孤立来看，这两次调用都不是异常的。但这种组合形成了从生产数据到工程师个人云端的单向管道，而且没有任何 DLP 规则能捕获它，因为出口目的地是 Notion 当天的 IP 范围，而这恰好也是工程师合法编写会议记录的地方。

加载中…