isolated-vm is a Node.js package that creates separate JavaScript isolates at the engine level. It is designed to provide stronger separation than Node’s built in vm module, making it more suitable for running untrusted code with tighter control over memory, CPU, and host access.
Expanded Definition
isolated-vm is best understood as a security-oriented execution primitive for Node.js that places JavaScript isolates closer to engine-level separation than the built-in vm module. That distinction matters: the package is used when developers want to run untrusted or semi-trusted code with tighter limits on memory, CPU consumption, and direct access to host objects. It is not a complete sandbox by itself, and it does not replace process isolation, container hardening, or application-level policy.
Definitions vary across vendors and community write-ups because the term is often used loosely to mean any “safer vm,” but in practice isolated-vm describes a specific library and execution model rather than a general security category. For security teams, the key question is whether the isolate boundary meaningfully reduces blast radius when code is user-supplied, plugin-driven, or generated at runtime. The most common misapplication is treating isolated-vm as a full trust boundary, which occurs when teams expose host capabilities through shared objects, permissive bridges, or unsafe serialization paths.
Examples and Use Cases
Implementing isolated-vm rigorously often introduces engineering friction, because tighter separation usually means more explicit data passing, more careful error handling, and less convenience when code needs host services. That tradeoff is often justified when the alternative is executing third-party logic inside the main application process.
- Running customer-authored JavaScript formulas or rules in a SaaS product while limiting access to internal state and secrets.
- Executing plugin code in a server-side workflow engine where each plugin needs CPU and memory constraints to reduce noisy-neighbor risk.
- Evaluating generated JavaScript from an LLM-assisted coding feature, where the isolate is used as a containment layer before results are accepted.
- Building a multi-tenant automation platform that must separate tenant-supplied scripts without giving them direct access to process internals.
- Testing untrusted snippets in a controlled environment before promoting them into a broader runtime. For broader context on governance and control objectives, NIST Cybersecurity Framework 2.0 remains a useful reference point.
Why It Matters for Security Teams
isolated-vm matters because many incidents begin with code that was assumed to be “just a script” or “just a plugin.” Once untrusted logic can execute inside the application stack, attackers may try to abuse object references, resource exhaustion, prototype manipulation, or indirect access paths to reach data and services that were never meant to be exposed. In that sense, isolated-vm is part of a broader defensive pattern: reduce privilege, constrain execution, and make host interaction explicit.
This is especially relevant in environments that combine JavaScript extensibility with AI-assisted automation, where generated code or third-party tools can change quickly and escape normal review assumptions. NHI Management Group treats that as an identity and access problem as much as a code execution problem, because the isolate boundary only helps if adjacent credentials, tokens, and runtime permissions are also tightly controlled. Security teams should evaluate whether the package’s isolation model matches the actual threat, then pair it with process-level containment and strict input validation. Organisations typically encounter the real cost of weak isolation only after a plugin, script, or generated snippet causes a production incident, at which point isolated-vm becomes operationally unavoidable to address.
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 Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST AI RMF and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.AC-3 | Access enforcement is relevant when code needs constrained host interaction. |
| NIST AI RMF | AI RMF helps govern generated code and tool-using automation that may run in isolates. | |
| OWASP Agentic AI Top 10 | Agentic AI guidance applies when generated or autonomous code is executed in a sandbox. | |
| OWASP Non-Human Identity Top 10 | NHI controls matter when isolates still need secrets, tokens, or service credentials. | |
| NIST SP 800-53 Rev 5 | SC-39 | Process and runtime isolation controls map directly to sandboxed execution boundaries. |
Use technical isolation controls to separate untrusted code from sensitive host functions.
Related resources from NHI Mgmt Group
- When should organisations treat a VM compromise as an identity incident?
- Why do SaaS breaches create outsized blast radius compared with isolated app compromise?
- What is the difference between shared IAM services and tenant-isolated IAM?
- What breaks when authentication services are reused across connected and isolated environments?
