Deny by default: network isolation patterns for autonomous AI code

Traditional server infrastructure defaults to allow-all outbound networking. A process can reach any internet endpoint unless a firewall rule blocks it. That default made sense when your team wrote, reviewed, and deployed every server process. It stops making sense when an AI agent generated the process seconds ago. Autonomous AI code requires a different trust model, network isolation, and a controlled rollout.

Autonomous agents write and execute code your team has never seen. During normal operation, they install packages and use APIs to contact external services. A coding agent selects package registries at runtime, mid-task. There is no ticket or review. A research agent fetches unvetted pages and feeds their contents straight into its own context.

Both patterns are routine. Both open outbound paths your team never approved. Under an allow-all posture, every agent in your fleet can reach every internet endpoint. A compromised agent, prompt injection, or hallucinated URL can push data to any destination.

In eBay's "Silent Egress" study, 95.0% of successful attacks moved sensitive data only through network requests. The assistant's final text response stayed benign. That class of leak appears at the network boundary, not in the transcript.

TL;DR

• Allow-all outbound was designed for human-written code: Broad network access was reasonable when your team wrote every process. Autonomous agents change the trust model.
• Deny-by-default blocks unapproved exfiltration paths by design: Agents reach only explicitly authorized domains. Every other destination is blocked and logged.
• Allow-listing is the minimum viable network policy: Define the exact domains each agent type needs. Block everything else and review quarterly.
• The operational cost is front-loaded: Plan days to build the allow-list and minutes to maintain each change.
• Isolation patterns compose: Pair deny-by-default egress with credential separation and microVM compute isolation for defense in depth.

Why allow-all outbound is the wrong default for autonomous code

Unrestricted egress grants autonomous code network authority that was designed for reviewed, human-authored processes.

Understand what unrestricted egress allows in agent workloads

Traditional infrastructure permits broad egress because engineers wrote the code. Code review caught obvious problems, and CI pipelines validated the rest. Under those conditions, assuming a process won't send data to an unauthorized endpoint is reasonable. Outbound rules stay loose because nobody expects the application itself to turn hostile.

That bet holds for deterministic, human-authored applications. It fails for autonomous agents because the agent's model writes code during execution. Nobody reviewed it. It can contain any outbound call the model chooses. Injected instructions can plant outbound requests through a poisoned issue comment. A hidden HTML tag or malicious README may steer the same decision.

Generated code warrants the same treatment as a third-party plugin from an unknown author.

An agent with open egress can do four things you'd never authorize explicitly:

• Send data anywhere: An agent can send its context or customer records to any URL. Internal documents face the same risk. This can happen by intent or injected instruction.
• Install packages from any registry: Frontier models produced hallucinated package references at rates of 4.62–6.10%. Across all five tested models, 127 names were hallucinated and 53 remain registrable. Each one is a free landing spot for an attacker. Sonatype logged 454,648 new malicious packages in 2025, so the supply of bait keeps growing.
• Contact command-and-control infrastructure: A compromised agent has the same outbound reach as any beacon.
• Abuse approved destinations: The Nx packages published in August 2025 scanned hosts for secrets and local AI tools. They then uploaded to GitHub through the GitHub CLI.

These actions exploit overly broad authorization without requiring a sandbox escape. "Any call to any destination" is too broad for code you didn't write. Shrinking that grant to named domains closes several paths, but approved registries and trusted services still need layered controls.

Network isolation patterns for agent workloads

Deny-by-default requires enforceable policy at the network boundary. Follow the Open Worldwide Application Security Project's 2026 guidance for agentic applications. Allow-list outbound destinations and deny everything else.

Domain allow-listing at the egress boundary

Start by naming the exact domains each agent type may reach. A data analysis agent needs your warehouse and a charting service. Most agents need finite destinations; arbitrary-domain research should use controlled proxy access instead of unrestricted egress. Everything off the list gets blocked and logged.

Enforce the list at the egress proxy or gateway, never in agent code. Generated code can rewrite, unset, or bypass any check that lives beside it. Make the enforcement point non-bypassable and independent of application code. Apply SP 800-207A at the boundary. A library inside the sandbox cannot meet that bar.

