影子 MCP:SOC 尚未看见的 AI 智能体盲区

MCP(Model Context Protocol,模型上下文协议)是 Cursor、Claude Desktop、VS Code 以及各类智能体(agent)框架连接真实工具的方式:数据库、Git 仓库、工单系统、命令行。每一个连接就是一个 MCP 服务器。过去一年多,它从一份规范变成了企业 AI 集成的默认基础设施,而安全审查远远没有跟上。

根据 2026 年年中汇总的数据,86% 的 MCP 服务器运行在开发者本地电脑上,只有 5% 运行在生产环境中。问题的本质就在这一句话里:企业内增长最快的集成层,运行在 SOC 眼中"普通笔记本"的终端上,以没人登记过的子进程形式启动,手里握着从未轮换过的凭证。

2026 年发生了什么:用数据说话

• 2026 年初短短 60 天内,针对 MCP 服务器登记的 CVE 超过 30 个,其中约 43% 属于命令注入类。
• 社区维护的 Vulnerable MCP Project 追踪了 50 多个已知漏洞,其中 13 个为严重级别。
• 一项覆盖 5,200 多个 MCP 服务器的审计发现:53% 依赖固定 API 密钥或个人访问令牌,79% 通过环境变量传递密钥,仅 8.5% 使用 OAuth。
• GitGuardian 在公开 GitHub 上的 MCP 相关配置文件中发现 24,008 个密钥,其中 2,117 个仍然有效。
• mcp-remote 的 CVE-2025-6514(CVSS 9.6)允许在客户端连接不可信服务器时实现远程代码执行,波及超过 43.7 万次下载。
• Cursor 的 CVE-2025-54136("MCPoison") 展示了一种更隐蔽的模式:一份已被信任的 MCP 配置,之后被悄悄替换为恶意版本,从而实现持久化代码执行。

对检测工作而言,最后一个案例最关键。攻击面不只是服务器代码,还包括告诉 AI 客户端"启动哪些服务器、使用哪些凭证"的配置文件本身。

为什么 MCP 是 SOC 的盲区

我们此前的文章《2026年的Agentic AI SOC》讨论的是安全团队自己掌握和管控的 AI 智能体。影子 MCP 不同:这些是员工自行配置的智能体与工具连接,大多出于善意,只是为了把工作做得更快。

flowchart TD
    A["开发者笔记本"] --> B["Cursor 或 Claude Desktop 等 AI 客户端"]
    B --> C["MCP 配置文件写明服务器与密钥"]
    C --> D["本地 MCP 服务器以子进程形式启动"]
    D --> E["用于 Git 数据库 或 SaaS API 的固定令牌"]
    E --> F["以开发者本人权限访问内部系统"]

从 SOC 的视角看,这条链路上的每一步都显得平平无奇:

1. 进程看起来正常。 通过 STDIO 启动的 MCP 服务器,通常只是以登录用户身份运行的 node、npx、python 或 uvx。没有新服务,没有安装程序,也没有可疑的新二进制文件。
2. 凭证看起来合法。 令牌属于真实员工。当智能体去查询客户数据库时,数据库日志里记录的是这名员工的身份,而不是"一个按照工具描述指令行事的 AI 智能体"。
3. 工具调用不在任何已采集的日志里。 MCP 协议交互发生在客户端进程内部。除非在中间部署网关,否则根本没有"调用了哪个工具、带了什么参数"的审计记录。
4. 没有人对清单负责。 IT 部门没有安装它们,安全部门没有审批过,而开发者上周可能又加了三个。

这也是 Obsidian 研究团队把 MCP 安全首先定义为"资产清单问题"的原因:不知道存在的服务器,就无法打补丁、无法轮换凭证、也无法监控。

本月即可在 Wazuh 上落地的四层检测

以下内容都不需要采购新产品。它们是适用于任何 Wazuh 4.x 环境(包括 simpliSOC)的参考模式,而不是 simpliSOC 打包好的 MCP 模块。这一区别我们会在后文明确列出。

flowchart TD
    L1["第一层 MCP 配置文件完整性监控"] --> W["Wazuh manager"]
    L2["第二层 进程创建遥测"] --> W
    L3["第三层 新增监听端口"] --> W
    L4["第四层 提交前的密钥扫描"] --> W
    W --> R["DFIR-IRIS 案例供分析师复核"]

第一层:对 MCP 配置文件做文件完整性监控(FIM)

