Default Network Boundaries in AI Agent Sandboxes: Codex, ChatGPT Work, and Claude Code Compared

The Security Defaults Nobody Talks About

When developers deploy AI coding assistants, they typically focus on model capabilities, code quality, and response speed — while overlooking a critical security dimension: what external network resources can the agent sandbox access before you configure any policies?

According to the technical analysis discussed here, Codex, ChatGPT Work (enterprise collaboration scenarios), and Claude Code make five distinct choices when it comes to outbound network access. In other words, even among tools that all "write code with AI," the way they connect to the outside world out of the box is fundamentally different — some are more open, some more restrictive, and their boundaries vary considerably.

This matters because outbound access directly affects data exfiltration risk, supply chain attack surface, and compliance boundaries. An agent with unrestricted external network access could theoretically transmit sensitive code or credentials to unintended destinations while executing a task. Conversely, a strictly sandboxed environment might hamper productivity by blocking access to necessary package registries or APIs.

Outbound Network Access refers to the ability of processes running inside a sandbox to initiate connections to external endpoints — for example, downloading npm/PyPI packages, calling external APIs, or accessing code hosting platforms like GitHub. Compared to inbound access (external connections entering the sandbox), outbound access poses a more subtle risk: it occurs during task execution, often without the user's awareness. Attackers can exploit this through supply chain attacks — embedding malicious code in dependencies — or by manipulating agents into calling compromised external services, using legitimate outbound channels to exfiltrate sensitive data. In traditional CI/CD security practice, strictly limiting outbound access in build environments is a baseline requirement. The same logic now applies to AI coding assistants' execution sandboxes.

Three Tools, Three Different Tradeoffs

The core observation in the original analysis is this: these three tools give fundamentally different answers to the question of "what can the agent reach" — and these differences exist before you touch any configuration.

For developers and security teams, this means you cannot assume all AI coding tools follow the same network policy. Codex, as an environment built for code generation and execution, must balance functionality against isolation when performing networked tasks. ChatGPT Work, designed for enterprise collaboration, typically comes with expectations of more explicit organizational-level controls. Claude Code, Anthropic's coding assistant, operates within its own distinct set of network access boundaries.

The analysis emphasizes three things to pay attention to:

• What each tool permits by default (before any configuration is applied)
• What the official documentation publicly states (documented behavior)
• Where the boundary breaks down or isn't covered (where the boundary does not reach)

The third point deserves particular scrutiny. Between the policies stated in documentation and the actual boundaries enforced at runtime, there is often a gray zone — access paths that are neither explicitly permitted nor explicitly denied. This is precisely the blind spot most easily overlooked in security assessments.

Why Defaults Matter More Than Configuration

A fundamental principle in security engineering: default configurations determine the actual security posture of the vast majority of users. Most teams don't audit and tighten every network policy — they use whatever ships out of the box. This means a vendor's default choices effectively define the risk baseline for the entire ecosystem.

If an AI agent allows broad outbound access by default, then even if tightening options exist, most users will remain exposed to elevated risk. Conversely, tools that default to strict controls may introduce some initial friction, but provide a much better safety net overall.

For organizations handling sensitive codebases, internal API credentials, or compliance-bound data, understanding these default differences is not optional. Before integrating any AI coding assistant into a production or semi-production environment, you should be able to clearly answer:

• What domains or IPs does this agent connect to during task execution?
• Can those connections be audited and intercepted?
• Do the isolation boundaries promised in the documentation hold across all execution paths?

This principle is known in security as Secure by Default — one of the cornerstones of zero-trust architecture and defense-in-depth. Its core logic: the real-world effectiveness of a security policy is determined by the weakest deployed instance, not the most hardened one. Research consistently shows that the vast majority of security incidents in enterprise environments occur on systems using default or minimal configurations, not those that have been carefully tuned. For AI agents, this problem is even more acute — the execution logic of an agent is often a black box to the user, making it difficult to determine whether a given task triggered unexpected network connections simply by observing behavior. This makes "secure by default" not just a matter of convenience, but the foundation of trust in the entire toolchain.

Practical Recommendations for Users

While the original material focuses on comparing facts, it's possible to distill actionable guidance from these observations.

Verify, don't assume: Don't rely on marketing materials or intuition to judge a tool's network behavior. Read the official documentation, and test outbound connections in a controlled environment.

Focus on where boundaries fail: Documented policies are only a starting point. Real risk often hides in paths that documentation doesn't cover. Security assessments should specifically probe these gray zones.

Match tools to your use case: If your scenario demands strict data isolation, prioritize tools with conservative defaults and clearly defined boundaries. If development velocity matters more and data sensitivity is lower, a relatively permissive default may be acceptable.

As AI coding assistants become deeply embedded in software development workflows, agent network access boundaries are emerging as a security issue that can no longer be ignored. Understanding what each tool can reach before you configure anything is the first step toward building a trustworthy AI development environment.