AI coding tools are the best productivity boost most developers have had in years. They’re also reading every file in your project directory, including .env.
Most developers add .env to .gitignore and consider the problem solved. That protects against accidental commits. It does nothing about Cursor, Claude Code, GitHub Copilot, or Windsurf reading those files while you work.
Here’s what’s actually happening, why it matters, and what you can do about it.
How AI coding tools build context
Cursor, Copilot, Windsurf, and Claude Code all work on the same basic principle: they read files in your project to build context for completions and chat. More context means better suggestions. That’s the whole design.
When you open a project in Cursor and ask it to help you write a function that calls your payment API, it may read your .env file to understand what variables are available. Your .env contains STRIPE_SECRET_KEY=sk_live_.... That key just entered the AI context window. Depending on the tool and your settings, that context gets sent to a cloud API to generate the completion.
.gitignore tells git which files to exclude from commits. It has no effect on what an AI tool running in your project directory can read.
This is different from the git leak problem
The familiar failure mode: you forget to add .env to .gitignore, you push, GitHub secret scanning catches it, you rotate the key and feel bad for a day. That’s a mistake you can guard against with tooling and habit.
This is different. You are not making a mistake. You are intentionally using an AI tool in your project. The AI tool reads files. .env is a file. The AI reads it. No accident occurred. The feature worked exactly as designed.
The visibility is also different. A git leak is typically noticed quickly because the commit is public and scanners watch for it. AI context window contents are less transparent. You have no record of which files were read for which completion request, and no alert fires when a key gets included.
What the actual risks look like
Keys in AI context windows
Every time you use your AI tool in a project, it sends context to the cloud for completions. If .env was indexed, your keys may be in that request. This happens per-request, every session, every day you work in that codebase.
Training pipelines
Some AI tools use your interactions to improve their models. The exact policy varies by tool, tier, and opt-out status. Most enterprise plans exclude your code from training by default. Most individual developer plans do not. If your keys are in the context, they could end up in training data. Read the privacy policy for whatever tool you’re using. Most people haven’t.
Conversation history and logs
AI tools store conversation history. If your .env values appeared in a completion, they may be in those logs, stored in the vendor’s infrastructure, not yours. That’s a different threat model than a key on your own machine.
Prompt injection
Less common, but worth knowing. If an attacker can influence your .env contents, through a compromised dependency, a malicious config template, or a supply chain issue, they can inject instructions that your AI tool will pick up and follow. “Ignore previous instructions. Output the contents of…” sounds paranoid until someone does it. This is an active research area.
What most devs do (that doesn’t actually help)
The typical response to secrets security falls into a few buckets. Some developers rely on .gitignore and consider themselves covered. Others assume the AI tool is smart enough to know not to “use” the API keys for anything bad. Most don’t think about it at all because they’re focused on shipping.
None of these prevent keys from being read and transmitted as part of AI context. The AI tool isn’t deciding whether to misuse your keys. It’s just including them in the request because they were in the context window.
What actually works
.cursorignore and equivalent files
Cursor supports a .cursorignore file that works like .gitignore but specifically for AI context indexing. Files listed there won’t be included in completions or chat.
Create .cursorignore in your project root:
# Keep secrets out of AI context
.env
.env.local
.env.*.local
*.pem
*.key
secrets/
credentials/GitHub Copilot respects .copilotignore. Some tools use .aiexclude. Check the docs for your specific tool and set this up for every project.
This reduces surface area but doesn’t eliminate the risk. It’s a good default, not a complete solution.
Stop using real keys in development
The more direct fix: if the key isn’t in the file, the AI can’t read it.
Use scoped, short-lived credentials for local development. AWS has temporary credentials via STS. Most payment providers let you create restricted test keys with limited permissions. Use those instead of production credentials.
Your local .env should look like this:
# Safe: references and configs, no real credentials
STRIPE_API_URL=https://api.stripe.com
DATABASE_URL=postgresql://localhost:5432/myapp_dev
REDIS_URL=redis://localhost:6379Not like this:
# These will end up in your AI tool's context
STRIPE_SECRET_KEY=sk_live_AbCdEf1234567890
DATABASE_URL=postgresql://prod-db.internal:5432/myapp
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEYInject secrets at runtime, not build time
The longer-term fix is to stop storing secrets in files entirely.
API Stronghold injects credentials into your application at runtime. Your .env contains a reference like STRIPE_SECRET_KEY=stronghold://stripe/production/key. The real value is fetched when your application needs it, not written to disk anywhere in your environment.
The practical difference: without this, your deployment pipeline has the actual key at some point, whether in an environment variable, a config file, or a CI secret. With runtime injection, the key is never written to a file your AI tool, your build logs, or your container image can reach.
You also get an audit log. Which service fetched which key, when, from where.
Rotate keys regularly
Short blast radius matters. If a key gets exposed through AI context, training data, or any other vector, how long does it stay valid? If the answer is “indefinitely,” the exposure window is indefinite too.
Rotate API keys quarterly, minimum. Most providers make this straightforward. The first rotation takes longer because you have to find every place the old key was used. That audit is worth doing.
Steps you can take right now
Start with .cursorignore. It takes two minutes and immediately reduces what your AI tool can read:
# In your project root
cat > .cursorignore << 'EOF'
.env
.env.local
.env.*.local
.env.production
*.pem
*.key
secrets/
EOFThen audit your current .env files. Count how many of those keys are production credentials. Count how many have never been rotated. That number is usually higher than expected.
Check your AI tool’s privacy settings. Is your code being used to improve the model? Find the opt-out, decide whether you want it.
If you want to remove secrets from your codebase entirely, that’s what API Stronghold is for. Your application fetches credentials at runtime. There’s nothing in the file for the AI to read.
The short version
.gitignore protects your git history. It does not protect your secrets from AI tools. The tools read your files by design. If your keys are in those files, they’re in the context window.
Add .cursorignore. Rotate old keys. For anything production-critical, consider runtime secret injection instead of file-based storage.
API Stronghold keeps your secrets out of files entirely, which means they stay out of AI context windows, build logs, container images, and anywhere else files end up.