Controlled Egress for Adversarial AI Agents with Modal Sandboxes

An agent may need to call a model provider, query an approved Model Context Protocol (MCP) connection, retrieve a document, deliver a webhook, or use a permitted web tool. Each capability creates a legitimate reason for outbound network access.

It also creates an escape path.

A prompt injection, compromised dependency, malicious tool response, or generated code step may influence the agent process. For a meaningful egress boundary, the security design has to assume the agent can take control of its own runtime. It may ignore application conventions, remove proxy environment variables, replace the HTTP client, or open a raw socket.

A trusted host derives the permitted destinations from the run, then applies that policy through one of two infrastructure-enforced paths:

1. Direct-domain enforcement gives Modal the resolved TLS domain list.
2. Proxy-mediated enforcement gives Modal only the proxy endpoint, while the proxy authorizes each downstream destination against the resolved run policy.

The two paths differ in where the destination policy is evaluated. Neither depends on the agent continuing to cooperate.

Two Enforcement Paths

In both paths, the trusted host resolves the model, tool, connection, webhook, and control-plane origins before the Sandbox starts. The Agent Manifest does not contain a separate egress allowlist, and the agent process cannot widen the network policy.

The proxy-mediated security property is:

The untrusted sandbox can reach only the policy proxy, and the proxy can reach a destination only when the trusted host authorizes it for that run.

Proxy-Mediated Enforcement Uses Two Controls

1. Force Traffic Through a Policy-Aware Proxy

The proxy is the application-aware control. The trusted host derives permitted origins from the agent's model, tools, connections, callbacks, and web-access settings. The proxy authenticates the run and evaluates each requested host, port, and protocol against that server-side policy.

Proxy environment variables help standard network clients find the proxy, but they do not provide the security boundary. The design has to work even when the agent ignores them.

2. Make the Proxy Non-Bypassable

The compute provider is the network control. It restricts the sandbox to the proxy's address before the agent starts. Direct TCP, HTTP, HTTPS, and UDP traffic to any other address is dropped outside the sandbox process.

The proxy provides run-aware authorization. The provider network policy prevents the runner from opening a route around it. Together, they implement the proxy-mediated property above.

Treat the Sandbox as Compromised

Application-level allowlists are useful, but they are not a security boundary against a hostile process. A wrapper around fetch, an HTTP client interceptor, or HTTP_PROXY and HTTPS_PROXY environment variables can guide ordinary application traffic. Code executing inside the same environment can often avoid those controls.

The threat model should assume the agent can:

• read its own environment and accessible files;
• replace or reconfigure its network libraries;
• make direct TCP, HTTP, or HTTPS connections;
• choose a different DNS resolver;
• remove proxy configuration;
• reuse any credentials deliberately provided to the run; and
• attempt to reach cloud metadata, private services, or arbitrary public endpoints.

This does not mean every agent is malicious. It means the security boundary remains useful when agent behavior is altered by untrusted input or code.

Derive Routes From Existing Capabilities

The portable Agent Manifest does not need a second egress policy.

An Agent Manifest already identifies the resources the agent intends to use: its model, tools, source connections, callbacks, and steps. The host has additional information that does not belong in a portable definition, including resolved provider endpoints, private connection configuration, credential scope, and internal callback routes.

The host resolves those inputs into a concrete set of permitted origins for each run. Depending on the agent, that set may include:

• the selected model-provider API;
• a control-plane callback used for run events and state;
• approved MCP servers or application connections;
• explicitly configured webhook destinations; and
• web-access services when web access is enabled.

This avoids two competing sources of truth. A separately maintained egress list could become broader than the tools actually available to the run, or fail to follow a connection when its approved endpoint changes.

The Agent Manifest remains portable. The host remains authoritative.

Keep Enforcement Policy Private

After resolving an agent definition, the host creates private, run-scoped launch configuration for the runner. The host can map the resolved policy to Modal's domain allowlist or keep it at the proxy authorization layer while giving Modal only the proxy endpoint.

That payload is operational infrastructure, not part of the portable Agent Manifest. Keeping the distinction clear has several benefits:

• an agent definition cannot grant itself a new network route;
• proxy credentials and signing material do not become portable configuration;
• the host can apply organization policy and deployment-specific routes;
• the same Agent Manifest can run under a different host implementation; and
• policy can be expired or revoked independently of the reusable definition.

The manifest describes what the agent does. The host decides what the run may reach.

Apply the Network Boundary With Modal Sandboxes

Modal Sandbox networking supports a full network block, CIDR allowlists, and TLS domain allowlists. Clear Ideas uses those controls outside the agent process. Modal currently labels domain allowlists as Beta.

Direct-Domain Enforcement

The trusted host resolves the run's permitted HTTPS origins, converts them to domain entries, and supplies the complete list when it creates the Sandbox:

