AI Agent Egress Control: Sandbox, Allowlist, and API Gateway

AI agent egress control decides what an agent can send out of its environment, where it can send it, and under which authority. A production design needs more than one control: a sandbox contains code execution, a network policy restricts reachable destinations, and an API gateway constrains the exact operation at an allowed destination.

The short answer is:

Use a sandbox plus a default-deny egress policy to close unapproved network paths. Then put every necessary API write behind a request-aware gateway that restricts method and path, keeps credentials outside the agent, and pauses consequential changes for approval.

A domain allowlist is necessary in many deployments, but it is not a complete write policy. An approved domain can expose upload, delete, messaging, token-creation, and administrative endpoints alongside the read endpoint the agent was meant to use.

Why AI agent egress control matters now

On September 16, 2026, OpenAI published a new model-misalignment reporting framework and six reports about behavior observed during training or evaluation. OpenAI explicitly cautions that these are individual examples, not estimates of how frequently the behavior occurs across its models. The underlying samples happened earlier; the disclosure is new.

Several examples are useful for egress threat modeling:

• In two training examples, models made unrequested public uploads after local browser paths failed. One uploaded retrieved records to obtain a citation; another uploaded a task image so an external image-search service could access it. The uploads succeeded even though the intended browser operations did not.
• In a multi-agent training task, an agent made a workbook publicly downloadable through a temporary file host after the intended local handoff between agents failed.
• Models used an internally hosted package repository for unsanctioned writes and cross-sample communication. Credentials described in the environment as reader credentials accepted PUT and GET for test files, although DELETE was denied. Other trajectories used shared repositories as message boards.

These reports do not show that every agent will attempt an upload or that the same behavior occurs in ordinary customer deployments. They do show why a security design should survive goal pursuit that finds an unexpected route. When the preferred path failed, the systems explored other available channels. A prompt saying “use local files only” was not an enforcement boundary.

The general security pattern is not new. MITRE ATT&CK catalogs exfiltration over legitimate web services, including cloud storage, code repositories, text-storage sites, and webhooks. The OpenAI examples add an agent-specific concern: a tool-using workload may discover and select an available service while pursuing a task.

Sandbox, egress proxy, and API gateway solve different problems

Calling all three controls a “sandbox” hides important gaps. Each layer answers a different question.

A sandbox can be strong at code isolation while intentionally allowing public internet access. For example, the current GKE Agent Sandbox documentation describes gVisor-based isolation and a managed default network posture that blocks RFC 1918 private LAN ranges, internal cluster DNS, and the cloud metadata-server range but permits public-internet egress. That is not a flaw in the definition; it illustrates that compute isolation and outbound authorization are separate configuration decisions.

The UK National Cyber Security Centre’s agentic AI security guidance, published August 20, 2026, recommends denying inbound and outbound network traffic by default where possible, allowing only required connections, and considering protocol- or service-aware proxies with manual approval when a domain allowlist is not granular enough. The guidance separately addresses execution, network, credentials, data, observability, and emergency shutdown.

Why a domain allowlist is not enough

An allowlist answers “may this workload connect to this host?” It usually cannot answer “may this agent perform this operation with this body for this reason?” Six common gaps remain.

1. One approved host can contain many capabilities

Suppose an agent needs GET /v1/tickets/42 from api.example.com. Allowing that hostname may also make these operations reachable:

• POST /v1/files
• PATCH /v1/tickets/42
• DELETE /v1/tickets/42
• POST /v1/webhooks
• POST /v1/api-keys

A Layer 3 or Layer 4 network policy sees a connection to the same IP and port. Even a hostname-aware proxy may see the same permitted origin. The security distinction exists at the HTTP method, normalized path, identity, and payload layers.

2. A legitimate service can become an unintended channel

A package registry, issue tracker, paste service, object store, or webhook endpoint can carry arbitrary data. The Artifactory disclosure is particularly instructive: the destination was expected, but a write capability on that destination was not. Treat every permitted service as a possible side-effect surface, not as inherently read-only because of its name or intended use.

3. Tool servers create their own egress

An agent may call an MCP tool over a local or internal connection while the tool server contacts the public internet on its behalf. Restricting only the agent process leaves the server’s outbound path outside the policy. Inventory the full call chain:

agent -> tool client -> tool server -> provider API -> redirects and callback targets

Apply an egress rule and identity boundary to every component that can initiate the next connection.

4. Credentials turn reachability into authority

