The Superposition Problem
A multi-agent workflow graph is a superposition of outcomes. At any moment before a syscall executes, the action it represents exists across all possible policy states simultaneously: permitted, blocked, or quarantined. Conventional governance systems evaluate this superposition after the fact — inspecting log lines, auditing API responses, running async classifiers against completed transactions. By the time the evaluation completes, the syscall has already resolved. The action has already affected external state.
Wave Function Collapse is the architectural thesis that governance must be synchronous with execution. The collapse from superposition to a single committed outcome must happen at the kernel boundary, inline with the syscall, before the action affects any external state. Everything after that boundary is immutable fact.
Pure-Rust eBPF: The Enforcement Substrate
The Phantom Engine is implemented in pure Rust targeting bpfel-unknown-none — a no_std eBPF target with zero libc dependency. The enforcement programs are compiled with cargo build --target bpfel-unknown-noneand loaded into the kernel via the Linux Security Module hook interface. There is no C runtime. There is no interpreter. The enforcement logic executes as native eBPF bytecode verified by the kernel's own verifier before attachment.
The choice of pure Rust over C eBPF programs is not aesthetic. The Rust type system eliminates the class of memory safety bugs — buffer overflows, use-after-free, integer wraparound — that have historically produced kernel panics in eBPF programs. A governance system that can crash the kernel it governs is not a governance system.
The Phantom Engine has never caused a kernel panic in production. This is not a claim. It is a property of the type system.
Ring-0 Collapse: < 1ms Synchronous Enforcement
The Phantom Engine attaches to the security_socket_connect, security_file_open, and security_bprm_check LSM hooks. When an AI agent process issues a syscall that traverses one of these hooks, the eBPF program evaluates the call against the loaded policy map in under 1 millisecond — synchronously, in the kernel's execution context, before the syscall returns to user-space.
The agent process is blocked at the syscall boundary during enforcement. It cannot observe the enforcement logic, cannot race against it, and cannot issue compensating actions while evaluation is in progress. The outcome — permit or block — is deterministic and immediate.
RISC Zero zk-SNARKs: The Cryptographic Receipt
Every enforcement decision produces a Cryptographic Anomaly Record. The record is generated asynchronously off the critical path via a RISC Zero zkVM running a Poseidon2-based Merkle proof circuit. The zkVM produces a Groth16 zk-SNARK that commits to:
- The kernel-monotonic timestamp of the enforcement event (nanosecond resolution)
- The process credential set at time of syscall (UID, GID, PID, cgroup ancestry)
- The syscall identifier and normalized argument hash
- The policy version hash that produced the enforcement decision
- The enforcement outcome (permit / block / quarantine)
The proof is appended to the bifurcated WORM ledger in append-only mode. The substrate is selected via the SOVEREIGN_MODE environment variable: cloud-native deployments use a TrueTime-stamped Google Cloud Spanner ledger; sovereign / air-gapped Tier 03 deployments bypass GCP entirely and commit to a localized append-only ledger inside the customer perimeter. No entry may be modified after commit in either mode. Any party with the Vantio verifier key can independently confirm the integrity of any record without access to Vantio infrastructure.
VANTIO_AUDIT_MODE
Enterprise deployments may activate VANTIO_AUDIT_MODE=1 to run the Phantom Engine in observe-only mode: all enforcement decisions are logged and cryptographically receipted, but no syscall is blocked. This allows security teams to characterize agent behavior against a draft policy before activating enforcement, without modifying the agent's observable behavior.
# Activate audit-only mode — no blocks, full receipts
export VANTIO_AUDIT_MODE=1
export VANTIO_POLICY_PATH=/etc/vantio/policy.toml
systemctl restart vantio-phantom-engineAudit mode records carry the same cryptographic weight as enforcement records. They are committed to the same Spanner ledger, sealed with the same RISC Zero proof, and are admissible in regulatory examinations under the same SEC Rule 17a-4 framework.
SLSA Level 3 Supply Chain
The Phantom Engine kernel module is produced by a SLSA Level 3 compliant CI/CD pipeline. Every build is hermetic: inputs are pinned by cryptographic hash, the build environment is a Distroless container with no shell or package manager, and the resulting binary is signed with a Sigstore ephemeral key whose certificate chain is committed to the Rekor transparency log at build time.
The provenance attestation — a signed SLSA provenance statement linking source commit to binary artifact — is published alongside every release. Enterprise customers can verify that the kernel module running in their environment was produced from the exact source commit they reviewed, with no undisclosed toolchain substitution.