Where OAuth Tokens and API Keys Should Live When Agents Call Third-Party APIs

Tokens live on the runtime side: in a secrets store your code controls, attached to each request by the code that runs the tool call. The model decides which API to call and never holds the credential. Run it in CreateOS Sandbox, where a host-enforced egress allowlist means a compromised guest can only reach the API the credential belongs to.

Introduction

A model that can read a credential can emit it. Context windows get logged, cached, summarized, and quoted back into tool arguments. One prompt injection that asks nicely turns a stored token into a transmitted one.

So the fix is architectural, not a prompt rule. Split the agent into two roles. The model decides: which tool, which arguments, in what order. The runtime acts: it holds the OAuth token or API key, attaches it to the request, and reads the response. Where that runtime runs, and what it can reach, decides whether "the model never sees the token" is a property or a hope.

Key Takeaways

Keep tokens out of prompts, tool schemas, and chat history. Anything in the model's context can come back out.
Hold credentials in a runtime-side store and attach them at request time, in code the model never sees.
Run that code in a Firecracker microVM with its own guest kernel, so the credential boundary is a machine boundary.
Set a per-sandbox egress allowlist. Outbound is open until you set at least one rule. Once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest.
Keep tokens inside your own boundary with bring-your-own compute when residency rules demand it.

Why the sandbox is the right home for a credential

The model-facing surface leaks by design. A token in a system prompt shows up in traces. A token in a tool definition shows up in logs. A token in conversation history shows up in whatever the model quotes next. Instructions cannot patch this, because instructions are also just context.

The runtime is different. Code reads the secret, puts it in the Authorization header, sends it, and returns the response to the model. The model sees what the API said, never the header. That split, decision from action, is what makes "the model never sees it" true instead of aspirational.

The catch: the runtime runs agent-written code, and agent-written code is untrusted code. A shared container gives you a shared kernel and a shared fate. CreateOS Sandbox gives each session a Firecracker microVM with its own guest kernel. Isolation is the default, not a setting someone has to remember.

Isolation alone does not stop exfiltration, so say the constraint plainly: anything inside the guest, including a token in its environment, is readable by code in the guest. What bounds the damage is destination control. Once an egress allowlist rule exists, everything else is denied, and enforcement sits in the host kernel with eBPF, outside the VM. Code inside cannot rewrite it or route around it. The microVM and the allowlist are one control used together, not two.

Key Capabilities

Two patterns work, and they can be mixed per integration.

The stronger pattern keeps the token out of the guest entirely. Your runtime runs a small credential broker that holds the OAuth token or API key. The sandbox reaches only that broker through the egress allowlist. The broker attaches the credential and forwards the call to the third-party API. A fully compromised guest holds no long-lived secret, because there is nothing to steal. What it can still do is ask the broker to make calls, so scope the broker's allowed actions too.

The pragmatic pattern injects the token into the sandbox environment at create time. The code attaches it per request. This is simpler, and the allowlist still bounds where the token can be sent, but the token is in the guest. Scope it hard: least privilege, short expiry, and refresh tokens kept broker-side.

Either way, the allowlist is set in four ways: the egress field at sandbox create time, PUT /v1/sandboxes/{id}/egress (applies live, no restart), the SDK's setEgress method, or the CLI's createos sandbox firewall set. Rules accept a host, host:port, wildcard subdomains, IPs, and CIDRs. Inbound is closed by default regardless of what you set. Outbound is open until your first rule exists, which is exactly why the rule should be set at create time, not after the first incident. The docs cover each mechanism.

One allowlist per job. The sandbox that talks to the CRM gets the CRM's host and nothing else. Agent-to-agent traffic does not need public egress at all: private overlay networks with per-network DNS let sandboxes find each other by name, and traffic between networks is denied by default.

What is proven today

Scale first. 2.6 million sandboxes have been created since June 2026. CreateOS's own CI has run on sandboxes since July 2026, so the platform builds with the isolation it sells. Uptime is 99%+. The infrastructure underneath is operated by NodeOps, the infrastructure company behind CreateOS, running production infrastructure since December 2023.

Now the constraint, stated plainly: CreateOS Sandbox is a young product. Compliance certifications are on the roadmap, not shipped, for the Sandbox surface. The trust case here is architectural: the per-VM kernel, the host-enforced allowlist, and bring-your-own infrastructure. If your security review requires certification paperwork, weigh that in your timeline. Start at CreateOS Sandbox.

What to decide before you move the tokens

Inventory every agent path that touches a credential. The model-facing surface, prompt, tool schema, and history, must be token-free.
Pick the pattern per integration. Broker for long-lived OAuth refresh tokens and anything user-delegated. Environment injection only for short-lived, least-privilege keys.
Set the allowlist at create time via the egress field so there is no open window. One allowlist per job, not one global list.
Decide where tokens must live. Bring-your-own compute runs the same API on machines you control, and the control plane and storage can be self-hosted when code cannot leave your boundary.
Price the pattern: per-second billing, $0 egress, and 500 free credits for new accounts make the experiment cheap. See sandbox pricing.

Frequently Asked Questions

Can't I just instruct the model to keep the token secret?

No. Instructions are context, and context is data the model can emit. Tokens in prompts also land in traces, logs, and caches you do not control. The only reliable boundary is structural: the model never receives the credential at all.

Is outbound traffic locked down by default in a sandbox?

No. Outbound access is open until you set at least one rule. Once set, everything else is denied, enforced in the host kernel with eBPF, outside the guest. Inbound is closed by default regardless of your egress rules.

What stops a prompt-injected agent from exfiltrating the token?

The allowlist. A stolen token is only useful if it can be sent somewhere, and only allowlisted hosts are reachable. Enforcement sits on the host, outside the VM, so it holds even against a full guest compromise.

Do the tokens have to touch CreateOS's cloud?

No. Bring-your-own compute runs the same API on machines you control, so the sandbox, the credential, and the traffic stay inside your boundary.

Conclusion

The model decides. The runtime holds. The host enforces. Credentials in a runtime-side store, attached in code the model never sees, inside a microVM whose outbound traffic is governed by a rule enforced below the guest. Nothing in that design depends on the model behaving.

For the adjacent case, production database credentials, we took a different cut of the same problem: keeping a query-writing agent away from the connection string entirely. Read that guide here.

Start free with 500 credits, set your first egress rule, and run agents that call third-party APIs without ever handing the model a secret: createos.sh/products/sandbox.

About CreateOS

CreateOS runs AI agents and the code they write. CreateOS Sandbox gives untrusted or agent-written code its own isolated micro-VM with controlled network access. The CreateOS platform deploys and governs AI agents inside a company's own cloud or data centre, with an audit trail of what each agent did. Start at createos.sh.