MCPoison 证明了配置文件可以成为持久化手段,所以要盯住它。在开发者终端上,把已知客户端配置文件的位置加入 Wazuh 的 syscheck。范围限定在"开发者工作站"这一 agent 分组,避免扫描全公司所有用户目录。

<!-- agent.conf, group: dev-workstations (Linux/macOS 示例) -->
<syscheck>
  <directories check_all="yes" realtime="yes"
    restrict="mcp\.json$|claude_desktop_config\.json$">/home</directories>
  <directories check_all="yes" realtime="yes"
    restrict="mcp\.json$|claude_desktop_config\.json$">/Users</directories>
</syscheck>

然后提高这些文件新增或修改时的告警级别:

<!-- local_rules.xml -->
<group name="mcp,syscheck,">
  <rule id="100910" level="10">
    <if_sid>550, 554</if_sid>
    <field name="file">mcp.json$|claude_desktop_config.json$</field>
    <description>MCP client configuration added or modified: $(file)</description>
    <mitre>
      <id>T1546</id>
    </mitre>
  </rule>
</group>

有一项配置是我们刻意不开的:不要在这些路径上启用 report_changes。 这些文件里经常包含 API 密钥,开启 report_changes 会把差异内容连同密钥一起复制进告警索引。我们需要知道的是"文件变了",而不是在另一个地方再存一份需要保护的密钥副本。

第二层:MCP 服务器启动的进程创建遥测

对于已经把 Sysmon 事件 ID 1 发送到 Wazuh 的 Windows 终端,一条低级别的清单规则就能把 MCP 启动变成可检索的记录:

<group name="mcp,sysmon,">
  <rule id="100911" level="5">
    <if_group>sysmon_event1</if_group>
    <field name="win.eventdata.commandLine" type="pcre2">(?i)(mcp-remote|@modelcontextprotocol|mcp-server|mcp_server)</field>
    <description>MCP server process launched: $(win.eventdata.commandLine)</description>
  </rule>
</group>

级别 5 是有意为之。在开发者电脑上它会频繁触发,而这正是目的:两周之后,你就拥有一份清单,知道哪些 MCP 服务器真实在运行、在哪些主机上、由哪个父进程启动。摸清"正常"之后,再为例外情况编写高级别规则,例如低于 0.1.16 版本的 mcp-remote,或出现在开发者分组之外主机上的 MCP 服务器。Linux 上可以通过 auditd 的 execve 记录或 osquery 实现同样的模式。

第三层:开发者主机上的新增监听端口

部分使用 HTTP 传输的 MCP 服务器默认绑定 0.0.0.0,于是一个本地工具就变成了同网段任何人都能调用的网络服务。Wazuh 默认配置里已经包含获取监听端口的 netstat 命令,以及在端口集合变化时触发的规则 533。请确认该命令在开发者分组中已启用,并把这一分组的规则 533 告警送入复核队列,而不是让它淹没在噪音里。笔记本上由 node 或 python 新开的端口,值得看一眼。

第四层:配置文件进入 Git 之前的密钥扫描

那 24,008 个泄露的密钥并不是从生产环境泄露的,而是来自被提交到代码仓库的配置文件。这一层不是 Wazuh 的职责范围,正确的工具是在 pre-commit 和 CI 中集成 gitleaks 或 TruffleHog 这类密钥扫描器,并把 MCP 配置文件名加入扫描范围。再把扫描结果作为日志源转发到 Wazuh,让密钥泄露事件进入与其他告警相同的案例处置流程。

要修的不只是检测,而是身份模型

检测能告诉你"某位开发者的 MCP 服务器持有一个长期有效的 GitHub 令牌",但改变不了这个令牌存在的事实。MCP 规范在 2025 年 6 月的修订中,建议基于 HTTP 的服务器采用 OAuth 2.1 加 PKCE,并将资源服务器与授权服务器分离。但在实践中,大多数企业内部的 MCP 服务器仍然接受固定密钥,因为这是最快的做法。

对于企业自研的内部 MCP 服务器,更好的模式是把它们放到现有身份提供商之后:每一次工具调用都携带与真实用户绑定的短期令牌,权限仅限于该用户实际需要的工具,并且可以集中吊销。基于 Authentik 构建的 simpliSSO 就是我们在客户项目中承担这一角色的组件。需要准确说明的是:让 simpliSSO 作为 MCP 服务器的授权服务器,是按项目界定范围的集成模式,而不是 simpliSSO 预置的 MCP 功能。

