Rivet releases Secure Exec SDK with 17.9 ms cold start and 56x cheaper Node.js runs

• Rivet launched Secure Exec, a library for running Node.js code with V8 isolates instead of containers or VMs, and its launch post claims 17.9 ms p99 cold starts, 3.4 MB memory use, and costs that are 56x lower on t4g.micro.
• The longer product thread says Secure Exec works across Node.js, Bun, and browsers, with support for common Node surfaces including fs, child_process, http, dns, process, and os.
• Security is framed as deny-by-default: according to the SDK thread, filesystem, network, child processes, and env vars are blocked unless explicitly allowed, with finer-grained controls than many sandbox setups.
• The immediate AI-agent angle is code execution and tool use, and one practitioner says some teams are already testing whether JavaScript execution can replace parts of a bash-tool workflow.

Secure Exec is Rivet's new SDK for “secure Node.js execution without a sandbox,” built on V8 isolates rather than a separate container or VM. In the technical thread, Rivet says that on Node.js and Bun the isolate runs “inside the host process,” while the browser version uses Web Workers for a similar isolation model.

The company is positioning it as a lightweight runtime for untrusted code execution, especially in agent systems. Rivet's GitHub link points to the open-source repository at the GitHub repo, and the same thread lists target use cases including AI agent tool execution, MCP “Code Mode” tool execution, dev servers, plugin systems, and interactive coding playgrounds.

The practical pitch is lower overhead than heavier sandbox stacks. Rivet's benchmark claim compares Secure Exec with “best-in-class sandboxes” at 17.9 ms p99 cold start versus 3.1 s, 3.4 MB versus 256 MB of memory, and 56x lower cost on t4g.micro. It also claims “native V8 performance,” arguing that code runs through V8's normal JIT pipeline rather than through a WASM-hosted interpreter.

For agent builders, the more consequential detail is the permission model. The product thread says access to the filesystem, network, child processes, and environment variables is blocked by default and must be explicitly granted, with support for in-memory or persisted state depending on the host. That lines up with a shift in agent tooling: a practitioner thread says one experiment is removing a bash tool entirely because agents can often write JavaScript that handles the same tasks more portably, even if gaps remain around tools like git.