Vault proxy

How the vault sidecar keeps real credentials out of the agent process.

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:

GITHUB_TOKEN=stub_github_a8f1
LITELLM_API_KEY=stub_litellm_bb20

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

agent → request with stub → vault sidecar → request with real key → destination

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:

Authorization: Bearer stub_litellm_bb20

What reaches the LiteLLM gateway:

Authorization: Bearer sk-real-litellm-key-...

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.

REPO_URL
BRANCH
LITELLM_API_KEY
LITELLM_API_BASE
LITELLM_DEFAULT_MODEL
AGENT_PROMPT
PORT
GIT_TOKEN
AGENT_REQUIREMENTS

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.