Egress and network access control
The sameproxy_config that injects credentials also controls which destinations a sandbox can reach.
Default egress posture
By default (noaccess_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
rulesandcallbacksinject credentials. - All other raw TCP is blocked. Connections to non-HTTP ports—databases (
psql/dbton 5432), SSH (22), Redis (6379), and so on—are dropped unless you explicitly allow them.
access_control.
Allow and deny lists
Add anaccess_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
Eachallow_list/deny_list entry uses the following forms:
Connecting to a database (raw TCP)
To let sandbox code reach an external PostgreSQL database withpsql, 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:
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 aproxy_config when creating a sandbox, or update an existing sandbox by patching its proxy_config. Each rule specifies:
Header types
Each header has atype that controls how its value is stored and displayed:
Authenticate AWS requests
Use an AWS auth rule when sandbox code needs to call AWS services with an AWS SDK or CLI. The proxy keeps the real AWS credentials outside the sandbox, then signs supported outbound HTTPS requests with AWS SigV4. This is useful when agent code needs to inspect S3 objects, call Bedrock, or use another supported AWS HTTPS endpoint without exposing long-lived AWS access keys in sandbox files, environment variables, shell history, or logs. The sandbox receives compatibility AWS credential placeholders so SDK credential detection works, while the proxy signs the outbound request with the configured credentials. AWS auth rules are different from header injection rules:- Set
typetoaws. - Put credentials under the
awsobject. - Do not set
match_hosts,match_paths, orheaders; AWS host matching is built into the proxy. - Configure at most one AWS auth rule per sandbox.
Configure AWS auth via SDK
AWS auth proxy rules currently support access key ID and secret access key credentials. They do not include a session token or assume-role configuration.
Authenticate GCP requests
Use a GCP auth rule when sandbox code needs to call Google APIs with Google SDKs or CLIs. The proxy keeps the service account JSON outside the sandbox, then authenticates supported outbound HTTPS requests to Google API hosts matched by the sandbox proxy. This is useful when agent code needs to inspect GCS objects or call another Google API without exposing service account JSON in sandbox files, environment variables, shell history, or logs. The sandbox receives compatibility credentials so SDK credential detection works, while the proxy authenticates the outbound request with the configured service account. GCP auth rules are different from header injection rules:- Set
typetogcp. - Put credentials under
gcp.service_account_json. - Set
gcp.scopesto a non-empty list of OAuth scopes. - The proxy matches Google API hosts automatically and authenticates those requests with the configured service account.
- Configure at most one enabled GCP auth rule per sandbox.
gcp_auth and gcpAuth helpers build this same rule shape.
Configure GCP auth via SDK
Single API example
Create a sandbox that automatically injects an OpenAI API key into outbound requests: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-onlyopaque 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
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:
gh CLI’s local check. The proxy injects the real Authorization header into the outbound request.
Configure via SDK
Callback credential example
Staticworkspace_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:2xx with a JSON body:
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
Connect these docs to Claude, VSCode, and more via MCP for real-time answers.

