VOLENT

§0 What was measured

You give a customer one file. They boot it as a virtual machine. What comes up is a locked-down system that runs their AI agents — with no way to log into it, nothing to install or patch, and a single controlled exit for network traffic. Ask it what it's running and it answers with proof you can check yourself.

There is nothing to log into and nothing to install. The disk is read-only and checked on every read, so a change made to it is detected rather than trusted. One small area is writable, for data only — nothing stored there can be run.

How it is deployed, and where a network partner sits

Left to right: your customer owns the machine, we control what runs on it and what's allowed out, and you carry it the rest of the way. The two shaded boxes are what we build.

Five properties are load-bearing for a network partner, and each has a section below: it boots fast enough to be treated as cattle (§2); it can prove its own identity and integrity to a third party (§3); every outbound connection it makes passes one auditable gate (§4); it holds agent concurrency without the VM growing (§6); and it gets onto a machine — imported, or written over whatever was already there (§7).

§1 How to read this report

Two kinds of number appear here and they are not interchangeable. Conflating them is the most common way a benchmark stops being true.

Everything below ran against the real appliance image — the same squashfs, the same dm-verity table, the same runtime — booted under KVM. Nothing was simulated on the host except where the report says so explicitly.

§2 Boot Certified

Cold boot to the first liveness line, under OVMF with the production image. Disk cache evicted before every run.

§3 Attestation Certified

The node produces a signed report carrying a real TPM2 quote. It is fetched from outside the guest and verified on the host by an implementation that shares no code with the node — it parses the attestation structure from the TPM specification and its cryptography is OpenSSL's, not the node's.

Four boots, each asserting something the others cannot

Why the PCR digest check is the load-bearing one

The quote signs a digest; the report carries values. Recomputing the digest from those values and requiring it to match is what makes them evidence. Boot B's third case is an attacker holding the node's identity key but not its TPM — they re-sign whatever claims they like, the identity signature verifies, and only the digest refuses them:

   the untouched report verifies; now breaking it
   FAIL: the machine-identity signature did not verify
   refused, as it must: one flipped bit in the payload
   FAIL: the machine-identity signature did not verify
   refused, as it must: a signature from a different node
   FAIL: the PCR values in the report do not produce the digest the TPM signed
   refused, as it must: a re-signed report with a PCR value replaced

The report also states its time source, trust-store digest, resolver lookup order, reachable egress destinations, API bind address, and whether the cloud-metadata window is sealed. A report that cannot say the window is shut cannot rule out the one hole that window exists to close.

The operator verifies it themselves

A signed report is only worth what the recipient can check. volent attest --verify policy.json is a standalone tool that takes a report and a policy describing what the node must be, and answers in exit status. It depends on neither the node's source nor any third-party package — it parses the attestation structure from the TPM2 specification and verifies with the platform's own cryptography, because a verifier built from the producer's code agrees with a bug in it.

  ok   machine identity signature — ed25519, over 2317 bytes of claims
  ok   node names its own key — 33b30618c5759d47…
  ok   freshness — the report carries the nonce that was sent
  ok   quote is TPM-generated — magic and attest type are a quote
  ok   quote is bound to a challenge
  ok   TPM signature over the quote — ECDSA P-256 / SHA-256
  ok   PCR values match the signed digest — 8 PCRs reproduce it
  ok   image version — 0.1.0-dev
  ok   pin digest — 642d379bdd51
  ok   verity roothash — b01bf5a4beb688e6df7939…
  ok   boot profile — verity_only
  ok   metadata window sealed — true

PASS: the report verifies and satisfies the policy (2 check(s) the policy did not ask for)

Every policy field is optional, and the tool states how many it was not asked to check. A thin policy printing a bare OK would be the most dangerous output it could produce, because it would look exactly like a thorough pass.

§4 Network posture Certified

The node configures its own network at boot and has exactly one way out. Both are properties a network operator can audit rather than take on trust, and both are enforced by the build rather than by convention.

What it does on its own at boot

