Dynamic, identity-aware, secure Sandbox auth

With outbound Workers added to Cloudflare Sandbox and Containers, all HTTP/HTTPS egress from the sandbox can now be controlled by trusted proxy code. The workload inside the sandbox is treated as an untrusted zone, while authentication and policy are handled by the Worker outside it.

The key idea is never giving the token directly to the workload. Using outbound and outboundByHost, you can intercept requests to log them, block specific methods, inject secrets per domain, and apply different permissions depending on the sandbox ID.

Existing auth approaches each had their own weaknesses.

• Standard API tokens: the simplest, but carry a high risk of leaking from the sandbox.
• Workload identity tokens (OIDC): safer, but native support from upstream services is often lacking.
• Custom proxies: flexible, but hard to implement in a way that dynamically and efficiently intercepts all traffic.

Outbound Workers tie this together in a way that is zero trust, simple, flexible, identity-aware, observable, performant, transparent, and dynamic. For example, for requests to my-internal-vcs.dev, you can put a SECRET that the sandbox can never see into a header, and read different auth keys from KV based on ctx.containerId, enabling separate access control per instance.

Integration with the Cloudflare Developer Platform is another strength. Inside an outbound Worker, you can directly call bindings for R2, KV, Agents, other Containers, and other Worker services, implementing fine-grained permission policies purely in code without any token-exchange logic.

Network control isn't tied to static configuration either. With outboundHandlers and setOutboundHandler, you can open only github.com and npmjs.org via allowHosts at boot time, then switch to noHttp once the task is done to close off egress. This effectively automates network permissions that are only needed briefly, such as during dependency installation or initialization, entirely in code.

Handling HTTPS transparently requires TLS decryption. Cloudflare generates a unique ephemeral CA and private key for each Sandbox instance; the sandbox trusts that CA, and the container can opt in to it when needed via sudo update-ca-certificates.

Thanks to this structure, outbound Workers behave not just as simple routing but as a transparent MITM proxy. The sandbox doesn't need to know protocol- or domain-specific implementation details, and all HTTP/HTTPS traffic passes through the same control plane to be filtered, modified, and logged.

At the underlying implementation level, interceptOutboundHttp and interceptOutboundHttps were added to ctx.container, enabling interception of specific hostnames, IP ranges, or all outbound traffic. Actual request handling is done by a WorkerEntrypoint, with the outbound Worker acting as the front gate of the sandbox network.