Skip to main content
The auth proxy lets sandbox code call external APIs (OpenAI, Anthropic, GitHub, etc.) without hardcoding credentials. When configured on a sandbox, a proxy sidecar automatically injects authentication headers into matching outbound requests using your workspace secrets or write-only credentials you provide in the proxy config.
You must configure your secrets (e.g., OPENAI_API_KEY) in your LangSmith workspace settings before creating a sandbox that references them.

Egress and network access control

The same proxy_config that injects credentials also controls which destinations a sandbox can reach.

Default egress posture

By default (no access_control configured):
  • HTTP and HTTPS (ports 80 and 443) to any host are allowed. Outbound HTTP(S) is transparently routed through the proxy, where your rules and callbacks inject credentials.
  • All other raw TCP is blocked. Connections to non-HTTP ports—databases (psql/dbt on 5432), SSH (22), Redis (6379), and so on—are dropped unless you explicitly allow them.
This means raw protocols are not blocked because the proxy “can’t speak” them—they are blocked by default and opened per host and port via access_control.

Allow and deny lists

Add an access_control object to proxy_config with either an allow_list or a deny_list (not both—the request is rejected if both are set):
Raw TCP egress (e.g. PostgreSQL on 5432) can only be enabled with an allow_list entry that specifies an explicit non-HTTP port (host:PORT). The default posture and deny_list mode only ever permit HTTP/HTTPS.

Pattern syntax

Each allow_list/deny_list entry uses the following forms:

Connecting to a database (raw TCP)

To let sandbox code reach an external PostgreSQL database with psql, dbt, or any driver, allow-list the host on its port. Because allow_list is default-deny, also list any HTTP(S) hosts the sandbox needs:
The connection to db.example.com:5432 is passed through at the TCP layer with no interception, so the PostgreSQL wire protocol—and TLS, host-key checking, and any other end-to-end protocol on top of it—works unchanged.

Configure via SDK

Configure auth proxy rules

Add a proxy_config when creating a sandbox, or update an existing sandbox by patching its proxy_config. Each rule specifies:

Header types

Each header has a type that controls how its value is stored and displayed:

Single API example

Create a sandbox that automatically injects an OpenAI API key into outbound requests:
The sandbox can now call OpenAI with no API key setup—the proxy injects it automatically.

Multiple API example

Add multiple rules to authenticate with several services at once:

GitHub example

Open SWE authenticates GitHub access by minting a short-lived GitHub App installation token outside the sandbox, then patching the sandbox with write-only opaque proxy rules. This keeps the short-lived GitHub access token out of the sandbox filesystem and out of deployment environment variables. Configure two rules:
Python
Call configure_github_proxy after creating or reattaching to a sandbox. GitHub App installation tokens expire, so refresh the proxy config whenever you reuse a sandbox for a new run. Inside the sandbox, set a non-secret placeholder token when a CLI requires a local credential before it sends a request:
The placeholder only satisfies the gh CLI’s local check. The proxy injects the real Authorization header into the outbound request.

Configure via SDK

Callback credential example

Static workspace_secret rules pull credentials from your workspace when the proxy configuration is applied, and opaque rules let your application patch in short-lived credentials such as the GitHub token example. For credentials that must be resolved by your own service at proxy time, use a callback. The proxy POSTs to a URL you provide, your endpoint returns the headers to inject, and the proxy caches the result. Callbacks are configured alongside rules under proxy_config: Static rules win. If any rule in rules matches the host, the callback is skipped for that host. Within rules, first-match-wins; the same applies between callbacks if multiple match.

Callback contract

The proxy makes the following request whenever it needs to resolve credentials for a matched host on a cache miss:
Your endpoint must respond 2xx with a JSON body:
The proxy injects every header in the response into the sandbox’s outbound request and caches the response for ttl_seconds. Any non-2xx response, transport error, or malformed JSON fails closed: the sandbox’s request is rejected with 502 callback resolution failed (no headers injected, response not cached).

Example

Use a callback when your OAuth tokens are minted on demand by your own service:

Configure via SDK