Where does an AI coding agent keep your API keys?
When an AI agent builds and runs code for you, it needs to call language models. Those calls require API keys. Where those keys live — in the sandbox, in the platform, or in your own environment — determines what happens if the sandbox is compromised, leaked, or simply misconfigured. The answer matters more than most tool comparisons do.
What is a build sandbox, and why does it exist?
A build sandbox is an isolated, short-lived environment where code is written, compiled and tested. It typically has access to a shell, a file system and real developer tools. The isolation is the point: if something goes wrong — a dependency pulls in malicious code, a script deletes files, a process runs away — the damage stays inside the sandbox and the host system is unaffected.
The sandbox is destroyed when the run ends. That destruction is also the point. A single-use environment cannot accumulate state, cannot be probed over time, and cannot carry secrets from one job into the next. The security guarantee depends entirely on the sandbox being genuinely ephemeral and genuinely isolated.
Why should a sandbox never hold a provider API key?
A provider API key is a credential that authorises spending — on compute, on model calls, on storage. If a key lives inside a sandbox, it is reachable by anything that runs inside that sandbox: the code being built, the shell commands being executed, any dependency that gets pulled in. A compromised build step can exfiltrate the key before the sandbox is destroyed.
The risk is not theoretical. Build pipelines are a well-documented attack surface. Supply-chain attacks targeting environment variables and credential files are common enough to have their own CVE categories. Keeping a provider key out of the sandbox entirely removes it from that attack surface. The model calls still happen — they are simply routed through a layer that holds the key on the platform side, never exposing it to the execution environment.
- Provider key
- A credential issued by a model provider (OpenAI, Anthropic, and so on) that authorises API calls and is billed against your account.
- Sandbox
- An isolated, single-use execution environment with real developer tools, destroyed at the end of a run.
- Proxied model call
- A model request routed through the platform rather than made directly from the sandbox; the key never enters the execution environment.
- Bring-your-own-key (BYOK)
- An arrangement where you supply your own provider key; the platform uses it on your behalf, and the security of that arrangement depends on where the key is stored.
What does it mean for model calls to be proxied?
Proxying means the sandbox sends a request to the platform, the platform attaches the credential and forwards the request to the model provider, then returns the response. The sandbox sees the response but never sees the key. From the sandbox's perspective, it is calling a local endpoint with no authentication of its own.
This architecture has a trade-off worth naming. The platform becomes a trust boundary. You are choosing to trust the platform with your key rather than managing it yourself inside the sandbox. That is a reasonable trade for most developers — the platform's security posture is likely better than an ad-hoc environment variable — but it is still a trust decision, not a free lunch. Ask any tool you use: where exactly is the key stored, who can read it, and does it ever enter the execution environment?
| Arrangement | Key location | Main risk | Main benefit |
|---|---|---|---|
| Key in sandbox env var | Inside the execution environment | Exfiltrated by any code that runs in the sandbox | Simple to set up |
| Proxied through platform | Platform layer, never in sandbox | Requires trust in the platform's storage and access controls | Sandbox compromise does not expose the key |
| BYOK with platform proxy | Platform layer, key supplied by you | Platform must handle your key securely; verify their policy | You control rotation and revocation |
| Local model, no remote key | Not applicable | Model capability is limited to what runs locally | No remote credential to steal |
What questions should you ask before using any AI coding tool?
The market for AI coding agents is moving quickly and documentation often lags behind implementation. Rather than taking a vendor's word for it, ask specific questions and look for specific answers in their security documentation or terms.
The questions below are not exhaustive, but they cover the most common failure modes. If a tool cannot answer them clearly, that is itself informative.
- Does the sandbox have access to any provider API key, even temporarily during a run?
- If model calls are proxied, where is the key stored and who within the platform can read it?
- If I bring my own key, does it enter the sandbox environment or stay at the platform layer?
- Is the sandbox genuinely destroyed after each run, or does it persist between jobs?
- What happens to files written during a build — are they retained, and where?
- Is there an audit log of what the agent executed inside the sandbox?
Common questions
Can an AI coding agent run safely without putting my API key in the sandbox?
Yes. The standard approach is to proxy model calls through the platform layer. The sandbox sends requests to a platform endpoint; the platform attaches the credential and forwards the request to the model provider. The sandbox receives the response but never handles the key. This removes the key from the execution environment entirely, so a compromised build step cannot reach it.
What is the risk of storing an API key as an environment variable in a build sandbox?
Any code that runs inside the sandbox can read environment variables — including malicious dependencies, injected scripts, or a compromised build step. A key stored this way can be exfiltrated before the sandbox is destroyed. The key then remains valid until you rotate it, potentially authorising charges or data access you did not intend.
If I bring my own API key to an AI coding tool, is it safer than using theirs?
Not automatically. The safety depends on where your key is stored and whether it enters the sandbox. If the platform proxies calls on your behalf and your key stays at the platform layer, the risk profile is similar to using the platform's own key. If your key is injected into the sandbox as an environment variable, you have the same exposure as any other key-in-sandbox arrangement. Ask the tool explicitly.
Does it matter which AI model writes the code if the sandbox architecture is insecure?
The choice of model is largely irrelevant to key security. A sandbox that holds a credential is vulnerable regardless of whether the code inside was written by a capable or a modest model. Architecture — specifically, whether the key ever enters the execution environment — is the variable that matters. Model choice affects code quality; sandbox design affects credential safety.
GROX Code runs builds in an isolated, single-use sandbox where model calls are proxied through GROX — the sandbox never holds a provider key and is destroyed when the run ends. If you want to see how that fits into a broader agent workflow, start on the free tier at grox.life — fifty actions a day, no card required.