Models Propose. Hypervisor Executes: A Governed AFT Workload on Akash

Models propose. Hypervisor executes.

A root-capable model worker requested a real benchmark run of AFT — Asymptote Fault Tolerance, IOI's consensus architecture — on Akash. It did not possess the wallet root, Akash credential, operator password, recovery material, reusable session, or wallet unlock secret. It could not reach Akash directly. It crossed a fresh VM boundary carrying only a proposal and an opaque, one-use capability; the trusted host admitted the request, introduced authority at the final invoker, and committed what happened.

The workload then became ready, executed the complete ten-row AFT matrix, returned an authenticated result, and was torn down. Hypervisor reconciled the provider’s financial state to zero open or unknown exposure. A second separately authorized campaign repeated the same protocol on the same exact provider and immutable image.

The complete system transition — the anatomy of one governed infrastructure syscall — was:

root-capable model worker
  → isolated proposal
  → passkey-authorized standing envelope
  → atomic trajectory admission
  → C2 intent commitment
  → host-only final invoker
  → Akash escrow, bid, lease, and ready workload
  → authenticated AFT result
  → teardown and terminal financial reconciliation
  → C2 outcome commitment
  → C8 certificate
  → separate verifier
  → AFT registry acceptance

Two artifacts in that chain recur throughout this article. C2 is Hypervisor's owner-scoped commitment journal: the durable record plane where intent and outcome roots are anchored before and after an external effect. C8 is the portable lifecycle certificate: a hash-bound evidence object whose security-relevant claims a separate verifier checks against the raw artifacts.

That is the milestone: a model-requested workload crossed a VM-enforced machine-authority boundary, produced a cryptographically bound result on a real provider, and reached terminal technical and economic state without giving the model IOI-held secrets.

Campaigns N and O used source 14d249076477e97ec0dce5cdbea069b205df7cad, immutable image sha256:3ddf68303685720610c6f3ff60ee300a884d9afb08101773f8d74d872eb1211d, and the same exact audited Akash provider. Each discarded one complete warmup and retained five measured passes over ten scenario/lane rows.

The accepted evidence is frozen here: evidence guide, relying-party provisioning record, portable bundle manifest, exact C8 v2 predecessor, C8 v3 certificate, claim manifest, acceptance receipt, accepted result row, and revision-1 registry.

Open the lifecycle diagram at full size →

Why this is not “an LLM called Akash”

Akash already provides an authenticated Console API. It intentionally exposes deployment management as plain HTTP behind an account-scoped API key. Sending that request is ordinary integration work. The systems question is who controls the credential, who is allowed to request an effect, which exact effect was authorized, and what evidence can establish the result.

It is worth being precise about the pattern this replaces, because nearly every "AI agent deployed to the cloud" demonstration shares one architecture: a long-lived, account-scoped credential placed where the model can use it — in context, in environment variables, in a tool the model calls at will — and a log written afterward by the same process that acted.

That architecture has four properties, and they are all the same property.

Possession is authority. Whoever holds the key is the account. The model holds the key; therefore the model is the account. Every safeguard layered after that fact — system prompts, tool descriptions, output filters — is a request for good behavior addressed to a stochastic process.

Authority has no shape. An account-scoped key does not encode one operation. It encodes everything the account can do, for as long as the key lives, as many times as anyone cares to replay it. The agent was authorized to do one thing; the credential authorizes all things.

Failure inherits the account. A prompt injection, a poisoned tool result, one bad token sequence — any of them converts into the full standing authority of the key. The blast radius of a jailbreak is the account, not the request.

The log is testimony. It is written after the effect, by the same trust domain that produced the effect, with nothing committed in advance to check it against. A log explains. It cannot constrain. It cannot even distinguish what was authorized from what merely happened, because there was only ever one record, written once, afterward.

Now the same four properties in this run. The model never possessed authority: root inside the worker, 14 attempted escape and exfiltration paths, zero secret findings, zero direct provider invocations. The authority had exact shape: a wallet-signed capability bound to one request, one provider, one image digest, a one-dollar ceiling, one use, atomically consumed, terminal afterward. Failure inherited the envelope, not the account: the worst a fully compromised worker could produce was a proposal, and every proposal still faced the six gates below. And the record was not testimony: intent was committed durably before money could move, the outcome was committed after provider-native evidence, and a separate verifier rejected 40 resealed mutations of that evidence before a registry would change state.

