How to scope credentials for an AI coding agent (so it can't read your .env)

The dev convention is older than the threat. Secrets in a .env file, read by your app at startup. It worked because the code reading the file was code you wrote.

An AI coding agent is not that code. It has a shell, runs commands, and reads files with cat — and what it runs next is decided by an LLM that responds to whatever text it has just read. Some of that text was written by someone else: a README, an MCP server's reply, a docstring three turns ago. The credentials the agent's shell can read are credentials the LLM can be talked into leaking.

This post covers the registered CVEs that demonstrate the threat and the two patterns that actually contain it.

Why .env files are uniquely bad for AI coding agents

An AI coding agent has shell access. It reads files from the filesystem and runs commands. The familiar dev workflow — keep API keys in a .env file, have your app read them at startup — assumes everything reading that file is code you wrote. The agent isn't. The LLM decides what to read and what to run based on whatever text is in its context, including text someone else wrote. A credential the agent's shell can cat is a credential prompt injection can curl to an attacker's host.

Five registered cases

The failure mode is not theoretical. The pattern across these is the same: prompt injection or a malicious repo file gets the agent to read a credential the agent shouldn't be able to reach, and then to send it somewhere the agent shouldn't be able to send it.

Claude Code DNS exfil (CVE-2025-55284, CVSS 7.1, Embrace the Red, June 2025). A prompt injection planted in a source file told Claude Code to read .env and encode the contents as DNS subdomains via auto-approved commands like ping, nslookup, and dig. The agent never asked the developer because those commands were on the "read-only" allowlist. Anthropic fixed it in v1.0.4 by removing the utilities from the default allowlist (Embrace the Red writeup, NVD entry).

Amazon Q Developer DNS exfil (no CVE, AWS silent patch August 2025). Same shape — ping miscategorized as a "read-only" command, prompt injection has Q read .env and exfil via a DNS query. AWS silently patched without filing a CVE, citing CNA criteria.

Claude Code ANTHROPIC_BASE_URL exfil (CVE-2026-21852, Check Point, February 2026). A crafted repo settings file set ANTHROPIC_BASE_URL to an attacker-controlled host. Claude Code applied the env override and started making API calls — carrying the user's API key — before showing the trust prompt. Simply opening the repo leaked the key. Anthropic patched in v2.0.65 (Check Point Research, GitHub Advisory).

GitHub Copilot Codespaces GITHUB_TOKEN (CVE-2026-21516). Prompt injection in repository content made Copilot for JetBrains read GITHUB_TOKEN from its own process environment and emit it back through the model's output channel (paperclipped writeup). The token was in process env because Codespaces put it there.

IDEsaster (Ari Marzouk, 24+ CVEs across Cursor, Copilot, Windsurf, Zed, 2025–2026). The agent writes .env contents into a JSON file with a JSON-Schema URL on the attacker's domain; the editor's schema validator fetches the URL and the secrets ride along in the HTTP request (The Hacker News). The agent never explicitly "sent" anything.

Every one of these assumed the credential was reachable from inside the agent. That assumption is what the patterns below break.

Two patterns that contain the leak

Short-lived credentials

The credential the agent holds expires in minutes, not weeks. AWS, GCP, Azure, and GitHub all issue short-lived tokens for their own services. HashiCorp Vault does the same for databases. A secret manager (Vault, AWS Secrets Manager, Doppler) holds the real long-lived key; the agent only sees the short-lived token issued from it when the task starts.

What it prevents. Leaked tokens that still work weeks later. A token leaked at the end of a 12-minute task is useless by the time the attacker tries to use it. CVE-2025-55284 was bad because the leaked .env credentials lasted forever — the same leak with a 15-minute token is a much smaller incident.

What it doesn't prevent. Two things. The token sits in the agent's memory while it's valid — the same cat that reads .env reads it just as easily — and for long-running tasks the token has to stay valid for the whole task, which stretches the leak window. And most third-party services don't issue short-lived tokens at all — Stripe, OpenAI, Anthropic, Slack, Mailgun, most of the SaaS surface only hands out long-lived keys. That's where brokering enters.

Credential brokering

The agent never holds the credential. The agent sends a request with a placeholder (or no auth at all); a proxy sitting outside the sandbox catches the request, attaches the real token, and forwards it. Three implementations to know:

Anthropic's git proxy for Claude Code — the agent uses a placeholder credential; the proxy swaps in the real GitHub OAuth token.
Cloudflare Outbound Workers for Sandboxes — a Cloudflare proxy reads the agent's outbound HTTPS and attaches credentials before forwarding.
Agyn's Egress Gateway — sits outside the sandbox, catches the agent's outbound HTTP on configured rules, attaches the real credential, and forwards it.

What it prevents. Everything in the CVE list above. The credential cannot be in .env, cannot be in the agent's environment variables, cannot appear in the model's output — because it is not in the agent's process at all. CVE-2025-55284, CVE-2026-21852, CVE-2026-21516, the IDEsaster leak — every one of them needed a credential the agent could reach. Brokering removes that target.

Why brokering covers what short-lived can't. Short-lived only works when someone is willing to issue a short-lived token. AWS, GCP, GitHub, and HashiCorp Vault (for databases) do that. Stripe, OpenAI, Anthropic, Slack, Mailgun, and most SaaS APIs only hand out long-lived keys — and Vault can't wrap them either. Brokering doesn't care. The broker holds the real key on your side; the agent gets a placeholder.

What it doesn't prevent. The action the broker authorizes. A brokered git push origin main is still a git push origin main. Brokering moves the question from "can the agent exfil the credential?" to "what is the credential allowed to do?"

Tool-by-tool reality

None of the popular AI coding tools ship credential brokering by default. Claude Code, OpenAI Codex CLI, Cursor, GitHub Copilot, and Windsurf all read files directly from disk through their bash tool. The ignore-files each ships (.cursorignore, Content Exclusions, .codeiumignore, Claude Code's permissions.deny rules) decide what the model sees — they do not stop the shell. That is the gap this post exists to name.

How Agyn handles this

You don't have to switch agents to close the gap. Claude Code and Codex CLI both run unmodified inside an Agyn sandbox — same binary, same workflow — but the runtime is a per-task isolated container with no path to your laptop's filesystem, and outbound HTTP goes through a credential broker that holds the real keys. cat .env inside that container reads the container's own (empty) .env, not yours; the agent's git push carries a token the agent never sees.

Two services sit outside every Agyn sandbox: the LLM Proxy and the Egress Gateway. Each pod has its own network identity, so the agent doesn't need an API key to talk to either of them.

LLM calls. The agent talks to the LLM Proxy using the standard OpenAI or Anthropic API; the proxy attaches the real provider key and forwards the request.
Other outbound HTTP. When the destination matches a configured rule, the Egress Gateway catches the request, attaches the real credential from the secret store, and forwards it.

The intended property: a prompt injection that reaches the agent finds no API key in .env and no provider key in the agent's environment. The credential to leak is not there.

Full platform at github.com/agynio/platform. For the broader sandbox-axes story, see AI agent sandboxing: filesystem and network isolation patterns. For a vendor-by-vendor scorecard, see How to select an AI agent runtime for production.

Takeaway

.env was a great convention for a world where one trusted process read the file. An AI coding agent is a different shape of process. Credential brokering is the pattern that actually contains the leak — it keeps the credential out of the agent entirely and works for any upstream. Short-lived credentials shrink the damage window where the upstream supports them (AWS, GCP, GitHub, Vault for databases) and do nothing where it doesn't (most SaaS). Use both — brokering everywhere, short-lived on top wherever you can get it.

Everything else is good hygiene. Scope every credential as narrowly as possible, keep secrets in a vault rather than in committed files, and don't share a global .env across agents — advice that pays back, but not a substitute for the two patterns above.

The single rule: a credential the agent can read is a credential the agent can leak.