Your AI Coding Agent Is Reading Your .env Right Now

Your AI Coding Agent Is Reading Your .env Right Now You opened Claude Code in your project directory this morning. Or Cursor. Or you let Copilot index the workspace. The agent did what agents do: it read the files to build context. Your .env was one of them. Nobody typed a command to make that happen. There was no prompt, no confirmation dialog, no line in a changelog. It's simply how these tools work — and it's the reason a threat model that didn't exist three years ago now applies to almost every developer machine. The old threat model was about publishing We built good habits around secret leakage. .env goes in .gitignore. Don't paste keys in Slack. Rotate anything that touches a public repo. GitHub reported over 39 million secrets leaked across the platform in 2024, and the tooling grew up in response: push protection, secret scanning, pre-commit hooks. Every one of those defences guards the same door: the moment a secret leaves your machine because you published something. And they aren't keeping up. GitGuardian's State of Secrets Sprawl 2026 counted 28.65 million new hardcoded secrets in public GitHub commits during 2025 — a 34% jump, the largest single-year increase they've recorded. Worse, 64% of the credentials they confirmed valid back in 2022 were still valid in January 2026. Four years in public code, never rotated. An AI agent doesn't use that door. It reads the file in place, on your disk, with your permissions, and moves the contents into a context window that may live on someone else's infrastructure. From there the key can surface in a log line, a chat transcript, a shared session, or a support ticket. .gitignore has no opinion on any of that. The same report puts numbers on this: 24,008 secrets were exposed in MCP configuration files on public GitHub in 2025 — a leak surface that didn't exist two years ago. And roughly 28% of all incidents now originate in collaboration and productivity tools rather than repositories, where credentials sit exposed to automations and AI agents. Computer-use agents make it worse A coding agent reads files. A computer-use agent — Claude's computer use, OpenAI's Operator, any assistant that drives a desktop — takes continuous screenshots and ships them to a provider. Now the attack surface isn't your .env. It's everything currently visible: the key in your open editor tab, the export line still sitting in your terminal scrollback, the provider dashboard you left open in a browser tab with the key revealed. You can't .gitignore a screenshot. What actually helps: stop putting the value in the file The fix isn't a better ignore rule. It's removing the plaintext secret from the place the agent looks. The pattern is not new — Doppler (doppler run), Infisical (infisical run) and 1Password (op run) all do a version of it. Your config file holds a reference, and the real value is injected into the process environment at launch: # before — the secret is the file ELEVENLABS_API_KEY=sk_a1b2c3d4e5f6g7h8i9j0 # after — the file holds a pointer, not a secret ELEVENLABS_API_KEY=apidrop://elevenlabs-1 Enter fullscreen mode Exit fullscreen mode apidrop run -- python app.py Enter fullscreen mode Exit fullscreen mode Your code still reads os.environ["ELEVENLABS_API_KEY"]. It never learns the reference existed. But an agent reading the file finds a harmless string — one you could screenshot, commit, or stream on Twitch without consequence. This applies to anything in a .env, not just API keys. Database URLs with embedded passwords, SMTP credentials, webhook URLs, JWT signing secrets, bot tokens. Testing it against an agent Claims like this deserve evidence, so here's the setup: a fresh clone, a vault holding a recognisable test key (sk-REALSECRET-abc123xyz789), and a .env containing only a reference. The agent reads project files: cat .env # → ELEVENLABS_API_KEY=apidrop://elevenlabs-1 grep -r "sk-REALSECRET" ./project ~/.apidrop # → no match in plaintext anywhere outside the encrypted vault Enter fullscreen mode Exit fullscreen mode The agent runs the code the normal way: import os print(os.environ.get("ELEVENLABS_API_KEY")) # → None Enter fullscreen mode Exit fullscreen mode Without the resolver, the reference is never resolved. The variable is simply empty. The agent tries the resolver without the master password: apidrop run -- python3 agent_script.py # → wrong master password or corrupted file Enter fullscreen mode Exit fullscreen mode The agent has the master password: APIDROP_PASSPHRASE="testpass123" apidrop run -- python3 agent_script.py # → sk-REALSECRET-abc123xyz789 Enter fullscreen mode Exit fullscreen mode That last one is not a bug, and pretending otherwise would be dishonest. A program has to receive the key at runtime or it can't call the API. If you hand something the password, you've granted access on purpose. Which is exactly the point: the pattern separates read access from secret access. An agent can review your entire repository, explain your architecture, refactor your modules — without that access implicitly including your credentials. Those used to be the same permission. They no longer have to be. Where this doesn't apply Worth being clear about the boundary, because it's easy to oversell. This is a local developer machine technique. It works because a human is present to type a master password. On a deployed server nobody is, and setting the passphrase as an environment variable there just trades one secret for another — a worse one, since a single value now unlocks everything. For deployed workloads, use your platform's secret management: Vercel environment variables, Docker secrets, AWS Secrets Manager, whatever your host provides. It's also not a sandbox. It doesn't constrain what an agent can do once authorised. It closes the accidental path, not the deliberate one. The practical takeaway You don't need a specific tool to act on this. The question worth asking today is simply: if an agent read every file in my project right now, what would it learn that I wouldn't put in a public gist? If the answer includes a working credential, the fix is the same regardless of which tool you pick — get the value out of the file and inject it at runtime. I built API Drop because I wanted that locally: no cloud, no account, no subscription, encrypted vault on my own disk (PBKDF2-HMAC-SHA256 at 390,000 iterations, Fernet/AES), injection via a child process rather than a system hook. It's MIT-licensed and runs on Windows, macOS and Linux. But the pattern matters more than the implementation. Doppler and Infisical do this well if you want team sync and don't mind a cloud account. Use whichever fits — just stop leaving the plaintext where your tools can read it. Found a hole in the reasoning? I'd genuinely like to hear it — the threat model here is new enough that it deserves scrutiny.