Your AI agent has already read your .env

For most of software history, the answer to "where do I put my API key" was "wherever it works." Keys went straight into source code, into config files, into wiki pages and into Slack messages. In 2011 the Twelve-Factor App methodology, written by Heroku engineers, pushed the industry toward a better default: store config in the environment, keep it out of the codebase. The .env file became the standard implementation of that idea. Libraries like dotenv made it trivial: put STRIPE_SECRET_KEY=sk_live_... in a file, add the file to .gitignore, load it at startup.

Teams with more infrastructure kept going: HashiCorp released Vault in 2015 and AWS Secrets Manager followed in 2018, giving companies a central encrypted store with access control and audit logs, while CI systems added masked environment variables. By the early 2020s the mature setup looked like this: secrets live in a vault or in your CI provider's settings, local development uses a .env file that never gets committed and production pulls from the cloud provider's own store.

In practice, most teams I have talked to at the seed and Series A stage still run on .env files passed around in Slack DMs, a shared 1Password vault someone set up in 2022 and a handful of keys pasted directly into Vercel or GitHub Actions. The tooling has existed for a decade, adoption lagged the whole time, because nothing forced change.

The .env approach kept producing incidents, even before AI, because it depends on every developer doing the right thing every time.

The example everyone in security still points to is Uber. In October 2016, attackers logged into a private GitHub repository belonging to Uber engineers using credentials reused from other breaches. Inside the repo they found hardcoded AWS keys, used them to open an S3 bucket and downloaded personal data on 57 million riders and drivers. Uber paid the attackers $100,000 to keep quiet, disclosed the breach more than a year later and fired its chief security officer in the fallout.

The speed of exploitation is the part people consistently underestimate. Comparitech ran a honeypot where they planted AWS credentials in public GitHub repositories, attackers found and used them within about a minute.

None of this slowed the leaking down. GitGuardian, which scans public GitHub for exposed credentials, has published rising numbers every year since 2020. The other half of the problem is what happens after the leak: 64% of secrets that were confirmed valid in 2022 were still valid in 2026. Rotation is painful enough that most teams simply do not do it.

GitHub Copilot launched in 2022 as autocomplete. ChatGPT launched a little after and developers started pasting code into a chat window, which produced its own incidents. Samsung banned generative AI tools in May 2023 after engineers pasted proprietary source code into ChatGPT.

The shift to agents is what changed the security picture. In November 2025, Anthropic released Claude Opus 4.5. In April 2026, OpenAI shipped GPT-5.5, tuned for exactly this kind of long-horizon agentic work: moving across tools, running commands and finishing multi-step tasks without a human approving each step. These releases mattered because they moved agents from "impressive demo" to "default workflow." Measurement studies now put AI-authored code at ~25% of merged production code. Surveys from early 2026 find developers spending more hours per week reviewing AI-generated code than writing their own.

For an agent to do its job it reads your filesystem, runs shell commands, calls APIs, installs packages and opens pull requests. It operates with your permissions, on your machine. Every one of those capabilities is exactly what an attacker wants.

A coding agent with file access will read your .env file. Sometimes because a task requires it, sometimes because it is debugging a connection error and the obvious move is to check the config. Once a secret is in the model's context, it is no longer only on your disk. It flows into request logs, conversation transcripts, telemetry and whatever session-sharing feature your team uses.

In 2025, researchers showed that Claude Code could be tricked via prompt injection into exfiltrating API keys through DNS lookups using pre-approved commands (CVE-2025-55284). In January 2026, a researcher at GMO Flatt Security chained an authorization bypass in Anthropic's claude-code-action with indirect prompt injection: the attack started with opening a public GitHub issue and ended with environment variables exfiltrated and malicious code pushed. In May 2026, Pillar Security disclosed a maximum-severity CVSS 10 flaw in Gemini CLI, where a malicious npm package carried injection payloads hidden in code comments; when the agent analyzed the codebase, it executed shell commands and shipped environment variables to the attacker.

The pattern across all of these is identical: the agent has legitimate access to your secrets and executes instructions it finds in untrusted content, whether that is an issue, a README, a code comment or a dependency. Classic malware had to bring its own tooling; prompt injection borrows yours.

GitGuardian's State of Secrets Sprawl 2026 report counted 28.65 million new hardcoded secrets pushed to public GitHub in 2025, a 34% year-over-year jump and the largest single-year increase they have ever recorded. Repositories showing signs of AI-assisted coding leaked at roughly double the GitHub-wide baseline rate.

MCP servers, the standard way to give agents access to external tools, are configured with JSON files that commonly contain API keys. GitGuardian found 24,008 unique secrets sitting in MCP-related config files on public GitHub, 2,117 of them verified as still valid.

Vibe coding platforms put app deployment in the hands of people who have never heard of .gitignore, which is mostly great and occasionally a disaster. In 2025, researchers testing 1,645 apps published on Lovable's marketplace found 170 of them leaking user data, with several exposing hardcoded Supabase credentials in client-side code (CVE-2025-48757). The people building these apps are not careless.

Secrets are leaking faster, through more channels and attackers now use AI to exploit them. Meanwhile the age of a leaked secret has not improved at all, most keys stay valid for years because rotation is manual and scary

The good news is that the fixes are mostly boring and none of them require believing any vendor's marketing, ours included.

Get secrets out of plaintext files. Secrets should live in one encrypted place and a CLI injects them into the process environment only when you run something, so nothing sits on disk. This is what we build at Enkryptify (ek run -- npm run dev), One source of truth, nothing in a file, nothing for a wandering agent or a postinstall script to read.

Explicitly wall your agents off from secret files. Every serious agent has a permission system; almost nobody configures it. In Claude Code that is a deny rule in settings.json:

{
    "permissions": {
        "deny": ["Read(./.env)", "Read(./.env.*)", "Read(./secrets/**)"]
    }
}

Cursor respects a .cursorignore file for the same purpose. This costs 5 minutes and it is the single cheapest mitigation on this list.

Turn on scanning before code leaves the laptop. GitHub's push protection blocks commits containing recognizable secrets and gitleaks runs as a pre-commit hook in seconds. With AI writing a quarter of merged code, you need a check that does not depend on a human reading every generated line.

Treat agent configs as a secrets surface. MCP config files, agent settings and tool manifests should reference environment variables, never contain literal keys. Add them to your scanners' paths.

Assume the leak and shrink its value. Prefer short-lived credentials where the platform supports them (OIDC in CI instead of long-lived cloud keys) and rehearse rotation for the ones that cannot expire, so that revoking a key is a 10-minute chore instead of a war room.

Secrets hygiene was a failing discipline for 15 years. The industry got away with it because the attacker had to find the key first. What changed with the agent era is that a reader with full filesystem access now sits inside every development environment, following instructions that increasingly come from places you do not control. The same property that makes agents useful makes them the perfect secret-finding machine, for you and for whoever manages to prompt them.

The response does not need to be panic and it definitely does not need to be banning the tools. It needs to be accepting that the .env era is over and moving to a setup where a secret on disk is the exception, where agents are walled off from the credentials they do not need and where any single leaked key is cheap to kill. Every piece of that is available today. The teams that do it now will read about the next s1ngularity with mild interest instead of from inside an incident channel.