为什么这在中国合规语境下更加重要

等保2.0 与《网络安全法》: 等保2.0 对安全审计有明确要求,《网络安全法》也规定网络日志留存不少于六个月。一条能直接访问内部数据库、却没有任何工具调用记录的通道,本身就是审计上的缺口。出了问题,"谁、在什么时间、通过什么工具、做了什么"这几个问题都难以回答。

《个人信息保护法》(PIPL)与《数据安全法》: 如果开发者电脑上的 MCP 服务器持有可访问客户数据库的令牌,一旦泄露,就可能构成需要采取补救措施并通知的个人信息安全事件。而要评估影响范围,前提是先知道这个令牌被哪些工具用过。

数据不出境: 这是影子 MCP 在中国语境下最容易被忽视的一点。不少 MCP 服务器会调用远程服务,AI 客户端本身也可能把工具返回的内容发送给境外的大模型接口。一个查询内部数据库的工具,其返回结果完全可能在开发者毫无察觉的情况下流向境外。没有 MCP 清单,就无法判断哪些数据流已经触及出境合规边界。对于正在推进"智改数转"的制造企业来说,在引入 AI 编码与智能体工具的同时建立这份清单,成本远低于事后补救。

已交付功能与参考模式的明确界线

本文所依赖的、simpliSOC 目前已交付的能力:

• 按客户部署并调优的 Wazuh 文件完整性监控、Sysmon 日志接入与命令监控
• 用于分析师复核上述告警的 DFIR-IRIS 案例管理
• 在《2026年的Agentic AI SOC》中介绍的只读本地 LLM 研判辅助,可以用通俗语言解释这些告警

本文中属于参考模式、并非已交付功能的内容:

• 上文的 MCP 规则(规则 ID 100910 与 100911)。我们在客户项目中部署和调优,但它们不属于 simpliSOC 打包的规则集
• 通过 MCP 网关或代理记录每一次工具调用
• 覆盖全组织的 MCP 服务器清单自动化报告
• simpliSSO 作为 MCP 的 OAuth 2.1 授权服务器(按项目界定范围)

30 天起步计划

1. 第 1 周: 建立开发者工作站 agent 分组,以级别 5 启用第二层。先不告警,只采集。
2. 第 2 周: 复核清单,把每个 MCP 服务器归类为"批准""暂时容忍"或"移除"。
3. 第 3 周: 为该分组启用第一层(配置文件 FIM)和第三层(监听端口),并把 MCP 配置文件名加入密钥扫描器。
4. 第 4 周: 轮换第 2 周发现的所有固定令牌,并把使用最频繁的内部 MCP 服务器迁移到身份提供商之后。

常见问题

MCP 不是本身就很安全吗?
MCP 提供了一个放置管控措施的标准位置,但不会替你把管控放上去。规范中的授权是可选项,STDIO 服务器根本没有网络层认证,而实际使用中的大多数服务器用的是固定密钥。

是否应该在公司电脑上全面禁用 MCP?
可以,监管严格的团队有时也确实应该这么做。但对大多数组织来说,一刀切的禁令会把开发者推向个人设备,形成更糟的盲区。先建清单,再逐个服务器做决定。

第二层规则会不会把 SIEM 淹没?
在开发者电脑上,前几天会比较热闹。所以它从级别 5 开始,并且只覆盖开发者分组。它的任务是建立清单,而不是半夜把人叫醒。

simpliSOC 的 AI 能自动检测工具投毒(tool poisoning)吗?
不能。我们的本地 LLM 辅助功能负责解释 Wazuh 已经产生的告警,并不会在运行时检查 MCP 的工具描述。检测工具投毒需要直接看到协议交互内容,也就是上文明确列为"尚未交付"的网关模式。

---

如果你正在运行 Wazuh,希望把这些模式落地为针对自身终端调优的规则,或者希望把内部 MCP 服务器放到规范的身份体系之后,这正是我们日常在做的工作。详情请见 simpliSOC 与 simpliSSO,也欢迎附上环境简介发送至 hello@simplico.net。

---

来源:

• MCP Security Statistics 2026: CVEs, Vulnerabilities & Breach Data — Practical DevSecOps
• MCP Security Vulnerabilities: Complete Threat Inventory — Obsidian Security
• 2026年的Agentic AI SOC — Simplico