Skip to content

Architecture

A secure execution layer for the code you can't fully trust

MVM runs any workload — an AI agent, a customer's code, a build job — inside a sealed, immutable, hardware-isolated microVM, on the laptop and in the fleet, with the security posture enforced by CI, not promised in a slide.

18security claims — 15 enforced, 3 preview
4runtime backends, one CLI
3workload sources, one signed contract
0guest NICs, SSH daemons, container fallbacks

View 1 · Zoom in

The MVM stack, top to bottom

Everything on the left runs on the host and is trusted. Everything on the right runs in the guest and is not. The only wire between them is vsock — the guest has no network card at all, so every byte that leaves it passes through host-side policy.

TRUSTED HOST · macOS / LINUX UNTRUSTED GUEST CHAIN-SIGNED AUDIT LOG 1 · Developer surface mvmctl CLI · language SDKs — code in, workload spec out 2 · Signed admission Every run becomes a signed ExecutionPlan — verified, policy-checked, replay-proof — before anything boots 3 · Runtime orchestration VM lifecycle · templates · checkpoints · one funnel every workload boots through 4 · Backend seam — one interface, interchangeable engines Firecracker Linux · KVM libkrun macOS 13–25 HVF macOS 26+ Wasm lightweight tier Host OS — Apple Silicon Mac or Linux/KVM · no Docker, no host Nix required Sealed microVM Your workload agent code · builds · customer jobs Guest agent speaks only vsock, runs unprivileged ✕ no network card ✕ no SSH, no shell in production ✕ no raw secrets in memory ✓ immutable, tamper-proof rootfs ✓ CPU / memory / wall-clock bounded vsock only Egress gate · default-deny host opens every connection, signs secrets in outbound request over vsock policy-admitted only Internet / approved endpoints
Fig. 1 — The MVM stack today. The guest boots with no network device; its only channel is vsock to the host, so authorization, secret substitution, and audit all happen at one enforced chokepoint. Click a layer to jump to its explanation.
  1. 1

    Developer surface

    One CLI (mvmctl) and language SDKs. A developer points MVM at code, a flake, or an OCI image and gets a running microVM — same commands on a MacBook and a Linux server. No Docker anywhere in the path.

  2. 2

    Signed admission — the security plane starts here

    Nothing boots ad-hoc. Every run is compiled into a cryptographically signed ExecutionPlan, verified, checked against policy, and recorded in a chain-signed audit log — tamper with the log and verification breaks. Image provenance, dependency scans (SBOM + CVE), and secret bindings all attach at this step.

  3. 3

    Runtime orchestration

    Lifecycle, reusable templates, and checkpoints. Critically, there is one funnel every workload boots through — a backend can't grow a side door, and CI has lint gates that fail the build if one appears.

  4. 4

    Backend seam — the portability story

    Interchangeable engines behind one interface: Firecracker (the AWS Lambda hypervisor) on Linux, libkrun on older Macs, our in-house Hypervisor.framework VMM on modern Apple Silicon — byte-identical artifacts across all three, with automatic fallback — plus an emerging Wasm tier for workloads that don't need a full VM. This is why "works on the laptop, ships to the fleet" is real, and why new isolation technologies slot in without rewriting the product.

  5. G

    The sealed guest — immutable by construction

    The workload runs in a hardware-isolated VM booted from an immutable, cryptographically verified image — flip a single block on disk and it refuses to boot, so there is no drift and no snowflake state; a new run is always a fresh, identical VM. No network card, no SSH, resource ceilings enforced at admission. Secrets never enter the guest — the host substitutes short-lived signed credentials into outbound requests at the egress gate, so a fully compromised workload still can't exfiltrate a raw key.

The differentiator isn't any one layer — it's that every security claim is wired to an automated check. Fifteen numbered claims (plus three in preview) each point to a specific test or CI gate that proves it still holds; delete that test and the build fails.

In most products a security guarantee can quietly rot after a refactor. Here, the rot shows up as a red build — the posture can't silently drift from the pitch.

View 2 · Zoom out

Where MVM sits inside a company

MVM slots in as the execution layer between the systems a company trusts and the code it doesn't. Work arrives from developers, CI, and AI agents; trusted systems plug into the host side; only policy-admitted traffic ever leaves.

WHERE WORK COMES FROM Developers laptops · mvmctl · SDKs CI / CD build & test jobs AI agent platforms autonomous code, sandboxed signed plans TRUSTED COMPANY SYSTEMS Image registry digest-pinned OCI Secrets manager keys stay host-side verified pulls brokered, never raw MVM · execution layer admission → policy → sealed microVMs agent run sealed VM customer job sealed VM build sealed VM eval suite sealed VM untrusted PR sealed VM …per-workload, hardware-isolated One VM = one workload · no shared kernel admission-bounded resources Runs on what the company already owns developer Macs · CI runners · Linux servers (fleet via mvmd) WHAT COMES OUT Audit & compliance SIEM · tamper-evident chain-signed trail every event External services APIs · model providers package registries default-deny policy-admitted only Results & artifacts outputs, checkpoints, reusable templates
Fig. 2 — MVM as company infrastructure. Trusted systems (registry, secrets) attach on the host side of the boundary; untrusted code runs inside it; the only outbound paths are the audited egress gate and the results themselves. Click a group to jump to its explanation.
  1. A

    The wedge: AI agents made this urgent

    Companies are handing autonomous agents the ability to write and execute code. Containers share the host kernel; a microVM doesn't. MVM gives each agent run a disposable hardware boundary with an audit trail — the thing a CISO asks for before agents touch production-adjacent systems.

  2. B

    Plugs into what exists

    MVM doesn't replace the registry, the secrets manager, or the SIEM — it connects them on the trusted side of the boundary. Images are digest-pinned and signature-verified on pull; secrets are brokered per-request; audit events are ready for compliance tooling.

  3. C

    Laptop to fleet is one product

    The same CLI and the same artifacts run on a developer's Mac and on Linux servers. The companion mvmd project extends this into multi-tenant fleet orchestration — pools, tenants, coordinators — which is the expansion path from single-developer tool to platform contract.

The one-sentence version: MVM is the layer where a company runs code it can't fully trust — AI agents, customer workloads, third-party dependencies — with hardware isolation, immutable execution, cryptographic admission, and a tamper-evident audit trail, from a single laptop to a fleet.

Every security property on this page is backed by a named test or CI gate in the mvm repository. Fleet orchestration is the companion mvmd project. · Read the docs