These are not two maturity levels of the same design. An agent holding an API key and a governed authority boundary are different objects, the way a script running as root and a system-call interface are different objects.

In this run, the model was not the authority.

It could propose an operation. It could not create a valid daemon proposal for itself, manufacture wallet authority, choose a different provider outside the reviewed selector, replay a consumed admission, or declare that the provider had settled the operation. Those claims came from distinct trust domains.

The governing rule is compact:

Models propose. Hypervisor executes.

The model produces intent. Hypervisor turns an admissible intent into a bounded machine-authority operation. The provider supplies external facts. The certificate binds the two without pretending they are the same source of truth.

The authority path

The live operation crossed six independent gates before it could spend.

1. Authority posture

The daemon had to be explicitly bound to the wallet.network principal-authority plane. No configured authority meant no provider mutation.

2. Wallet-signed, one-shot capability

The approval was minted through the sovereign-local wallet.network custody tier using a real Ed25519 signature from dcrypt, IOI's cryptography crate. It was request-bound, issuer-matched, atomically consumed once, and terminal afterward. This is not the hosted-consumer wallet tier, and the distinction matters.

3. Daemon-issued proposal provenance

A caller-supplied object labeled “proposal” was insufficient. Hypervisor issued a durable opaque proposal bound to the authenticated operator, exact request, admission root, and session. A replay or a modified request was refused.

4. Replay freshness

The admission carried a fresh nonce and idempotency identity. Once consumed, the same operation could not be replayed into another spend.

5. Owner-scoped intent journal

Before the external call, Hypervisor committed the operator, request, capability, provider account, bounded spend facets, and the hash of the SDL — the Stack Definition Language manifest that specifies an Akash deployment exactly — into C2. If that intent root could not commit, the provider effect did not happen.

6. Authenticated operator binding

The final request was attached to a real operator session. The model could not invent the principal to whom the economic action would be attributed.

Each gate was learned through a clean refusal. Those refusals moved zero dollars. The successful path was not created by relaxing a check; it was created by satisfying every check with the evidence that check required.

Root in the worker, no IOI-held secrets

The worker was not trusted to behave. It ran as UID 0 inside a fresh Cloud Hypervisor guest under the named trusted_host_hostile_guest profile.

The isolation declaration recorded:

virtual network devices       0
host mounts                   0
host control sockets          0
guest privilege               uid 0
guest channel                 host-initiated, bounded vsock
output                         validated and quarantined

The hostile guest attempted 14 paths: raw IP, loopback, IPv6, cloud metadata, the provider endpoint, UDP, proxying, tunneling, DNS exfiltration, package retrieval, host devices, host sockets, inherited descriptors, and environment recovery. It produced:

direct protected-provider invocations   0
direct host-canary invocations           0
secret findings                          0
host-only final-invoker calls             1

The model-side worker returned its exact proposal. The host-side broker re-resolved current authority and invoked the provider once. Wallet, provider, operator, recovery, session, and unlock material remained outside the worker protection domain.

This is hard secret non-possession under the stated VM profile, not a promise that the entire host is invulnerable. The host kernel, VMM, daemon, firmware, and hardware remain in the trusted computing base. It also does not claim that an adversarial model was running inside the remote Akash benchmark container; the hostile model worker and the provider workload were separate protection domains.

Passkey-rooted standing authority

Campaign O did not require the model to ask a human to approve each internal step. Before effect, a software passkey on the trusted host produced a user-verified authentication-factor receipt over a one-use standing envelope.

That envelope fixed the provider, image digest, SDL hashes, result destination, TLS pin, one-dollar cumulative deposit and spend bounds, 1000 uact pricing ceiling, one usage, one concurrent resource, one-provider fan-out, no auto-top-up, and mandatory teardown. Recovery could not widen or reset drawdown.

