How to design networking for secure AI-agent sandboxes

AI agents need network access to be useful. They install packages, call external APIs, access databases, communicate with internal services, and fetch information from the internet. The problem is that an agent can use that same network access to reach resources it was never supposed to reach, or exfiltrate data to an unauthorized destination.

The design principle that follows from this is simple: give the sandbox the minimum network access required to perform its task and deny everything else. What makes this hard is working out what "minimum" means in practice, how to enforce it reliably, and how to extend it consistently across tenants, environments, and VPC resources. This guide covers the network controls that answer those questions.

A microVM gives each agent session its own kernel, its own memory space, and its own filesystem. A compromised or manipulated execution inside the microVM cannot directly access the host or adjacent workloads. That is the compute isolation guarantee, and it is a necessary starting point.

But compute isolation answers only one question: what can this program access on the machine where it runs? It says nothing about what the program can reach beyond the machine. A perfectly isolated microVM with unrestricted network access can still exfiltrate data to an attacker-controlled endpoint, probe internal services that are reachable from the VPC, reach the cloud instance metadata service to steal credentials, install malicious dependencies that phone home, or respond to prompt injection by calling an unauthorized destination. Isolation without egress control contains the process. It does not contain the process's consequences. Both controls are required.

A secure AI sandbox should give agent code access only to the network resources it needs. The core controls are default-deny egress, explicit allowlists, DNS controls, private networking, and per-tenant network policies.

The starting point for AI sandbox networking is to block outbound traffic by default and explicitly allow only the destinations an agent needs to reach. This limits the damage caused by unexpected or malicious code, whether an agent tries to contact an unapproved API, download a package from an unknown source, or exfiltrate data to an external endpoint.

The network policy should enforce the allowlist independently of the agent. The agent should not be able to modify its own network permissions. For workloads that need package installation or external APIs, allow only the required registries, services, and endpoints rather than granting unrestricted internet access.

An egress allowlist defines exactly where a sandbox can connect. Policies can restrict traffic by hostname, IP range, port, and protocol, depending on how much control the workload requires. A proxy can provide hostname-level controls for outbound requests, while firewall or network policies can enforce broader restrictions at the IP and port level.

For sensitive credentials, enterprises can also keep tokens outside the sandbox and use a credential brokering pattern. Instead of injecting a real API key into the agent environment, an external proxy can authenticate the request, attach the required credential, and forward it to the approved destination. This means the sandbox does not need to hold long-lived credentials that untrusted or AI-generated code could access.

DNS needs to be part of the sandbox's network policy. An agent with unrestricted DNS access can resolve unapproved domains and potentially use DNS as a channel for data exfiltration. If internal DNS also exposes names for sensitive services, unrestricted resolution can reveal information about the internal network.

DNS controls should also prevent sandboxes from bypassing the resolver through services such as DNS-over-HTTPS. Internal services should use private DNS names that resolve only within the appropriate VPC or network, rather than requiring the sandbox to connect through publicly exposed endpoints.

Sandbox-to-service traffic should use private network paths wherever possible. Databases, internal APIs, queues, and other services should be reachable through private IP addresses and DNS rather than being exposed to the public internet simply so an agent can access them.

Running sandboxes inside a VPC does not automatically give them unrestricted access to everything in that VPC. Network policies, security groups, and other controls should limit each sandbox to the specific services and subnets it needs. In a BYOC deployment, this allows enterprises to apply their existing VPC controls to sandbox workloads while keeping sensitive services off the public internet.

Multi-tenant AI platforms should apply network policies at the tenant or project level rather than using one global policy for every sandbox. Each tenant should have an explicit allowlist that determines which external endpoints and internal services its sandboxes can reach.

The same principle should apply across environments. A development sandbox may be allowed to access development databases and APIs, while a production environment should have a separate policy. This prevents one tenant or environment from using an otherwise valid network path to reach another tenant's services or sensitive infrastructure.

A simple secure AI sandbox network might look like this:

A typical architecture puts the sandbox behind a default-deny egress policy while using private networking to connect it to only the internal services it needs.

