Governed execution for critical software
Run it under constraint. Keep what the run proves.
A sandbox that produces evidence about what it ran — four isolation levels, a network of its own, and every create, exec and destroy sealed into a chain that verifies offline.
Source available (BUSL‑1.1, Apache‑2.0 in 2030) · runs on your machines · nothing to call to verify
What it is
A sandbox is normally a way to forget what happened.
It contains the run and throws the details away. NaZelo keeps them: the profile it ran under, and every lifecycle event, in a form somebody else can check.
That matters where a failure is physical, regulatory or financial — industrial control, medical devices, vehicles, aircraft, rail, maritime, energy, finance. In those places the question is never only "did it work". It is "show me how it ran, and show me you did not write the answer yourself".
NaZelo is the part that runs the software and records the run. It does not interpret the record: your compliance layer does that, from events it can read.
Isolation
Four levels, and each names the tool it uses.
You choose how hard the wall is, and the profile you chose travels inside the signed record — so a run cannot claim a level it did not have.
TL1 — bubblewrap
Fast, unprivileged, for a quick pass over untrusted code.
TL2 — namespaces + cgroups
The Linux primitives directly: separate views, bounded resources.
TL3 — gVisor
A user-space kernel between the workload and yours.
TL4 — Firecracker
A microVM. Its own kernel, for the runs you would not host otherwise.
Its own network. A sandbox gets a network namespace of its own, so what it may reach is a decision rather than an accident. Reaching further — reading the content of what crosses, per protocol — is what the industrial plugin adds.
The rule everything else follows from
The thing being observed must not hold the key that signs the observation.
The engine already enforces it against the workload: a backend that handed the child its environment would hand it the key that signs its own evidence, and NaZelo refuses that.
The same rule has one more step to climb, and it is the commercial one. Today the host holds the key. That is right against a hostile workload and worth little to an assessor — because the host is you, and you are the party being reviewed. A record signed by the organisation under audit is self-attestation.
Move the key one level out, to an operator with no stake in the result, and the record becomes evidence. That is what the paid service is for, and it is the one thing a copy of this code cannot reproduce: it either ran on infrastructure you do not control, or it did not.
Run it entirely yourself and you lose nothing but that. The engine is source-available, the isolation is the same, the record is the same shape, and it verifies with the same tooling. What you cannot give yourself is somebody else's signature.
First vertical — industrial and energy
Test against a peer that answers, before you book the bench.
The industrial plugin ships simulated peers — a Ghost PLC, a Ghost ECU, a Ghost Chip, DICOM and HL7 endpoints — so software that talks to equipment can be exercised without the equipment.
A protocol peer that replies is the difference between a test and a mock. It is also where the run stops being generic: what was written to which register, and whether it was allowed, is the part an assessor asks about.
What NaZelo does not do
It tests. It does not certify. NaZelo runs before a HIL bench, before SCADE, before VectorCAST — to find defects earlier and more cheaply, and to hand the evidence on. It replaces none of them.
It does not reproduce hardware faithfully. A simulated peer answers a protocol. It is not a model of your device, and a run against it proves nothing about timing, wear or physics.
It does not guarantee safety. It records what ran under which constraints. Deciding whether that is safe is somebody's job, and that somebody is not a sandbox.
The record
Create, exec, destroy — sealed where it happened.
Every lifecycle event is a structured entry, and the entries are links in a chain that verifies offline, with no server in the loop.
The profile is inside
Trust level, limits and what the sandbox was allowed to reach travel within the signed bytes. Outside them the chain would verify perfectly and answer nothing.
Verifies without us
The chain is checked with the same open tooling as everything else in the house. No account, no network, no permission from anybody.
Your compliance layer reads it
NaZelo emits events. Mapping them to IEC 62443, ISO 27001, DORA or an internal standard is interpretation, and interpretation is not a sandbox's job.
Pricing
Per organisation. Not per run.
A developer starts a sandbox hundreds of times a day. Charging for that turns a safety tool into a line somebody is asked to reduce — and the first thing they reduce is the safety.
Prism
- The whole sandbox, all four levels
- The full record, signed with your key
- Self-hosted, air-gapped if you like
- The engine, source available
Alchemy
- Everything in Prism
- Attested runs — signed by a key you do not hold
- Retention beyond the sprint
- The export an assessor reads
Harmony
- Everything in Alchemy
- Fleet — what ran across the estate, over time
- Retention for a certification cycle
- Team scoping
Sovereignty
- Everything in Harmony
- Dedicated deployment in your region
- Custom SLA
- Contractual support
Sold together
Decided, enforced, sealed.
NaZelo runs it. Pimatika decides what it may reach. Litatoli seals what it produced. Each is sold on its own; together they cost a third less.
NaZelo Policy
NaZelo + Pimatika — decided and enforced, no sealed chain.
NaZelo Evidence
NaZelo + Litatoli — isolated and sealed, no policy engine.
NaZelo Trust
All three. Decided, enforced, sealed — the whole guarantee.
Annual is ten months. Bundles start at Alchemy; the free tier is for one engine at a time.
Launch pricing, and the paid service is opening. If a plan is wrong for your situation, say so — we would rather hear it now than model it.