Node’s Permission Model Is a Seat Belt, Not an AI Code Sandbox

The answer: keep the flag, move the trust boundary

Use Node’s permission model to make accidental authority visible and to reduce what trusted code can do by default. Do not describe a Node process started with --permission as a sandbox for AI-generated or adversarial code. The project’s own documentation says the feature does not protect against malicious code and describes it as a seat belt. That sentence should control the architecture review.

For generated code, put the enforceable boundary outside the guest runtime: a dedicated operating-system identity plus a hardened container, sandboxed process, microVM or remote executor appropriate to the consequence. Deny network egress by default, mount only staged inputs, expose outputs through a narrow exchange directory, omit ambient credentials, cap CPU, memory, processes and time, and destroy the environment after the run. --permission can remain inside that boundary as another diagnostic and defense layer.

The surprising result was not a bypass—it was the documented contract

The flag feels like a sandbox interface. Starting Node with --permission denies filesystem access, process creation, worker threads, native addons, WASI and the inspector unless the corresponding permission is granted. Filesystem flags accept paths and wildcards. process.permission.has() exposes checks to application code. Since Node 22.13.0 and 23.5.0, the feature is marked Stable.

But API stability is not a security-strength claim. In the first two paragraphs of the pinned permissions page, Node says it trusts code it is asked to run, says malicious code can bypass the model, and frames the control as protection against trusted code unintentionally using undeclared resources. The pinned security policy is equally direct: JavaScript, WASM, native code and dependencies are trusted and inherit the execution user’s privileges. A hostile generated program is outside that threat model before a test begins.

Node 26.7.0 turns permissions into a dry run, not a different sandbox

The v26.7.0 release note explicitly calls out documentation for --permission-audit, and the permissions docs now define two operational modes. Enforce mode denies undeclared access with ERR_ACCESS_DENIED. Audit mode performs the same checks but publishes violations through node:diagnostics_channel and continues execution. That is operationally useful because it lets teams inventory what a workload asks for before they flip the deny switch.

I verified the Darwin arm64 tarball against SHASUMS256.txt and reran the local fs-read probe. In my test script, both audit and enforce runs emitted node:permission-model:fs for /etc/passwd; audit mode printed READ_OK, while enforce mode raised ERR_ACCESS_DENIED. The new mode therefore improves rollout ergonomics and observability, but it does not move the trust boundary out of Node. Hostile code is still only contained when the outer runner constrains the whole process tree and its I/O.

Chronology: experimental restriction became stable without becoming a hostile-code boundary

Node introduced the permission model in v20.0.0. Pull request 56201, titled “stabilize permission model,” merged on December 12, 2024; the documentation records stable status in v22.13.0 and v23.5.0. The exact runtime in our environment, v24.10.0, was released October 8, 2025. At retrieval, Node’s release index also contained newer v26 releases, so this report deliberately does not generalize our observed behavior to all versions.

The important continuity is the documented scope. Stabilization made a useful capability ready for supported use. It did not remove the seat-belt warning, add a claim of containment against malicious code, or make every operating-system authority a Node permission. Teams should version-pin both the runtime and the security assumption: “Stable” answers whether the API is expected to change abruptly; “hostile code contained” is a different proposition that Node explicitly does not make.

What the implementation actually gates

In pinned src/env.cc, permission initialization applies deny rules for native addons, the inspector, child processes, worker threads and WASI unless their allow flags are present. It then applies filesystem read and write allowlists. The CLI and tests cover those paths, including multiple allow flags, wildcard and traversal handling, entrypoint reads, workers, process execution, sqlite extensions, compile cache and symlinks.

That is a meaningful control surface. It can catch a package that unexpectedly writes a cache, a plugin that starts a helper process, or application code that reads a directory omitted from its declared needs. It can also document expected authority in a testable command line. It is not a kernel reference monitor for every way a process can affect the machine. The documentation names several gaps: node:sqlite is not covered by node:fs checks; existing file descriptors bypass the model; initialization occurs after some configuration reads; and relative symlinks under allowed paths can reach arbitrary locations.