VOLENT-ENTROPY  seeded after 1ms
VOLENT-NET      link eth0 up
VOLENT-NET      eth0 addr=10.0.2.15/24 gw=10.0.2.2 lease=86400s
VOLENT-NET      resolver: 1 nameserver(s) installed
VOLENT-TIME     no time server offered by the network; running on monotonic time
VOLENT-PROVISION provisioned from ec2: api_token, api_bind; metadata window sealed
VOLENT-API      control api: listening

Interface selection comes from the kernel's own link table rather than a configured name, so the image boots unattended on a hypervisor nobody tried — eth0, ens3 and enp0s3 are all the same to it. DHCP, address, default route and resolver are the node's own work. A guest with no interface is a reported condition, not a crash.

One egress path, deny by default

Every outbound request — an agent's tool call, a model API, an image update — traverses a single gate in a fixed order. There is no second socket, and that is checked at build time by auditing the compiled modules rather than by grepping source: naming a socket API anywhere outside the gate fails the build.

Every decision, allowed or refused, is journalled with host, bytes, duration, the agent that asked and the reason. In §5's 896-call run the tally was allow: 896, deny: 0 — and in the security controls run alongside it, a host not on the allowlist was refused, a deliberately emptied trust store produced a TLS failure rather than a silent downgrade, and a scan of the node's own output for the provisioned credential came back clean.

Transport

§5 Agent workload Measured

Real agents running inside the booted appliance, reaching a real model server over TLS and HTTP/2 through the node's single egress gate. Not a host-side harness calling a model.

5.1  The corpus is ordered by cost, not by difficulty

Tasks are graded into four tiers by expected output length, because difficulty is not a quantity a benchmark can measure and output length is — on a decode-bound server it is what drives cost. The results confirm the distinction is real rather than pedantic:

5.2  Per task, 32 runs each at concurrency 8

5.3  Concurrency against a real model server

The benchmark's own verdict: throughput flattened while the node stayed flat — this is the endpoint's ceiling, not the appliance's. One CPU-bound model server with a fixed number of decode slots saturates long before the runtime does. No figure in this subsection is a claim about the appliance, because the appliance is not what ran out.

§6 Concurrency capacity Measured

To measure the runtime's own ceiling the model is removed: an in-process stub answers with a fixed 5 ms latency, so what is being measured is admission, scheduling and bookkeeping rather than somebody's GPU. Five VM shapes, four load levels.

What the table says

• Nothing was refused, anywhere. 150,000 concurrent in-flight calls on a 1 vCPU / 1 GB guest, with the admission controller accepting every one.
• More vCPUs did not help. The 1 vCPU shape matched or beat the 8 vCPU shape at every load. The workload is wait-bound rather than CPU-bound, so extra schedulers add coordination without adding work. Buying cores for agent concurrency alone is not indicated by this data.
• Memory tracks agent count, not the VM's RAM. 79 MB at 1,500 rising to ~215 MB at 150,000, on every shape. Size the guest by how many agents it must hold, not by giving the runtime headroom it will not use.
• Atom count is flat — identical across all four loads within each shape. That is the property a 24-hour soak depends on, and the per-destination connection-pool design exists to preserve it.
• Process count is flat at 140–154 regardless of load, because in-flight accounting lives in the admission controller rather than in a process per call.

§7 Deployment Certified

One image, four ways onto a machine. Each one below was run, not described: the numbers and the refusals come from gates that boot the artifact they are claiming about.

The three formats, and the one that is not obvious

The image emits as raw, qcow2 and a fixed VHD. All three are re-encodings of the same 2 GiB disk, so each is compared back against the raw byte for byte, and the qcow2 and the VHD are then booted. What makes that worth doing: converting to VHD without pinning the virtual size rounds it up to the next legacy disk geometry, producing a file that is a slightly different disk from the one it was made from — silently, with the consequence arriving at an image import weeks later.

Taking over a machine that already has an operating system

The end-to-end test installs the appliance over a stock, unmodified Debian cloud image in a virtual machine — fetched by digest from Debian's own mirror, driven by cloud-init exactly as an operator's automation would drive it, running the byte-identical installer that ships beside the image. The machine reboots into the appliance, answers for its attestation report from outside the guest, and the previous operating system is gone — read off the partition table, not inferred from a console that anything inside the guest could have written to.

