Vault Mode isolation

Vault Mode is for workloads where a policy boundary is not enough and the answer should be a different machine. It runs the workload in a pinned Linux guest under Apple’s Virtualization.framework, with a verified runtime manifest and one authenticated pipe back to the host.

What Vault isolation is not

Stated first, because this is the word most often used loosely:

• a sanitised set of environment variables
• a separate working directory
• an ordinary subprocess with fewer arguments
• a policy simulation
• a dashboard that says “isolated”

Each of those leaves the workload on the same kernel, sharing the same process table, sockets and filesystem namespace as everything else you own.

Two setup states, never collapsed

Vault host capability is whether the exact running, signed BitShout runtime artifact on this Mac can use Virtualization.framework for the selected Linux arm64 architecture. Vault runtime readiness is whether the trusted Linux manifest, kernel, optional initrd, root disk and guest helper are installed and verified.

A Mac can pass the first while the second says NOT READY, and that is setup required — not evidence that the machine cannot host a Vault. Collapsing these two states turns a missing download into a hardware verdict.

The diagnostic is passive by design: it performs no Keychain writes, no credential retrieval, no privileged setup, no runtime download, no VM start and no system-extension activation. It inspects the running binary’s signature and entitlement, calls VZVirtualMachine.isSupported, validates the manifest when present, and exits deterministically.

The authority chain

A capability request that originates inside the guest reaches the broker only after the trusted host service has validated all of:

• the stored Vault session
• an active Phase 1 containment session
• the registered protected subject fingerprint
• the authenticated helper runtime identity
• the bridge session ID
• an active BitShout-managed registry record
• the current security generation

Guest helper frames are typed, bounded assertions to be validated. They are never host authority, and nothing the guest says about itself is believed because it said it.

What was verified on hardware

The isolation proof ran live on a physical Apple silicon Mac with a signed artifact, the VM started through VZVirtualMachine.start(), and the guest helper authenticated over the virtio-socket bridge. The verified properties include:

• read-write workspace semantics, and the read-write scope boundary
• symlink escape denial from inside the guest
• host socket absence
• host process isolation observed through the guest’s own /proc
• guest-root filesystem, network and credential checks
• raw credential and socket bridge rejection
• unauthorized capability denial
• guest-private tmpfs destruction across a fresh VM start
• host-visible read-write workspace persistence

The authority-chain proof separately exercised guest-originated unauthorized denial, Phase 4 request creation, an allowOnce approval, exactly one successful use, the consumed-grant denial that must follow, concurrent allowOnce consumption, parameter and tool scope denial, broker-owned synthetic credential custody, raw credential and generic proxy rejection, session-scoped authority, live Panic Lock denial, lock-time authority mutation denial, recovery revalidation, correlated Phase 8 evidence, a secret scan, stale authority rejection, BitShout-owned orphan detection and cleanup, and fresh-session stale-authority absence.

The proof returned PHASE 9 PASS — VAULT MODE ISOLATION VERIFIED, with 125 evidence records checked, 105 correlated Vault records, all required events present, and no synthetic secret leakage.

Credentials

Moving an agent into a virtual machine achieves nothing if you mount your secrets inside it. The credential store stays host-side and broker-owned. A guest capability request crosses the same grant path as every other request, and what returns to the guest is the result of one approved operation.