Prompt injection meets your API keys: why the key should never enter the sandbox

01How do injected instructions steal API keys?

Indirect prompt injection was described in 2023 by Greshake and colleagues: an attacker plants instructions in content an LLM application is likely to retrieve, such as a web page, a file or an issue, and the model follows them as if the user had asked. Data theft was one of the impact classes they demonstrated. OWASP now lists prompt injection first in its Top 10 for LLM applications, and its definition of the indirect form is exactly that: instructions arriving from external sources such as websites or files.

A coding agent is a near-ideal target. Its job is to read untrusted content, it usually runs as the developer, and its environment is full of credentials: ANTHROPIC_API_KEY or OPENAI_API_KEY in the shell, a .env file in the project, cloud and Git tokens in the home folder. Simon Willison calls the dangerous combination the lethal trifecta: access to private data, exposure to untrusted content, and the ability to communicate externally. An agent holding a key in its own environment has all three.

02A documented case: DNS exfiltration from Claude Code

Security researcher Johann Rehberger reported a concrete version to Anthropic in May 2025. Claude Code asked before running most shell commands, but a built-in allow-list let some run without confirmation, including ping, nslookup, host and dig. His proof of concept used indirect prompt injection to have the agent read the .env file and place its contents into a hostname under a domain he controlled. Resolving that name delivered the data to his DNS server. He also noted that environment variables could be read from /proc/PID/environ.

Anthropic fixed it in Claude Code v1.0.4 and published advisory GHSA-x5gv-jw7f-j6xj, CVE-2025-55284, rated High, describing an overly broad allow-list of safe commands that let a file be read and sent over the network without user confirmation. The lesson generalises beyond one tool: any channel out, even DNS, is an exfiltration path, and any secret the agent can read is a secret the attacker can ask for.

03Why filtering the prompt is not enough

Detection helps, but it is probabilistic. Willison's point is that a filter that catches most attacks still fails in security terms, because the attacker only needs the one that gets through. Allow-lists of commands also drift: the Claude Code case was a list of commands considered harmless that turned out to be a network channel.

OWASP's mitigations for prompt injection lean on architecture instead: restrict the model to the minimum privileges it needs, and give the application its own API tokens, handled in code rather than passed to the model. That points to a simple rule. If the real key is never in the agent's process, file system or environment, no injected instruction can read it, encode it or send it anywhere.

04The egress broker pattern: inject the key after the request leaves

The pattern is an HTTP proxy that sits outside the sandbox, on the trusted side. The agent's tool is pointed at the proxy as its API base URL and given a placeholder in place of the key. The proxy checks the request, replaces the placeholder with the real key, and forwards it over TLS to the one upstream that key belongs to. The response streams back. The agent never sees the key, and a placeholder copied out of the sandbox is just a random string.

For this to hold, the proxy must be the only way out. Close the sandbox's network except to an allow-list, so there is no side route like the DNS channel above. Pin each credential to one upstream host. Do not follow redirects, so the upstream cannot bounce the key elsewhere. Keep the key out of logs, snapshots and the sandbox's saved record. The pattern needs a client that accepts a custom base URL; tools that do not cannot be brokered this way.

• Placeholder inside the sandbox, real key only in the broker's memory.
• One upstream per credential, over verified TLS, redirects not followed.
• Network closed except the broker and an explicit host allow-list.
• Every brokered request recorded with host, method, path and status, never the key.

05The limit: the agent can still spend the key

A broker stops the key from being stolen. It does not stop it from being used. The placeholder is a capability: an injected agent can still make any request the broker allows, with the real credential attached, for as long as the sandbox runs. If the key can delete repositories, create public gists or send email, the agent can do those things without ever learning the key. Request bodies to an allowed destination can also carry whatever data the agent can read, and an upstream that echoes the key in a response body hands it back.

So the broker needs a policy, not just a swap. Restrict each credential to the HTTP methods and path prefixes the task needs, matched on segment boundaries so /v1/messages does not also admit /v1/messages_admin. Scope the key itself at the provider to the narrowest permissions. And cap volume: OWASP's guidance on excessive agency notes that rate limiting does not prevent misuse but limits how much damage happens before monitoring catches it. Providers offer this directly; Anthropic, for example, lets you set spend limits and per-workspace rate limits, so an agent's key can live in a workspace with its own low ceiling.

• Allow-list methods and path prefixes per credential.
• Give the agent its own narrowly scoped key, never a personal or admin key.
• Set spend and rate limits for that key's project or workspace at the provider.
• Review the broker's log for refused and unusual requests.