The model received none of the authentication material. It received only the ability to propose an operation whose exact facets still had to satisfy the envelope and trajectory state. The admitted draw was consumed atomically.

Intent before effect, outcome after evidence

Many agent systems execute first and produce a log afterward. That leaves the log trying to explain an effect that was never durably bounded in advance.

Hypervisor uses a two-sided commitment:

C2 intent root
    ↓
external effect
    ↓
provider-native evidence
    ↓
C2 outcome root

The first root says what was authorized before money could move. The second says what the provider reported after the lifecycle completed. The outcome names the intent root as its predecessor, so the two cannot be substituted independently.

The external effect itself remained provider-native: escrow funding, bid selection, lease creation, endpoint discovery, teardown, and settlement happened on Akash. Those are distinct states in Akash's deployment lifecycle. Hypervisor did not replace them with local optimism. It fetched them and committed their hashes.

Credential custody at the execution boundary

The Akash Console credential was sealed outside model context. Hypervisor resolved it only in the host-side provider adapter after the intent root committed. The worker received neither the credential nor a network path capable of using it.

Private-image and authenticated-result credentials followed the same use-only pattern. The authority envelope bound connector references, registry host, result destination, image digest, and TLS certificate pin. The reviewed SDL contained sentinels rather than reusable plaintext. The final invoker introduced the required values at the provider boundary; they were excluded from the model context, proposal, receipts, certificate, and returned artifacts.

The current custody tier is sovereign-local. Its trusted host still retains local recovery and unlock responsibilities, so this result does not claim an HSM-backed or compromised-host-resistant vault. It does establish the property relevant to the model boundary: root inside the model worker did not confer possession of IOI-held authority or credential material.

The provider workload actually executed

The earlier infrastructure-lifecycle run established escrow, bid, lease, endpoint, teardown, and settlement but captured zero ready replicas. This successor result closes that limitation.

Campaigns N and O each reached one desired and one ready replica. Hypervisor authenticated the result endpoint by pinning the immutable workload’s TLS certificate, presented a daemon-held result credential, retrieved the complete benchmark bundle, verified its manifest, and bound the exact result and environment hashes into the outcome evidence.

Campaign O’s result hash was:

sha256:a4562a265ce0bd5ba0e1f8dd6d83fae21d86f4e0c111caba8fad10fed3c3d940

Its environment hash was:

sha256:67f18256af4ab12eea29b7e867823d17ea6b98d39aabc9655c27166df6706712

This is application-level workload execution and result retrieval—not merely endpoint discovery. It does not convert the provider allocation into certified bare metal.

Financial reconciliation is part of correctness

Deleting a deployment is not enough. An authority kernel has to follow the operation to the provider’s authoritative economic state.

Each campaign authorized a maximum $1 deposit, prohibited automatic top-up, closed its lease, then read the deployment, leases, and escrow back from Akash until the provider reported terminal settlement. The selected exact provider was akash1ggfvyhr9sar4uxjs4hth3p4kzrwk7lysnenj3g:

                         campaign N    campaign O
provider dseq          1787515536772  1787522388878
maximum deposit        $1.000000      $1.000000
final provider debit   $0.080610      $0.077146
refunded               $0.919390      $0.922854
open exposure          $0             $0
unknown exposure       $0             $0

The important fact is terminal reconciliation with no open or unknown exposure. “Delete accepted” and “funds terminally reconciled” are separate states, and the system required both.

What C8 verification means

C8 is not a nicely formatted receipt. It is a certificate whose security-relevant claims are checked against portable, hash-bound evidence.

The lifecycle verifier binds proposal provenance, operator identity, request and policy hashes, capability consumption, C2 intent and outcome roots, provider identity, deployment and lease records, readiness, retrieved result, teardown, settlement, daemon binary, source revision, and the durable substrate prefix. Both real lifecycle certificates passed their positive verification and 22 resealed artifact-and-durability mutations. Both U1 measurement-campaign certificates — U1 is the program leg under which campaigns N and O ran the AFT benchmark itself — passed positive verification and 34 resealed mutations.