The run that matters is the one that must fail. The same install is attempted first with one byte of the image changed. It has to be refused with nothing written, and the disk has to still hold Debian afterwards. Without that, this test would pass just as happily against an installer that verified nothing.

Four boot paths, three of them alternates

Ten provider runbooks, generated from the build

Every digest an operator is asked to check is substituted from the signed manifest of the build being documented, and a gate fails if a committed runbook and the build disagree. A runbook whose digests do not match the artifacts beside it teaches operators to skip the verification step, which is the one step that matters.

§8 Method

Test article

Production image volent 0.1.0-dev, pin digest 642d379bdd51, built with a development Secure Boot keyset — stated because it is a property of the article measured, and the attestation report in §3 carries that provenance as a field. Read-only squashfs under dm-verity; only /data writable and mounted noexec. Kernel 6.12.104 hardened with MODULES=n. No shell, no package manager, no init system other than the project's own PID 1. The image states its own version from the pin file, never from version control, so the same source tree always produces the same image.

Host

x86-64 Linux, 8 cores, 31 GB, KVM. Every result is tagged T3-KVM; the harness refuses to run without /dev/kvm and asserts -accel kvm in the command line it actually executed, because emulated results are not admissible.

Model path (§5)

llama3.2:1b served by ollama on the host, fronted by TLS and HTTP/2 so the appliance's transport requirements are met without relaxing them. The guest reaches it through the hypervisor's host alias at an address the SSRF guard permits — no gate rule was weakened to make the rig work. Every call traverses the same egress path a production deployment uses: capability check, allowlist, URL inspection, DNS pinning, connection to the judged address, and a journal entry for the decision.

Stub path (§6)

An in-process mock with fixed 5 ms latency replaces the provider. This removes the network and the model deliberately: it is the only way to measure the runtime's own admission and scheduling behaviour rather than a model server's decode capacity.

Correctness scoring

Every corpus task carries the substring a correct answer must contain. Matching is lenient about form and strict about content — case and non-alphanumerics are dropped from both sides, so 12:00, "count" and Tokyo. need no special case. A stack returning HTTP 200 with garbage is a different result from one that works, and a completion count cannot tell them apart.

§9 Limits of this report

Stated in full. A benchmark that omits these is not a benchmark.

§10 Where this sits Public sources

Agent execution became funded infrastructure in 2026: $355M into Modal, $24M into Daytona, a billionth sandbox at E2B. This section places VOLENT against that field honestly, including where the field is ahead.

The category split

Almost everything funded in this space is a hosted sandbox: you send code or an agent to the vendor's cloud, it runs in an isolated microVM, and you are billed for it. VOLENT is the other shape — an image the customer boots in their own VM, on their own hypervisor, which proves its own integrity to whoever asks. The buyer is different, and so is the objection it answers.

The nearest neighbour is not an agent company

Talos Linux occupies this OS position almost exactly — no SSH, no shell, no package manager, read-only squashfs under 80 MB, YAML machine configuration applied over an authenticated API. It is a Kubernetes appliance rather than an agent appliance, and it does not set out to prove itself to a third party. But anyone evaluating "a minimal immutable appliance OS" will find it in seconds, and a claim that the shape is novel does not survive that search.

The same applies to the runtime. Running very large numbers of concurrent agents on the BEAM was an active argument through 2025–26, with at least one public claim of millions of agents on a cluster. The §6 figures are good; they are not a category claim, and BEAM process cost is the well-understood reason for them.

What is actually distinctive

Not the minimal OS, not the WASM sandbox, not TPM attestation, and not BEAM concurrency — each of those exists elsewhere. What could not be found in public prior art is the combination in §3 and §4 together: an attestation report that binds the measured boot chain to the runtime's network posture — which certificate authorities it trusts, in what order it resolves names, where its management API is bound, which destinations it has reached, and whether the cloud-metadata window is sealed — signed by the machine's own identity and verifiable by a tool that shares no code with it.

A hosted sandbox cannot make that statement, because the boundary it would attest to is the vendor's. A minimal OS can attest to its boot chain but has no runtime posture to bind to it. That intersection is the claim worth defending.

Where the field is ahead