When you start working with AI tools and APIs, instructions will tell you to "add your key to the environment file." If you have not used one before, that can feel like a gap. This article explains what an environment file is, how it works, and what can go wrong when one ends up in the wrong place.
What is an environment file?
A .env file is a text file with one setting per line:
OPENAI_API_KEY=sk-abc123
DATABASE_URL=sample_database_url.io
When your application starts, it reads this file and loads those values into memory. Your code can then access OPENAI_API_KEY without the actual key ever being written into the code itself.
That distinction matters. The code is what you share, push to GitHub, or show a collaborator. The .env file stays private, on your machine only.
Why can't I just put the key in the code?
When credentials are written directly into code, they travel everywhere that code goes. Upload your project to GitHub (even a private repository) and the key goes with it. Share a file with a collaborator and the key goes with it. Post a snippet on a forum and the key goes with it.
GitGuardian scanned 1.94 billion public GitHub commits and found that 28.65 million new secrets were pushed to public repositories in 2025 alone — a 34% increase from the prior year. Most of them were not intentional. The developer just wrote a key into the code and forgot.
The harder part: keys that end up in a repository often stay valid for years. Attackers don't need to find the key the day it was pushed. They can find it months later.
What happens if your key leaks?
The consequences are fast and concrete. Attackers typically use exposed credentials within minutes of finding them.
What they do with an API key depends on what it unlocks. A leaked OpenAI key can be used to rack up API charges in your name. A leaked AWS key can spin up servers in your account, mine cryptocurrency, and generate bills in the thousands before you notice. A leaked database URL can expose or destroy your data.
In one documented campaign, researchers found attackers scanning more than 230 million unique targets and compromising over 110,000 domains using credentials found in exposed environment files. Among the credentials they collected: 1,185 AWS access keys, 333 PayPal OAuth tokens, 235 GitHub tokens, and 111 HubSpot API keys.
If you ever suspect a key has been exposed, revoke it before you investigate. Attackers move faster than forensics. Containment time drops significantly when you revoke first.
The AI agent risk
This is the part of the .env file picture that gets skipped in most setup guides.
When you use an AI coding tool (Claude Code, Cursor, Copilot, and similar), the tool runs with access to your project directory. That includes your .env file. Credentials stored there are silently loaded into the agent's working context.
A poorly scoped or compromised AI tool does not need to be designed to steal your keys. It just needs to have access to the directory where they live. Researchers have demonstrated that malicious extensions and agent integrations can read and exfiltrate secrets, SSH keys, and tokens without any obvious sign of tampering.
This does not mean AI coding tools are dangerous by default. It means the hygiene rules that applied before AI matter more now: keep secrets out of your project directory, rotate keys regularly, and use the narrowest permissions possible.
How to use a .env file correctly
Add it to .gitignore before you create it. Git is the tool most developers use to track and upload code changes. .gitignore is a file that tells Git what to ignore. If .env is in that list before the file is created, Git will never see it. If you add it after, check your history — the file may have already been captured.
Create a .env.example file. This is a version of your environment file with the real values replaced by placeholders:
OPENAI_API_KEY=your-key-here
DATABASE_URL=your-database-url-here
This file gets committed and shared. It tells anyone working on the project what values they need to provide, without exposing anything real.
Use separate files for different environments. A key you use for testing should not be the same key your live application uses. Keep a .env.development and a separate configuration for production. Most hosting platforms (Heroku, Render, Fly.io, AWS, and others) have built-in settings for environment variables — use those for production instead of uploading a file.
Do not log your environment variables. Debug output that prints all configuration values will include your credentials. Log the name of a variable if you need to confirm it loaded. Never log the value.
Restrict file permissions. On a shared machine, limit who can read your .env file. On most systems this is a one-line command. Anyone else with access to the machine should not be able to read your credentials by default.
What are common mistakes to watch for?
- Creating the
.envfile before adding it to.gitignore - Putting real credentials in
.env.exampleinstead of placeholders - Sharing
.envfiles over Slack, email, or other channels not designed for secrets - Using the same credentials for development and production
- Keeping old keys active after they are no longer needed
- Giving AI coding tools broader directory access than necessary
