bivdi

Honest status

What exists today

It would be easy to describe this project in the present tense. It is not a shipped system. It is a specification with a growing executable proof of its core model, and a security layer that does not yet do everything the model describes.

In one line#

A design corpus of roughly 23,000 words, and a Rust workspace that makes the core model executable on Linux — 71 tests, published as a container image you can run in one command. No kernel, no hardware support, no installer.

What has been built#

The specification corpus#

Twenty-four documents covering the specification, the ABI requirements, the threat model, the capability model, the object-store model, the durable-token proposal, the manifest model, identity, events, provenance, resources, drivers, networking, compatibility, observability, performance, recovery, boot and attestation, the agent model, the glossary, and the name. Four RFCs record the decisions taken since.

Every document opens by declaring which of its contents are decided, which are proposed, and which are open. That is the project's central working discipline and it is enforced in review.

The Runtime#

A Rust workspace on Linux — eleven crates, in-process, that make the decided model concrete and testable rather than merely described:

CrateWhat it implements
bivdi-objectThe object store — content-addressed blobs, compare-and-swap cells, catalogs reached only by handle, deterministic CBOR written to disk atomically and flushed
bivdi-capThe capability runtime — mint, attenuate by subset inclusion, subtree revocation, leases, a BLAKE3 hash-chained provenance log
bivdi-stateThe state engine — desired state, reconciliation against observed state, immutable generations, rollback
bivdi-agentThe agent host — capability-constrained, leased, quota-bounded agents with plan execution
bivdi-eventThe event bus — typed events, subscription filters, correlation identifiers
bivdi-identityThe identity service — kinds, fingerprints, petnames, attribute predicates
bivdi-netThe networking model — identity-based endpoints and flow capabilities
bivdi-wasmThe WASI host — running components on wasmtime with a capability context
bivdi-sandboxProcess hardening — a seccomp agent profile with an architecture check, applied to every thread, plus a Landlock policy and a strict mode that refuses to run degraded
bivdi-runtimeThe node that composes them, with a queryable provenance interface
bivdi-cliAn end-to-end demonstration tying them together

A separate conformance suite states the contract in tests, so that any future implementation has to pass the same vectors. Continuous integration runs formatting, a workspace build, Clippy with warnings denied, the test suite, a minimum-Rust-version check, a security-advisory scan, and a sign-off check. main is protected.

Six of six primitives, three of four gate clauses#

The Runtime has an implementation of each primitive in the model, and the hardening that was failing an audit a day ago now enforces what it claims. Milestone A's exit gate has four clauses; the one still open is the developer-facing half — there are no generated bindings and no SDK, so callers link Rust crates directly rather than going through the contract. See the roadmap for the clause-by-clause state.

An audit, and what came of it

An audit on 20 September 2026 found the enforcement layer lagging the model: the sandbox allowlist permitted outbound network access, arbitrary reads and execve; the seccomp filter had no architecture check and covered one thread; name resolution handed out network authority to any caller who knew the name; and the provenance log had none of the integrity properties its specification described. All of those are now closed — the filter enforces an agent profile with an architecture check and TSYNC, resolution requires a capability, and the log is BLAKE3 hash-chained with a verification check in the demo. The findings stayed in the repository rather than being quietly fixed, which is why this paragraph can be specific.

Watch it run#

Five recorded terminal sessions show the Runtime doing the things described above — the six primitives, an injected instruction failing to reach past its grant, durable persistence, WASI under least authority, and the hardening reporting its own limits. See the demos.

What has not been built#

  • No generated bindings and no SDK. The contract is valid WIT and is now proven bindable — a test runs wit-bindgen and checks the Rust it produces compiles — but nothing in the Runtime consumes those bindings yet. Callers link Rust crates directly, which is a language calling convention, not the contract.
  • No real network stack. Flow capabilities model the authority structure and the agent scenario denies a connection for want of one, but there is no socket layer behind it.
  • No kernel. The microkernel is a parked research track, deferred indefinitely.
  • No drivers, no bootable image, no installer, no attestation, no Linux ABI layer, no compositor.
  • No encryption and no crypto-shredding implementation.
  • No signed provenance. The log is hash-chained, so tampering is detectable; it is not signed, replicated, or anchored anywhere outside the process.

What has to be true before Milestone A closes#

A developer can, on a Linux machine: write a program against the Bivdi API, hand it an attenuated capability, run it, and query provenance for everything it wrote — with no code running outside a sandbox.

That is the gate. It is not met — the bindings and the SDK have to land first. The other three clauses now hold: capabilities attenuate and revoke, provenance is queryable and hash-chained, and the sandbox enforces an agent profile rather than reporting one. Each significant decision is recorded as an RFC before work that depends on it begins.

How to read anything else on this site#

Every other page describes a design. Where a page says Bivdi "does" something, it means the decided model specifies it — not that code exists today which does it. Where something is proposed or open, it is marked.

If you find a page on this site that states a not-yet-decided choice as fact, or describes an enforcement guarantee the Runtime does not yet make true, that is a defect and it is worth reporting.

Following along#