Remove ambient authority first. Add narrow capability second.
Some work should not run on your Mac at all. Vault Mode moves the workload into a real virtual machine under Apple's Virtualization.framework — a pinned Linux guest with a verified manifest, no host sockets, no view of host processes, and exactly one authenticated pipe back to the broker.
What Vault Mode is not.
"Isolated" is the most abused word in this category. Vault Mode uses the word only for the thing the hardware and the hypervisor actually provide, and the list on the right is what people usually mean when they say it and have not built it.
The distinction is not academic. Every item on that list leaves the workload on the same kernel, with the same process table, the same sockets, and the same filesystem namespace as everything else you own.
Not Vault isolation
- A sanitised set of environment variables
- A separate working directory
- An ordinary subprocess with fewer arguments
- A policy simulation
- A dashboard that says “isolated”
What was actually verified, from inside the guest.
These are not design intentions. Each was exercised 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.
Isolation properties
- Read-write workspace semantics and scope boundary
- Symlink escape denial from inside the guest
- Host socket absence
- Host process isolation through guest /proc
- Raw credential and socket bridge rejection
- Unauthorized capability denial
- Guest-private tmpfs destroyed across a fresh VM start
- Host-visible read-write workspace persistence
The authority chain a guest request must satisfy
A capability request originating inside the Linux guest does not reach the broker until the trusted host service has validated all of these:
- Stored Vault session
- Active containment session
- Registered subject fingerprint
- Authenticated helper runtime identity
- Bridge session ID
- Active BitShout-managed registry record
- Current security generation
Guest frames are assertions, never authority. Nothing the guest helper sends is trusted because it said it. Every frame is typed, bounded, and validated host-side against state the guest cannot influence.
The vault does not travel with the workload.
Moving an agent into a VM is pointless if you mount your secrets inside it. In Vault Mode the credential store stays host-side, owned by the broker, and a guest capability request crosses the same Phase 4 grant path as everything else. The guest receives the result of an approved operation.
The live proof exercised guest-originated denial, a one-time allowOnce approval, the consumed-grant denial that must follow it, concurrent consumption, parameter and tool scope denial, broker-owned credential custody, raw credential and generic proxy rejection, Panic Lock denial during a live session, and recovery revalidation.
Two states, deliberately not merged.
BitShout separates whether your Mac can host a Vault from whether the Vault runtime is installed, because collapsing them turns a missing download into a hardware verdict.
- Vault host capability
- Whether this exact signed BitShout runtime can use Virtualization.framework for the selected Linux arm64 guest. Checked passively — no Keychain writes, no downloads, no VM start.
- Vault runtime readiness
- Whether the pinned kernel, root disk, guest helper and manifest are installed and verified. If they are not, that is Setup required, not Unsupported.