公共 MCP 配置中泄露 2.4 万个秘密:没人先构建的治理层

ancilartech 发布于 2026-07-28 00:07 阅读 15

文章指出在一年内,安全研究人员在公共GitHub上的MCP配置文件中发现了24,008个唯一秘密,其中2,117个是有效的活动凭证。泄露的凭证包括云API密钥、数据库连接字符串等,直接威胁生产系统。作者认为问题根源在于官方文档鼓励在配置文件中硬编码凭证,而MCP标准缺乏身份治理层。文章提出了修复方案:从配置文件中移除秘密,使用秘密管理器、预提交Hook和CI扫描、短生命周期Token,并要求生产操作需人工审批。最后强调,团队应先构建身份与治理层,再追求连接性,避免重蹈覆辙。

这个数字足以让任何正在发布 AI Agent 的团队停下脚步。在短短一年内,安全研究人员在公开的 Model Context Protocol 配置文件中发现了 24,008 个独特密钥,其中 2,117 个被确认为有效且活跃的凭证,任何人都可以用它们来对真实系统进行身份验证。

这些可不是什么不起眼的测试密钥。泄露的凭证直接对接 Agent 所依赖的系统:云 API 密钥、数据库连接字符串、搜索和数据服务。通往王国的钥匙,以明文形式,出现在公开仓库中。

令人震惊的不是事情发生了,而是为什么会发生。这不是一次复杂的入侵或零日漏洞。这是成千上万的开发者按照文档操作,复制快速入门指南,并将密钥粘贴到示例让他们粘贴的地方。MCP 为生态系统提供了一种连接 Agent 与工具的绝妙方式,但它并没有首先提供一种安全地做到这一点的方法。这就是那个从未被构建的治理层的故事,以及现在如何构建它。

这项研究到底发现了什么?

一项 2026 年的密钥扩散研究发现,在公开 GitHub 上的 MCP 配置文件中暴露了 24,008 个独特密钥,其中 2,117 个被确认为有效且活跃的凭证。泄露的类型正是 Agent 用来连接世界的那些:云 API 密钥约占五分之一,数据库连接字符串约占七分之一,其余的是搜索和检索服务。这是更广泛激增的一部分,AI 服务凭证泄露数量同比增长超过 80%。

头条数字已经够糟糕了,其构成则更糟。

泄露的密钥并非低价值 Token。它们是让 Agent 读取数据库、调用云服务或访问付费 API 的凭证,这意味着每一个活跃的密钥都是通往真实系统的直接路径。云密钥和数据库连接字符串占据了列表的主导地位。

而 MCP 并非孤立事件。它处于一个更大的模式之中:单一年份内有数千万个新密钥被上传到公开仓库,与 AI 服务相关的凭证增长速度超过任何其他类别。MCP 泄露是一个本已到处泄露的体系中最新出现的泄露面。

为什么凭证最终会出现在 MCP 配置文件中?

因为文档告诉人们把它们放在那里。流行的 MCP 设置指南通常会将凭证直接硬编码到配置文件中,作为命令行参数传递,或嵌入到连接字符串中。新的标准通过其示例传播,所以当官方快速入门指南演示通过本地文件中的硬编码密钥进行身份验证时,这便成为了每个人复制的默认模式。MCP 并非特别粗心,这是便捷优先的示例如何演变为整个生态系统模式的典型情况。

这就是将统计数据变为教训的部分。

开发者不会阅读标准后从头设计一个凭证架构。他们会找到一个能用的示例,复制它,修改它,然后发布。所以,示例怎么做,生态系统就大规模地怎么做。如果示例硬编码了密钥,生态系统就会硬编码密钥。

这正是发生的事情。让 MCP 服务器工作的最快路径就是将你的密钥放入 JSON 配置或 CLI 标志中,这条路径被复制了数万次。标准以采纳的速度传播,安全的模式并没有随之一起发布,因此它永远无法赶上。

为什么这比普通的密钥泄露更糟糕?

因为 MCP 凭证是对实时系统的高权限连接,持有它们的 Agent 拥有深度访问权限。一个泄露的 MCP 密钥可以直接解锁生产数据库或云账户。爆炸半径会叠加:Agent 可以访问编辑器、终端和凭证存储,因此一次提示注入或一个被投毒的依赖项可以将本地密钥转变为组织级的数据泄露。而且补救措施也失败了,大多数泄露的凭证数年都没有被撤销。

一个泄露的密钥的危险程度取决于它能解锁什么,而 MCP 密钥能解锁很多东西。

这些是 Agent 用来接触真实基础设施的凭证。一个活动的数据库连接字符串可不是小范围的泄露。它是对生产数据的读或写访问权限。这种泄露最终会出现在事件报告中。

爆炸半径也比文件本身更大。Agent 具有深度本地访问权限,可以访问开发者的机器和工具,因此凭证边界现在包括每台运行 Agent 的工作站。在一个有记录的案例中,共享 MCP 注册中心中的一个单一的、权限过高的 Token 就足以在数千台托管服务器上实现代码执行。

然后还有这一切之下的无声失败:补救措施。同一项研究发现,几年前被确认为有效的绝大多数凭证至今仍然活跃,从未轮换,从未撤销。检测不是问题所在,问题在于没有人负责清理。

那个从未被优先构建的治理层是什么?

MCP 标准化了连接性,而非身份。它定义了 Agent 如何连接到工具,但没有定义这些连接如何被授权、限定范围、归属、过期或审计。缺失的那一块是非人类身份治理:知道哪些 Agent 身份存在,每个能访问什么,谁拥有它,以及何时过期。创建速度超过了治理成熟度,因此生态系统在没有被管理的凭证之上发布了强大的连接性。解决方案是将这个身份和治理层构建为 Agent 基础设施的一等公民。

