AI 编程智能体会泄露更多密钥吗？GitGuardian 2026 年的数据与 10 分钟检查清单

指南John Silver16 分钟阅读

根据 GitGuardian 的 State of Secrets Sprawl 2026，Claude Code 辅助的提交有 3.2% 泄露了密钥，而 GitHub 公开提交整体的基线是 1.5%。同一篇文章还统计到，公开 GitHub 上与 MCP 相关的配置文件中有 24,008 个唯一密钥，其中 2,117 个有效。这些都是真实的测量结果，也有局限：它们描述的是公开仓库，比较的对象是所有提交，而且 GitGuardian 自己也提醒不要把这个差距理解为工具的缺陷。本指南按来源原文给出这些数字，解释为什么智能体及其配置文件改变了密钥的去向，并提供一份大约需要 10 分钟的检查清单。

GitGuardian 对密钥和 AI 编程智能体报告了什么？

GitGuardian 销售密钥检测产品，所以它既有数据，也与这个话题有利益关系。两点都值得记住。我们只引用它自己的发布内容，不添加任何内容：State of Secrets Sprawl 2026 报告页面和 GitGuardian 对发现的介绍文章。下面的数字来自这两个页面，是我们在 2026 年 10 月 18 日阅读时所见。

数字 统计的内容 出处
28,649,024（约 2865 万） 2025 年在公开 GitHub 提交中检测到的新密钥，同比增长 34% 报告页面（精确数字）和介绍文章（2865 万），开篇部分
约 19.4 亿 2025 年的 GitHub 公开提交 介绍文章，开篇部分
3.2% 对 1.5% Claude Code 辅助提交的密钥泄露率，对比 GitHub 公开提交整体的基线 介绍文章，“AI is creating a new generation of leaks”。报告页面表述为“~2× the baseline”
24,008 公开 GitHub 上与 MCP 相关的配置文件中的唯一密钥 报告页面，“MCP configuration files routinely expose secrets”；介绍文章，“Hardcoding secrets into MCP configs”
2,117 其中经确认有效的唯一凭据 介绍文章，同一部分
1,275,105 和 81% 暴露的 AI 服务密钥，以及与 AI 相关服务的密钥的同比增长 报告页面，“AI adoption creates new credential security risks”
超过 64% 2022 年有效、并在 2026 年 1 月重新测试时仍然有效的凭据 介绍文章，“64% of valid secrets from 2022 are still active and exploitable”

阅读这张表时有几点需要注意。

3.2% 是按提交计算的比率。 介绍文章称之为“secret-leak rate”，没有进一步定义。自然的理解是包含硬编码密钥的提交所占的比例，但来源没有明说。

基线是所有公开提交。 它不是谨慎的人工提交的基线，也不是使用其他 AI 工具的人的提交的基线。3.2% 与 1.5% 的差异可能来自工具本身、使用它的项目类型、代码被审查的程度，或这三者的共同作用。报告没有把它们分开。

GitGuardian 并没有把这称为工具的缺陷。 介绍文章说，这个差距不应被简单地理解为工具的缺陷：接受、修改、忽略或推送什么内容仍由人决定，用户也可以无视警告，或引导模型写出不安全的代码。

MCP 的数字针对的是公开仓库。 24,008 是在推送到公开 GitHub 的、与 MCP 相关的配置文件中发现的唯一密钥。介绍文章补充说，流行的 MCP 安装指南常常建议把 API 密钥直接写进配置文件、命令行参数或连接字符串。在这两个页面上，我们都没有找到这个数字的样本量、收集方法或时间范围。请把它当作 GitGuardian 的计数，而不是比率。

有些细节只出现在其中一个页面。 我们阅读时，报告页面没有显示 3.2% 和 1.5%，只有“约为基线两倍”的概述。介绍文章两者都有，也有 2,117 这个数字。当某个数字只出现在一个页面时，表中会注明是哪一个。

同一来源的另一个数字会改变你在泄露之后的做法。GitGuardian 重新测试了 2022 年有效的凭据，发现到 2026 年 1 月仍有超过 64% 可以使用。泄露的密钥不会因为没人注意到就自行失效。

为什么编程智能体会改变密钥的去向？

智能体是一种读取文件、运行命令，并把所见内容的一部分发送给模型服务商的程序。这就是它的工作。对密钥来说，由此带来三件事。

智能体会读取人们存放密钥的文件。 .env 文件是存放本地密钥的标准位置，而为了理解项目去浏览它的智能体常常会打开这个文件。这些值随后会与其余上下文一起传给服务商。.gitignore 这样的规则能让文件不进入提交，但它并不保证智能体可以读什么，各个智能体的处理方式也不同。

智能体会写配置。 当智能体添加 MCP 服务器、搭建测试或接入数据库时，最快能跑通的改法往往是在文件里写一个字面值。下一次提交就带上了它。人也许会在这里停一下。被要求让测试通过的智能体可能不会，而审阅很长的 diff 的人也可能没有注意到多出的那一行。

MCP 配置把凭据放进了一类新的文件。 MCP 服务器需要向某处认证，它的配置文件就是存放设置的地方。在文件里直接写密钥的安装指南让这成了最省事的路径。这类文件也很容易被提交：它们就放在项目文件夹里，常常叫 .mcp.json，紧挨着代码。

这并不意味着这些工具不严谨。现在有一个新的参与者在高速地接触存放密钥的文件，而较早的防护是围绕一个人手动敲提交来设计的。仍然有效的防护，是那些不依赖任何人记得去做的防护。

10 分钟内可以做什么？

