Network isolation: agent can't see production

The accidental Claude Code source-map leak (v2.1.74-2.1.88) revealed Anthropic's internal permission model: granular per-tool, per-domain, per-command policies that gate every agent action. Vendors are now exposing similar configuration knobs - use them. Network isolation at the firewall is necessary but not sufficient; combine with per-tool MCP RBAC (which tools can the agent call) and per-domain network allowlists (what URLs can MCP servers reach). The "agent can't see production" rule is much stronger when enforced at three layers - network, MCP authorisation, and tool permission - than at any single one.

A May 2026 development is that the agent's own config files became a persistence and attack surface, so isolation must now extend to hardening them. The Mini Shai-Hulud worm (CVE-2026-45321, CVSS 9.6; 170+ npm and PyPI packages, 518M+ weekly downloads) propagated by writing Claude Code hooks into ~/.claude/settings.json - so treat that file and IDE agent configs as security-sensitive, monitored assets rather than throwaway dotfiles. Note too the rise of classifier-gated sandboxed execution as a default: Cursor 3.6 Run Mode (May 29) sandboxes Shell, MCP and Fetch operations out of the box.

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.

• 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

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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).

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.