Because the agent may still have writable or relay paths that the local sandbox view does not expose. A GET endpoint that writes, DNS tunnelling, shared storage or a public web service can all become covert exits. Verify restrictions from outside the sandbox and treat every writable path as potential egress.
Why inside-the-sandbox checks miss the real egress path
An agent sandbox can look closed from the inside and still leak outward if the environment exposes a path that is not obvious to the local control plane. That is why egress reviews that only inspect the sandbox’s own view often miss writable endpoints, indirect relay channels, and services that can turn ordinary requests into exfiltration paths.
What matters is not only whether the sandbox can open a raw outbound socket. A GET request that triggers server-side work, DNS lookups that carry data, shared object stores, or a public web service with write semantics can all become covert exits even when the sandbox policy appears tight at the process boundary.
That gap is especially common when teams equate “no direct network access” with “no egress.” An agent may still be able to encode data into side effects, route traffic through a trusted integration, or use a platform feature that was allowed for convenience and later becomes an escape hatch.
How writable and relay paths become covert exits
The failure mode is usually a mismatch between the enforcement point and the actual data path. Local sandbox rules can block obvious sockets, but they do not automatically neutralize every writable destination the agent can reach through tools, APIs, caches, queues, object storage, or browser-like interactions.
This is why verification has to follow the full chain, not just the sandbox boundary. A request that looks like harmless output from inside the system may still produce externally visible state, and that state may be readable by an attacker-controlled endpoint or by a third party outside the control boundary.
In practice, the dangerous paths are the ones that can both accept agent-controlled input and surface that input somewhere the defender does not monitor. That includes write-only endpoints, file drops into shared volumes, DNS-based data leakage, and integrations that proxy outbound traffic under a legitimate service identity.
Why the test must be run from outside the sandbox
Security teams should validate egress from the outside because the inside view is inherently partial. The sandbox can accurately report what it believes it can reach while still hiding relay routes, inherited permissions, network mediation layers, or platform-managed egress that bypasses the local policy check.
That external test should ask a simple question: what can an attacker actually exfiltrate if the agent is allowed to write, not just what can it directly connect to? The answer often changes once you include shared infrastructure, downstream processors, and systems that transform a request into an outbound transaction.
For agent sandboxes, the safest assumption is that any writable path can become a communications channel until you have proved otherwise from the outside. That mindset is more reliable than trying to enumerate every possible covert path from within the same constrained environment you are trying to distrust.
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 addresses the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI02 — Tool Misuse | Agent sandboxes fail when tools can be abused as covert exits. |
| ASI03 — Identity & Privilege Abuse | Relay paths and writable services often work through overbroad agent authority. | |
| ASI07 — Insecure Inter-Agent Communication | Covert exits often ride trusted communication channels between components or agents. | |
| Recommendation — Constrain tool behavior so agent actions cannot create unintended outbound effects. Limit agent privilege so write-capable paths cannot be used for exfiltration. Authenticate and constrain inter-agent channels to prevent data leakage through trusted links. | ||
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | The issue is failure to enforce and validate boundaries at the true egress points. |
| AC-4 — Information Flow Enforcement | The question is fundamentally about controlling which data flows can leave through writable paths. | |
| AU-2 — Event Logging | Detecting covert exits requires observable evidence from tool and write actions. | |
| Recommendation — Enforce boundary controls at every real exit path, not only the sandbox edge. Apply information-flow rules to block unauthorized outbound data movement. Log agent write actions and outbound effects so suspicious exits can be reconstructed. | ||
Practitioner Guidance
What to verify: Test egress from an external vantage point and include write paths, not only outbound connections. If the agent can influence DNS, storage, webhooks, queues or shared services, treat those as candidate exits until you have evidence they cannot carry data off-box.
Decision rule: If a control only proves “the sandbox cannot open a socket,” do not treat it as an egress control. Require evidence that the agent cannot cause observable external state changes through any writable or relayed channel.
What practitioners underestimate: The most common blind spot is assuming a benign HTTP method or internal integration is safe because it is not labeled as egress. In agent systems, write capability is often the real boundary, not the network ACL.
Practitioner takeaway: Egress control for agents is only credible when it is validated against the full external effect of the sandbox, not the sandbox’s own internal idea of connectivity.
Related resources from NHI Mgmt Group
- Guide: AI Coding Agents Security Guide
- Why do AI agent sandboxes still leak secrets even when egress policies are enforced?
- How should security teams handle credentials inside AI coding agent sandboxes?
- Where does agent authorisation fail if scope is checked only at login?
- Why do living-off-the-land attacks work inside agent sandboxes?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 22, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org