The .env file was a good idea for a different era.
Load environment variables at startup, keep credentials out of source code, use .gitignore to prevent accidental commits. For a traditional web application running on a server you control, that is a reasonable security model. The application does what you wrote. The credentials sit where you put them. Nobody is sneaking instructions into the execution context through a product description.
AI agents changed that completely.
What changed
A traditional application does exactly what you programmed it to do. It reads the .env file, stores the values in memory, and uses them where your code specifies. The attack surface is your code, and if your code is trustworthy, the credentials are safe.
An AI agent processes external content. Webpages, documents, emails, API responses. Some of that content is written by people who know you are building agents and know what credentials your agent is likely to hold.
The moment your agent processes a document containing a malicious instruction, your .env file becomes a liability. The credentials that were "safe in environment variables" are now in the context of a system that can be told what to do by external inputs, and some of those inputs are adversarial.
The specific ways it fails
Filesystem access. Most AI tools, including Claude Code, Cursor, and OpenClaw, have read access to your project directory by default. Your .env file lives in your project directory. Any tool that can read files can read your credentials. This is not a theoretical risk, it is the default capability of every tool your agent uses.
Environment variable inheritance. When your agent spawns a subprocess or calls a tool, the subprocess inherits the parent process environment. The .env values you loaded are now available to every child process your agent starts, whether you intended that or not.
Shared copies. .env files travel. They get sent to new team members, stored in password managers, committed by accident and deleted from git history but not from existing clones. Each copy is an exposure point you cannot track.
No access control. If STRIPE_KEY and OPENAI_KEY are both in the file, every process that reads the file gets both. There is no mechanism to say "this tool can use the OpenAI key but should not have access to the Stripe key." It is all or nothing.
The alternative does not add complexity
The natural reaction to "stop using .env files" is to assume the replacement involves more infrastructure and more configuration. For traditional applications that is often true. For AI agents specifically, there is a path that is both more secure and simpler to operate day to day.
AgentSecrets stores credentials in your OS keychain and injects them at the transport layer when your agent makes an API call. Your agent passes a key name, the proxy resolves the value and injects it into the outbound request, and your code gets the API response. The credential value never existed in any file or environment variable the agent could read.
For processes that genuinely need environment variables, the env command handles that without a .env file:
agentsecrets env -- stripe mcp
agentsecrets env -- node server.js
agentsecrets env -- npm run dev
The Stripe CLI reads STRIPE_API_KEY from the environment exactly as it always did. The value came from the OS keychain and existed only in child process memory for the duration of the process, written nowhere.
The real problem
The .env file is a symptom. The actual problem is that credentials are being managed at the application layer in a world where the application layer is no longer a trusted boundary.
AI agents process untrusted external content, and that content can instruct the agent to do things. Keeping credentials somewhere the agent can reach them is keeping credentials somewhere an attacker can direct the agent to retrieve and exfiltrate. The fix is not a more careful .env file or a stricter .gitignore. It is moving credential management to a layer the agent cannot read.
AgentSecrets is open source and MIT licensed. The full architecture is at agentsecrets.theseventeen.co. The repository is at github.com/The-17/agentsecrets.
Read a deep dive on how it's being built at engineering.theseventeen.co
Top comments (0)