Assurance
What we claim, and what we do not.
A security claim without its assumptions is marketing. Every claim on this site carries the conditions under which it holds, and the three guarantees are proven separately because none of them implies the others.
The test
Give the attacker root on the host. Then measure.
An outside firm, holding root on the application host, against a strong conventional baseline (scoped authorization, hardware-backed keys, independent policy enforcement) running the same workload, so the result isolates what the token and the out-of-host controller actually add.
| Measure | What a credible result shows |
|---|---|
| Authorization violations | None observed in testing, and none reachable in the model, over a narrow action vocabulary |
| Budget conservation | No overspend under delegation, concurrency, retry and restart, including lost acknowledgments and snapshot restores |
| Effect containment | No route around the protected executor |
| Availability and cost | Behavior under failure, partition and lost keys is defined; added latency is measured, not asserted |
| Workload compatibility | Fit-to-envelope completion rate. “No operational loss” is a hypothesis we test, not a promise |
Success is one sentence: with full control of the host, an adversary cannot create authority, spend it twice, redirect it to another resource, or exceed the envelope, under stated assumptions.
Results are published as claims and assumptions, with the detailed evidence available under controlled access. A finding that is found and fixed is a better outcome than a claim that was never tested.
Three claims
Never collapsed into “bounded damage.”
No more than the approved allowance is consumed
Under delegation, concurrency, retries and restart. Established by ledger design, exactly-once commit with the executor, and adversarial testing.
No protected operation occurs without an applicable grant
Established by the grant registry, the controller’s four checks, and proofs over a narrow action vocabulary.
Admitted transitions preserve specified invariants
Under stated environmental assumptions. Established by a modeled envelope, independent sensors, and a defined simulator.
Limits
Claims we will not make.
דAI-proof” or “impervious”
The assurance target is enforcement of specified authorization and resource limits under a defined host-compromise threat model. Exploit resistance and recovery performance are evaluated separately.
דBounded damage”
We bound authority, not consequence. A permitted action can still be harmful, and limiting the machines affected does not bound every business consequence of disrupting them.
דA press proves consent”
A press proves a person acted on a protected device. It does not prove they understood the effect, were free from manipulation, or agree with what follows.
דUnclonable hardware”
Unclonability is a property of a construction under a threat model, not a blanket guarantee. Published modeling attacks exist against several PUF constructions, and no supply chain becomes trustworthy on its own.
דDiversity stops exploits”
Per-install variation defeats layout- and encoding-dependent exploits. Against a shared logic error it changes nothing; the envelope has to catch that.
דVerified, therefore correct”
Running on a proven microkernel verifies the kernel, under its own stated assumptions about hardware, boot code, DMA and information channels. It does not verify our parser, ledger, policy logic, drivers or manifest interpretation. The assurance argument runs from the kernel through the enforcement code to the protected resource, and it says where it stops.
Certification roadmap
Sequenced by which buyer they unlock.
Stated plainly: none of the following is held today. This is the order in which we intend to pursue them, published so a security team can see whether our timeline fits their procurement.
| Certification | Unlocks | Status |
|---|---|---|
| SOC 2 Type I, then Type II | Bank and enterprise procurement | Planned: readiness first |
| IEC 62443-4-1 and 4-2 | Utilities and industrial operators | Planned: gap assessment first |
| FIPS 140-3, hardware module | Federal buyers and bank crypto policy | Planned: started early for its long lead time |
| CMMC Level 2 | Defense contracts handling controlled unclassified information | Planned: follows the first defense engagement |
| Common Criteria (card) | Bank card schemes and some governments | Only when a scheme requires it |
| FedRAMP | Not applicable | Deliberately not pursued. The controller is an appliance, not a cloud service |
Open specification
The protocol is meant to be read, and re-implemented.
The token and lease protocol and the manifest schema will be published under a permissive licence, because adoption is the moat and an open spec is how a bank’s security team says yes. The assurance case, the controller implementation and the hardware designs stay proprietary.