Open network access creates a direct exfiltration path. If the agent is prompt-injected or otherwise misled, it can write code that sends sensitive data out of the sandbox without ever exposing it in a normal tool response. That is why network controls, least-privilege data exposure, and execution logging are mandatory when code mode is enabled for agents.
Why Open Network Access Changes the Risk Profile
Once an LLM-generated program can reach the network, the sandbox is no longer just a place where code runs, it becomes a place where data can leave. That changes code mode from a local execution concern into an exfiltration concern, because any prompt injection, tool misuse, or misleading instruction can be turned into a live outbound channel. In agentic environments, that is often the real failure mode: the code itself may look harmless, but its network reach makes it able to act on stolen context.
AI Agents: The New Attack Surface report is a useful reminder that agent governance is already lagging behind deployment, and that visibility into agent data access remains incomplete in many organisations. If code can connect out freely, that gap becomes operationally expensive very quickly.
In practice, teams usually discover the problem only after a model has already produced code that sends data somewhere they did not intend.
How It Works in Practice
Open network access creates a simple but dangerous execution model: the LLM writes or modifies code, the code can make outbound requests, and the model may be able to package sensitive data into those requests without surfacing it in an ordinary tool response. That means the main control question is not only whether the code is correct, but whether it is allowed to communicate at all, where it may communicate, and what data can be reached from its runtime context.
Practically, the risk increases when the program has access to:
- session tokens, API keys, source material, or retrieved files in the same execution context
- general-purpose HTTP clients or unrestricted DNS resolution
- environment variables, mounted secrets, or internal service endpoints
- tooling that permits both code execution and network egress in one step
The safe pattern is to treat network access as an explicit capability, not a default. Where code mode is enabled, teams should bound egress to approved destinations, isolate sensitive inputs from the execution environment, and log outbound requests with enough context to reconstruct what the program attempted to send. That last point matters because exfiltration through generated code often looks like normal application traffic until the investigation stage.
OWASP Top 10 for Agentic Applications 2026 is directly relevant here because prompt injection and tool misuse are not abstract concerns, they are the conditions that turn open network access into data loss. For baseline security controls, CIS Controls v8 supports the practical requirements around access control, logging, and secure configuration that keep this kind of execution bounded.
These controls tend to break down when developers treat the sandbox as trusted enough to reuse production credentials or internal data feeds inside it.
Common Variations and Edge Cases
Tighter egress control often increases friction, so teams need to balance developer convenience against blast-radius reduction. Not every code runner needs full internet access, and not every agent needs the ability to call arbitrary hosts; current guidance suggests that most workflows are safer when the network is allowlisted and purpose-built rather than open-ended.
There are a few edge cases worth calling out. If the generated program only needs a narrow upstream API, permit that destination explicitly and block everything else. If the program is allowed to fetch external content, assume that content may be attacker-influenced and avoid giving it access to high-value secrets in the same execution context. If the code must exchange data with internal systems, separate the execution identity, the secret store, and the data plane so one compromise does not automatically become an outbound leak.
OWASP Agentic AI Top 10 fits this nuance well because the real issue is not just whether code can run, but whether the agent can combine network reach with delegated authority in ways the operator did not intend. NIST AI Risk Management Framework also applies where organisations need a governance lens for deciding which AI-enabled execution paths are acceptable.
The practical edge case is simple: once outbound access is broad enough to reach arbitrary internet services, the sandbox starts behaving like a covert relay instead of a controlled execution environment.
Risk and Threat Considerations
Open network access materially raises exfiltration, persistence, and abuse risk because the code can communicate outside the sandbox without waiting for a human to copy anything out. That makes the environment attractive for prompt injection, malicious instruction following, and hidden data staging.
Failure mechanism: The attacker or malformed prompt persuades the model to generate code that packages secrets, retrieved documents, or internal outputs into outbound requests. Once egress is allowed, normal-looking network traffic can carry the leak, bypassing the ordinary visibility of a tool response or chat transcript.
Impact: Sensitive data can leave the environment silently, including credentials, proprietary files, or internal system data. The same path can also be used to call attacker-controlled endpoints, enabling command-and-control style behaviour, unauthorized disclosure, and harder incident reconstruction.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while CIS Controls v8, NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | A2 — Prompt Injection and Instruction Hijacking | Open network access amplifies injected instructions into live outbound exfiltration paths. |
| A4 — Tool Misuse and Unauthorized Actions | Generated code with network reach can misuse tools or endpoints to leak data. | |
| Recommendation — Restrict tool and egress capabilities when prompt injection can influence generated code. Constrain agent tools and network destinations to approved, least-privilege actions. | ||
| CIS Controls v8 | 6 — Access Control Management | Least-privilege access and approved connectivity reduce code-mode blast radius. |
| 8 — Audit Log Management | Outbound requests must be logged to detect and reconstruct silent exfiltration. | |
| Recommendation — Limit code execution and egress to the minimum required permissions and destinations. Log network activity from agent runtimes and retain records for investigation. | ||
| NIST AI RMF | MAP — Measure, Analyze, and Manage | AI risk management should govern whether agent code may access external networks. |
| Recommendation — Assess agent egress risk and manage network capabilities as part of AI governance. | ||
| NIST CSF 2.0 | PR.AC — Access Control | Network reach and data exposure must be bounded by access control decisions. |
| Recommendation — Apply least-privilege access and restrict network paths for agentic execution. | ||
Practitioner Guidance
What to prioritise: Treat outbound network access as a high-impact capability and decide first whether the agent truly needs it. If the answer is yes, define the exact destinations and data types up front, because broad internet access is usually the wrong default for code that can see sensitive context.
What to verify: Confirm that egress rules, runtime logging, and secret isolation are working together rather than as separate assumptions. A control that blocks some destinations but leaves secrets in process memory still leaves a usable leak path, so verification needs to cover both network reach and data exposure.
Decision rule: If generated code can reach production systems, external APIs, or the public internet, assume it can also exfiltrate anything the runtime can read. In that case, restrict the execution context before expanding the tool set, not after a warning appears.
Practitioner takeaway: The real boundary is not code execution, it is whether the code can turn stolen context into outbound traffic with enough reach to matter.
Related resources from NHI Mgmt Group
- What happens when an LLM is given tool or data access without strong guardrails?
- What happens when LLM access is granted without validating user group membership and request content?
- What happens when attackers deploy custom malware after gaining access to a manufacturing network?
- What happens when third party access is not isolated in a network environment?