• Allowing unrestricted internet egress: An agent with unrestricted outbound access can exfiltrate data, contact attacker-controlled infrastructure, or download untrusted dependencies. Start with default-deny egress and allow only the destinations the sandbox actually needs.
• Giving every sandbox the same network policy: A global policy can allow one tenant or environment to reach another tenant's services or sensitive infrastructure. Apply policies at the tenant, project, or environment level to keep network access isolated.
• Putting internal services on public endpoints: Exposing a database or internal API through a public endpoint just so a sandbox can reach it unnecessarily increases the attack surface. Use private networking and internal DNS for sandbox-to-service communication.
• Treating VPC membership as an access grant: A sandbox being inside a VPC does not mean it should be able to reach every resource within it. Use security groups and network policies to limit access to the specific services and subnets the sandbox needs.
• Ignoring DNS when designing egress controls: IP-based egress rules are less effective if the sandbox can freely resolve and connect to unapproved domains or bypass the approved resolver. Restrict DNS resolution and design DNS policies alongside your egress controls.
• Not logging denied connections: Blocked requests can reveal prompt injection attempts, compromised dependencies, unexpected agent behaviour, or misconfigured policies. Logging denied traffic gives security teams visibility into what the sandbox tried to reach, even when the request was blocked.

Northflank is a runtime platform for running AI-agent sandboxes alongside applications, databases, and other services. It gives teams the networking controls needed to isolate sandbox workloads, restrict what they can reach, and connect them to private infrastructure.

• Sandbox isolation: Run untrusted agent code in isolated microVM-backed environments, providing the compute isolation that network policies build on.
• Network policies: Configure deny-all egress and explicit allowlists to control which services and endpoints sandbox workloads can reach at the project and workload level. This lets you apply the same network isolation principles without building the policy layer yourself
• Private networking: Connect sandboxes to applications, databases, and other services over private internal networks without requiring those services to be publicly exposed.
• BYOC and forward-deployed deployments: With Bring Your Own Cloud, sandbox workloads can run in your own AWS, GCP, Azure, or other supported infrastructure, allowing your existing VPC, subnet, and network security controls to apply. For stricter requirements, Northflank can also run within your own environment through a forward-deployed control plane, including deployments designed for limited or no external connectivity.
• Secrets management: Use secrets management to securely manage credentials used by sandbox workloads without embedding them directly into the sandbox configuration.
• Enterprise security: RBAC, SSO, and audit logging provide access control and visibility across the platform, helping teams govern who can access and manage sandbox workloads.

The advantage is that you do not need to assemble a separate networking layer around your sandbox infrastructure. Northflank brings the sandbox runtime, applications, databases, private networking, and enterprise security controls together in one platform, so you can enforce how agent workloads communicate without managing each component separately.

Secure AI sandbox networking is about giving agents the connectivity they need while limiting everything else. Default-deny egress, explicit allowlists, controlled DNS, private access to internal services, and per-tenant policies reduce the paths an agent can use to reach unrelated infrastructure or exfiltrate data.

These controls are most effective when enforced at the infrastructure layer, where they apply regardless of what code the agent generates or executes. For teams that want to run isolated AI-agent sandboxes alongside their applications and private infrastructure, Northflank provides the runtime, networking, and BYOC capabilities to build this architecture without assembling a separate sandbox networking stack.

AI sandbox networking controls what an AI agent can access over the network while it executes code. It typically includes egress policies, destination allowlists, private service connectivity, DNS controls, and network isolation between workloads or tenants.

Sandbox egress controls restrict outbound connections from an agent's execution environment. A default-deny policy blocks traffic unless a destination is explicitly allowed, reducing the risk of data exfiltration, unauthorized service access, and connections to malicious infrastructure.

They can have internet access when the agent needs it, but unrestricted access is usually unnecessary. A better approach is to allow only the domains, IP ranges, ports, or services required by the workload and deny everything else by default.

An AI sandbox can access private services through a private network or VPC connection rather than a public endpoint. Network policies, routing rules, and firewall controls should then restrict the sandbox to only the internal services it needs.

Apply network policies at the tenant, project, environment, or sandbox level so each workload receives only the destinations it is authorized to reach. For a multi-tenant platform, Tenant A's sandbox should not be able to route to Tenant B's applications, databases, or other private resources.

• How regulated enterprises can run AI-agent sandboxes securely
• How to secure AI agents in the cloud
• Best enterprise AI sandbox platforms