这就是这个数字背后的真实故事。

MCP 很好地回答了“Agent 如何连接到工具”这个问题,而“我们如何管理使这成为可能的凭证”则被留作读者的练习。因此凭证变成了事后才考虑的东西,被硬编码并遗忘,因为没有负责它的层。

登录时记住我,以便更快登录

这里的治理并非抽象概念。它是一系列具体问题,每个团队都应该能够回答关于每个 Agent 身份的问题:谁创建的,它具体能访问什么,谁拥有它,以及何时过期。今天大多数组织都无法回答关于他们 Agent 的任何这些问题。这种无力感就是那个从未被构建的治理层。

教训不是说 MCP 不好,而是连接性标准需要附带一个身份方案一起发布,而这一次没有,所以创建跑到了控制前面。

你实际上如何修复它?

彻底将密钥从配置文件中移除。使用由真正的密钥管理器支持的环境变量,让客户端拥有凭证并在查询时提供它们,而不是将其硬编码到服务器配置中,并发布限定范围、短期的 Token,而不是长期的全访问密钥。将 MCP 配置目录排除在版本控制之外,在预提交和 CI 中扫描密钥,要求人为批准生产操作,并指定命名负责人定期轮换。目标是让凭证被管理,而不是被粘贴。

修复方法并不奇特。它们是应该随快速入门指南一起发布的凭证卫生规范。

从配置本身开始。导致泄露的模式是在被追踪的文件中有一个字面意义的密钥。修复方法是对托管密钥的引用,而不是密钥本身。

// 导致泄露的模式:追踪的配置文件中包含活跃凭证
{
  "mcpServers": {
    "database": { "command": "db-mcp", "env": { "DATABASE_URL": "postgres://admin:REAL_PASSWORD@prod-db:5432/app" } }
  }
}
// 修复方法:引用托管密钥,运行时解析,绝不提交
{
  "mcpServers": {
    "database": { "command": "db-mcp", "env": { "DATABASE_URL": "${secret:prod/db_url}" } }
  }
}

然后让意外提交变得不可能。一个预提交Hook和一个 CI 关卡能阻止密钥,这是底线,而不是锦上添花。

## 在任何密钥到达分支之前阻止它
- run: echo "config/mcp/" >> .gitignore        # 将 MCP 配置排除在版本控制之外
- run: gitleaks protect --staged --no-banner    # 预提交,本地
- run: gitleaks detect --no-banner               # CI,每次推送和 PR 时

最后,更改凭证本身。优先使用限定范围、短期且会自动过期的 Token,而不是具有广泛访问权限的长期密钥;让客户端在查询时提供凭证,而不是由服务器存储;并要求任何涉及生产或部署的 Agent 操作都必须经过人为批准。

团队本周应该从哪里开始?

审计、遏制、然后治理。首先,扫描每个仓库、配置目录和 CI 日志以查找硬编码的密钥,并将 MCP 配置文件视为优先处理面。撤销并轮换所有活跃的凭证,每个凭证指定一个命名负责人。然后防止复发:密钥在管理器而不是文件中,在预提交和 CI 中扫描,使用限定范围的短期 Token,以及人为批准生产操作。最后,建立清单:知道哪些 Agent 身份存在,它们能访问什么,以及何时过期。

现在可以开始行动的简短清单:

  • 你是否扫描了你的仓库、配置目录和 CI 日志以查找硬编码密钥,并将 MCP 配置视为高优先级?
  • 你是否撤销并轮换了每个找到的活跃凭证,并为每个凭证分配了命名负责人?
  • 密钥是否在运行时从密钥管理器获取,从不存储在 MCP 配置文件中或提交到版本控制?
  • 预提交Hook和 CI 是否在任何密钥到达分支之前阻止它?
  • 你的 Agent 凭证是否被限定范围且短期有效,遵循最小权限原则,而不是长期的全访问密钥?
  • 任何涉及生产的 Agent 操作是否都需要人为批准?
  • 对于每个 Agent 身份,你是否知道谁拥有它,它能访问什么,以及何时过期?

如果你能按这个清单逐一完成,你就已经构建了标准遗漏的治理层。如果你无法回答最后一个问题,那么你的 AI 采纳速度已经超过了身份成熟度,而这正是那 24,000 个密钥泄露的根源。

在构建令人印象深刻的部分之前,先构建枯燥的部分

很容易将 24,000 个泄露密钥读作一个关于粗心开发者的故事。其实不是。这是一个关于强大能力在没有使其安全的不起眼部分的情况下就被发布的故事。连接性令人印象深刻并首先到来,治理很枯燥且从未到来,因此生态系统用硬编码的密钥填补了空白。

这个顺序就是错误,而且它是可重复的。每一个新的 Agent 标准,每一个新的集成模式,都会通过其示例以生态系统的速度传播。如果那些示例假设了托管身份、限定范围的访问以及文件中没有密钥,那么安全性就会随之传播。如果它们假设了便利性,那么扩散就会随之传播。

那些正确实现 AI Agent 的团队,不会是连接工具最多最快的团队。他们将是那些首先构建身份和治理层的团队,将每个凭证视为需要管理而非粘贴的东西,并且总能回答每个 Agent 被允许接触什么的简单问题。先构建那个层,令人印象深刻的部分才能安全发布。

为 AI Agent 和 MCP 构建身份和治理层,使凭证被限定范围、归属明确且可审计,而不是被硬编码和遗忘,是决定 Agent 基础设施是资产还是风险敞口的安全工作。这就是我们所做的工作。

  • 原文链接: medium.com/@ancilartech/...
  • 登链社区 AI 助手,为大家转译优秀英文文章,如有翻译不通的地方,还请包涵~

相关文章

0 条评论