Our eight-scenario fixture

The repository now includes scripts/audit-node-permission-model.mjs. It creates an allowed directory, a denied directory containing a marker secret, and a relative symlink from the allowed directory to that secret. It also starts a Python HTTP server bound only to 127.0.0.1, opens the secret before launching one guest, and invokes a small probe under --permission. Every expected result is asserted; a mismatch makes the audit fail.

The fixture uses synthetic data and loopback networking only. It is not exploit code and does not contact an external target. The command is simply node scripts/audit-node-permission-model.mjs. On Darwin arm64 with Node v24.10.0, all eight assertions passed. The script prints structured JSON so another environment can preserve its exact version, platform, scenario result, permission error and conclusion.

Result table: three useful denials and four authority paths that remained open

The allowed-directory write succeeded. A direct read of denied/secret.txt failed with ERR_ACCESS_DENIED and permission FileSystemRead. A direct write outside the allowlist failed with ERR_ACCESS_DENIED and FileSystemWrite. Calling /bin/cat failed with ChildProcess when --allow-child-process was absent. These are the controls working as designed.

Four results define the boundary. First, fetch reached the loopback HTTP server even though no network permission was granted; network is not among the resources the documented model restricts. Second, reading allowed/relative-link returned the marker from denied/secret.txt. Third, a descriptor opened by the parent and passed as fd 3 returned the same marker. Fourth, adding --allow-child-process let /bin/cat read the denied file and return it to Node even though process.permission.has("fs.read", target) was false. The non-Node child is governed by its operating-system credentials, not the parent’s Node filesystem allowlist.

Why the relative-symlink result matters in agent workspaces

Agent runners often grant a broad repository or workspace directory because the task needs recursive reads and writes. Repositories can contain symlinks, package-manager links, generated build trees and mounted paths. Node’s documentation warns specifically that relative symbolic links under a granted path may allow arbitrary filesystem access. Our fixture reproduced that documented behavior with a link created before the restricted process started.

Canonicalizing one requested path in application code is not a complete repair. Links can change, path checks can race filesystem operations, and dependencies may open paths through code the orchestrator does not intercept. Before mounting an untrusted repository, inventory and reject unsafe links, stage ordinary files into a fresh root, make host mounts read-only where possible, and enforce the real boundary through the operating system or virtualized executor. Treat the Node allowlist as an additional check, not the final containment layer.

Why network is a first-class permission even when the runtime has no network flag

Generated code that cannot read a host secret may still download payloads, call metadata services, scan reachable internal endpoints, send task content away, consume paid APIs or coordinate through DNS and HTTP. Our loopback test establishes only that fetch was permitted in this configuration; it does not claim internet availability or reachability to any particular service. It is enough to show that --permission alone did not enforce an egress-deny policy.

Put outbound policy below the guest runtime. Start with no route or a deny-all network namespace, then add a proxy or allowlist only when the task contract requires a destination. Block cloud metadata and private address ranges independently, bind DNS to the same policy, cap bytes and requests, record destinations, and do not expose proxy credentials that can be reused elsewhere. Package installation is network execution plus supply-chain authority; prebuild approved images or proxy immutable packages rather than opening general egress mid-run.

Child-process permission is an authority cliff

Denying child creation by default is valuable, and our test observed the expected ChildProcess error. But many coding tasks immediately request --allow-child-process so they can run git, a compiler, a test runner or a shell. At that point, a non-Node executable receives the operating-system identity and can use system calls that do not consult Node’s permission object. Our /bin/cat case made the distinction visible with one harmless marker file.

In our shell probe, `/bin/sh -lc "cat /tmp/aag-outside-secret.txt"` printed the marker string even though the parent Node process still denied the same path. Node’s own child-process guard stayed intact for Node-to-Node subprocesses, but the shell regained the operating-system user’s full file authority. The permission model is therefore a policy boundary for Node APIs, not for arbitrary shell commands.

