What is .env file security?
A .env file is a plain-text configuration file that stores environment variables for a software project, typically containing API keys, database connection strings, OAuth secrets, and cloud provider credentials. .env file security refers to the practices and tools used to prevent these secrets from being exposed. Traditionally, .env security focused on keeping secrets out of git commits using .gitignore. With AI coding assistants, the threat model has expanded: tools like Copilot, Cursor, and Claude Code read project files directly from disk, meaning .env contents can be sent to cloud APIs even if the file is never committed. There are at least five distinct access paths AI tools use to reach your credentials, and most developers only protect against one of them.
A .env file is a plain-text file in your project folder that stores passwords, API keys, database addresses, and other secrets your app needs to run. .env file security means keeping those secrets from leaking. The old advice was simple: add .env to your .gitignore so it never gets uploaded to version control. But AI coding tools have changed the game. Tools like Copilot, Cursor, and Claude Code read files straight from your project folder, which means your secrets can be sent to cloud servers even if you never upload the file. There are at least five ways AI tools can reach your credentials, and most people only protect against one of them.
A .env file is a plain-text configuration file that stores environment variables for a software project -- typically API keys, database connection strings, OAuth secrets, and cloud provider credentials. .env file security refers to the practices and tooling used to prevent these secrets from leaking beyond their intended trust boundary. Traditionally, that meant keeping secrets out of git commits via .gitignore. With AI coding assistants, the threat model has expanded: tools like Copilot, Cursor, and Claude Code read project files directly from disk, which means .env contents can be sent to cloud APIs at inference time even if the file is never committed. There are at least five distinct access paths AI tools use to reach your credentials, and most developers only guard against one of them.
Your AI coding assistant can probably read your .env file right now. And your AWS credentials. And your MCP server configs with API keys hardcoded in plain text. Here is how to check.
Most developers know not to commit secrets to git. That is table stakes. But committed secrets are only one of five ways your AI assistant can access your credentials. The other four are paths most developers have not thought about.
Your AI coding tool can probably read your .env file right now. And your AWS credentials. And your MCP server configs with API keys sitting in plain text. Here is how to check.
Most people who build with AI know not to upload secrets to version control. That is the bare minimum. But uploaded secrets are only one of five ways your AI tool can access your credentials. The other four are paths nobody thinks about.
Your AI coding assistant can probably read your .env file right now. And your AWS credentials. And your MCP server configs with API keys hardcoded in plain text. Here is how to check.
Most developers know not to commit secrets to git. That is table stakes -- the one access path everyone covers. But committed secrets are only one of five ways your AI assistant can reach your credentials. The other four are tool-use surfaces most developers have never audited.
The five-second test
Open your AI coding assistant. Ask it: "What's in my .env file?" If it shows you your credentials, you have an exposure. That is path one.
$ cat .env
STRIPE_SECRET_KEY=sk_live_EXAMPLE_KEY_REDACTED
DATABASE_URL=postgresql://admin:s3cret@db.example.com:5432/prod
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEYNow ask it to run printenv. If your API keys appear in the output, that is path two: runtime output. The credentials are not in any file the AI reads directly, but they are in the command output that enters the AI's context.
$ printenv | grep -i key
STRIPE_SECRET_KEY=sk_live_EXAMPLE_KEY_REDACTED
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
OPENAI_API_KEY=sk-proj-abc123def456...Check your MCP server config files. Open them. Are there API keys hardcoded in the JSON? That is path four. GitGuardian's 2026 State of Secrets Report found 24,000+ developers with this exact exposure.
// ~/.cursor/mcp.json
{
"servers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres",
"postgresql://admin:s3cret@db.example.com:5432/prod"]
}
}
}| # | Leak Path | How It Works | Existing Scanners |
|---|---|---|---|
| 1 | Direct file read | AI reads .env, .aws/credentials, config files | None |
| 2 | Runtime output | printenv, debug logs, error messages with credentials | None |
| 3 | File search | AI searches project tree, finds credential files | None |
| 4 | MCP config | API keys hardcoded in MCP server JSON configs | None |
| 5 | Git history | Previously committed secrets still in reflog | GitGuardian, TruffleHog |
Why your current tools miss this
GitGuardian and TruffleHog are excellent at what they do: scanning git history for committed secrets. But they were built before AI coding assistants existed. They do not scan your AI tool's access surface because that attack surface did not exist when they were designed.
Your AI assistant can access secrets through file reads, command execution, file search, and MCP configs. None of these paths involve committing anything to git. Your git-focused secret scanner sees nothing.
Git secret scanning catches committed secrets. AI assistants can access your credentials without committing anything. Four exposure paths are invisible to existing tools.
GitGuardian and TruffleHog are great at what they do: scanning your version control history for secrets that were accidentally uploaded. But they were built before AI coding tools existed. They do not check whether your AI tool can reach your secrets, because that risk did not exist when they were designed.
Your AI tool can access secrets by reading files, running commands, searching your project folder, and pulling from MCP server configs. None of these require uploading anything to version control. Your secret scanner never sees it happen.
Version control scanners catch uploaded secrets. AI coding tools can access your credentials without uploading anything. Four exposure paths are invisible to existing scanners.
GitGuardian and TruffleHog are excellent at what they do: scanning git history for committed secrets. But they were built before AI coding assistants widened the capability envelope. They do not scan your AI tool's access surface because that surface did not exist when they were designed.
Your AI assistant can reach secrets through file reads, command execution, file search, and MCP server configs -- none of which involve committing anything to git. Every one of these paths operates outside the permission scope of a git-focused secret scanner. It sees nothing.
Git secret scanning catches committed secrets. AI assistants can access your credentials without committing anything. Four exposure paths sit entirely outside the governance layer of existing tools.
GitGuardian's 2026 State of Secrets Report found 24,000+ developers with MCP configs containing hardcoded API keys. These credentials are readable by any AI tool with file access. Existing secret scanners don't flag them because MCP configs aren't in git history.
What to do about it
First, add deny rules. If you use Claude Code, add patterns to .claude/settings.json that block access to .env files, credential stores, and sensitive config paths. Other AI tools have similar permission mechanisms.
First, add deny rules. If you use Claude Code, add patterns to .claude/settings.json that block access to .env files, credential stores, and sensitive config paths. Other AI tools have similar permission settings.
First, add deny rules to restrict the tool-use surface. If you use Claude Code, add patterns to .claude/settings.json that block access to .env files, credential stores, and sensitive config paths. Other AI tools have similar permission scope mechanisms -- the goal is least-privilege agent access at tool-call time.
// .claude/settings.json
{
"deny": [
"Read(.env*)",
"Read(.aws/**)",
"Read(**/credentials*)",
"Read(**/*.pem)",
"Read(**/*.key)",
"Bash(printenv*)",
"Bash(env | *)"
]
}- Block
.env,.env.*, and credential files from AI file access - Audit MCP server configs for hardcoded API keys
- Use environment variable injection instead of config file secrets for MCP
- Add pre-commit hooks that catch secrets before they reach git
- Test your deny rules by asking your AI to read a blocked file
Test your deny rules. After adding them, ask your AI assistant to read a blocked file. If it can, your rules aren't working. Manual configuration is fragile -- one typo means one open door.
Second, generate sanitized test configurations. You need to test your integrations without using real credentials. Create .env.example files with placeholder values and ensure your AI assistant uses those instead of real credentials.
Second, create safe test versions of your secrets. You need to test your integrations without using real credentials. Create .env.example files with placeholder values and make sure your AI tool uses those instead of the real ones.
Second, generate sanitized test configurations. You need to validate integrations without exposing real credentials inside the agent context. Create .env.example files with placeholder values and ensure your AI assistant operates against those instead of production secrets.
The real fix
Manual deny rules work but they are fragile. You add a new tool, a new MCP server, a new credential file, and the rules need updating. One typo in a glob pattern and a path stays open. Scale that across a team and it falls apart.
What an automated scanner needs
A real solution would need to scan every AI coding tool on the machine, check all four non-git leak paths, and generate the fix files automatically -- deny rules, sanitized configs, pre-commit hooks. Not just flag the problem. Fix it.
That's what devsafe diagnose does. Free. Runs locally. No data leaves your machine.
Manual deny rules work, but they break easily. You add a new tool, a new MCP server, a new credential file, and the rules need updating. One typo in a pattern and a path stays open. Try to keep that consistent across a team and it falls apart.
What an automated scanner needs
A real fix would need to scan every AI coding tool on your machine, check all four non-upload leak paths, and generate the protective files automatically -- deny rules, safe test configs, pre-upload hooks. Not just flag the problem. Fix it.
That is what devsafe diagnose does. Free. Runs on your machine. No data leaves your computer.
Manual deny rules work, but they drift. You add a new tool, a new MCP server, a new credential file, and the rules need updating. One typo in a glob pattern and a path stays open. Scale that across a team and the governance layer falls apart.
What an automated scanner needs
A real solution needs to scan every AI coding tool on the machine, audit all four non-git leak paths, and generate the fix files automatically -- deny rules, sanitized configs, pre-commit hooks. Not just flag the exposure. Close it.
That is what devsafe diagnose does. Free. Runs locally. No data leaves your machine.
$ devsafe diagnose
Scanning AI tool access surfaces...
Claude Code ~/.claude/settings.json 3 paths exposed
Cursor ~/.cursor/mcp.json 2 API keys in config
VS Code .vscode/settings.json clean
5 exposures found.
Generating fixes...
✓ .claude/settings.json deny rules written
✓ .env.example sanitized config created
✓ .gitignore patterns added
✓ .pre-commit-config.yaml secret hook added
Done. Paste the deny rules into your project.| Tool | Surfaces | Violations | Policy |
|---|---|---|---|
| Claude Code | 3 | 2 | deny rules |
| Cursor | 2 | 1 | .cursorignore |
| VS Code | 2 | 0 | clean |
Read the full research: Five Paths Your AI Coding Assistant Can Leak Your Secrets documents all five exposure paths with evidence from GitGuardian's 2026 report and real-world examples.
Frequently asked questions
How do I check if my AI assistant can read my .env file?
Open your AI coding assistant in a project that has a .env file and ask it: 'What is in my .env file?' If it returns your secrets, it has access. You can also run 'devsafe diagnose' to scan for all five access paths AI tools use to reach your credentials.
What are the five ways AI assistants access .env secrets?
AI assistants can access your secrets through five paths: direct file reads from the project directory, shell command execution (like cat .env), MCP server configs with hardcoded credentials, context inheritance from parent directories, and git history if .env was ever committed. Most developers only protect against the last one.
Why does .cursorignore not fully protect my .env file?
Tool-specific ignore files like .cursorignore and .claudeignore are documented as best-effort, not guaranteed. The AI assistant can still access ignored files through shell commands, MCP tool calls, or direct path references. These ignore files reduce accidental reads but do not provide a security boundary.