Internet of Intelligence

Hypervisor Daemon Roadmap

The Hypervisor Daemon is the runtime under every Hypervisor client. It runs on a node its user controls and needs no network and no blockchain. Its job is to put every effect an agent causes (network, credentials, model and tool calls, spend, delegation) through one monitor that records the intent, decides it under the user’s policy, and leaves a signed receipt. A private pre-Alpha build runs locally today, and the Alpha exit tests below are the work in progress. Next: every Alpha test met, each with a verdict recorded by an independent reviewer.

Hypervisor Daemon

The Hypervisor Daemon is the runtime under every Hypervisor client. It runs on a node its user controls and needs no network and no blockchain. Its job is to put every effect an agent causes (network, credentials, model and tool calls, spend, delegation) through one monitor that records the intent, decides it under the user’s policy, and leaves a signed receipt. A private pre-Alpha build runs locally today, and the Alpha exit tests below are the work in progress. Next: every Alpha test met, each with a verdict recorded by an independent reviewer. Its records span Built and released through Horizon 4 — hosted, attested and embodied.

Records

14 records, each with its own status, horizon and evidence.

  • IIP-005: Runtime daemon v0: Bounded preview, Built and released. The local daemon: sessions, harness launches, policy, approvals, environments and receipts behind one HTTP API, with Rust services underneath.
  • IIP-075: One monitor for every boundary effect: Active implementation, Horizon 0 — building the governed core. Every effect a guest agent can cause (network, credentials, model and tool calls including MCP and connectors, business actions, spend, delegation) crosses one small reference monitor. The monitor records the intent before dispatch, decides it under policy, and reconciles the outcome. Guests run in isolated cells that fail closed.
  • IIP-069: Approvals mid-run, exactly bound: Active implementation, Horizon 0 — building the governed core. When policy says ask, the guest pauses and the request lands in the Inbox. The approval binds the exact arguments, target versions, an expiry and a one-time nonce; it is signed with a passkey and rechecked just before dispatch. Standing permissions can be set once, so routine work needs no prompt. An agent can forward a request but never an approval.
  • IIP-070: Receipts anyone can verify offline: Active implementation, Horizon 0 — building the governed core. A run exports as a session whose signed, chained receipts verify on a clean machine with only a verifier and independently trusted roots, and whose recorded inputs replay to the same decisions.
  • IIP-058: Run control, spend and observability: Active implementation, Horizon 0 — building the governed core. Runs are asynchronous and stream events live. Kill and revocation take effect within fixed bounds, budgets count in-flight reservations against per-effect ceilings, and every run exports OpenTelemetry spans.
  • IIP-019: Durable state, recovery and scale: Active implementation, Horizon 0 — building the governed core. An append-only store for effects and receipts. A crash at any dispatch boundary leaves idempotent effects done exactly once and ambiguous ones marked unknown for reconciliation, never retried blindly. Recovery and per-tenant limits hold under load.
  • IIP-053: Any harness, any model provider: Active implementation, Horizon 0 — building the governed core. One policy governs the coding-agent harnesses people already use (Claude Code, Codex, OpenCode, Gemini CLI, or any CLI with no hooks), on hosted or self-hosted models, local ones included.
  • IIP-078: Hypervisor Alpha: Planned, Horizon 1 — Hypervisor Alpha on one node. Every Alpha exit test met on one node, each with a recorded verdict: a verified starting point, any harness and model, the monitor, approvals, receipts, typed actions, agents as entities, a learning plane that earns its place, evaluate-improve-release, security under attack, run control, one app and public API, scale and recovery, dogfooding, the operators’ drill, vendor exit, and fault survival. Alpha means ready to dogfood. It is not a launch.
  • IIP-076: Typed business actions over your own ontology: Planned, Horizon 1 — Hypervisor Alpha on one node. High-impact actions (deploy, merge, rotate a secret, delete, spend above a threshold, send an external message) run only through action contracts with preconditions, postconditions and compensation, written over the organization’s own ontology and importable from existing ontology systems.
  • IIP-020: Agents as entities: install, identity and delegation: Planned, Horizon 1 — Hypervisor Alpha on one node. A packaged agent installs into a tenant and runs with its own identity under the tenant’s policy. Installing grants nothing: authority comes from a grant made by a person or organization, which stays accountable. A child’s authority is a subset of its parent’s, budgets are reserved from the parent, and revoking a grant stops every descendant. Track records derive from receipts, and compositions of several agents build on the same objects.
  • IIP-077: Vendor exit, tested: Planned, Horizon 1 — Hypervisor Alpha on one node. A system exports into a clean deployment its owner controls (its ontology, action contracts, agents, skills, policy and evidence) and keeps running on a different model provider with our access revoked.
  • IIP-027: Opt-in network services: Evidence-gated, Horizon 3 — two independently owned systems. A Hypervisor node can choose to use a network service (anchor a commitment, open an escrow, join a registry) without the runtime depending on any chain. Without that choice, nothing in the node needs the network.
  • IIP-057: Hosted and attested runtime nodes: Speculative horizon, Horizon 4 — hosted, attested and embodied. The same runtime on hosted machines, with the receipt-signing key moved into an attested enclave so receipts can be trusted without trusting the operator.
  • IIP-067: HypervisorOS bare-metal profile: Speculative horizon, Horizon 4 — hosted, attested and embodied. Speculative Type 1 node profile with the daemon as node root; there is no HypervisorOS build today

Evidence

Each link is a paper, release, repository path or published evidence bundle behind a status on this page.