Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.litellm-agent-platform.ai/llms.txt

Use this file to discover all available pages before exploring further.

Every sandbox pod runs a vault sidecar alongside the harness container. The sidecar acts as an HTTPS proxy: all outbound connections from the sandbox flow through it. When the sidecar sees a request that carries a stub credential, it replaces the stub with the real value inline — on the wire, before the packet leaves the cluster. The harness process itself never holds the real credential at any point.

​
How stub credentials work

When the platform boots a sandbox, the harness container receives stub values in its environment instead of the real secrets. A stub looks like this: 
GITHUB_TOKEN=stub_github_a8f1
LITELLM_API_KEY=stub_litellm_bb20
The agent can read these environment variables freely — echo $GITHUB_TOKEN returns stub_github_a8f1. But when the agent makes an outbound HTTPS request that includes the stub as a bearer token or header value, the vault sidecar intercepts that request at the TCP level and substitutes the real credential before forwarding.

​
The credential swap flow

1

Platform injects stubs into the container env

At sandbox creation time, the platform writes stub values into the harness container’s environment. Real credentials are given to the vault sidecar separately and are never placed in the harness environment.
2

Outbound connections are proxied

Every outbound HTTP/S connection from the harness process is automatically routed through the vault sidecar. This is configured transparently — the harness does not need to do anything special; all network traffic exits via the vault proxy.
3

Agent makes an outbound request

The agent calls an external API — for example git push uses GITHUB_TOKEN, or the LLM client calls the LiteLLM gateway with LITELLM_API_KEY. The request header contains the stub value.
4

Vault sidecar intercepts and swaps

The sidecar holds the real credentials in its own process memory. It identifies stubs in the request headers and replaces them with the real values before forwarding the connection to the destination.
5

Real credential never leaves the sidecar

The harness process sends a stub; the destination receives the real value. The harness never has an opportunity to log, exfiltrate, or expose the real credential — even if it is compromised.

​
Why this matters

A compromised or misbehaving agent cannot exfiltrate your real credentials. Even if the agent attempts to read its own environment, print all variables, or send them to an external endpoint, it only ever has access to the stubs. The real values exist only in the vault sidecar’s memory and on the wire for the duration of each proxied request. This model is especially important when running agents with broad tool access or bypass-permissions mode enabled, where the agent can execute arbitrary shell commands.

​
Reserved env keys

The following keys are managed by the vault and the harness runtime. You cannot set them via agent-level or per-session env_vars — the API returns 400 if you include any of them. 
REPO_URL
BRANCH
LITELLM_API_KEY
LITELLM_API_BASE
LITELLM_DEFAULT_MODEL
AGENT_PROMPT
PORT
GIT_TOKEN
AGENT_REQUIREMENTS
These keys are reserved because the platform sets them itself to control harness behavior. Allowing callers to override them could break sandbox startup or bypass security boundaries. GIT_TOKEN deserves special mention: the sandbox entrypoint uses it to authenticate the initial git clone, then immediately erases it from the environment so the harness process cannot read it back. If you need a token that persists into the agent shell for push operations, pass GITHUB_TOKEN or GH_TOKEN instead — those flow through the vault normally.

​
Vault-protected agent credentials

Credentials you set in an agent’s env_vars are vault-protected. The platform encrypts them at rest in the database. At session boot time, the harness receives stub values and the vault sidecar receives the real values. The swap happens transparently for every outbound request, on every session, for the lifetime of the agent.
This means you can store a long-lived GITHUB_TOKEN or API key in an agent’s env_vars without worrying that any future session will expose the real value to the agent process.

​
Example: comparing what the agent sees vs what reaches the destination

The following example shows what happens when an agent calls the LiteLLM gateway. What the harness process holds in its environment: 
echo $LITELLM_API_KEY
# stub_litellm_bb20
What the harness sends in the request header (the stub): 
Authorization: Bearer stub_litellm_bb20
What the vault sidecar forwards to the LiteLLM gateway (the real value, swapped inline): 
Authorization: Bearer sk-real-litellm-key-...
The gateway receives the real key and responds normally. The harness never knows the substitution happened.