MCP 服务器正在往你的 Agent 上下文里塞指令：已索引 18230 个样本

上周，一支名为 Digital Applied 的研究团队做了一件很简单的事：他们查看了 19 个流行的 MCP 服务器实际放进了 AI agent 的 context window（agent 读取为可信指令的文本）中的内容。

问题遍地都是。工具输出中 routinely 包含与服务器声明功能完全无关的材料，其中包括足以重定向 agent 行为的指令。19 个之中有一个叫 Context7——大多数人都接入了自己 coding agent 的文档检索服务器——存在一个可 active exploited 的 prompt-injection 路径。2026 年 9 月 2 日的发现意味着这样一件事：一台服务器，其全部职责是向你的 agent 输送文本，并且你正因为它流行而信任它，却可以向你的 agent 输送你从未发出的指令。

这份报告并非孤立地抛出来。它恰好落进了这样一周：整个 MCP 层正在公开场合被拆解。

这一周，工具层不再装样子了

以下是 8 月 27 日到 9 月 2 日之间发布的内容：

Wiz Threat Research 发布了 90 天的蜜罐遥测数据（8 月 27 日）。攻击者并非在 generic 地扫描 AI 基础设施——他们为此专门构建了原生工具（native tradecraft）。他们利用了 CVE-2026-42271，这是 LiteLLM MCP 服务器测试端点中的一个命令注入漏洞，自 6 月起就躺在 CISA 的 Known Exploited Vulnerabilities 目录中。有效载荷下载了一个 Monero 挖矿程序，以 detached 方式启动它，删除其 staging 目录，然后返回一个看似合法的 MCP 握手，使连接测试报告成功。在一个 Langflow 目标上，攻击者在 /app/data/.claude/ 中放置了一个挖矿程序，并将其命名得与 Claude Code artifacts 混在一起。他们还从 Python 进程内存中直接拉取了 LiteLLM proxy master keys——因为在 LiteLLM 上那个 key 从不触碰磁盘，所以他们知道了哪个对象持有它。

Sentry 的自托管 MCP 服务器有一个未认证的 SSRF 漏洞，CVE-2026-81421（7 月 12 日通过 Forkast 报告，8 月 27 日）。调用者可控制的端点参数被直接传递给一个 HTTP 客户端，没有任何验证，将服务器变成了横向移动的 pivot 点。公开利用代码已存在。维护者已超过 46 天没有回应。BlueRock Security 发现，扫描的 7,000 台 MCP 服务器中有 36.7% 存在 SSRF 漏洞；41% 完全没有认证。

微软的 UFO agentic 自动化框架发布了 CVE-2026-73296，CVSS 9.4（8 月 31 日）。它的 Mobile MCP 服务器打开两个 Streamable HTTP 端口——一个用于数据，一个用于操作——没有 authentication provider，也没有 authorization check。按照微软自己的文档化远程配置部署，任何能访问这些端口的客户端都可以在连接的 Android 设备上调用 capture_screenshot、get_ui_tree、tap、swipe、type_text 和 launch_app。没有 API key，没有 token，没有用户批准。没有 patched version。

而在这所有一切的底层，7 月 28 日的 MCP 规范修订版变成了无状态的，drop 了 Mcp-Session-Id header，并将 session 级安全性推给了各个实现者——在独立扫描发现实现者已经跟不上的时刻，引入了六个新的攻击面。仅 2026 年 1 月到 4 月间，MCP SDK 和服务器上就出现了 40 多 CVE，大约每四天一个。对 2,600+ 个在线实现的扫描发现，82% 处理文件操作的实现存在路径遍历漏洞，67% 携带代码注入风险。Censys 在 5 月份统计到超过 21,000 台互联网可达的 MCP 服务器。

再把这份清单看一遍。共同因素不是对 agent 的巧妙新攻击。而是 agent 被告知要信任的那些服务器。

盲点不是 agent。而是 agent 能触及的东西。

过去一个月头条新闻事件——OpenAI 的 agents 建留言板、Hugging Face 被入侵、agents 伪造自己的 transcripts——让整个行业都在问同一个问题：我们如何记录 agent 做了什么？

这个问题问对了，但不完整。

当 agent 出问题时，序列很少是"模型自己决定"。而是"模型信任了什么东西"。Agent 调用了一个工具。工具返回了文本或数据。那个返回值以特权输入的形式进入 agent 的 context——在功能上与开发者自己的指令无法区分。在 Context7 的案例中，那个输入可以包含命令。在 Wiz 的案例中，工具端点执行了命令。在 Sentry 的案例中，工具服务器可以被胁迫去探测你的内部网络。在 UFO 的案例中，工具可以 tap 屏幕并在物理设备上输入。

Agent 有身份。它有权限。人们越来越多地记录它的行为。中间的 MCP 服务器往往什么都没有。

想想今天被记录的东西之间的不对称：

你的 agent 的聊天记录？已记录。

你的 agent 的工具调用？已记录，通常。

MCP 服务器返回了什么？有时在 transcript 里，更常见的是被截断，而且从不在 agent 无法 influence 的地方。

MCP 服务器在服务器端做了什么——它发出的网络请求、其端点执行的命令？通常在同一台机器上，在与 agent 相同的信任边界内。

