infrastructureL3 SystematicAgent Runtime & Sandboxing

Network isolation: agent can't see production

Network isolation for agents means that the agent's execution environment has a constrained network configuration: it can reach the systems it needs for development work (GitHub, p

·Isolated agent environments (devbox model) prevent agents from accessing other projects
·Pre-warmed containers with codebase at HEAD and dependencies installed are available
·Network isolation prevents agents from reaching production systems

·Container warm pool size matches team's agent usage patterns
·Network isolation rules are tested and audited quarterly

Evidence

·Devbox configuration showing per-project isolation boundaries
·Pre-warmed container pool metrics (pool size, warm hit rate, cold start rate)
·Network policy configuration (Kubernetes NetworkPolicy, firewall rules) blocking production access

What It Is

Network isolation for agents means that the agent's execution environment has a constrained network configuration: it can reach the systems it needs for development work (GitHub, package registries, CI APIs, staging environments) but cannot reach production systems, internal infrastructure, or sensitive services that it has no business touching. The agent is blocked from production databases, production APIs, internal admin interfaces, and any other systems where an accidental or malicious connection would cause harm.

The technical implementation uses standard network controls: Docker network policies that restrict outbound traffic, Kubernetes NetworkPolicy resources that whitelist permitted destinations, firewall rules on the host network, or egress filtering via a proxy. The mechanism does not matter much at L3 - what matters is that the boundary exists and is enforced by infrastructure rather than by agent behavior. An agent that is simply told "do not connect to production" can still connect to production if it reasons incorrectly or is given a task that leads it there. An agent whose network access physically does not include production routes cannot connect regardless of what it is told.

The practical implementation for most teams starts with an allowlist of outbound destinations: the version control host, the package registry for the project's language, the CI API, and specific staging environment endpoints. Everything else is denied by default. This allowlist is tighter than what developers need in their full environment, but it is appropriate for an agent that has a specific, bounded task.

Network isolation is particularly important because it is the control that prevents the worst class of agent accidents: an agent that is refactoring a service accidentally makes an API call to a production endpoint, causing a live transaction or data mutation. These accidents are not hypothetical - they happen when agents work in environments where production endpoints are reachable and the agent's context includes production credentials or URLs.

Why It Matters

Prevents accidental production mutations - an agent refactoring code that contains production API calls cannot accidentally trigger those calls if the network policy blocks the production endpoints
Contains the blast radius of credential mistakes - if an agent somehow gets hold of a production credential, network isolation prevents it from using that credential to reach production systems
Enables agents to work safely with real endpoint URLs in code - developers can let agents read and modify code that contains production API URLs without risk, because the agent's network cannot reach those URLs even if it tries
Simplifies compliance - demonstrating that agents cannot access production systems is a clear, auditable control that satisfies the "AI systems must not have access to production data" requirements in most compliance frameworks
Creates a clear boundary for code review - when an agent's network is isolated, code reviewers can focus on code quality rather than worrying about whether the agent might have accidentally touched production during its task

Getting Started

Map what agents actually need to reach - For each agent use case, list the specific external hosts the agent needs: github.com for git operations, registry.npmjs.org for package installs, api.anthropic.com for the LLM API call, and specific staging service hostnames. This list is your allowlist.
Identify what agents must not reach - Document your production network topology: production database endpoints, production API gateways, internal admin UIs, secrets management systems (Vault, AWS Secrets Manager), and internal service meshes. This is your denylist - or more precisely, the set of hosts not in your allowlist.
Implement Docker network isolation - Create a Docker network configuration that uses iptables rules to allow outbound traffic only to the allowlisted destinations. Use a restricted Docker network mode (not host mode) to prevent the container from seeing the host's network interfaces.
Test the isolation with adversarial probes - After implementing network isolation, test it: from inside an agent container, try to reach curl https://your-production-db-endpoint. The connection should time out or be refused. Test several production endpoints to verify the policy is comprehensive.
Allow DNS resolution carefully - DNS queries reveal information about what the agent is trying to reach even if the TCP connection is blocked. Configure the agent's DNS resolver to use a controlled resolver that returns NXDOMAIN for internal production hostnames, preventing name resolution for production endpoints.
Log blocked connections - Configure the network policy to log denied connection attempts. A log of what the agent tried to reach that was blocked is useful for two purposes: debugging (agent failing because it cannot reach something it needs) and security monitoring (agent trying to reach something suspicious).

Tip