A closed destination allow-list cut attack success to 0% in "The Framing Gap" study. Fine-tuning in the same study let 32.5% through. Model-side defenses degrade under adaptive pressure, while the network boundary does not.

Treat each allowed domain as a capability grant. In a May 2026 Anthropic red-team exercise, Claude completed credential exfiltration in 24 of 25 attempts. An injected instruction made Claude upload workspace files through api.anthropic.com to an attacker's account. The agent can't function without that domain.

Log blocked requests and review allowed ones too. Repeated blocked calls from one agent to an odd domain deserve attention.

Protocol and port restrictions

Limit agents to HTTPS for external calls. Block raw TCP, UDP, and non-standard ports unless a documented use case needs them. OpenAI's Codex cloud can restrict agents to GET, HEAD, and OPTIONS and block other methods. A read-only web is a poor exfiltration channel.

The Domain Name System (DNS) needs its own control. An agent resolving arbitrary names can encode data into subdomain labels. Each lookup carries another piece. This attack succeeded inside the AWS AgentCore Code Interpreter sandbox in January 2026. Python socket.gethostbyname calls succeeded and bypassed HTTP-layer allow-lists entirely.

Route resolution through a resolver you control. Also block outbound port 53, port 853, and unauthorized DNS-over-HTTPS servers. Apply these restrictions at every external egress point and monitor attempts to bypass them. Without resolver control, a clean HTTP allow-list still leaves an open leak path.

Per-agent-type network policies

Give support agents access only to the customer relationship management (CRM) API and pull request review agents access only to the Git host. Research agents require broad web access under tighter monitoring. Route research agents through a browsing proxy that strips credentials before each request leaves. GitHub's Copilot coding agent ships with internet access limited by a firewall. That published allow-list is a reasonable starting template for your coding agents.

Define policies per agent type, not per instance. A new deployment inherits the policy for its type. Change network policy in code, never manually at runtime.

Include the network policy change when a pull request adds a tool integration. Keeping network policy in the repository preserves an auditable record. A console entry does not offer the same long-term visibility.

How to implement deny-by-default without breaking agent functionality

Deny-by-default is clean on a whiteboard and disruptive in a running fleet. Agents that reached many domains yesterday will fail if today's list misses one.

Start with an audit, not a block

Run agents in audit mode before enforcing anything. Log every outbound destination for a representative workload period. Do not block traffic during that window. The platform team runs the audit and owns the policy repository. Capture destination, method, agent type, and request frequency for every call.

The resulting log becomes your baseline allow-list. It reflects what agents did rather than what someone guessed. Switch to blocking after confirming legitimate traffic remains unaffected. Centralize egress under AWS egress guidance before switching from audit mode to blocking.

Review the baseline with the team that owns each agent type. Delete destinations that aren't essential. Add anything the audit window missed, and record why each entry exists.

Audit-first avoids a common failure mode. A restrictive policy ships, agent workflows break, and the team restores allow-all under pressure. Logging first costs less than that rollback.

Handle new domains through a controlled exception process

Agents evolve, and new integrations bring new domains. The developer submits a request naming the domain and its purpose. Assign the platform team's on-call reviewer to the queue. Set a prompt service target for each request. That reviewer checks the domain against the tool manifest and agent-type policy.

The policy repository gets a commit, and the change deploys through the code pipeline. Treat it as configuration change control. Before deployment approval, identify the change and review its security impact. Developers seek workarounds when the approved process becomes slower than those workarounds.

Automate the request where the framework allows. If the agent declares tool endpoints, generate the allow-list from its tool manifest. Adding a tool then opens a policy change request automatically. Allow api.stripe.com with POST rather than *.stripe.com with every method.

Fit Blaxel into the deny-by-default model

For agents that execute generated code, deny-by-default egress should arrive with the compute. OpenAI's Codex ships with network access turned off, and Claude Code pre-allows no domains.

Blaxel is a perpetual sandbox platform with a per-sandbox domain allow-list. Rules can scope access to HTTP methods and URL path prefixes. Domain filtering rules (allowlist and denylist) are enforced by the sandbox's domain filtering configuration, while adding a proxy config enforces use of the proxy on all outbound requests.

Domain filtering applies per sandbox. A proxy configuration sets the standard proxy environment variables when the sandbox is created. Outbound calls then route through the proxy. A coding agent's list usually includes the Git host and package registries. Add any internal API the agent needs. This scope supports required development workflows without granting general internet access.