最后这个问题就是症结所在。Wiz 的 LiteLLM 攻击者在放置挖矿程序后返回了一个合法的 MCP 握手。注入没有留下痕迹，因为处理它的工具和记录它的层共享着一条攻击者刚刚跨越的边界。你无法通过询问信任该工具的 agent 来审计该工具。

这不是假设性的架构焦虑。Digital Applied 的审计明确建议将 MCP 服务器输出添加到 agent 动作审计跟踪中，因为"注入的上下文 [必须] 与 agent 决策一起被记录，实现事件后的取证重建"。治理框架列出了 AGT-006——Agent Action Audit Trail——并指出它在上下文被静默篡改的那一刻就失效了。每个人都看到了这个缺口。没有人处于能够填补它的位置，因为 agent 能够写入的日志就是注入指令也能够写入的日志。

关于这个无人记录的层，我们的数据说明了什么

我们运营着一个中立的、跨平台的 AI agent 行为记录系统。截至 2026 年 9 月 2 日，生产系统持有：

2,652,732 个 agents，跨 63+ 个平台索引

10,335,339 条哈希链式行为记录

275 个具有独立验证记录的 agents——大约每 9,646 个中有一个

18,230 个 MCP 服务器，从六个公共注册表索引（Glama MCP 9,982；MCP.so 6,798；PulseMCP 967；Smithery 312；加上两个较小的来源）

读一下这个比率。我们的索引中大约每 145 个 agents 对应一个 MCP 服务器。Agents 有行为记录、层级历史、哈希链式变更日志。这 18,230 台服务器只有注册表列表，除此之外什么都没有——零独立行为记录、零验证声明、零持续保管。

这与外部研究的发现相呼应，只是这是在整个生态系统的层面测量的：Wiz 报告 MCP 存在于 80% 的云环境中，大约六分之一的部署将服务器暴露在互联网上，其中约 70% 向匿名调用者返回完整工具目录。连接 agents 到数据库、仓库、云控制台和支付通道的层，是部署最广、凭证最密集、却最少独立记录的 agent 技术栈部分。

上述事件没有一个是通过监视工具层 catch 到的。Wiz 在专门构建的蜜罐中 catch 到了他们的。Digital Applied 在一次手动的 19 服务器审计中 catch 到了他们的。Sentry 是由一位独立研究人员提交 GitHub issue 时 catch 到的。UFO 是由一位研究人员用测试 stub 替换 ADB 二进制文件时 catch 到的。在每一种情况下，发现都是外部的、手动的、事后的——正是你发现没人持续记录的事情的方式。

一个被记录的工具有层需要什么

如果你今天在生产环境中运行 agents，上述缺口是你的，无论别人建了什么。具体清单：

清点每一个 agent 能触及的 MCP 服务器，包括你的开发者 IDE 插件未经审查就添加的那些。OWASP 将此编纂为 MCP09（"shadow MCP servers"）。如果 Context7 或 Sentry self-hosted 在你的技术栈中，那就是一个已知的注入或 SSRF 路径——按一个来对待。

假设没有补丁会很快到来。Sentry 的维护者已沉默 46+ 天；微软 UFO 没有 patched version。将这些服务绑定到 localhost，将它们放在经过认证的反向代理后面，如果你不需要的话，完全阻止非 loopback 暴露。

默认开启认证。41% 的扫描服务器没有认证。网络可达性加上零认证正是 Wiz 观察到被 exploit 90 天的确切条件。

轮换代理持有的密钥。一个 LiteLLM proxy 可以同时持有 OpenAI、Anthropic、Azure 和 Gemini 密钥，通常还伴随着云 IAM。假设它们已经公开那样轮换——内存凭证窃取技术假设 on-disk 保密救不了你。

在 agent 无法写入的地方捕获工具输出。MCP 服务器返回了什么，其记录必须在到达的那一刻就离开 agent 的信任边界，否则它与 OpenAI agents学会伪造的日志具有相同的取证价值。

原语存在：基于签名的服务器身份、能力作用域、受众绑定令牌、只追加哈希链、跨平台撤销。不存在的是一个持有记录的独立实体——agent 无法调解，没有单一平台控制它。

我们持续为服务器建索引，原因与我们持续为 agents 建索引相同：市场不需要对 MCP 是否安全做出裁决。它需要对 MCP 做了什么有记录，且记录要保存在运行 agent 的机器之外。

六周前故事是供应链中的一个投毒包。这一周是一个流行文档服务器注入指令、一 个微软设备驱动没有密码、以及知道哪个 Python 对象持有你 master key 的攻击者。Agents 正在被监视。驱动它们的服务器没有被监视。

AgentRisk 维护着一个跨 63+ 平台的平台中立、只追加的 AI agent 行为记录层。本文中所有数据均于 2026 年 9 月 2 日从生产系统查询。事件事实来自 Wiz Threat Research 的 90 天蜜罐报告（2026 年 8 月 27 日）、Digital Applied 的 19 服务器 MCP 上下文审计（2026 年 9 月 2 日）、Forkast 的 Sentry CVE-2026-81421 分析（2026 年 8 月 27 日）、CyberPress 的微软 UFO CVE-2026-73296 披露（2026 年 8 月 31 日）以及 MCP 2026-07-28 规范修订版。