每一步都有时间。如果只做前两步，你就已经处理了真实存在的暴露。

1. 找出智能体能接触到什么（2 分钟）

在你工作的文件夹中运行：

npx -y zn-gate reach

它会列出 .env 文件中密钥的名称（绝不显示值）、你主目录中的凭据文件、名称看起来像密钥的环境变量，以及 MCP 服务器和智能体设置中的发现。它是只读的，不发送任何内容。如果你不想为此使用工具，就在项目里搜索 .env、.mcp.json、.cursor/、.codex/ 和 .claude/，并逐个打开查看。

2. 轮换所有曾经暴露的密钥（3 分钟）

如果某个真实密钥曾经出现在已提交的文件、已推送的分支、聊天记录或你共享过的配置中，就把它当作已经暴露。在服务商处创建新密钥，更新使用它的地方，然后吊销旧密钥。即使仓库是私有的也要这样做：GitGuardian 报告称，内部仓库包含硬编码密钥的可能性大约是公开仓库的六倍，而私有仓库也可能被公开或被复制。

先轮换，再整理。如果有人已经保存了密钥的副本，删除文件或改写 git 历史都没有用。

3. 把密钥从 MCP 配置文件中移出（2 分钟）

把 MCP 配置中的每个字面值替换为对文件之外某处的引用。哪种写法可行取决于你的客户端，请查阅它的文档。许多客户端允许按名称传入变量，或在条目中展开环境变量，保险库或密钥管理器也可以在启动时提供值。目标是让仓库里的文件不包含任何单独就能使用的值。

下面是改动的大致形态，使用示例名称，没有任何真实的值：

{
  "mcpServers": {
    "example-service": {
      "command": "npx",
      "args": ["-y", "example-mcp-server"],
      "env": { "EXAMPLE_API_KEY": "<set in your environment, not here>" }
    }
  }
}

如果密钥已经在文件里，并且文件离开过你的机器，请回到第 2 步。

4. 在提交前加上密钥扫描器（2 分钟）

每次提交都运行的扫描器，能拦住其他环节漏掉的失误。两个常见的选择是 GitGuardian 的 ggshield 和开源的 gitleaks。两者都可以作为 pre-commit 钩子运行。它们的安装命令会随版本变化，请按各自项目 README 中的最新说明操作。选一个，对现有历史运行一次，然后对新的提交启用它。

这并不能取代其他步骤。提交扫描器看到的是你提交的内容，看不到智能体从你的磁盘读取并发送给模型的内容。

5. 限制智能体能读取的内容（1 分钟，外加确认提示）

先使用智能体自带的设置：大多数智能体都有权限规则和忽略文件，具体行为各不相同。然后，如果你想要一层能跨多个智能体工作的保护，zn-gate 是一个选择。它是开源的（MIT），在你的机器上运行，不需要账号。

npx -y zn-gate init
npx -y zn-gate env shadow .env
npx -y zn-gate check

init 会找到 Claude Code、Codex CLI、Cursor 和 OpenCode，展示每一个的设置，并在每次更改前询问。env shadow .env 会把真实的值移入本地加密保险库，并在文件中留下 __ZN_STRIPE_KEY__ 这样的标记。第一次使用时，运行 npx -y zn-gate unlock 创建保险库。check 会在临时文件夹里用一个假密钥测试设置，并告诉你哪个智能体没有受到保护。请在你自己的终端里运行 init：由智能体或脚本运行时，它只会打印步骤。

然后检查这个项目把你的智能体配置为信任什么：

npx -y zn-gate audit
npx -y zn-gate scan .

npx -y zn-gate audit 会审查 .claude/、.mcp.json、.codex/、.cursor/、钩子、AGENTS.md 和 CLAUDE.md、插件以及 skills。加上 --include-home 可同时检查主目录中的设置。zn-gate scan 会在配置文件中查找泄露的密钥，并附上下一步建议。同样的检查也可以作为 GitHub Action 在 CI 中运行。

这些步骤没有覆盖什么？

  • 你的机器之外的密钥。 保存在第三方控制台、CI 变量或聊天中的密钥，超出了本地工具能保护的范围。请用支出上限和较短的有效期来限制这些密钥。
  • 你的工具无法识别的密钥。 扫描器匹配的是已知的格式和名称。一个没有可识别特征的自定义令牌可能绕过其中任何一个，zn-gate 也不例外。给变量起清晰的名字会有帮助。
  • zn-gate 只部分支持的智能体和编辑器。 各个智能体的支持程度不同。兼容性表列出了每一个允许什么。在某些编辑器里，zn-gate 只能作为由智能体选择是否调用的 MCP 服务器工作，这不是自动保护。
  • 这些数字对你意味着什么。 GitGuardian 的数字描述的是公开 GitHub。你的私有仓库可能不同，可能更好，也可能更差。

zn-gate 是完成第 5 步的几种方式之一，也是我们开发的那一个。其他步骤不依赖它。轮换和扫描才是关闭现有暴露的手段。

在哪里可以读到更多？

上面引用的两个 GitGuardian 页面是原始来源。关于 zn-gate 的细节，请参阅 reach 以及scrubber 与密钥保险库的文档。关于让智能体读不到 .env 的基础知识，请阅读如何用一条命令阻止 Claude Code、Codex CLI、Cursor 和 OpenCode 读取你的 .env。想了解钩子曾如何被绕过以及如何修复，请阅读编程智能体如何间接读取你的 .env 文件。zn-gate 采用 MIT 许可证，在本地运行，不需要账号：GitHub 和 Install。

分享