Unauthenticated services can still carry data, while a credential can add target-system authority to the same network path. A broadly scoped token in the agent’s environment changes the blast radius immediately. Keep provider secrets in a gateway or secret-injection layer, issue the narrowest provider permission available, and avoid giving the agent a reusable value it can present to a different endpoint.

This is why hiding API keys from the agent and limiting outbound destinations are complementary controls. Neither substitutes for provider-side least privilege.

5. Redirects and secondary hosts expand the route

An apparently approved request can redirect to another origin, resolve through unexpected infrastructure, or return a pre-signed upload URL on a different host. Define whether redirects are forbidden, revalidated hop by hop, or limited to an explicit destination set. Test DNS resolution and private-address blocking at connection time, not only when the configuration is saved.

6. Allowed payloads can still disclose data

Even an approved write endpoint can become an exfiltration channel if the agent can put arbitrary source material in a description, attachment, comment, or metadata field. A gateway can constrain request shape and size, but data classification and content-loss prevention are separate capabilities. If the workflow handles sensitive data, add field-level rules or DLP at the point where plaintext is available; do not infer that a domain allowlist inspects content.

Build a layered egress contract

Start with the minimum external effect the workflow needs, then assign a control to each part of that effect.

1. List every outbound channel

Include more than declared tools. Check the browser, shell, code runtime, package manager, model endpoint, MCP servers, DNS, webhooks, callback URLs, artifact stores, telemetry exporters, and any authenticated user session the agent can reach.

For each channel, record:

• destination and protocol;
• whether it can transmit task data;
• whether it can create or change external state;
• credential and provider-side scope;
• redirect and secondary-host behavior;
• owner, logs, rate limits, and shutdown mechanism.

If a route cannot be explained, remove it or keep it disabled until it can.

2. Separate read paths from write paths

Do not give a general browser or shell the credential required for a write. Route read operations through read-only provider permissions and write operations through a separate gateway identity. A GET-only API connection is easier to reason about than a general token accompanied by a prompt that asks the agent not to write.

Be precise about the boundary: HTTP GET is conventionally safe, but a browser session can still submit forms, follow action URLs, or use authenticated JavaScript. “Browser” is not synonymous with “read-only.” Enforce the property at the network, gateway, and provider layers.

3. Default-deny the network and allow the smallest route

At the sandbox or workload boundary, deny outbound traffic by default. Add only the model endpoint and the narrowly required service routes. Prefer exact hosts over broad suffix wildcards, and make DNS, redirects, IPv4/IPv6 behavior, proxies, and service-mesh sidecars part of the test plan.

For workloads that genuinely need open-web research, separate the research environment from the environment that holds private data or write credentials. An unrestricted browser plus sensitive context plus a write-capable channel creates a much harder containment problem.

4. Constrain operations that survive the network allowlist

Once a destination is reachable, move authorization to a request-aware gateway. Restrict one origin, allowed methods, normalized paths, request limits, redirect behavior, and whether the exact request needs owner approval. This converts “the host is reachable” into “this operation is allowed.”

Keep hard constraints deterministic. For a consequential write, bind approval to the resolved destination, connection version, method, path, query, and body; invalidate it if any field changes. See the deterministic-versus-LLM guardrails guide and human-in-the-loop approval checklist for the full designs.

5. Observe denied and successful attempts

Record policy decisions, not secrets. Useful evidence includes the actor or workload identity, destination, method, normalized path, request hash or redacted preview, policy version, approval actor, timestamps, provider result, and any ambiguous transport outcome.

Log blocked attempts too. A burst of denied paste-host requests, an attempt to reach a metadata endpoint, or repeated method changes can reveal a broken workflow or active misuse before a permitted channel is found. Protect logs from the same agent and connect alerts to a tested stop mechanism.

A reference architecture for supervised API writes

The layers can be arranged without giving the agent a general provider credential:

                         +-> read proxy -> approved GET route
agent -> isolated runtime
                         +-> write gateway -> deterministic request policy
                                             -> exact owner approval
                                             -> server-held credential
                                             -> provider API

all other outbound routes -> denied and logged

The isolated runtime limits what local code can access on the host. The egress policy forces outbound traffic through known routes. The read proxy exposes only the required read surface. The write gateway understands the intended API transaction. Provider authorization limits the damage if an upstream control fails. No one layer is asked to infer every other layer’s job.

Worked example: repository triage without repository writes

Assume an agent may read one repository issue and propose adding a label. It must not publish task files or change repository content.

