Superserve injects API keys at the network level, not as environment variables. When your agent makes an HTTP request, the platform intercepts it, adds the appropriate Authorization header, and forwards it to the destination.
The agent never sees the API key. It doesn’t appear in environment variables, tool outputs, or LLM context.
Use the superserve secrets command to manage credentials:
# Set one or more secretssuperserve secrets set my-agent ANTHROPIC_API_KEY=sk-ant-...# Set multiple secrets at oncesuperserve secrets set my-agent \ ANTHROPIC_API_KEY=sk-ant-... \ OPENAI_API_KEY=sk-proj-... \ DATABASE_URL=postgresql://...# List secret key names (values are never shown)superserve secrets list my-agent# Delete a secretsuperserve secrets delete my-agent ANTHROPIC_API_KEY
Secrets are encrypted at rest and scoped to the agent. You can’t accidentally use one agent’s credentials in another.
Secret values are write-only. You can’t retrieve a secret after setting it. Store keys in a password manager or secret vault.
Some credentials aren’t API keys sent in HTTP headers - database URLs, signing secrets, or configuration tokens. For these, Superserve injects them as environment variables inside the microVM:
import os# This is injected as an environment variabledatabase_url = os.environ["DATABASE_URL"]
The difference:
API keys (e.g., ANTHROPIC_API_KEY, OPENAI_API_KEY) are intercepted at the network level
Non-API secrets (e.g., DATABASE_URL, JWT_SECRET) are injected as environment variables
Use the secrets field in superserve.yaml to declare which environment variables your agent needs:
Let’s see exactly what’s visible inside the agent:
import osimport requests# Environment variablesprint(os.environ.get("ANTHROPIC_API_KEY")) # None - not exposedprint(os.environ.get("DATABASE_URL")) # postgresql://... - injected# HTTP request WITHOUT credentialsresponse = requests.post( "https://api.anthropic.com/v1/messages", json={ "model": "claude-sonnet-4-20250514", "max_tokens": 1024, "messages": [{"role": "user", "content": "Hello"}] })# The proxy added the Authorization header# The agent only sees the responseprint(response.json())# {"content": [{"type": "text", "text": "Hello! How can I help..."}], ...}
The agent makes the request as if it’s unauthenticated. The proxy handles authentication transparently.
Most agent SDKs automatically use environment variables for API keys. Since Superserve intercepts network requests, the SDK works without changes:
from claude_agent_sdk import ClaudeAgentOptions, ClaudeSDKClient# No API key needed in code - the proxy handles itoptions = ClaudeAgentOptions( model="sonnet", system_prompt="You are a helpful assistant.",)async with ClaudeSDKClient(options=options) as client: await client.query(prompt="Hello", session_id="chat") async for msg in client.receive_response(): print(msg)
The SDKs make HTTP requests to the API, and Superserve’s proxy adds the credentials.
The model doesn’t see the key in environment variables, code, or tool outputs. It can’t accidentally leak them in responses.
# Even if the agent tries to read the key...import osprint(os.environ.get("ANTHROPIC_API_KEY")) # None# The proxy still injects it at the network levelresponse = requests.post("https://api.anthropic.com/v1/messages", ...)# Works! But the agent never saw the key
Keys don't leak into logs
Tool outputs, error messages, and debug logs don’t contain credentials:
# This would normally print the full Authorization headerresponse = requests.get("https://api.anthropic.com/v1/messages")print(response.request.headers) # No Authorization header visible# The agent only sees: {"User-Agent": "python-requests/2.28.0", ...}# The proxy added the header after interception
Per-agent credential scoping
Each agent has its own set of secrets. You can’t accidentally use Agent A’s API key in Agent B.
# Set different keys for different agentssuperserve secrets set agent-a ANTHROPIC_API_KEY=sk-ant-alice...superserve secrets set agent-b ANTHROPIC_API_KEY=sk-ant-bob...
Sessions for agent-a will only see alice’s key injected. Sessions for agent-b will only see bob’s key.
Revocation and rotation
Change or revoke credentials without redeploying your agent:
# Rotate a keysuperserve secrets set my-agent ANTHROPIC_API_KEY=sk-ant-new-key...# All new sessions immediately use the new key# Active sessions continue using the old key until they restart
This is faster and safer than redeploying with a new environment variable.
Audit trail
Every HTTP request the agent makes is logged with:
Destination URL
Request method and headers (except credentials)
Response status and size
Session and agent ID
You get a full audit trail of which agent made which API call, without exposing the credentials themselves.
For credentials that aren’t HTTP API keys (e.g., database URLs, SSH keys), use environment variables:
import osfrom sqlalchemy import create_engine# DATABASE_URL is injected as an environment variableengine = create_engine(os.environ["DATABASE_URL"])
The environment variable is visible to the agent. If your threat model requires hiding database credentials from the LLM context, use a connection proxy or secret manager that your agent calls via HTTP.
Some frameworks cache API clients at import time. Ensure your agent creates clients after the proxy is initialized:
# Bad - client created at import time (before proxy is ready)from anthropic import Anthropicclient = Anthropic() # Might fail or miss proxydef run_agent(): client.messages.create(...)# Good - client created when agent runsfrom anthropic import Anthropicdef run_agent(): client = Anthropic() # Proxy is ready client.messages.create(...)
