Skip to content
Capsem

Security Model

Capsem sandboxes AI agents inside Linux VMs. The security model treats the guest as fully untrusted and the host as the trusted computing base.

Threat Model

Section titled “Threat Model”
PartyTrust LevelGoal
Host (Capsem binary, macOS/Linux kernel)TrustedContain guest escape, protect host resources
Guest (AI agent, user code, guest kernel)UntrustedMay attempt sandbox escape, resource exhaustion, data exfiltration
Network (external services)ControlledDNS and HTTPS pass through host Security Engine boundaries before upstream dispatch

What Capsem defends against:

  • Guest code escaping the VM boundary
  • Guest exhausting host CPU, memory, disk, or file descriptors
  • Guest accessing network services outside profile-owned enforcement policy
  • Unaudited data exfiltration via HTTPS

What Capsem does not defend against:

  • Compromised host processes (they already have equivalent privileges)
  • Hardware side-channel attacks (mitigated by OS/firmware, not Capsem)
  • Denial of service against the guest itself (the guest is disposable)

Defense Layers

Section titled “Defense Layers”
LayerMechanismWhat It Protects
Hardware virtualizationApple VZ / KVMGuest cannot access host memory, devices, or kernel
Kernel hardeningNo modules, no debugfs, no IPv6, no swap, read-only rootfsReduces guest kernel attack surface
Network isolationAir-gapped NIC, DNS proxy, iptables, MITM proxyDNS and HTTPS are lifted into audited Security Events
Filesystem sandboxingVirtioFS with path validation, resource limitsGuest confined to workspace directory
Security EngineCEL enforcement, ask/confirm, detection, resolved eventsDecisions, findings, rewrites, telemetry, and logs share one event path
Build verificationCode signing, notarization, SBOMHost binary integrity

Profile Chain Of Trust

Section titled “Profile Chain Of Trust”
flowchart TD
    A["Capsem binary<br/>manifest signing public key"] --> B["signed manifest"]
    B --> C["profile id + revision + lifecycle status"]
    C --> D["signed/hashed profile payload"]
    D --> E["package/tool contract"]
    D --> F["VM asset declarations"]
    F --> G["downloaded assets verified by signature/hash"]
    G --> H["VM pinned to profile revision + asset hashes"]
    H --> I["boot with pinned verified assets"]

Profiles are the contract between enterprise intent and VM reality. A VM that does not carry profile id, revision, package contract, and asset pins is invalid for the bedrock release.

Trust Boundaries

Section titled “Trust Boundaries”
+------------------+          +-----------------------+
|   Guest VM       |  virtio  |   Host (Capsem)       |
|                  |<-------->|                       |
|  AI agent        |  vsock   |  Terminal bridge      |
|  Guest kernel    |  virtio  |  MITM proxy           |
|  Guest userland  |  fs      |  VirtioFS server      |
|                  |          |  Snapshot scheduler    |
+------------------+          +-----------------------+
                                        |
                                   Host kernel
                                   (macOS / Linux)

Guest/host boundary (virtio): All communication uses virtio devices (console, vsock, VirtioFS). The guest cannot directly access host memory or syscalls. The hypervisor validates all virtio descriptor chains.

Network boundary (DNS + MITM proxies): Guest DNS and HTTPS traffic are redirected to guest proxy binaries and forwarded over vsock to host Network Engine handlers. The Network Engine parses transport, builds typed Security Events, and applies Security Engine decisions. Per-session telemetry records resolved events plus HTTP/DNS projections.

Filesystem boundary (VirtioFS): The host VirtioFS server validates all path components, canonicalizes symlinks, and rejects any path that resolves outside the shared workspace. Resource limits prevent guest-driven host exhaustion.

Per-Layer Documentation

Section titled “Per-Layer Documentation”