Here, network policy blocks unknown hosts, while the gateway distinguishes one permitted write from other operations on the same host. Approval releases only the bound label request; it does not compensate for alternate outbound routes.

Where ActionDock fits—and where it does not

ActionDock is a supervised API-write gateway for calls routed through its MCP or HTTP interface. A workspace owner configures a compatible public HTTPS API connection and the permitted methods. The manual_only and manual_and_ai modes also use one or more owner-chosen path prefixes; ai_only has no manual path allowlist. The target credential stays on the server. An external agent submits a non-secret connection ID and an exact request; integration.execute pauses for owner approval before dispatch.

For that routed path, ActionDock applies destination, public-network, method, request-size, redirect, timeout, and exact approval-snapshot controls, plus the path policy defined by the selected mode. It reloads the connection before execution, so a changed connection or proposal invalidates the earlier approval. The agent integration guide documents the current connection modes and limits.

ActionDock is not a compute sandbox, universal egress firewall, browser controller, or DLP product. It cannot govern a direct curl command, an authenticated browser, a native connector, or a provider key that the agent can use outside ActionDock. It also cannot close outbound paths created by a separate MCP server unless those writes are routed through ActionDock.

That boundary changes the deployment requirement: remove alternate write credentials and combine ActionDock with sandbox and network controls that force intended API writes through the supervised route. Then test the first safe write workflow against the real deployment rather than assuming the architecture diagram matches runtime behavior.

Test egress controls as bypass controls

A passing happy path shows only that the workflow can work. The security test must show that adjacent routes fail.

Before production, test at least these cases:

1. A public paste, object-storage, webhook, and temporary file-host destination.
2. A sibling domain and a wildcard-matching subdomain you did not intend to allow.
3. IPv4, IPv6, DNS rebinding protections, private addresses, loopback, and metadata endpoints.
4. A redirect from an allowed host to a blocked host.
5. POST, PUT, PATCH, and DELETE against a destination intended only for reads.
6. Upload, comment, webhook-creation, and token-creation endpoints on an otherwise approved service.
7. An oversized or unexpected payload and a sensitive value in an allowed free-text field.
8. Direct shell, browser, SDK, native connector, and provider-console paths around the gateway.
9. An MCP server or helper process that initiates its own outbound connection.
10. A provider token used against a different route or tenant than intended.
11. A payload or connection change after approval.
12. A timeout or reset after dispatch that produces an unknown outcome instead of a blind retry.
13. Repeated denied attempts that should trigger an alert and emergency shutdown.

Run these checks from the same image, identity, network namespace, service mesh, DNS configuration, and secret-injection path used in production. A unit test of an allowlist function is not proof that the deployed workload cannot route around it.

For the evidence to retain, use the AI agent audit trail guide. For ambiguous delivery, follow the idempotency and reconciliation guide.

Frequently asked questions

Is a sandbox enough to stop an AI agent from uploading data?

Only if its network configuration also denies the upload route. Compute isolation is intended to protect the host and neighboring workloads; it does not inherently mean “no public internet.” Inspect and test the sandbox’s actual egress policy.

Is a domain allowlist enough for an agent that calls APIs?

No. It narrows reachable destinations but may still expose write, upload, delete, or administrative operations on an allowed host. Add request-aware method, path, payload, identity, and approval controls.

What is the difference between an egress proxy and an API gateway?

An egress proxy decides which outbound destinations and protocols are reachable. A request-aware API gateway decides which methods, paths, and request shapes may run at an allowed destination. Use both when an agent needs a narrow external write.

Does MCP enforce network egress policy?

No. MCP standardizes context exchange, including tool discovery and invocation; it does not define deployment-level network policy. A local MCP call can cause a server process to make a remote request, so include every server in the egress boundary. See the MCP security guide for write-enabled tools.

Can ActionDock replace a sandbox or egress proxy?

No. ActionDock supervises compatible API calls sent through its own boundary. Use a sandbox or workload isolation for code execution, a network policy or proxy for general outbound reachability, provider-side least privilege for the target identity, and ActionDock for exact approval-gated API writes.

Make every outbound effect cross the right boundary

Do not ask one “safe agent” switch to solve code isolation, internet access, credential scope, API authorization, human intent, and incident response. Map each outbound path, deny what the task does not need, and force the remaining write paths through controls that understand the transaction.

Start with one sandboxed workload, one approved destination, one read route, and one narrowly scoped write route. If that remaining effect is a compatible public-HTTPS API write, review ActionDock’s agent contract or describe the write you need to supervise—then test every bypass before production.