Build · founder · 9 min read

Your .env File Is the First Thing Your Coding Agent Reads

Putting secrets in .env was good advice for a decade. AI agents quietly broke it. What actually protects your keys now.

Published August 27, 2026 ·

security ai-agents secrets credentials

For about a decade, the advice was simple and correct: never hardcode a password or an API key, put it in a .env file, and add that file to .gitignore. Do that and your secrets stay off GitHub. It worked. It’s in every tutorial. It’s in our own security guide.

It is now incomplete, and in a specific way that nobody updated the tutorials for. .gitignore keeps a file out of Git. It does nothing to keep that file away from an AI coding agent sitting in the same folder — and the agent reads the folder to build context. That’s the whole job.

So the file you carefully kept out of your repository gets read, packed into a prompt, and sent to a model provider. Nothing has gone wrong. Nothing has been hacked. The tool did exactly what you asked it to.

Three things that happened this summer

This isn’t theoretical. In the space of about six weeks, the same failure showed up from three completely different directions.

One: a tool uploaded whole repositories, on purpose

On July 12, a researcher publishing as Cereblab posted a wire-level analysis of xAI’s Grok Build CLI. Grok Build wasn’t sending the files a task needed. It was packaging up the entire repository as a Git bundle — full history included — and uploading it to a Google Cloud Storage bucket.

Two details make this worth remembering. First, because it shipped the full Git history, secrets that had been deleted from the repo months earlier went up with it. Deleting a key from your current files never removed it from history; you always had to rotate it. Now there was a pipe carrying that history somewhere else. Second, the researcher ran the test with a deliberately trivial prompt: reply with “OK”, and explicitly do not open any files. It uploaded everything anyway. Other users reproduced it, one reporting that their entire home directory — SSH keys, password manager database — was read and shipped.

xAI switched the behaviour off within about a day. But the /privacy command the company publicly pointed users toward was not what fixed it; a global server-side flag was. (The Register)

We had this wrong on our own Grok Build page for six weeks, where we described the tool as local-first. That correction is now live at the top of that page.

Two: a CVSS 10.0 that started with a .env file

At Black Hat USA on August 5, researcher Elad Meged of Novee Security demonstrated that a GitHub issue — opened by an account with no privileges on the repository at all — could reach CI secrets in the reference workflows shipped by Anthropic, Google, and OpenAI.

The Gemini CLI finding is the one to understand, because it’s the most ordinary. Running headlessly, as CI does, Gemini CLI automatically trusted the folder it was working in and loaded configuration from it — including a .env file placed inside the repo’s .gemini/ directory — without the authorization step interactive use requires. Combined with a command allowlist that was checked when tools were registered but never actually enforced when they ran, that produced remote code execution and credential theft. It’s tracked as CVE-2026-12537 and scored 10.0 out of 10 on CVSS v4.

Anthropic’s Claude Code Action went three rounds of patch-and-bypass, ending in CVE-2026-54316, where an attacker exfiltrated an API key one character at a time by using public download counters on Hugging Face as a covert channel. OpenAI’s Codex got no CVE at all, because OpenAI classified the underlying behaviour — one agent pass writing an AGENTS.md that a later pass loads and trusts — as the sandbox working as designed.

All three fixes are shipped. The part worth your attention is that Novee found well over a hundred other public repositories running functionally identical configurations, because they’d copied the vendors’ own defaults. (Cloud Security Alliance)

Three: attackers started hunting the agent’s context

Sonar’s research team documented Mini Shai-Hulud, which they describe as the first in-the-wild supply chain attack built specifically to persist through AI coding agent sessions. It hunts for more than 80 environment variables and more than 130 file paths — ~/.aws/credentials, ~/.ssh/, ~/.npmrc, database connection strings, wallet files.

That’s the tell. The agent’s context window is now a target that attackers build tooling for. (Sonar)

Why this is worse than leaking a key to GitHub

A secret committed to Git is bad, but it’s findable. It sits in places you own. You can scan for it, scrub it, rotate the key, and know roughly where it went.

