你的 AI 编程代理正在读取你的 .env 文件

你的 AI Coding Agent 正在读取你的 .env 文件

发布于 2026 年 4 月 9 日，星期四

如果你是 2026 年的软件开发者，几乎肯定正在使用像 Cursor、Claude Code 或 Codex 这样的 AI coding agent 来更快地编写和交付代码。虽然这些工具大幅提升了工程团队的生产力，但它们也带来了一个大多数开发者还没有意识到的问题：你的 agent 正在读取你的 .env 文件，包括其中的明文密钥，并将这些上下文作为每次请求的一部分发送到外部服务器。

这篇文章讨论了 .env 文件的不足，以及在 2026 年更好的方案可能是什么样子。希望这能成为一篇有价值的文章，并帮助那些随着 AI 工具逐渐成为编码方式重要组成部分，而开始重新思考 secrets 管理的人。

我们是如何开始的

在过去十五年里，.env 文件一直是本地开发中管理环境变量的首选方案。生成你的 API keys 和数据库凭证，把它们放进一个明文文件里，加入 .gitignore，然后继续开发。正是这种简单性推动了它的普及。无需设置基础设施，无需运行任何服务，而且几乎没有学习成本。

但简单也伴随着代价。归根到底，你的凭证仍然存放在一个未加密的明文文件中，而它们与意外泄露之间唯一的屏障就是 .gitignore。随着 AI agents 如今成为团队编写代码的核心组成部分，.gitignore 已经不再足够。

Agent 问题

AI coding agents 会读取你工作目录中的文件。它们被设计用来遍历你的代码库，利用真实上下文并避免幻觉，但当它们遇到项目中的 .env 文件时，也会像读取其他文件一样读取它。

问题在于，agents 并不遵守 .gitignore 规则。有些工具提供了自己的方式来排除 agents 读取某些文件（例如 Cursor 使用 .cursorignore），但这些方式在不同 agents 之间并不一致，默认也不是开启的，而且没有解决根本问题。agent 会读取你的 .env，把其中的内容纳入上下文，并将其作为推理请求的一部分发送到外部服务器。

想象一下实际情况：你在一个支持 agent 的编辑器中打开项目，并让 agent 帮你开发一个功能。作为其中的一部分，agent 遍历你的项目，并意外读取了你的 .env 文件，认为为了完成这个功能，它需要访问其中的敏感数据。转眼之间，这些上下文，包括你的明文密钥，就已经成为发送到你无法控制的推理服务器的请求的一部分。

这就是当 AI agents 成为开发工作流的一部分后，.env 文件带来的意外后果。你提出了一个合理的问题，agent 也只是做了它本来要做的事，但你的密钥也被一起带了出去。

解决方案：运行时 Secret 注入

考虑到 .env 文件已经存在了这么久，大多数开发者从未想过去质疑这种做法。但有一种不同的方法值得考虑：与其从明文文件中加载 secrets，不如从像 Infisical 这样的 secret store 中获取它们，并在运行时直接注入到你的本地开发进程中。

那么，这具体是如何工作的呢？

如果你愿意把你的 secrets 存放在外部（这正是 secrets management 的核心），你可以自行构建或使用现有的 CLI 工具，像上面那样获取并注入它们。采用这种方式后，你的应用程序仍然以类似的方式读取它们——通过 process.env、os.environ，或你运行时环境中的等价方式——但不再有任何 secrets 以明文形式存在。相反，它们驻留在内存中，按需获取，仅作用于单个进程，并在该进程退出时消失。

关键点在于：agent 可以读取你项目中的每一个文件，但它无法直接访问正在运行进程的环境变量。通过将 secrets 从文件中移出并放入运行时环境，你就彻底切断了 agent 的访问路径。

这在实践中是什么样子

如果你具备相应的工程能力，可以自己构建运行时注入所需的基础设施，包括一个 secrets store。你需要为静态存储的 secrets 提供加密存储、认证层、授权控制、审计日志，以及在后端不可达时的故障处理。这个模式已经很成熟，但构建和维护它确实需要投入不少工作。

如果你不想这样做，Infisical 将这一模式实现为一个你可以自托管或使用托管服务的平台。在 CLI 层面，infisical run -- <start command> 会完成认证、获取 secrets，并将你的命令作为子进程启动，同时把 secrets 作为环境变量注入。通过在应用启动命令前加上 Infisical CLI，你可以让它在启动时获取 secrets 并将它们加载到你的应用程序中。下面是在不同运行时中的示例：

infisical run --env=dev --path=/apps/frontend -- npm run dev

infisical run --env=prod --path=/apps/backend -- flask run

infisical run --env=dev --path=/apps/ -- ./mvnw spring-boot:run --quiet

你会注意到，这并不是 Node.js 特有的方案。这个 CLI 在操作系统层面注入环境变量，因此 Python、Go、Rust、Java，以及任何其他读取环境变量的运行时都可以无需修改直接工作。

顺便说一句，从 .env 迁移到运行时注入，只需要对你的开发工作流做一行改动。

删除 .env 文件

.env 文件在十多年里很好地完成了它的使命。它简单、广为人知，并且在唯一的风险只是一次意外的 git commit 时也足够好。但开发工作流已经改变，威胁模型也随之改变。你的编辑器现在会读取项目中的每一个文件，从中构建上下文，并将这些上下文通过网络发送出去。如果你的 secrets 存放在工作区里的一个明文文件中，它们就是这些上下文的一部分。

运行时注入才是 secrets 从一开始就应该采用的方式。无论你是自己构建基础设施，还是使用像 Infisical 这样的工具，原则都是一样的：secrets 应该存在于内存中，限定在一个进程范围内，并且只在一次运行期间有效，而不是放在你 agent 上下文窗口里的一个明文文件中。

删除 .env 文件吧。你不会想念它的。

Jake Hulberg

Developer Advocate，Infisical

Tony Dang

Product，Infisical

• 原文链接： infisical.com/blog/your-...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～