Implement network isolation at the container level, not just the agent level. Do not rely on the agent software having a built-in "do not call production" setting. The network boundary should be enforced by infrastructure that the agent cannot modify. Defense in depth means both the agent's instructions and the network policy agree on what is off-limits.

6 steps to get from here to the next level

Common Pitfalls

Allowlisting by IP address rather than hostname. Production services often share IP ranges with staging services, CDN endpoints, or cloud provider infrastructure. An allowlist based on IP addresses will either be too permissive (allowing production because it shares IPs with staging) or too restrictive (blocking staging because it shares IPs with production). Use hostname-based allowlists with DNS control, not IP-based allowlists.

Not isolating egress to the LLM API. Agents connect to the LLM API (Anthropic, OpenAI, etc.) to function. This is a permitted outbound connection, but it is also a channel through which sensitive data could be exfiltrated in the agent's prompt. While you must allow LLM API egress, you should be aware that the agent's conversation includes file contents and consider whether sensitive files should be excluded from the agent's context.

Implementing network isolation only in production CI, not in local development. Developers running agents locally bypass CI-level network controls. The network isolation that protects your staging environment from accidentally-triggered API calls should apply to local agent execution as well. Use Docker network policies consistently regardless of where the agent runs.

Breaking agent functionality with overly restrictive allowlists. An agent that cannot reach GitHub cannot push commits. An agent that cannot reach the npm registry cannot update dependencies. An overly restrictive network policy that breaks common agent workflows will lead developers to disable network isolation entirely rather than tune the allowlist. Start with a generous allowlist and narrow it based on observation, not assumptions.

No refresh process for the allowlist. Infrastructure changes - new staging environments, new API endpoints, new package registries. The allowlist needs to be a living document with an owner and a regular review cycle. An allowlist that is set once and never updated will accumulate gaps as the infrastructure evolves.

Mistakes teams actually make at this stage - and how to avoid them

How Different Roles See It

BobHead of Engineering

Bob's team recently had a near-miss: a developer was using an agent to refactor an API client and the agent, while testing code, made a real API call to a production webhook endpoint. No data was corrupted, but the unexpected API call triggered a monitoring alert and caused a 30-minute investigation. Bob wants to prevent this class of incident but does not know where to start.

What Bob should do: Bob should treat the near-miss as a concrete justification for network isolation. He should ask the infrastructure team to design and implement network isolation for all agent environments within the next sprint. The immediate measure (days, not weeks) is to ensure that the staging environment's firewall rules explicitly deny inbound traffic from agent execution environments. The medium-term measure (weeks) is to implement outbound network policies on agent containers that enforce the allowlist. Bob should also create a runbook for future near-misses: if an agent makes an unexpected external call, what is the incident response process?

What Bob should do - role-specific action plan

SarahProductivity Lead

Sarah has been worried about a pattern she is seeing: developers are overly conservative about which tasks they give to agents because they are concerned about accidental API calls or database writes. This conservatism limits agent use to "safe" tasks (code generation, documentation) and excludes tasks that touch external services. Network isolation would make it safe to use agents for a wider range of tasks.

What Sarah should do: Sarah should survey developers to understand specifically which agent tasks they are avoiding due to network safety concerns. The survey results will likely show a clear category: "tasks that involve code which calls external services." Sarah should then work with infrastructure to implement network isolation and run a pilot where developers specifically use agents for the previously-avoided tasks in isolated environments. Measuring the expansion of agent-assisted task coverage is a direct productivity metric that justifies the infrastructure investment.

What Sarah should do - role-specific action plan

VictorStaff Engineer - AI Champion

Victor has been implementing network isolation in his local agent setup using Docker network policies. He has a working configuration that allows outbound connections to GitHub, the npm registry, and the team's staging environment, while blocking everything else. He tested it by running an agent on a payment service codebase and verifying that the agent could not reach the production payment gateway even when it tried to run integration tests.

What Victor should do: Victor should package his Docker network configuration as a reusable template and document the testing methodology he used to verify isolation. The documentation should cover: how to define the allowlist for a project, how to test that production endpoints are blocked, and what to do when the agent fails because a new endpoint needs to be added to the allowlist. Victor should also raise the question of consistency: the network policy he runs locally should be the same policy that runs in CI. If there is a gap between local and CI isolation, that gap is a security hole. Victor should propose making the network policy configuration a first-class artifact in the repository, versioned alongside the agent runtime configuration.

What Victor should do - role-specific action plan