To stop a coding agent from leaking your API keys when it spins up subagents, make sure no subagent ever holds a real key. Keep the keys on the host, give each subagent a short-lived token that a proxy swaps for the real key on the way out, block outbound traffic except to that proxy and an allowlist, and cap what each token can spend. Then a subagent that is tricked into printing its environment or sending it somewhere leaks a token that is capped, revocable and useless outside your machine.

This guide explains why subagents make the problem worse, walks through the five controls that fix it, and shows how to set them up locally with Hotcell, our open-source sandbox runtime. Last reviewed October 2026.

#Why subagents leak keys

Most agents get their credentials the simple way: an OPENAI_API_KEY or GITHUB_TOKEN in an environment variable. Every process the agent starts inherits it. When the agent spins up subagents, the usual approach is to pass the same variables into each one so it can call the model too.

That gives you several copies of a long-lived key, each inside a process that reads untrusted input: files in the repository, dependency source code, web pages, tool output. A prompt injection hidden in any of those can ask the agent to run printenv, read a .env file, or curl the value to an outside server. The more subagents you run, the more chances that one of them reads something hostile. And because they all hold the same real key, one leak means rotating it everywhere.

OWASP lists this pattern in its CI/CD security top 10 as CICD-SEC-6: Insufficient Credential Hygiene: secrets that are long-lived, broadly scoped and exposed to more processes than need them. An agent with subagents is a pipeline that writes its own steps, so the same advice applies.

#Five controls that stop it

You don't need all five on day one, but each one closes a gap the others leave open.

1. Keep real keys out of the agent's environment. No real key in environment variables, .env files or config the agent can read. This is the one that matters most: a key that isn't there can't be printed.
2. Put a credential broker in the path. The agent calls a local proxy instead of the provider. The proxy holds the real key and adds it to the outgoing request, so the agent only ever sees a placeholder or token.
3. Give each subagent its own scoped, short-lived token. One token per subagent, with an expiry, and ideally a model allowlist. If one leaks, you revoke that token and nothing else changes.
4. Deny outbound traffic by default. A subagent should reach the proxy and an allowlist of hosts (package registries, your git host) and nothing else. Even a token can't be sent anywhere if there's no route out.
5. Cap spend and rate per token. A leaked or runaway token should hit a hard ceiling, not your monthly invoice.

Isolation matters too: run each subagent in its own container or microVM so it can't read the host's files, including the key store the proxy uses.

#Setting it up with Hotcell

Hotcell runs sandboxes on your own machine (Docker containers, Firecracker microVMs on Linux, or Apple Virtualization microVMs on macOS) and builds in the five controls above. The commands below are from the Hotcell README and its egress and keys guide.

1. Install it and put your keys on the host.

npm i -g hotcell
hotcell keys add openrouter      # or openai, anthropic, google, github

If your keys live in a .env file, hotcell keys import .env walks through every variable and asks you to choose gateway (the real key stays on the host and sandboxes get a token), inject (the value is copied into sandboxes, for plain config like NODE_ENV) or skip. It never guesses which values are secrets, and it shows everything that will enter a sandbox before saving.

2. Create sandboxes with the gateway wired in.

hotcell create -n 5 --name feat --branch auto --egress \
    --repo https://github.com/you/app

With --egress, each sandbox gets OPENROUTER_BASE_URL pointing at Hotcell's gateway and OPENROUTER_API_KEY set to a per-sandbox token, not your key. The gateway swaps the token for the real key on the way out and records the cost. If a GitHub key is registered, each sandbox's git origin also goes through the gateway, so git push works without a GitHub token inside the sandbox.

3. Scope the tokens. Mint a token limited to what one agent should do:

hotcell egress <id> --spend-cap 5 --models 'claude-*' --rate-calls 60 --rate-window 1m --ttl 24h

Once the token has spent $5 the gateway returns 402; a model outside the allowlist or an expired token gets 403; too many calls get 429. If a token leaks, hotcell egress <id> --revoke <token> kills it without touching your real key or any other sandbox. For a hard ceiling across all of a sandbox's tokens, use --egress-spend-cap, for example hotcell run --egress --egress-spend-cap 2 "...".

4. Turn on default-deny egress. On Linux, start the daemon with HOTCELL_EGRESS_ENFORCE=true (it needs CAP_NET_ADMIN). Sandboxes can then reach only the gateway and DNS; the gateway forwards package and git traffic to an allowlist of hosts and logs every denial. Direct calls to model providers are blocked too, so nothing can skip the key swap. Apple Virtualization microVMs have no network device by default, so the gateway is the only way out by construction.

If you use Autopilot, our terminal coding agent, its subagents already work this way: once Hotcell is running and your OpenRouter key is in its key store, each subagent runs read-only in its own Hotcell sandbox, and files like .env are never copied in.

#What this doesn't protect

A header-swapping gateway only works when the credential travels in an HTTP request header. That covers OpenAI, Anthropic, OpenRouter, GitHub, Stripe, Slack and most REST APIs. It doesn't cover:

• Database passwords for Postgres, Redis or MongoDB, which travel inside the protocol handshake.
• Request-signing schemes like AWS SigV4, where the key signs locally and is never sent.
• mTLS client certificates and OAuth refresh-token exchanges.

If a subagent truly needs one of these, the real value has to go into the sandbox, so give it a dedicated low-privilege credential and treat it as exposed. Two more caveats: an SDK that hardcodes its API host won't pick up the gateway's base URL and needs a one-line change, and on macOS with Docker Desktop, egress enforcement is advisory because the firewall can't be installed. Use the Apple Virtualization driver if you need it enforced on a Mac.

#Other tools that use the same pattern

Hotcell isn't the only tool that keeps real keys out of the sandbox, and the idea matters more than the tool:

• Docker Sandboxes run agents in microVMs. A host-side proxy replaces a placeholder with the real credential after the request leaves the VM, and outbound traffic is deny-by-default.
• microsandbox (Apache-2.0) lets you declare secrets that never enter the VM, each limited to an allowed host.
• agentbox (MIT) runs agents in Docker with an egress policy and injects secrets through a proxy rather than environment variables.

What sets Hotcell apart is the per-sandbox token layer: spend caps, model allowlists, rate limits, expiry and revocation for each sandbox, plus keyless git push.

#FAQs

#Is it enough to put the key in a .env file the agent doesn't open?

No. The agent can read any file its user can, and a prompt injection can ask it to. Treat any secret on a path the agent can reach as exposed.

#Do I need a separate API key for every subagent?

Not from your provider. You keep one real key on the host, and the broker issues a separate token to each subagent. That gives you per-subagent revocation and limits without managing extra keys.

#What happens if a subagent tries to call an unexpected host?

With default-deny egress, the connection is dropped and logged. In Hotcell on Linux this is enforced by the host firewall; in an Apple Virtualization microVM there is no network device to use.

#Does this slow the agent down?

The gateway adds a local hop to each API call. Next to model response times, it's small.

#Is Hotcell free?

Yes. Hotcell is Apache-2.0 and Autopilot is MIT. Both run on your own hardware.