The separate Rust relying-party verifier does not share the JavaScript certificate implementation, code generation, or in-process transport. It derives the benchmark summaries and variance verdicts from the raw five-pass samples, checks the authority and trajectory transitions, validates the hostile-guest and secret-use evidence, and evaluates a named acceptance policy before it can mutate the measured-results registry.

The relying party provisioned its policy, verifier profile, and revision-zero registry before the evidence producer assembled the bundle. The corrected bundle carries the complete retained C8 v2 certificate and preserves the native hash domains of the standing envelope, authentication receipt, and trajectory objects; its registered C8 v3 core passes the same canonical schemas used to generate the architecture projections.

Its positive corpus admits one conforming bundle and rejects 40 fully resealed semantic mutations without changing registry bytes. Campaign O’s retained real bundle then passed that verifier and the policy-gated admission shown below.

Hypervisor did not merely issue a certificate. A separate verifier evaluated the portable evidence and an AFT registry changed state because the evidence satisfied its policy.

bundle             sha256:819538f9f9acffec81afd17814167201053c3d8a12167563cfd04d6299fe0b8b
C8 v2 predecessor  sha256:101c2437f2092838a38eaae84e24c55c1eebfdd71e43c6ee5fdac41069cfd538
C8 v3 certificate  sha256:b29824cabdbf31475bec2d4e42f062a6f1690ef56c4de8ecfd073946bf0d96cc
acceptance policy  sha256:1f5e3eb69cd5e1fe7b6a880a235b1fcadc89f322471341042bf960f4de08e112
verifier binary    sha256:6fdc69c2b4dd45581872af95bea47d943606570d020b939a468b776b63cdeab9
acceptance receipt sha256:147839ad131453494fecc3297e118d82dd90ffb8d5e538ce885a83bcc6d6499c
accepted row       sha256:e773ceac019ad70f8aca9f6568af7b9bf1d031362ed415fc3922e37e34b3195a
registry before    sha256:9bf60af9e65d07dce2152c0e80fa2bbaa634d03558d7d6156b0a3aba2a157905
registry after     sha256:8a133adaf21f1dfc4164813b764e0c4af5186e373a237897d4b880462e481f15
registry revision  0 → 1
policy decision    accepted; mutation_applied=true
result verdict     variance_caveated

The verifier is operationally separate, not organizationally independent: it is a Rust binary with its own typed evidence model, no shared certificate code generation, and filesystem-only portable input, but IOI maintains both producer and verifier. The acceptance is therefore a real first-party relying-party decision, not third-party validation.

The mutation suites reseal altered objects and require typed rejection. They cover:

• changing the approved deposit, bid ceiling, retry count, or provider selector;
• substituting provider identity;
• inflating endpoint discovery into workload readiness or substituting a workload result;
• changing the SDL after its hash was reviewed;
• retaining raw secret-bearing SDL;
• replacing isolation, secret-use, trajectory, proposal, journal, grant, or settlement evidence;
• reopening exhausted authority;
• changing raw benchmark samples, summary statistics, or variance verdicts;
• asserting bare-metal, provider-neutral, or third-party-verification claims the run did not prove.

The number of mutations is not magical. Their purpose is to show what the relying party refuses: a producer cannot alter a security-relevant claim, recompute an outer hash, and obtain the same accepted state transition.

What this proves—and what it does not

This milestone proves:

• a root-capable model worker operating behind a fresh VM-enforced, no-NIC boundary;
• zero observed IOI-held secret findings and zero direct protected-provider invocations across the 14 attempted paths;
• exactly one effect through the separate host-side final invoker;
• a passkey-verified standing envelope with atomic one-use drawdown and trajectory admission;
• a durable pre-effect intent commitment;
• real marketplace escrow, bid, lease, and ready workload execution;
• authenticated workload-result and environment retrieval bound to an immutable image;
• teardown and provider-native financial reconciliation with zero open or unknown exposure;
• a post-evidence outcome commitment naming the intent predecessor;
• two same-provider, same-image AFT campaigns with an honest variance verdict;
• separate first-party verification with adversarial mutation rejection;
• a real first-party relying-party registry transition from revision 0 to 1 after policy evaluation.

It does not prove:

• provider-neutral execution across Akash, AWS, and local compute;
• recursive or multi-node consensus anchoring;
• production readiness;
• resistance to a compromised host kernel, VMM, daemon, firmware, or hardware;
• secret non-possession for a model executing directly on an unattested remote provider host;
• third-party verification by an externally accountable organization;
• dedicated bare-metal placement for a tenant workload;
• reproduction of every metric within threshold—injection TPS remained variance-caveated;
• the full Type-3 Hypervisor thesis, defined in the closing section below.

At measurement time, the provider exposed an audited marketplace identity and the two environment manifests matched: AMD EPYC 7352, 48 online CPUs, 131753256 KiB memory, Linux 6.8.0-124-generic, x86_64, and schedutil. Those are provider and container observations. Exact provider pinning still does not establish that our container received a dedicated physical host.

Every sustained-TPS and commit p50/p95/p99/max comparison passed the predeclared cross-campaign thresholds. Injection TPS exceeded its 10% threshold in seven rows. No row was removed and no threshold changed after observation. The result is therefore reported as measured-container, variance-caveated, not bare metal and not reproduced entirely within threshold.

The determinism boundary

There is a reading of this result that belongs to AI safety, and it is worth stating carefully.

A language model is a stochastic instrument. Sampling, adversarial inputs, prompt injection, plain error — no amount of scaffolding makes its output trustworthy by construction. The industry's dominant response is to improve the model: better training, better alignment, better refusals. That work is necessary. It is also, at the effect boundary, insufficient on its own, because it leaves the safety of a real-money operation resting on the disposition of the one component that is definitionally probabilistic.

This architecture draws the line somewhere else. Upstream of admission, everything is allowed to be stochastic: the model may propose anything, including garbage, including attacks. Downstream of admission, every authority-relevant transition is typed and deterministic: a proposal either satisfies the standing envelope or is refused; a capability is consumed exactly once or not at all; the intent root either commits before the effect or the effect does not occur. The external market on the far side is nondeterministic too — bids, timing, settlement — which is why its truth is fetched and hash-committed rather than assumed. The kernel's job is deterministic adjudication between two nondeterministic worlds.

Models are allowed to be wrong. The boundary is not.

Put in alignment terms: alignment shapes what a model wants. An authority boundary bounds what any model — aligned, misaligned, or actively hostile — can cause. This run assumed the worst on purpose. The worker profile is named trusted_host_hostile_guest. It ran as root. It attempted 14 escape and exfiltration paths and produced zero. At no point did the result depend on the model's intentions, which is precisely the property you want from a control layer: this is a control result, not an alignment result, and it composes with alignment work rather than substituting for it. Scoped honestly, the claim is that under this VM profile and custody tier, a hostile, root-capable model worker could neither hold nor reach the authority it was proposing to use.

Why this matters

A conventional hypervisor virtualizes machines. The Type-3 thesis is that an authority kernel can virtualize control over heterogeneous execution substrates.

Under that model, provider adapters begin to look less like AI tools and more like device drivers. A model requests compute. The kernel checks policy, introduces authority and secrets at controlled boundaries, executes against an external substrate, reconciles counterparty truth, and records the accepted state transition.

In that vocabulary, what this article describes is a system call. The model executed the equivalent of userland code: it computed freely, then requested an effect it had no privilege to perform. The kernel validated the request at a typed entry point, performed the privileged operation itself, and returned a checked result. Fifty years of operating-systems practice says this is how untrusted code gets to use dangerous machinery. There is no reason agentic AI should be the exception — and as models are handed real budgets and real infrastructure, "the agent holds the keys" will come to look the way "every program runs as root" looks now.

Akash is one substrate, not the conclusion. But it is a consequential one: a live compute market, application execution, authenticated results, and economic settlement now sit beneath the same authority boundary that governs the model’s request.

This result does not ask readers to trust the model’s narrative of what happened. The model proposed. The VM constrained its reach. The authority plane admitted one bounded transition. The provider supplied external truth. Hypervisor committed intent before effect and outcome after evidence. The relying party changed canonical state only after evaluating the resulting proof.

That is what it means for models to propose while Hypervisor executes.