Dynamic, identity-aware, and secure Sandbox auth (opens in new tab)

Sandboxes for AI agents need more than isolation: they also require fast startup, platform control, and safe access to external services. The post introduces outbound Workers, programmable egress proxies that intercept sandbox traffic and can authenticate, restrict, modify, log, or cancel requests. This approach combines zero-trust security with identity-aware, flexible, observable, and dynamic authorization without exposing secrets to untrusted agents.

Sandbox Requirements

Sandboxes provide three core benefits:

• Security: Untrusted users or agents can run code without compromising the host or neighboring sandboxes, often through microVM isolation.
• Speed: Users can quickly start new sandboxes and restore existing state.
• Control: The trusted platform can mount files, execute commands, and control network access inside the sandbox.

Outbound Workers add network-level control to this model by acting as programmatic egress proxies for Sandboxes and Containers.

How Outbound Workers Work

• A sandbox can define handlers for all outbound requests or for requests to specific hosts.
• For example, requests to github.com can be intercepted through static outboundByHost.
• The handler can:
  • Add authentication headers.
  • Log requests.
  • Modify request data.
  • Reject or cancel requests.
• Secrets remain outside the sandbox and can be accessed by the Worker through its environment.
• Workers run near the sandbox, can access distributed state, and can be updated using ordinary JavaScript.

A sample handler copies the request headers and injects x-auth-token from env.SECRET before forwarding the request.

Challenges with Existing Agent Authentication

Agent workloads cannot be fully trusted, even when the underlying language model is not intentionally malicious. Credentials must therefore limit accidental misuse and prevent data exfiltration.

Standard API Tokens

• Tokens are commonly passed through environment variables or mounted secret files.
• They are simple to implement but expose credentials to the sandboxed workload.
• A compromised or misbehaving agent could leak the token.
• Expiration and rotation are required, creating operational overhead.

Workload Identity Tokens

• Systems such as OIDC provide an identity assertion rather than a general-purpose service token.
• The agent can exchange the identity token for a short-lived access token.
• Tokens can be invalidated when a workflow ends, simplifying expiration.
• The drawback is limited upstream support: many services do not natively accept OIDC, forcing platforms to build custom token-exchange services.

Custom Proxies

• Proxies provide maximum control and can enforce granular permissions even when an upstream service has weak RBAC.
• They can be combined with workload identity tokens.
• However, intercepting all sandbox traffic and building an efficient, dynamic, programmable proxy is difficult.

Characteristics of an Ideal Agent Auth System

The post argues that agent authentication should be:

• Zero trust: Never expose a reusable token to an untrusted workload.
• Simple: Avoid complicated token minting, rotation, and decryption systems.
• Flexible: Enforce permissions independently of the upstream service.
• Identity-aware: Apply rules based on which sandbox is making the request.
• Observable: Record and inspect outbound calls.
• Performant: Avoid slow, centralized authorization round trips.
• Transparent: Require no changes to the sandboxed application.
• Dynamic: Allow authorization rules to change while systems are running.

Outbound Workers are presented as a way to satisfy all of these requirements.

Restriction and Observability

A basic outbound handler can enforce network policy with only a few lines of JavaScript:

• Inspect each outgoing HTTP request.
• Log requests using disallowed methods.
• Return a 405 Method Not Allowed response for anything other than GET.
• Forward permitted requests with fetch(req).

This demonstrates that outbound Workers can enforce restrictions and provide observability without modifying the application running inside the sandbox.

Practical Recommendation

Use outbound Workers as a trusted egress layer for agent sandboxes. Keep sensitive credentials outside the workload, inject or exchange them only at the proxy, and use the Worker to enforce identity-specific policies, logging, and request restrictions dynamically.