01 · What it is
What a JavaScript runtime is, and why it matters
JavaScript mostly runs inside browsers. But enormous amounts of it run outside browsers — servers, CLIs, build tools — each executed by a program called a runtime. The incumbent is Node.js, which owns that lane outright: npm, the debugger and profiler ecosystem, every hosting platform. When your editor runs an extension, or a coding agent installs and executes third-party code at machine speed, a runtime is what decides what that code is allowed to touch.
That last workload — running code you did not write and do not fully trust — is the one this project is about. The incumbent answer to "secure JavaScript" is Deno, which is secure by default: no file, network, or environment access unless explicitly granted with flags like --allow-net or --allow-read. There is also a membrane-model school (SES, LavaMoat) that contains untrusted code inside JavaScript itself, without asking anyone to adopt a new runtime. Deno owns buyer perception for secure runtimes; the membranes own the "contain it where it runs" lane. Nobody owns the combination of: a runtime that proves, on the record, what it decided and refuses to overclaim.
02 · Why build it
Why rewrite it in Rust?
The maintainer's stated case, in the project's constitutional documents: retrofitting information-flow control and capability-typed authority into a binding-led engine (V8, JavaScriptCore, QuickJS bindings) is "structurally lossy." The bindings ship megabytes of upstream unsafe C++/Zig outside any authority algebra, and wrapping a type-safe membrane around them cannot recover the guarantees. The charter therefore forbids binding-led core paths outright: the parser-to-scheduler pipeline must be native safe Rust so the security labels are computed inside the same algebra that enforces them. The target workload is agent systems running untrusted extensions, where a malicious or buggy extension can exfiltrate secrets or spawn processes and where post-incident forensics must reconstruct why a containment decision fired.
The counter-arguments, several of them surfaced by the maintainer's own documents, cut deep. First, Deno already owns "secure JS runtime" in buyer perception and is V8-fast; SES/LavaMoat already contain untrusted code without a new runtime, and no campaign anywhere in the materials pits this project's capability algebra against them on the same corpus. Second, the maintainer's own claim ledger keeps the throughput claim at TARGETED: the only cross-runtime number in the tree is a June 2026 bundle measuring roughly 0.000920× Node and 0.000791× Bun, about a thousand times slower, on a declared non-normative dirty worktree. The perf gate that could certify any lap time has never run. The security story has to carry the entire value proposition, because the performance story is a vacancy the author himself refuses to fill.
03 · What was built
What the project actually built
The scale is the first thing you notice: about 3.5 million lines of Rust across 10 crates, with development velocity near 20 commits a day through September 2026 — and zero agent co-authorship in the sampled history, a sharp contrast with the suite's Redis rewrite. What got built: a hand-rolled parser feeding a four-stage lowering pipeline; an information-flow lattice with five labels from Public to TopSecret (fail-closed, allowlist-only by default); a 22-variant capability algebra partitioning authority into disjoint zones; deterministic replay with byte-for-byte gates; every decision receipt Ed25519-signed and hash-chained into a transparency log with Merkle proofs; and a probabilistic guardplane, the "testing by betting" kind of anytime-valid sequential testing, driving a six-rung escalation ladder literally named in code: allow, challenge, sandbox, suspend, terminate, quarantine.
More interesting than the scale is the honesty machinery:
- A 28-claim JSON ledger gates the README in CI (continuous integration: automated checks that run on every change). Each claim carries an owning issue, an artifact path, a verification command, and a freshness bound; a gate script refuses README wording whose state outruns its evidence and emits the exact downgrade text. This is the only repo in the program that lints its own marketing.
- The README refuses its own performance claims. The Node/Bun denominator stays TARGETED because the only measured bundle is a declared non-normative historical artifact. A separate gate rejects fixture artifacts as backing evidence.
- The only
unsafe blocks in 3.5 million lines are attacks. Two adversarial test files transmute-forge IFC labels as negative tests proving the capability membrane catches forgery; every library crate compiles with unsafe forbidden. The unsafe-forbidden badge is a compile-time gate, not a goal.
Evidence · CI status
What the project’s own CI said at the pin
- ✕The core CI lane is red at the pin (the commit the assessment was pinned to) and has never been green: the native-runtime workflow failed all three jobs at the pinned commit, and all 46 recorded runs fail.
The uncomfortable findings
Uncomfortable finding
It has never gone green in the observed window. Two named quality gates and the perf regression gate have zero runs ever. The headline security promise is TARGETED by the project's own ledger: the end-to-end compile-time contract, ambient-authority rejection over all constructs, is an open item; only selected hostcall edges are observed. source The v0.1.0 release targets an earlier commit, so there is no release artifact for the assessed code. And then there is the license: MIT plus a rider naming OpenAI and Anthropic, the builders of the agent systems this runtime targets, as forbidden parties barred from even analyzing the code. The rider excludes the demand side by name.
04 · Where it stands
Where it stands
In our program's terms: TRL 4–5, NODUS ring Explore. In plain English: the security machinery is real code with real gates, but no independent party has validated it, the core verification lane does not run green, and the license blocks the likeliest collaborators. It is the infrastructure substrate under the suite's agent runtime (franken_node), so these ceilings are inherited downstream.
Technology readiness
TRL 4–5 on a 1-to-9 scale.
NODUS ring
MonitorExplorePilotInvest
The program’s adoption ring for this project.
Verdict key
- NODUS ring
- Explore: The default for substantive-but-unproven work.
- TRL
- Technology Readiness Level, a 1-to-9 scale of how proven a technology is. This brief rates the project at TRL 4–5.
- CI
- Continuous integration: the project’s automated checks, run on every change.
- The pin
- The exact commit the assessment was pinned to. “At the pin” means as of that commit.
Evidence tiers
- Tier 1 · Verified — Confirmed by direct inspection of a fresh clone, an API response, or a live page read by the analyst.
- Tier 2 · CI-observed — Observed executing on live CI pages. Attests the suite runs, not that it is green, unless pass/fail is legible.
- Tier 3 · Maintainer claim — Asserted in README or docs by the maintainer; not independently executed or reproduced.
- Tier 4 · External — Independent sources: APIs, papers, press, third-party benchmarks. Absence of coverage is reported as a finding.
- Tier 5 · Inference — The analyst’s judgment. Always labeled; never presented as fact.
What this verdict rests on. Tier labels are the assessment packet’s own annotations.
- Tier 1 · Verified: 3.53M lines, zero unsafe in lib code, a 4,537-record bead journal: counted and code-verified.
- Tier 2 · CI-observed: Core CI lane red at the pin across all 46 recorded runs.
- Tier 3 · Maintainer claim: Nothing was compiled or executed; every OBSERVED ledger row is existence-verified, not behavior-verified.
- Tier 4 · External: No independent validation, no production user.
- Tier 5 · Inference: The Explore ring: substantive-but-unproven.
Should you use it?
No: no release at the pin, red core CI, a bus factor (the number of key contributors who could disappear before the project stalls) of one, and a containment boundary the author admits is partial.
Should you learn from it?
Emphatically yes.
The claim-to-proof matrix, with its wording-state gating on public claims, freshness bounds, and exact downgrade text, is an unusually portable artifact: it ports to any project without the runtime.
What would change the verdict, in order
- the license rider narrowed or removed (the necessary condition: an agent-extension runtime that bars the agent builders is self-defeating), a green core-CI lane at a pin, an independent party executing the ledger's 13 OBSERVED rows and publishing pass/fail, and the red-team campaign the ledger already specifies, fully scripted and never executed, run with its verdict published, loss included. source Until then, if you need a secure JS runtime, Deno wins
- if you need containment inside JS, the membranes win.
05 · What it teaches
What this teaches about building with agents
Here is the exportable insight, and it is not about JavaScript.
Most documentation is a rumor the code has not confirmed. This project's answer is to make the documentation a build artifact with a test suite: a JSON ledger binding each public claim to an owning issue, a verification command, an artifact path, and a freshness bound; a gate that fails the build when a sentence outruns its evidence and prints the exact downgrade text to use. "Observed for selected edges" can never quietly become "end-to-end" in a slide, because the gate does not permit the sentence.
The deeper point, and the reason this beats ordinary "docs as code," is the inversion of who the self-audit machinery serves. It does not protect users from the maintainer. It protects the maintainer from the future versions of himself that success would produce: the version that ships a benchmark table, the version that writes "secure" without scope. FrankenEngine's README is not humble; it is bound. source For anyone building with agents, whose output arrives at machine speed with machine confidence, the lesson is mechanical: do not review your claims. Make your claims un-reviewable-by-you, by giving the gate the keys to your own wording. The teams that do this will be slower to claim victory and faster to actually earn it.