Because network policies govern destinations, not intent. An agent that can execute npm install, git, gh or node still has authorised paths that can be repurposed for credential theft, repository tampering and persistence, especially when the attacker controls inputs or can poison the agent’s configuration.
Why network policies reduce exposure but do not eliminate it
Network controls can stop an agent from reaching arbitrary hosts, but they do not remove the authority already embedded in the local runtime. If the sandbox can still run trusted developer tools, read mounted files, or invoke package and repository workflows, an attacker who shapes inputs can turn those legitimate paths into a theft or tampering channel. The residual risk is therefore inside the permitted toolset, not just on the network edge.
That distinction matters because many agent failures happen without any policy bypass. An agent allowed to execute shell commands may be able to inspect environment variables, read cached credentials, or use repository access that was supposed to support development tasks. The AI Coding Agents Security Guide is useful here because it treats sandboxing as one layer, not a complete boundary, and shows how secrets in context and over-scoped tokens remain attack paths.
Practically, the question is not whether egress is restricted, but whether the remaining local permissions are safe if the agent is misled. If the toolchain can install code, modify repositories, or access developer credentials, then the agent can be repurposed even when every outbound connection is policy-compliant.
How legitimate tools become the attack path
Residual risk appears when the sandbox preserves functions that are useful for normal work but dangerous under attacker control. Commands such as npm install, git, gh or node are not simply “allowed programs”, they are access multipliers that can fetch code, alter state, interact with hosting platforms, and inherit whatever credentials are already present. That is why an agent can be compromised through configuration poisoning, malicious package references, or prompt-driven misuse without ever needing a forbidden network destination.
This is the same pattern seen in agent authorization failures: an allowed action becomes harmful because it is too broad, too persistent, or too loosely scoped. AI Agent Authorisation Guide is relevant because it frames per-action authorisation, task-scoped access and human approval as the controls that narrow what a sandboxed agent may do when its inputs are not trustworthy.
It also explains why sandboxing alone does not stop repository tampering. If the agent can create commits, open pull requests, or push changes using an attached token, a hostile instruction can turn the authorised development workflow into persistence or supply-chain compromise. The exploit is not “break out of the sandbox”; it is “use the sandbox exactly as designed, but for the attacker’s objective.”
What practitioners should verify before trusting an agent sandbox
Two sandboxes can look similar and have very different risk profiles. The useful test is whether the agent can still reach anything that matters if it is manipulated: source code, package managers, secret stores, cloud credentials, CI variables, repo write access, or local caches. If any of those are present, network policy is only constraining one dimension of the blast radius.
The most valuable verification is to trace the agent’s effective authority end to end: what files it can read, what binaries it can execute, what tokens are injected, what identity those tokens represent, and what irreversible actions those tokens can trigger. Zero Trust for AI Agents supports that approach by treating each request as something to verify, not something to trust because it arrived inside a sandboxed environment.
When those checks are done well, the remaining risk becomes measurable rather than assumed. If the agent can only perform short-lived, narrowly scoped actions with no reusable secrets and no direct path to production changes, the residual risk is much lower. If it can install dependencies, alter code and inherit developer trust, the sandbox is only containing the network path, not the security problem.
Risk and Threat Considerations
Residual risk persists because an attacker does not need unconstrained internet access when the agent already has enough local authority to act on behalf of a trusted workflow. The dangerous condition is a permitted toolchain with reachable secrets, writable repositories or durable credentials, especially when attacker-controlled inputs can steer the agent into using them.
Failure mechanism: The sandbox blocks some destinations, but the agent still has authorised local actions that can be repurposed for credential theft, code tampering or persistence through package installs, repository operations or config poisoning.
Impact: A compromise can stay inside policy boundaries while still producing real harm, including stolen tokens, altered source, poisoned dependencies and continued access through legitimate developer pathways.
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 and OWASP API Security Top 10 address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | ASI03 — Identity & Privilege Abuse | Agent sandboxes still permit harmful use of granted authority. |
| Recommendation — Restrict agent permissions per action and revoke standing privilege. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Residual risk depends on whether reusable credentials remain reachable. |
| AC-6 — Least Privilege | Sandboxed tools remain dangerous when excess local authority exists. | |
| Recommendation — Limit secret lifetime and rotate credentials exposed to agents. Remove unnecessary write, install, and token access from the agent runtime. | ||
| NIST Zero Trust (SP 800-207) | ZT-NIST-207 — Zero Trust Architecture | The question is about trusting permitted requests inside a constrained environment. |
| Recommendation — Verify each agent request and do not trust sandbox placement by itself. | ||
| CIS Controls v8 | CIS-6 — Access Control Management | The issue is excessive effective access, not only outbound connectivity. |
| Recommendation — Review and remove paths that let agents act with broader access than intended. | ||
| OWASP API Security Top 10 | API5 — Broken Function Level Authorization | Authorised functions can still be abused when the caller has too much power. |
| Recommendation — Enforce function-level checks on agent actions that can change state. | ||
Practitioner Guidance
What to verify: Check whether the agent can reach any reusable secret, writable repo path or production-facing token through its allowed tools. If yes, treat the sandbox as partial containment, not as a final control.
Decision rule: If an action can change code, fetch dependencies or authenticate as a human or service principal, require explicit approval or a narrower delegated credential before allowing it to run unattended.
What good looks like: The agent has only task-scoped, short-lived authority, cannot see long-lived secrets, and cannot convert a successful prompt injection into durable access or code changes.
Practitioner takeaway: The real control objective is to minimize the consequences of a successful agent prompt or config manipulation, not to assume that network enforcement alone makes the workspace safe.
Related resources from NHI Mgmt Group
- Why do AI agent sandboxes still leak secrets even when egress policies are enforced?
- Why do permitted AI agent actions still create security risk even when RBAC, admission control, and network policy all pass?
- Why do AI agents create compliance risk even when policies exist on paper?
- Why do AI agent deployments create new risk even when the underlying models are well secured?