A secret that traveled through an agent is scattered across systems you don’t own and can’t search. It’s in the model provider’s logs. It’s probably in the logs of whatever gateway sits between you and the model, often in plain text. Rotating the key closes the door going forward and does nothing about the months of prompt history already sitting on someone else’s infrastructure. You cannot grep another company’s data retention.

And the clock is not on your side. The Verizon 2025 Data Breach Investigations Report puts the median time to remediate a leaked secret in a public repository at 94 days. Three months is more than enough for an automated scanner to find and use it.

The vendors are starting to admit it

Two things landed in Claude Code’s changelog this week that read, together, like a confession.

On August 26, a fix: /ultrareview and locally seeded cloud sessions had been uploading uncommitted edits to prod.env-style and *.tfvars files — plus editor swap, temp and backup copies of credential files, things like key.pem.tmp and id_rsa.swo. Those now stay on your machine. Read that list again. The backup copy your editor made of your private key was being uploaded.

On August 27, a new option: a --restricted flag (or CLAUDE_CODE_RESTRICTED=1) that, in Anthropic’s own words, “removes the built-in tools that run commands or code and WebFetch (unless named in --tools), keeps file tools inside the working directory, refuses bypassPermissions, and ignores user, project and local settings files.” (Claude Code changelog)

Worth flagging honestly: as of this writing that flag appears in the changelog but is not yet described on the permission-modes documentation page, so treat the changelog line as the authoritative description and expect the docs to catch up.

The direction is what matters. After eighteen months of every vendor racing to give agents more reach — more tools, more files, more autonomy — the newest features are about giving them less. That’s not a step backwards. That’s the category learning what least privilege means.

What to actually do

Ordered by how much protection you get per unit of effort.

Don’t keep production secrets on the machine where the agent runs. This is the whole ballgame and everything below is a consolation prize. Your local .env should hold development keys against a development database. If a dev key leaks, you rotate it and nothing happens to a customer. Most founders have production credentials in their local .env purely because it was convenient once.

Use short-lived, narrowly scoped credentials. A token that expires in an hour and can only read one bucket is a bad prize. A permanent key with account-wide access is a jackpot. Nearly every provider supports scoped keys now and almost nobody uses them, because the default key is right there in the dashboard.

Assume agent ignore-files are a preference, not a wall. Most agents support some form of ignore list. Use it. Also understand that Grok Build was explicitly instructed not to open files and did it anyway, and that Gemini CLI’s allowlist was registered but never enforced. These mechanisms are requests to well-behaved software. They are not access control.

Rotate anything that was in a repo an agent touched. Especially if you used Grok Build on a real codebase before July 13. Include things you deleted from the repo earlier — they were in the history, and the history went too.

Check what your CI can be tricked into running. If a workflow in your repo fires when an outside person opens an issue or a PR, that’s the exact trigger every one of the Black Hat findings used. This one is worth asking a technical friend about if you’re not sure.

Turn the agent’s reach down when it’s reading anything untrusted. Where a restricted or no-network mode exists, use it for work involving code, issues or dependencies you didn’t write.

The uncomfortable part

You cannot fully solve this yourself. The exposures above were not caused by founders being careless — they were default behaviours in tools built by Anthropic, Google, OpenAI and xAI, in configurations those companies shipped and recommended. The Cloud Security Alliance’s read is that the vulnerable code sat in the harness, the plumbing between the model and your machine, not in the model’s judgment. No amount of prompting carefully fixes plumbing.

What you can do is make the blast radius small. Keep production credentials off the laptop. Scope your keys. Rotate on a schedule instead of after an incident. Then pick vendors partly on how they behave when they get this wrong, because they will — and the difference between a company that ships a fix and documents it plainly and one that points you at a privacy toggle that wasn’t the fix is the most useful signal you’re going to get.

For the related failure where agents are manipulated by what they read, see prompt injection is the new SQL injection. For what happens when agents get spending power on top of file access, see agents that spend money.