Sandboxing agents vs credential brokers: complementary, not competing

The standard advice for running AI coding agents is to sandbox them: containers, minimal images, network egress filters, seccomp profiles. It is good advice. A sandboxed agent that gets prompt-injected into running destructive commands fails — the filesystem is read-only, the network is blocked, and the blast radius stays small. And yet teams that sandbox their agents still lose API keys. Sandboxing answers one question: what can the agent do? It does not answer the other question: what can the agent see?

Sandboxing contains actions, not secrets

A sandbox constrains capability. It can stop an agent from writing outside a directory, spawning shells, or reaching arbitrary hosts on the network. What it cannot do is let the agent call an API without the API key. If the agent must talk to the model provider, the key has to exist inside the sandbox, in the agent’s environment. The key enters the context window, and the context window is shipped to a third-party service as part of every request. The sandbox’s network filter does not see that — the request to the model provider is legitimate, so it passes.

The context window is outside the sandbox

This is the part container runtimes do not model. The agent’s context — every file it read, every command output it captured — is serialized and sent to the model API. From the sandbox’s perspective, that is just the agent’s normal outbound traffic. A secret read by the agent is a secret that leaves the machine, sandbox or not. Egress filtering can block an attacker’s server, but it cannot block the model provider the agent is supposed to talk to. The leak channel is the tool itself.

What a credential broker adds

A credential broker removes the secret from the agent’s environment entirely. The agent references a credential by name; the broker injects the value at the layer where it is used. trustless run -s <key> -- <cmd> injects secrets into the subprocess environment and sanitizes stdout and stderr, including base64 and URL-encoded variants, so command output cannot carry the value into context. For HTTP tools, trustless proxy adds per-host headers and query parameters, so the agent talks to a local endpoint and never sees the token. Plaintext simply does not exist where the context window can reach it.

Where the broker still needs the sandbox

The broker is not a replacement for containment. An agent that holds a valid session can still call the API, spend quota, or move data through the very requests it is allowed to make. The broker controls which credentials exist and where they are injected; the sandbox controls what the agent can do with them. Capability and secrecy are orthogonal, and defense in depth means layering both: sandbox the agent’s actions, broker its credentials.

The combined posture

Practical setups do both. The agent runs in a container with a minimal image and no persistent secrets. The broker, running on the host or in a separate namespace, injects credentials at spawn time and scrubs output. OAuth tokens never enter the sandbox at all: the broker runs the RFC 8628 device flow, rotates refresh tokens after a single use, and the agent receives only short-lived access credentials. trustless implements this side — a zero-dependency static Go binary with 321 tests under -race, reading an existing pass or Bitwarden store — while the sandbox handles the rest. The command reference describes each mode.

Sandboxing and credential brokering answer different questions. Which one are you relying on today — and what happens to a secret your sandbox lets through?