Skip to main content
Every sandbox pod runs a vault sidecar alongside the harness container. It acts as an HTTPS proxy: all outbound connections from the sandbox flow through it. When the sidecar sees a stub credential in a request, it swaps the stub for the real value inline — before the packet leaves the node.

​
Stub credentials

At sandbox boot, the harness env gets stubs instead of real secrets:
The agent can echo $GITHUB_TOKEN and only ever sees the stub. The real values exist only in the vault sidecar’s process memory.

​
The swap

The destination receives the real value. The harness never knows the substitution happened. Even if the agent is compromised or runs with bypass-permissions, it cannot exfiltrate real credentials — it doesn’t have them.

​
Example

What the harness sees:
What reaches the LiteLLM gateway:

​
Reserved env keys

The vault and harness runtime manage these — you cannot set them via agent or session env_vars. The API returns 400 if you try.
GIT_TOKEN is used by the entrypoint for the initial git clone, then erased. If you need a token that survives into the agent shell (for git push, gh pr create), pass GITHUB_TOKEN or GH_TOKEN instead — those flow through the vault normally.