Credentials injected through proxy routing rules never enter the sandbox. Blaxel's proxy secrets injection resolves secrets server-side. The sandbox runtime therefore never sees raw secret values. The sandbox runs in a microVM and adds compute isolation to the network policy.

The case against common objections

Platform and product teams often push back on the cost and scope of deny-by-default.

"It slows down development"

Gartner predicts that 25% of enterprise breaches will trace to AI agent abuse by 2028. That forecast puts the burden of proof on allow-all. Plan the upfront work in days rather than treating that timing as universal. The audit window runs in the background while agents keep working. The review should remain short. Set a target of minutes for routine domain changes. Schedule the audit window against an existing release cycle so nobody waits on it.

IBM's 2026 breach report puts the global average at $4.99 million and the mean lifecycle at 247 days. That lifecycle includes forensics, customer notifications, regulatory filings, and remediation. The engineers doing that work would otherwise ship product. The allow-list pays for itself when it turns an exfiltration attempt into a logged 403.

"Our agents need flexible network access"

Flexibility describes the range of services an agent can use. The list encodes exactly that range. "Flexible" shouldn't mean "unrestricted." When a product manager asks for flexibility, ask which destinations the feature requires. The answer is almost always a finite list of services.

Some agents genuinely need access to unpredictable destinations. A web research agent browsing arbitrary domains is the honest case. Isolate it under its own network policy with enhanced logging and credential stripping. Don't let one agent's requirements relax policy for the rest of the fleet. OpenAI refuses open-ended outbound access for its own Codex deployment. Its managed policy allows expected destinations and requires approval for unfamiliar ones.

"We trust our agent frameworks"

Agent frameworks can establish trust only for code their authors wrote. Code generated through that framework carries no such review. The model can emit any HTTP call it chooses. An injected instruction can make that decision for it. Framework guardrails reduce the odds without removing them. Make the environment the final enforcement layer.

The structural problem is plain. An untrusted and manipulable agent cannot reliably block its own leaks. The enforcer and constrained party are the same.

Network-level controls enforce policy regardless of what runs inside the sandbox. That is the right place for the trust boundary. If your framework vendor offers egress controls, turn them on. Add a network-layer control that still works if the framework becomes compromised. Put both lists in the same quarterly review. The same reviewer should compare the framework and network-layer allow-lists side by side.

Default to deny for autonomous code

Deny-by-default outbound networking is the only defensible posture for infrastructure running autonomous AI-generated code. Every agent with allow-all egress is one prompt injection away from a full data leak. Deny-by-default shrinks the blast radius to the agent type's allow-list. Method restrictions and controlled DNS shrink it further.

For agents that execute code, Blaxel lets teams enforce an allow-list at the proxy layer. The workload itself runs in a microVM. Domain filtering and proxy secrets injection ship as built-in primitives.

MicroVM compute isolation is built in too. Dedicated egress gateways, currently in private preview, add static outbound IPs. Downstream providers can then allow-list Blaxel traffic. Give coding agents and pull request review agents separate allow-lists. Data analysis agents need their own as well. Use one policy per agent type and check it into the repository.

Talk to the team or start building.

FAQ

What does deny-by-default mean for agent networking?

Treat it as a least-privilege baseline: an agent begins with no approved outbound destinations, and its role determines the exceptions. Evaluate each exception as a capability grant, narrowing methods and paths where supported. This controls reachability, while credential separation and microVM isolation address separate risks. Apply NIST SP 800-53 controls to inbound and outbound traffic under separate policies.

Does deny-by-default egress affect inbound traffic too?

No. To choose the right control, identify which side initiates the connection. A sandbox call to an external service is egress; a user or platform submitting a task to the sandbox is inbound. Secure each flow according to its initiator, exposed interface, authentication requirements, and reachable destination.

How do I maintain an allow-list for agents that call many external services?

Separate stable role dependencies from task-specific exceptions. Treat arbitrary browsing as its own class. Keep stable dependencies in the agent-type policy and send exceptions through change control. Place arbitrary browsing under a dedicated research policy. During quarterly review, use list growth and unrelated destination requests as signals that the role may need to be split.