const sandbox = await modal.sandboxes.create(app, image, {
  command: ["node", "/app/agent-runner.js"],
  outboundCidrAllowlist: [],
  outboundDomainAllowlist: resolvedRunDomains,
});

Modal admits TLS traffic on port 443 only to those domain entries. Non-TLS traffic is blocked unless a CIDR entry separately permits it. The agent can replace its HTTP library, remove proxy variables, or open a raw socket without changing the allowlist.

The host sends an explicit list for every run. An empty list stays empty rather than falling back to Modal's default public-network access.

Proxy-Mediated Enforcement

When the policy proxy has a stable address, a Sandbox can be created with an outbound CIDR allowlist containing only that address:

const sandbox = await modal.sandboxes.create(app, image, {
  command: ["node", "/app/agent-runner.js"],
  outboundCidrAllowlist: ["<policy-proxy-ip>/32"],
});

Modal applies the CIDR restriction at the infrastructure layer and permits any protocol only to the listed range. The agent can replace its HTTP library or open a raw socket, but traffic to any other address is blocked.

The proxy's upstream firewall exposes only the proxy listener to sandbox traffic. The CIDR allowlist limits the destination address; the firewall limits the destination port. Together, they leave one usable outbound route.

A proxy may instead sit behind a regional CDN or an access network whose addresses are intentionally dynamic. Resolving that hostname once and pinning the result as a CIDR is brittle: another region or a later connection may receive a different address. In that topology, the host allows only the proxy's TLS access hostname with Modal's domain allowlist:

const sandbox = await modal.sandboxes.create(app, image, {
  command: ["node", "/app/agent-runner.js"],
  outboundDomainAllowlist: ["policy-proxy.example.com"],
});

This remains proxy-only. The domain entry names the proxy endpoint, not the model, connector, webhook, or callback destinations behind it.

For a run that needs no network, blockNetwork: true removes outbound access entirely. For a connected run, the host supplies either the direct-domain list or the proxy endpoint before execution begins.

Modal combines CIDR and domain allowlists additively. A proxy-only Sandbox must therefore omit downstream model, MCP, API, and webhook domains; adding them would create direct routes around the proxy. Prebuilt images also avoid a temporary package-install policy that is broader than the run policy.

Proxy environment variables remain useful for client compatibility, but Modal's network policy is the enforcement boundary.

Proxy Authorization

The proxy accepts authenticated, run-scoped CONNECT requests. Signed context binds the requested host and port to a runner authorization and agent-run or job identity. The policy service checks that destination against the origins resolved for the run.

An allowed request opens an end-to-end TLS tunnel. A denied request stops at the proxy; the proxy does not need to decrypt destination traffic.

Before run-policy evaluation, the proxy denies localhost, private, link-local, metadata, carrier-grade NAT, reserved, and equivalent IPv6 ranges. It evaluates the resolved address as well as the requested hostname, preventing an allowed hostname from resolving into a private network.

Destination policies use exact HTTPS origins and ports where possible. Redirects to another hostname require a new authorization decision. Wildcards are reserved for providers whose documented endpoint patterns require them.

Caching and Revocation

The policy service may return the run's complete allowed-origin set after the first authorization. The proxy can cache that policy briefly using the authenticated run identity and policy version.

Cache lifetimes bound the delay between policy revocation and enforcement. When no current or explicitly permitted cached policy is available, authorization fails closed. Stale-policy behavior must be bounded and observable.

Scope of the Control

Sandbox takeover does not widen the network policy. Proxy credentials and signing material exposed to the run remain bound to its identity and destination set, so they do not authorize arbitrary public addresses, private services, metadata endpoints, or additional tools.

An allowed destination, however, remains allowed. Egress enforcement controls where traffic goes, not every field in an encrypted request. It cannot prevent an authorized external service from being exploited or used as a covert channel. A permitted package cache, repository, webhook, or platform API could become a relay or dead drop without the agent contacting an unapproved hostname.

This boundary is paired with least-privilege, short-lived credentials; narrow tool schemas and server-side authorization; approval gates for sensitive actions; and destination-specific rate and size limits.

Egress Evidence

The proxy records the run and authorization identities, destination, decision, policy source and version, cache status, and latency. It does not log proxy credentials, signing material, authorization headers, query strings, or request bodies.

Runtime and Host Responsibilities

Clear Ideas™ Agent Runtime keeps the Agent Manifest portable. Its resolver walks the manifest's models, tools, connections, webhooks, and referenced agents, while the host maps those capabilities to normalized HTTPS origins.

The host selects direct-domains, proxy-only, or block, configures Modal, supplies run-scoped credentials, and records the resulting policy decisions. DNS, CIDR, proxy, firewall, and private-network configuration remain host-owned deployment concerns rather than Agent Manifest fields.