Only if they can prove the use case is low risk, tightly internal, and not exposed to arbitrary user input. For any public or semi-public execution path, the safer choice is to move to isolation-first design because repeated bypasses show that the model itself is fragile.
Why This Matters for Security Teams
A critical escape flaw in vm2 is not just a library bug, it is an architectural warning sign for any team letting untrusted code run inside a shared application boundary. Once the sandbox can be bypassed, the question shifts from “is the code isolated?” to “what can it reach if it is not?” That matters because untrusted execution paths often inherit secrets, network access, and service account privileges that were never meant for hostile input. The NHI Mgmt Group notes that 30.9% of organisations still store long-term credentials directly in code in its Ultimate Guide to NHIs, which turns a sandbox escape into a credential exposure event. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls still points to strong separation, least privilege, and defensive depth rather than trust in a single control. In practice, many security teams discover the blast radius only after a payload has already reached internal APIs, metadata endpoints, or runtime secrets.How It Works in Practice
The safe response to a vm2 escape is to stop treating the sandbox as the primary control and move to isolation-first design. That usually means running untrusted code in a separate process, container, microVM, or dedicated worker with tightly scoped workload identity, short-lived credentials, and explicit network policy. Static IAM is a poor fit here because untrusted code is dynamic by nature and may behave differently on each request. The practical goal is to make the execution environment disposable, observable, and unable to inherit broad privileges by default.Security teams should evaluate three layers together:
- Execution isolation: separate runtime, separate OS boundary where possible, and no direct access to application secrets.
- Identity and secrets: issue just-in-time credentials only for the task, then revoke them immediately after completion.
- Policy enforcement: evaluate every request at runtime using policy-as-code rather than assuming a pre-approved code path.
This is consistent with the identity and lifecycle emphasis in the Ultimate Guide to NHIs, where rotation, visibility, and offboarding are treated as operational controls, not optional hygiene. It also aligns with NIST SP 800-53 Rev 5 Security and Privacy Controls, especially where access enforcement and system boundary protection are concerned. For agent-like or code-execution workflows, the emerging best practice is to bind authority to the specific task and context, not to the code package itself. These controls tend to break down when untrusted code runs on the same host with shared filesystem mounts, shared service credentials, and outbound network access to internal systems because one escape can collapse all three layers at once.
Common Variations and Edge Cases
Tighter isolation often increases latency, operational complexity, and cost, so organisations have to balance safer execution against the performance profile of the workload. There is no universal standard for this yet, but current guidance suggests the risk decision should depend on who can submit code, what data the code can touch, and whether the runtime has any path to secrets or internal services. A low-risk internal utility with code review and no arbitrary user input is very different from a public plugin runner, SaaS extension point, or LLM tool execution path.One common edge case is “trusted untrusted code,” where teams assume a partner, customer, or internal developer is safe because the source is known. That assumption fails if the code path is still reachable by arbitrary input, because the attack surface is the execution boundary, not the author. Another edge case is environments that already use container isolation but share host credentials, mounted vault tokens, or broad outbound connectivity. In those setups, the container is only a partial control. For broader NHI governance context, the Ultimate Guide to NHIs is useful for separating credential management from runtime containment. The practical rule is simple: if the code can be triggered by untrusted input and can reach anything valuable, vm2 should not be the only thing standing between the attacker and the estate.
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, OWASP Non-Human Identity Top 10 and CSA MAESTRO address the attack and risk surface, while 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 | Sandbox escape risk maps to weak runtime containment for autonomous code. |
| OWASP Non-Human Identity Top 10 | NHI-03 | Escapes often expose long-lived secrets tied to non-human identities. |
| CSA MAESTRO | SG-3 | Agentic workloads need isolation and bounded authority before tool execution. |
| NIST AI RMF | AI risk governance requires runtime controls for unpredictable code behaviour. | |
| NIST CSF 2.0 | PR.AC-4 | Least-privilege access is central when sandbox escapes can expose internal resources. |
Eliminate static secrets from code paths and rotate any exposed NHI credentials immediately.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 2, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
