> For the complete documentation index, see [llms.txt](https://handbook.harmonic.security/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control.md). # 3.3 Network egress control Why default-deny outbound access with administrator-owned allowlists is safer than broad internet access for AI agents. *Last reviewed: August 18, 2026* {% hint style="info" %} Network egress is the path from a compromised prompt to external data loss. Default-deny is the clean starting point for agent runtimes. {% endhint %} ## Network egress control: what security teams need to know Agents often need network access for package installs, tests, retrieval, or API calls. That need should be explicit. A broad wildcard turns network policy into a hope that the agent behaves. Good egress control distinguishes model access, package registries, approved APIs, internal services, and general browsing. Each should have its own owner and review path. ## Common network egress control security failures * Network is opened for package installs and never narrowed again. * Bash tools can reach domains that the browser tool blocks. * The allowlist covers hostnames but not the business reason. * A prompt injection drives the agent to paste data into an approved but wrong endpoint. * Logs show a request happened but not the prompt or tool chain that caused it. ## Network egress control security controls checklist * Start from default-deny for agent-controlled network access. * Allow domains by workflow, not by user preference. * Separate package registries, vendor APIs, internal APIs, and web browsing. * Block shell network tools unless they are part of an approved workflow. * Log denied and allowed outbound attempts with process, tool, domain, and session. ## Anthropic ### Overview Claude Code treats the network as an approval surface: tools that make network requests require user approval by default, and network-fetching commands such as curl and wget are not auto-approved, so a prompt-injected exfiltration attempt hits a human decision. Permission rules can deny shell network tools outright, deny rules take precedence, and managed settings enforce the rules across the organization. Claude Code cloud execution adds isolated VMs with configurable network controls. Managed Agents put the default on your side: cloud sandboxes run with network access disabled until the environment configuration enables it, so every reachable domain is the result of an explicit environment decision. Cowork remote sessions use Anthropic-managed temporary sandboxes and a proxy that mediates outbound traffic, with no private-network access by default. Cowork local browser, computer, file, and app use instead follows the desktop and target application's network path. Review remote connectors and API web tools too; they are egress paths even when they do not look like network policy. Claude Tag channel egress is proxy-mediated and default-deny, but three allow layers can admit traffic: a connection's allowed websites, the Access bundle's Domains list, and the session environment's network setting. New environments can start at Anthropic's Trusted level, which includes documented developer hosts and package registries. Pin a stricter environment when the channel should reach only explicitly approved destinations. ### Anthropic documentation * [Claude Code security](https://code.claude.com/docs/en/security) * [Configure permissions](https://code.claude.com/docs/en/permissions) * [Claude Code settings](https://code.claude.com/docs/en/settings) * [Cloud sandbox reference](https://platform.claude.com/docs/en/managed-agents/cloud-sandboxes-reference) * [Claude Managed Agents overview](https://platform.claude.com/docs/en/managed-agents/overview) * [Claude Cowork architecture overview](https://support.claude.com/en/articles/14479288-claude-cowork-architecture-overview) * [Claude Tag security and data handling](https://claude.com/docs/claude-tag/concepts/security-and-data) ### Applicable Harmonic guides for Anthropic * [Securing Claude Cowork: A Security Practitioner's Guide](https://www.harmonic.security/resources/securing-claude-cowork-a-security-practitioners-guide) ## OpenAI ### Overview Codex network defaults are conservative where it matters: in workspace-write mode, commands run without network access unless it is explicitly enabled, and Codex cloud tasks allow network during the setup phase while the agent phase runs offline by default. Managed configuration can pin these settings so a local config cannot quietly reopen egress. That makes "who enabled command network access, and why" a concrete review question rather than a hope. For ChatGPT, Lockdown Mode limits outbound web and external-service access to reduce prompt-injection data exfiltration, and admins assign it through RBAC roles. It does not affect Codex network access. Work adds another boundary: web and mobile Work use workspace cloud controls, while desktop Work follows the local Codex permission and managed-configuration plane. Review Chat, Work cloud, Work desktop, and Codex egress separately even though the new desktop app places them together. ### OpenAI documentation * [Codex sandboxing](https://developers.openai.com/codex/concepts/sandboxing) * [Codex managed configuration](https://developers.openai.com/codex/enterprise/managed-configuration) * [Agent approvals and security](https://developers.openai.com/codex/agent-approvals-security) * [Lockdown Mode](https://help.openai.com/en/articles/20001061) * [RBAC](https://help.openai.com/en/articles/11750701-rbac) * [Work Admin FAQ](https://learn.chatgpt.com/docs/enterprise/work-admin-faq) ### Applicable Harmonic guides for OpenAI * [Securing Codex Best Practice](https://www.harmonic.security/resources/securing-codex-best-practice) ## Frequently asked questions about network egress control ### Why is network egress important for AI security? Egress is usually the last step of the attack chain: a prompt injection can steer an agent, but data only leaves when the agent can reach an external endpoint. Cutting or narrowing egress therefore weakens whole classes of attack even when the injection itself succeeds. That is why several agent runtimes now ship with network access off by default. ### Should web search bypass egress policy? No. Web search, web fetch, and browser tools are egress paths with friendly names, and injected content can use them to carry data out in a query string or URL. Govern them under the same allowlist thinking as shell network tools, and log their destinations the same way. ### What belongs on an allowlist? Only domains a defined workflow requires, each with an owner, a purpose, a data class, and a review date. Separate package registries, vendor APIs, internal services, and general browsing into different entries, because they fail differently and get reviewed by different people. An allowlist entry without a recorded reason is just a hole with better paperwork. ### Should package registries be allowed? Allow them where builds genuinely require installs, but restrict to approved registries and treat install scripts as code execution, because they are. A malicious package's install script runs inside whatever network and file boundary the agent has. Where the runtime separates a network-enabled setup phase from an offline execution phase, prefer that split. ### What should egress logs capture? For network events specifically: the tool or process that made the request, destination domain, URL class, allowed or denied result, and the user, agent, and session behind it. Denied attempts are the high-signal rows, because they show what an agent tried that policy stopped. Sandbox-mode and file-event logging are covered in 3.1 and 3.8. ## Applicable regulations and frameworks | Governance page | Relationship to this article | | --------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- | | G.1 Map your controls to NIST AI RMF and CSF 2.0 | This article supplies implementation evidence for the NIST AI RMF and matching NIST CSF 2.0 outcomes. | | G.3 DORA and AI resilience in financial services | Conditional: for a DORA-regulated workflow, this supports ICT containment, resilience, continuity, and recovery. | | G.5 SANS Critical AI Security Guidelines mapping | This article implements relevant SANS Deployment Strategies and Inference Security guidance. | | G.6 Write an AI Acceptable Use Policy that holds up | This article supplies a technical or process control used to enforce the acceptable-use policy. | | G.9 HIPAA controls for AI systems handling PHI | Conditional: for a workflow handling ePHI, this supports HIPAA technical access, integrity, transmission, availability, and audit safeguards. | *G.2, G.3, G.4, and G.9 are conditional mappings. They apply only when the deployment is within the legal or regulatory scope described on the linked governance page.* ## Related handbook guidance * [3. Runtime, Sandbox & Autonomy](/handbook/3.-runtime-sandbox-and-autonomy.md) * [3.4 Internet access and browser automation](/handbook/3.-runtime-sandbox-and-autonomy/3.4-internet-access-and-browser-automation.md) * [3.1 What Even is an AI Sandbox?](/handbook/3.-runtime-sandbox-and-autonomy/3.1-what-even-is-an-ai-sandbox.md) * [5.2 Data exfiltration via tools and connectors](/handbook/5.-threats-and-adversarial/5.2-data-exfiltration-via-tools-and-connectors.md) * [6.2 OpenTelemetry for AI runtime visibility](/handbook/6.-observability-audit-and-evidence/6.2-opentelemetry-for-ai-runtime-visibility.md) --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://handbook.harmonic.security/handbook/3.-runtime-sandbox-and-autonomy/3.3-network-egress-control.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.