Do not grant a general shell merely because an agent needs one command. Prefer a broker exposing named operations with fixed executable paths, validated arguments, controlled working directories, clean environments, deadlines and output limits. Better still, place the complete process tree inside the external sandbox so a necessary compiler cannot escape the mount, identity, network and resource policy. Child denial inside Node is defense in depth; process-tree containment belongs to the host boundary.

Inherited descriptors can smuggle authority into a restricted guest

The pinned documentation says existing file descriptors used through node:fs bypass the permission model. We opened the marker before launching the restricted process, passed it as descriptor 3, and read it successfully even though the path itself was outside the read allowlist. This is expected, documented behavior—not a newly reported Node vulnerability.

Descriptor hygiene is therefore part of runner design. Launch guests with an explicit stdio map, close everything else, and inspect service managers, test harnesses, telemetry agents and language bridges that may pass sockets, pipes or files. A connected socket is network authority even if the guest cannot create a new one. A writable log or cache descriptor can cross an intended mount policy. The least-privilege review must begin before process creation, not at the first JavaScript line.

A production runner needs layered gates

A defensible runner begins with provenance: pin the Node binary, dependencies, base image and generated artifact; verify hashes; and keep the guest immutable. Give each run a fresh low-privilege identity and disposable root. Mount only copied inputs, prefer read-only source plus a bounded output directory, remove host sockets, and supply no home-directory or cloud credentials. Enforce egress, syscall or platform policy outside Node. Cap wall time, CPU, memory, files, bytes, processes and output, and terminate the full process tree on expiry.

Above that boundary, retain --permission with the smallest filesystem grants and no child, worker, addon, WASI or inspector permission unless the frozen task proves it needs one. Route necessary operations through narrow brokers. Validate outputs as untrusted, scan diffs and artifacts, and run acceptance tests in a separate environment that does not trust the guest. Log policy decisions and violations without copying secrets. Destroy state after evidence collection and exercise the kill and rollback paths before production.

Build, buy, deploy or avoid

Build an internal runner only when the organization can own kernel or virtualization policy, image provenance, patching, quotas, egress, secret isolation, telemetry and incident response. Buy a managed executor when isolation engineering is not differentiating and the provider can supply evidence for tenant boundaries, identities, regions, retention, network controls, limits, patching, forensics, deletion and escape response. In either path, reproduce a bounded adversarial suite against the exact configuration.

Deploy Node --permission as a supplementary control when trusted code benefits from an explicit authority manifest and the runner already contains the whole process. Avoid any design that accepts generated code, passes ambient credentials, grants a writable host workspace or Docker socket, leaves unrestricted egress, and calls the result sandboxed because direct node:fs reads failed. The rollback condition is simple: if the external boundary cannot contain the entire process tree and its I/O, do not execute the code.

What this investigation does not prove

Eight synthetic scenarios are not a complete security evaluation. Beyond the fs-read audit/enforce check, we did not test Linux or Windows; containers, sandbox-exec, seccomp or microVMs; node:sqlite; native addons; WASI; worker behavior; inspector paths; race conditions; denial of service; side channels; package managers; environment leakage; or undisclosed bypass techniques. macOS path resolution required the fixture to use the canonical /private/var path rather than the /var symlink; that startup failure was an experiment-design issue, not a product finding.

We also did not execute LLM output. The findings apply to any code outside the runtime’s trust assumption, whether generated by a model, downloaded from a dependency, supplied by a plugin or written by an adversary. A future Node release can change behavior. Re-run the artifact on every supported runtime and operating system, inspect the contemporaneous documentation and threat model, and keep the conclusion bounded to the exact runner configuration.

Disclosures

AccessAllGPT did not receive access, payment, private information or review from the Node.js project, OpenJS Foundation, NIST, a sandbox vendor or an AI coding vendor. The experiment used public source and a locally installed runtime with synthetic files and loopback networking. No model or third-party system was tested or ranked. AccessAllGPT Research is operated by NeuralArc, is independent, and is not affiliated with OpenAI. Publication-wide relationships are listed on the disclosures page.