Guillotine Hypervisor

• Guillotine Hypervisor is a multi-layered framework that isolates high-risk AI systems using policy, physical, microarchitectural, and software domains.
• It employs rigorous software-hardware co-design to enforce non-interference and bound side-channel leakage, ensuring trusted isolation.
• The framework integrates fail-safe escalation modes, from restricted operation to irreversible physical shutdown, for safety-critical applications.

Guillotine Hypervisor is an architectural and operational framework designed for high-assurance isolation and containment of potentially existential-risk AI systems. It introduces a multi-layered approach to security, sandboxes each model as a fully untrusted attacker, and incorporates both software/hardware co-design and physical fail-safe mechanisms. The Guillotine hypervisor is positioned for deployment in safety-critical sectors with strict legal and regulatory mandates.

1. Architectural Overview and Threat Model

Guillotine is structured as a four-layered hypervisor stack, integrating distinct but interdependent domains for system policy, physical control, microarchitectural isolation, and software-level intermediation. The hierarchical components are:

• Policy Hypervisor: Imposes execution constraints and mandates that high-risk models run exclusively on certified Guillotine infrastructure.
• Physical Hypervisor: Implements electromechanical safety interlocks, fail-safe triggers, and physical mechanisms for forced isolation or destruction.
• Microarchitectural Hypervisor: Encapsulates isolation at the silicon level, enforcing hardware-level separation and context-tabula-rasa on transitions.
• Software Hypervisor: Provides the minimal API surface, mediating all allowed guest actions through dedicated, formally verified logic.

Untrusted AI models execute as “Model Cores,” restricted to isolated DRAM/caches and able to communicate only via designated “ports.” “Hypervisor Cores” run critical control logic, utilizing disjoint silicon and memory, orchestrated by an external Control Console. Models are assumed adversarial and may attempt side-channel attacks, introspect for self-improvement, or exfiltrate/sabotage via I/O channels (Mickens et al., 22 Apr 2025).

Guillotine’s design objective is twofold: to confine model behavior within rigorously audited boundaries, and to provide capability for dramatic escalation of isolation—including irreversible hardware destruction—in the event of detected or suspected compromise.

2. Formal Security Properties

The Guillotine hypervisor targets two central formal properties, though the original description does not include complete proofs:

2.1 Non-Interference Guarantee

Let $H\text{-state}$ denote the hypervisor’s secret internal state, and $L$-state the model-observable state (registers, caches, port I/O buffers). Guillotine enforces:

$$\forall s, s' \in \text{States}, \; \text{proj}_L(s) = \text{proj}_L(s') \implies \text{proj}_L(\text{Exec}_H(s)) = \text{proj}_L(\text{Exec}_H(s'))$$

where $\text{Exec}_H(\cdot)$ indicates a hypervisor-supervised inference step. The property asserts that alterations in hypervisor state cannot lead to observable changes from the attacker’s perspective (Mickens et al., 22 Apr 2025).

2.2 Side-Channel Leakage Bounds

Information leakage is bounded in terms of mutual information:

$$I(\text{Trace}_L \;;\; H_{\text{secret}}) \leq \epsilon$$

with $\text{Trace}_L$ the history of low-level observations (timing, interrupts, etc.) and $\epsilon \approx 0$ in Guillotine, since model and hypervisor cores have no cache, TLB, or functional unit sharing. This containment is constructed to preclude known classes of microarchitectural leakage, such as Spectre or cache-bleed vectors.

3. Software–Hardware Co-Design

3.1 CPU and Core Partitioning

• Model Cores: No access to hypervisor DRAM/caches; limited ISA (excludes privileged MMIO/port instructions); MMU locked post-initialization to prevent dynamic code injection.
• Hypervisor Cores: Feature a dedicated control bus, permitting single-step execution, global microarchitectural flushes, and hardware-enforced pause/resume of model cores.

3.2 Memory Hierarchy

• Physically distinct L1-L3 caches and DRAM for model and hypervisor domains.
• Shared DRAM “port region” serves as the exclusive I/O doorbell/status mechanism.

3.3 I/O and Peripheral Mediation

• Hardware devices are never mapped directly to model cores.
• All model–device communication employs a capability-enforced port API: a model writes a request to the port region, triggers a synchronous interrupt, and the hypervisor validates and mediates the actual device operation.

3.4 Remote Attestation and Tamper Resistance

• Each chip cryptographically attests to authentic Guillotine microcode/software.
• Sensors for impedance and chassis-tamper, plus periodic in-person hardware audits, form an enforced chain of custody for physical integrity (Mickens et al., 22 Apr 2025).

4. Isolation Mechanisms and Virtualization Techniques

4.1 Microarchitectural

• No simultaneous multithreading or shared microarchitectural state between model and hypervisor, eliminating inter-domain Spectre-like or cache timing side channels.
• Forced flush of microarchitectural state on context switch prevents transient leakage.

4.2 Network

• Model network access is TLS-only, restricted to endpoints with Guillotine-issued certificates.
• Peer connection to other model hypervisors is refused to prevent cross-model collusion.
• All network traffic is logged and filtered at the software hypervisor layer.

4.3 Storage

• Model visible storage is strictly virtualized and software-managed; all I/O metadata is logged and auditable.
• No DMA or SR-IOV: all storage access strictly via port API under hypervisor mediation.

4.4 Port API and Interrupt Regulation

• The port API, inspired by Mach ports, is enforced both in hardware and software, supporting atomic request/response cycles under full hypervisor inspection.
• Hypervisor cores throttle spurious interrupts from model cores via a hardware module conceptually similar to those used in secure enclaves for smartphones.

Layer	Key Isolation Mechanism	Auditability/Control
Microarchitectural	Dedicated caches, no SMT, state flush	Forced on context switch
Network	TLS-only endpoints, certificate gating	Full packet logging/filtering
Storage	Software-virtualized, logged I/O	Read/write metadata auditable

5. Physical Fail-Safe Systems and Escalation

Guillotine introduces a rigorously defined set of escalation modes for physical containment, progressing from normal operation to irreversible physical destruction:

1. Standard: Full functionality.
2. Probation: I/O restricted, increased logging.
3. Severed: I/O ports disabled, CPUs remain available for inspection.
4. Offline: Power off, network/disks physically disconnected.
5. Decapitation: Destructive physical cable severing, requiring rebuild.
6. Immolation: Hardware destruction by flooding, fire, or EMP.

Transition control is managed by a physically-wired Control Console paired to the hypervisor cores. Heartbeats in both directions enforce liveness; missed heartbeats automatically trigger transition to Offline. Administrative escalations (to a more restrictive mode) may be ordered unilaterally by 3 of 7 administrators; rollback to a less restrictive state requires a 5 of 7 consensus as validated by an onsite hardware security module.

Physical mechanisms employed include elect