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. 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.