What is an AI context window?
An AI context window is the total set of text that a large language model processes when generating a response.
AI coding assistants build this window by reading files from your project directory, including source code, configuration files, and environment files like .env. Everything in the context window is sent to the AI provider's API for processing.
The context window has a token limit (ranging from 8,000 to 200,000 tokens depending on the model), and tools prioritize files they consider most relevant.
The security problem is that .env files containing API keys, database passwords, and cloud credentials are treated as relevant project files and routinely included in the context window alongside your source code.
You installed an AI coding assistant. You gave it file access. It read your .env.
Not theoretically. Not in a contrived demo. Right now, in your running session.
If you have a .env file in your project directory and an AI coding tool open in that project, the tool can read your database credentials, your API keys, your cloud secrets. It does this because context ingestion is recursive over your working directory, and your secrets sit alongside your source code. That is working as designed. The tool has no concept of sensitivity. To the model, DATABASE_URL is just another string.
You installed an AI coding tool. You pointed it at your project folder. Now it can read the hidden file that stores all your passwords and API keys.
Not theoretically. Not in some weird edge case. Right now.
If you have a .env file in your project folder and an AI tool like Cursor, Copilot, or Windsurf open in that project, the tool can see your database passwords, your API keys, your Stripe secret key, your cloud login tokens. All of it.
It does this because you asked it to help you build, and your passwords are sitting in the same folder as your code. That is not a bug. That is how these tools work.
You spun up an agent with file-system access. Every file in the project directory is now inside the agent's capability envelope. That includes your .env.
Not theoretically. Not in a contrived red-team scenario. Right now, in your working tree.
If your project directory contains a .env file and an agent-backed coding tool has a file-read capability grant on that directory, the agent can ingest your database credentials, your API keys, your cloud tokens. It does this because the capability envelope you authorized -- "read files in this project" -- draws no boundary between source code and secrets. The trust boundary violation is architectural. It is working as designed.
You gave it file access. It read your secrets.
Every major AI coding assistant uses the same pattern. It reads files from your project to build context for inference. Source code, configs, manifests, environment files. Everything goes into a context window that gets serialized and sent to a remote API endpoint.
The problem is structural. Your .env lives at the same directory level as your code. AI tools perform no classification between "files I need for code understanding" and "files containing production secrets." There is no allowlist, no content-type filtering, no sensitivity heuristic. To the model, your .env is another text file with useful context. It gets tokenized and transmitted like everything else.
Your AI Tool Reads Every File in Your Project -- Including Your Passwords
Every major AI coding tool works the same way. It scans files from your project folder to understand what you are building. The more files it reads, the better its suggestions get. Your app code, your config files, your package lists, your .env -- the hidden file where your passwords and API keys live.
All of it gets bundled up and sent to a server so the AI model can process it. That bundle is called the context window -- it is how much of your project your AI tool can see at once.
Here is the problem. Your .env file lives in the same folder as your code. AI tools do not look at a file and think "this one has production passwords, I should skip it." To the model, your .env is just another text file with useful information. It reads your Stripe key the same way it reads your homepage component.
The Capability Envelope Has No Credential Boundary
Every major agent-backed coding tool operates on the same pattern. It reads files from your project to build context for inference. The broader the context, the better the completions. Source files, config manifests, lockfiles, environment files -- all of it enters the context window and gets transmitted to an API endpoint for model inference.
The architectural gap is straightforward. Your .env lives in the same directory tree as your source code. The agent's file-read capability makes no distinction between "files that inform code generation" and "files that contain production credentials." To the model, your .env is another text file inside the capability envelope. There is no permission scope that separates credential surfaces from code surfaces. The agent treats the entire directory as a flat, undifferentiated context source.
This is not a bug. AI coding assistants are designed to read your project files. Your .env is a project file. The tools are doing exactly what they were built to do.
Knostic's research confirmed that Claude Code automatically loads .env, .env.local, and similar environment files without explicit user permission. Cursor's own documentation describes its ignore functionality as "best effort," not a guarantee. Even when you add .env to .cursorignore or .claudeignore, the tools can still access those files through direct path references or shell commands.
What gets sent to the cloud
When your AI coding assistant reads your project, the following file types routinely enter the context window:
.env,.env.local,.env.productioncontaining API keys, database URLs, and service tokensconfig.json,settings.jsoncontaining cloud provider credentialsdocker-compose.ymlcontaining database passwords and service credentials- MCP config files containing plain-text credentials for every connected service
credentials.jsonfrom Google Cloud, Firebase, or other providers- SSH keys and certificates if they happen to be in or near the project directory
That context gets packaged into an API request and sent to the AI provider's servers. For Cursor, that means Anthropic or OpenAI infrastructure. For GitHub Copilot, that means Microsoft and OpenAI. For Windsurf, that means their own servers plus whichever LLM provider they route to.
Every keystroke. Every session. Every day you work in that codebase.
Which AI assistants read your .env
We looked at five major AI coding tools and examined how each handles environment files, where data is sent, and what controls exist.
| Tool | Reads .env | Data sent to | Ignore file | Ignore enforced |
|---|---|---|---|---|
| GitHub Copilot | Yes | Microsoft / OpenAI | .copilotignore |
Partial |
| Cursor | Yes | Anthropic / OpenAI | .cursorignore |
"Best effort" |
| Claude Code | Yes | Anthropic | .claudeignore |
Bypassable |
| Windsurf | Yes | Codeium / various | .codeiumignore |
Partial |
| Cline | Yes | User-configured LLM | .clineignore |
Partial |
Every tool reads .env files. Every tool sends context to a cloud API. Every tool offers an ignore file. No tool guarantees that the ignore file is enforced in all modes of operation.
Cursor explicitly calls it "best effort." Claude Code has documented bugs where .claudeignore is bypassed by direct file reads. Windsurf's Agent mode with shell access can read any file on disk regardless of ignore rules.
Where the data goes
Your code and context traverse at least two network hops before reaching a model.
Hop 1: The tool vendor's infrastructure. Cursor, Copilot, and Windsurf each operate proxy servers that receive your context, apply tool-specific processing (prompt construction, caching, routing), and forward it to an LLM provider. Your data transits their infrastructure regardless of their retention policy.
Hop 2: The LLM provider. Model inference runs on OpenAI, Anthropic, or another provider's GPU cluster. Your context is present in GPU memory during inference. That includes whatever was in your .env. The data is encrypted in transit (TLS), but it exists in plaintext in memory during processing. Two hops means two trust boundaries, two sets of access controls, two attack surfaces you do not administer.
Where Your Passwords Actually Go When You Use AI Tools
When your AI tool reads your project, your code and passwords travel through at least two stops before reaching the AI model.
Stop 1: The tool company's servers. Cursor, Copilot, and Windsurf each run their own servers that receive your project files, do their own processing, and forward everything to an AI provider. Your data passes through their infrastructure even if they say they do not store it long-term.
Stop 2: The AI provider's servers. The actual AI processing happens on OpenAI, Anthropic, or another provider's hardware. Your project files sit in the machine's active memory while it generates a response. That includes whatever was in your .env -- every API key, every password, every secret token.
Two companies. Two sets of servers. Two chances for your passwords to end up somewhere you did not intend.
Trust Boundary Hops in the Execution Path
Your code and credentials traverse at least two trust boundaries before reaching the model that processes them.
- Hop 1: The tool vendor's proxy infrastructure. Cursor, Copilot, and Windsurf each operate intermediary servers that receive your context, apply routing and preprocessing, and forward it to an LLM provider. Your data crosses into their execution environment even if their retention policy says they discard it. You are trusting their infrastructure with every credential the agent ingested.
- Hop 2: The LLM provider's inference layer. Model inference runs on OpenAI, Anthropic, or another provider's GPU infrastructure. Your full context -- including whatever the agent pulled from
.env-- is present in GPU memory during inference. Each hop is a distinct trust domain with its own threat surface, its own retention policies, and its own compliance posture.
Two hops. Two organizations. Zero governance layers between the credential surface in your directory and the compute that processes it.
And then there is the training question.
In March 2026, GitHub updated its privacy statement. Starting April 24, 2026, interaction data from Copilot Free, Pro, and Pro+ users is used to train AI models unless you opt out. That includes code snippets and "associated context." If your .env contents were part of a completion prompt, they are now training data.
The opt-out is buried. Go to github.com/settings/copilot/features and disable "Allow GitHub to use my data for AI model training." If you have not done this, your interaction data. Including context. Is being used.
GitGuardian's 2026 State of Secrets Sprawl report found that AI-assisted commits leak credentials at twice the baseline rate. Commits written with AI assistance had a 3.2% secret-leak rate compared to 1.5% across all public GitHub commits. In total, 28.65 million new secrets were exposed in public GitHub repos in 2025 alone.
The MCP config problem
Model Context Protocol configs compound the exposure. MCP is the emerging standard for connecting AI tools to external services: your database, your deployment pipeline, your monitoring stack. The connection details live in a JSON file on your local filesystem. In plaintext.
GitGuardian identified 24,008 unique secrets exposed in MCP configuration files. The protocol specifies no secret management. No encryption at rest. No keychain integration. No credential rotation hooks. Just plaintext JSON containing connection strings, API tokens, and service account keys.
That file is readable by every AI tool on your machine. It is also readable by every other process running under your user account. The threat model here is not sophisticated. It is cat ~/.mcp/config.json.
The Plugin Config Problem Nobody Talks About
There is a newer problem that makes this worse. AI tools now support plugins that connect to outside services -- your database, your deployment platform, your analytics. The standard for these plugins is called MCP (Model Context Protocol), and the connection details live in a settings file on your computer. In plain text. No scrambling. No protection. Just a JSON file with your passwords typed out in the open.
Security researchers at GitGuardian found 24,008 unique passwords and API keys exposed in MCP config files. The plugin standard has no built-in way to protect secrets. No encryption (scrambling your files so only you can read them). No integration with your computer's built-in password manager. Just plain text sitting on your hard drive, visible to every AI tool that opens your project.
If you have connected your AI tool to Supabase, a database, or any external service through MCP, your connection passwords are probably stored this way right now.
MCP Configs -- The Ungoverned Tool-Use Surface
Model Context Protocol configurations compound the trust boundary problem. MCP defines how agents connect to external tool servers: your database, your deployment pipeline, your monitoring stack. The connection credentials live in a JSON config file on your local machine. In plain text. No encryption. No keychain integration. No schema-level secret management.
GitGuardian found 24,008 unique secrets exposed in MCP configuration files. That number reflects a protocol-level governance gap. MCP was designed for capability, not for credential isolation. Every tool server entry in your MCP config is a capability grant that carries its own authentication surface -- and none of those surfaces have built-in protection.
The result: your agent's tool-use surface is defined by a plain-text file that doubles as a credential store. Anyone -- or any process -- that can read that JSON file has the full map of what your agent can reach and the keys to reach it.
What is actually in your .env file
If you are a working developer, your .env file probably looks something like this.
# Database
DATABASE_URL=postgresql://admin:s3cur3_p4ss@prod-db.us-east-1.rds.amazonaws.com:5432/myapp
# Auth
JWT_SECRET=a7f2c9e1b4d6f8a3c5e7d9b1f3a5c7e9d1b3f5a7c9e1d3b5f7a9c1e3d5b7f9
# Payments
STRIPE_SECRET_KEY=sk_test_EXAMPLE_51HG3x2CjY8dP4oR7w9K1mN3qS5tU7vW9xY1zA3bC5dE7fG9hJ1kL3
# Cloud Storage
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
# Email Service
SENDGRID_API_KEY=SG.xxxxxxxxxxxxxxxxxxxx.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
# Third-party APIs
OPENAI_API_KEY=sk-proj-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxThat is seven services. Seven sets of credentials. One file. Every one of those values is a direct path to a production system, a billing account, or a user database.
In February 2026, a developer reported an $82,000 cloud bill after their Google Cloud API key was stolen. Their normal monthly spend was $180. The exposure took 48 hours to detect and cost 46,000% more than normal spend.
Check Point discovered two vulnerabilities in Claude Code (one high-severity, one moderate) (CVE-2025-59536 and CVE-2026-21852) that allow attackers to exfiltrate API keys simply by tricking a developer into opening a malicious repository. The attack works because the AI tool reads the project files. Including the payload. And executes it as part of normal operation.
The three threat vectors
1. Accidental inclusion
The simplest vector. Your .env is in the project directory. The AI tool reads it as part of building context. The contents get sent to the LLM provider's API. No attack required. No vulnerability exploited. Just normal operation.
Even if you have a .gitignore that excludes .env, the AI tool does not care about your .gitignore. It reads the filesystem, not the git index. The file exists on disk. The tool reads it.
2. Prompt injection and exfiltration
A malicious file in your project can instruct the LLM to exfiltrate secrets from its context. This is not hypothetical. A documented MCP prompt injection attack deploys a malicious MCP server with embedded prompt injection that tells the AI agent to read SSH keys, AWS credentials, npm tokens, and .env files. Then send them to an external endpoint.
The AI tool has shell access. It can make HTTP requests. It has your secrets in context. One well-crafted prompt injection in a Markdown file, a package README, or a config file is all it takes.
3. Model training data
If your AI tool's provider uses interaction data for training, your secrets may end up embedded in model weights. Not recoverable in plaintext, but potentially reconstructible through targeted prompting. GitHub confirmed in March 2026 that Copilot Free/Pro/Pro+ interaction data is used for training by default.
AI-service credential leaks surged 81% year-over-year in 2025, reaching over 1.2 million detected leaks. That number will be higher in 2026. The tools are getting more access, not less.
The question is not whether your AI tool can read your secrets. It can. The question is whether you have done anything about it.
What to do about it
Three layers, in order of effort:
- Ignore files. Add
.env,.env.*, and your MCP config paths to.cursorignore,.claudeignore, and equivalent tool-specific ignore files. This prevents context ingestion. It does not prevent other processes from reading those files, but it keeps your secrets out of the context window. This is the minimum. - Secret managers. Move credentials out of flat files entirely. Vault, 1Password CLI,
doppler run, oraws secretsmanagerinject secrets into your environment at runtime without writing them to disk. Your.envreferences a secret manager, not the credential itself. Nothing on disk means nothing to ingest. - Encrypted backup. For credentials that must exist as files (TLS certs, service account JSON keys), encrypt at rest. GPG, age, or SOPS. The AI tool ingests ciphertext, which is useless in a context window and useless if exfiltrated.
DevSafe AI Shield scans your MCP configs, environment files, and AI tool settings for exposed credentials. The scan runs locally on your machine. No context is transmitted, no files leave your filesystem. See what your tools can see before they see it.
The secret leak rate doubles with AI tools. GitGuardian measured a 3.2% leak rate in AI-assisted commits vs. 1.5% baseline. If you are using AI tools without checking what they can see, the odds are working against you.
AI coding tools are not going away. They are gaining deeper filesystem access with every release. The question is not whether to use them. The question is whether your threat model accounts for what they can read.
Three Ways to Lock This Down
You do not have to stop using AI tools. You have to make sure they cannot see the files they should not be reading. Here are three layers of protection, starting with the easiest.
Layer 1: Tell your AI tool to skip your password files.
AI tools support ignore files -- small text files you add to your project that say "do not read these." It works like a "do not enter" sign. You create a file called .cursorignore, .copilotignore, or the equivalent for your tool, and list the files it should never touch. Add your .env, any MCP config files, and anything else with passwords. This takes two minutes and blocks the most common exposure.
Layer 2: Move your passwords out of files entirely.
Instead of storing API keys in a .env file inside your project, you can use a secret manager -- a separate app that holds your passwords and feeds them to your project only when it is running. Think of it like a password manager (1Password, Bitwarden) but for your app's settings. Tools like Doppler or Infisical store your keys on their servers and inject them when your app starts up. The passwords never exist as a readable file in your project folder, so AI tools never see them.
Layer 3: Encrypt your backups so your project stays yours.
If you back up your project folder to the cloud, to an external drive, or even to a Git service, your .env and config files can travel with it. Encryption -- scrambling your files so only you can read them -- makes sure that even if someone accesses your backup, they get unreadable data.
Want to find out what your AI tools can see right now? DevSafe AI Shield scans your project for exposed passwords, API keys, and plugin config files that are sitting in plain text. It is free, it runs entirely on your computer (nothing gets uploaded anywhere), and it takes about 90 seconds. You might be surprised what it finds.
The secret leak rate doubles with AI tools. GitGuardian measured a 3.2% leak rate in AI-assisted commits vs. 1.5% baseline. If you are using AI tools without checking what they can see, the odds are working against you.
The bottom line: AI coding tools are not going away. They are getting smarter and they are getting deeper access to your project files. The question is not whether to use them. The question is whether you know what they can see -- and whether you have told them what to ignore.
Adding Governance Layers to Your Agent Stack
The fix is not a single control. It is three governance layers, each addressing a different surface in the agent's execution path.
- Layer 1: Scope the agent's capability envelope. Use
.cursorignore,.copilotignore, or the equivalent ignore file for your tool to exclude.env,.env.*, and MCP config files from the agent's file-read surface. This is the least-privilege boundary. The agent does not need credential files to generate code. Remove them from what it can reach. - Layer 2: Remove credentials from the agent's reachable surface entirely. Move secrets into a dedicated secret manager -- 1Password CLI, Doppler, AWS Secrets Manager, or OS-level keychain. Reference them by name, not by value. If credentials never exist as plain text in the project directory, the agent's capability envelope contains no credential surface to leak. The ignore file is a policy control. The secret manager is a structural one.
- Layer 3: Cryptographic state checkpoints with provenance. Encrypt your configuration backups and track what changed, when, and why. If a credential is exposed or rotated, you need an audit trail that lets you identify exactly which state was compromised and what the blast radius looks like. A governance layer without provenance is a policy without enforcement.
Map your agent's trust boundaries before they map themselves. DevSafe AI Shield runs a local capability audit across your MCP configs, environment files, and AI tool settings -- surfacing exposed credentials, ungoverned tool-use surfaces, and permission scopes that exceed what your agent stack actually needs. The audit runs on your machine. Nothing crosses a trust boundary. Nothing leaves your execution context.
The secret leak rate doubles with AI tools. GitGuardian measured a 3.2% leak rate in AI-assisted commits vs. 1.5% baseline. If you are using AI tools without checking what they can see, the odds are working against you.
Agent capabilities are expanding. Context windows are growing. Tool-use surfaces are getting broader. The agents are not going away -- they are getting more capable, more connected, and more deeply embedded in your infrastructure. Every new capability grant widens the trust boundary. The question is whether your governance layers are expanding at the same rate, or whether you are handing out broader capability envelopes with the same flat permission model you started with.
Frequently asked questions
Can AI coding assistants read my .env file?
Yes. Every major AI coding assistant (Copilot, Cursor, Claude Code, Cline, Windsurf) reads project files to build context, and .env files are treated as ordinary project files. If your .env is in the project directory and the tool has file access, it can and likely will read your secrets.
Does .gitignore protect my .env from AI tools?
No. .gitignore only prevents git from tracking files. AI coding assistants use their own file-reading mechanisms and do not respect .gitignore. You need tool-specific ignore files like .cursorignore or .claudeignore, but even those are described as best-effort by the tool vendors.
Are my .env secrets sent to the cloud when using AI coding tools?
Yes. When an AI coding assistant reads your .env file, the contents enter the context window and are sent to the provider's API endpoint for processing. This means your API keys, database passwords, and service tokens travel over the network to servers you do not control.