您的 AI 编程助手刚刚读取了您的钱包
AI 编程工具会在您输入任何内容之前就读取 .env 文件。您的 API 密钥——每一把都相当于一张没有额度上限的信用卡——在您写下第一个提示词之前就已进入他人的上下文窗口。问题不在于 AI，问题在于：密钥是文件。
打开您的 AI 编程助手。在您输入任何一个字符之前，它已经读取了您的项目目录。您的 .env 文件。您的 API 密钥。您的数据库密码。您的 Stripe secret key。
您没有要求它这样做。您也没有批准过。这不是缺陷，而是功能——工具需要项目上下文才能发挥作用。因此，它会读取开发者能读到的一切。
而开发者什么都能读到。
绿字版
本周有一篇帖子广为流传，写成了一位开发者的内心独白：
> 打开 Claude Code。您还没打字，.env 就被读了。您的 API 密钥现在在聊天记录里。您在 CLAUDE.md 里加了一句“不要读 .env”。没用。
38 万人看到了这篇帖子。2,700 人收藏了它。不是因为它是什么新闻——而是因为它是一面镜子。
每个读到它的开发者都想到了同一件事：这就是我的开发环境。
指令不起作用
人们首先尝试的是写规则。“不要读 .env 文件。”写在 CLAUDE.md 里，写在 AGENTS.md 里，写在系统提示里。直接、明确的禁令。
工具照样读了那些文件。
只要想一想就会明白这合乎逻辑。文件的读取发生在构建项目上下文的过程中——甚至在指令被处理之前。让模型不要读取一个它已经读过的文件，就像叫人忘掉自己刚看到的东西。信息已经在上下文窗口里了。它已经被传输了。指令在损害发生之后才到达。
一位研究人员发现，即使是文件级的拒绝规则，也可以通过自定义脚本或管道链绕过。另一位则发现自己的代理费用异常飙升，因为 HTTP_PROXY 凭据被自动加载并使用了。
您 .env 里的钱
人们把这个问题当作隐私问题。它其实是个财务问题。
打开一个生产项目里典型的 .env 文件：
OPENAI_API_KEY=sk-... STRIPE_SECRET_KEY=sk_live_... AWS_ACCESS_KEY_ID=AKIA... AWS_SECRET_ACCESS_KEY=... DATABASE_URL=postgresql://user:pass@...
那把 OpenAI 密钥就是一张没有额度上限、没有 PIN 码的信用卡。拿到这个字符串的人一夜之间可以发起 40,000 美元的 API 调用。Stripe 密钥可以发起退款、创建扣款、访问客户支付数据。AWS 凭据——取决于 IAM 策略，而该策略几乎可以肯定过于宽泛——可以启动 GPU 实例、访问 S3 存储桶，或者删除基础设施。
这不是一份密码清单。这是一份钱包清单，每个钱包余额不同，而且都没有锁。
人行道上的 2,900 万个钱包
GitGuardian 最新报告统计，2025 年公开的 GitHub 提交中暴露了 2,860 万个密钥。比上一年增长 34%，也是他们历年记录到的最大年度增幅。
AI 相关的数字更糟。120 万个 AI 服务密钥暴露——同比增长 81%。由 AI 编程工具参与撰写的提交，其密钥泄露率约为基线的两倍。而在 MCP 配置文件——连接 AI 智能体与外部服务的管线——中发现了 24,000 个唯一密钥。
增长最快的泄露密钥类型前十五名中，有十二类是 AI 服务。不是数据库。不是云服务商。是 AI 服务。
我们用来更快编写代码的工具，正在泄露这些代码所连接系统的密钥。
真正的问题
发布那条绿字帖子的开发者最后给出了一条实用的修复方案——一个阻止文件读取的 settings.json 配置。这有用。目前有效，对那个工具有效。
但真正的问题不是 Claude Code，不是 Cursor，也不是 Copilot。真正的问题是：密钥是文件。
.env 文件是以明文形式存放在磁盘上的文档，任何以您的用户身份运行的进程都能读取。在 AI 编程工具出现之前，读取您项目的进程是 git、npm、node、您的编辑器。您对它们默认信任。您从未想过，您的密钥与暴露之间只隔着一条 cat 命令。
AI 编程工具只是把隐含的东西变成了显式的。它读取您项目的方式与其他所有工具完全相同——只不过它会把上下文发送到一个您看得见的地方。
您的 CI 流水线也读取 .env 文件。您的测试运行器也读。您的代码检查工具也读。您的 Docker 构建也读。它们同样没有请求许可。您只是没注意到，因为它们不会把发现的内容整理成一份聊天记录给您看。
底层的模式
2022 年泄露的密钥中，有 70% 今天仍然有效。没有轮换。没有吊销。三年之后，仍然可用，仍然授予权限。
这才是真正的数字。不是 2,900 万次泄露——而是 70% 从未修复。因为轮换一个密钥意味着找到每一个使用它的系统，更新每一个部署，测试每一个集成。密钥只被创建过一次，粘贴进一个 .env 文件，之后就再也没人想起它。泄露它的代价是瞬间发生的。修复泄露的代价却无上限。
所以大多数组织不修复。它们做不到。它们不知道哪些密钥在哪里，哪些仍然有效，哪些已经被其他开发者为了在周五下午让某个功能跑起来而复制到了其他机器上的其他 .env 文件里。
这究竟意味着什么
每一个 .env 文件都是一次押注。押不会有不该读它的进程读到它。押不会有工具把它发送到意想不到的地方。押不会有开发者不小心把它提交上去。
去年，这个赌注输了 2,900 万次。仅公开的 GitHub 上。那些私有仓库——GitGuardian 发现其中 35% 存在密钥——甚至没有计入。
修复方案不是一条 settings.json 规则。修复方案不是一条 .gitignore 条目。修复方案不是在您的指令文件里用全大写写上“DO NOT READ .ENV”。
修复方案是：密钥根本不应该出现在那里。不在文件里。不在从文件加载的环境变量里。不以任何形式存在，让一个拥有您权限的进程能用进程惯常的方式读到它——读取您项目目录里的文件。
密钥只要在磁盘上，就会被读取。唯一的问题是：何时，以及被谁。
---
来源
- GitGuardian — State of Secrets Sprawl 2025 — 2,860 万个密钥泄露、AI 服务凭据趋势、修复统计数据
- GitGuardian: 29M Leaked Secrets — Why AI Agent Credentials Are Out of Control — Help Net Security 报道，含 AI 相关细分数据
- Claude Code Can Consume, Transmit, and Compromise Your .env Files — Martin Paul Eve 关于 CLAUDE.md 禁令失效的分析
- Claude Code Automatically Loads .env Secrets, Without Telling You — Knostic 对自动加载密钥行为的技术分析
- From .env to Leakage: Mishandling of Secrets by Coding Agents — Knostic 针对 Claude 与 Cursor 的更广泛分析
- @zodchiii on X — 促使本文成文的那篇病毒式帖子（38 万次浏览，2.7 千次收藏）