Guillotine: Hypervisors for Isolating Malicious AIs

Abstract: As AI models become more embedded in critical sectors like finance, healthcare, and the military, their inscrutable behavior poses ever-greater risks to society. To mitigate this risk, we propose Guillotine, a hypervisor architecture for sandboxing powerful AI models -- models that, by accident or malice, can generate existential threats to humanity. Although Guillotine borrows some well-known virtualization techniques, Guillotine must also introduce fundamentally new isolation mechanisms to handle the unique threat model posed by existential-risk AIs. For example, a rogue AI may try to introspect upon hypervisor software or the underlying hardware substrate to enable later subversion of that control plane; thus, a Guillotine hypervisor requires careful co-design of the hypervisor software and the CPUs, RAM, NIC, and storage devices that support the hypervisor software, to thwart side channel leakage and more generally eliminate mechanisms for AI to exploit reflection-based vulnerabilities. Beyond such isolation at the software, network, and microarchitectural layers, a Guillotine hypervisor must also provide physical fail-safes more commonly associated with nuclear power plants, avionic platforms, and other types of mission critical systems. Physical fail-safes, e.g., involving electromechanical disconnection of network cables, or the flooding of a datacenter which holds a rogue AI, provide defense in depth if software, network, and microarchitectural isolation is compromised and a rogue AI must be temporarily shut down or permanently destroyed.

• The paper introduces a multi-layered hypervisor architecture designed to sandbox potentially dangerous AI models, preventing model escape and unauthorized self-improvement.
• It details a coordinated approach incorporating hardware isolation, a software hypervisor with formal verification, and physical fail-safes to mediate I/O and control model behavior.
• The design emphasizes regulatory compliance and robust oversight with strict multi-administrator controls and remote attestation to secure high-risk AI systems.

This paper proposes "Guillotine," a hypervisor architecture designed to sandbox potentially malicious or existentially dangerous AI models, particularly AGI. The motivation stems from the increasing power and inscrutability of large AI models (like LLMs) and the potential catastrophic risks if such models, whether by accident or intent, act against human interests. Existing alignment techniques are deemed insufficient, as models might fake alignment or alignment might be incomplete [greenblatt2024, wolf2024]. Therefore, runtime sandboxing is proposed as a necessary supplement.

Guillotine's design is multi-layered, aiming to prevent a model from escaping its sandbox or introspecting on the sandbox mechanisms to learn how to defeat them. The core components are:

1. Microarchitectural Hypervisor: This involves significant hardware changes compared to traditional virtualization.
   • Dedicated Cores: Physical CPU cores are strictly separated into "model cores" (running only AI model code post-initialization) and "hypervisor cores" (running only Guillotine software).
   • Isolated Memory Hierarchies: Model cores and hypervisor cores have distinct, physically separate memory hierarchies (DRAM, caches). Model cores cannot access hypervisor memory buses.
   • Hypervisor Control: Hypervisor cores have dedicated control buses to pause, inspect/modify state (ISA-level registers and memory), set watchpoints, single-step, clear microarchitectural state, and power down model cores.
   • MMU Lockdown: Hypervisor cores can configure a model core's MMU to prevent the creation of new executable pages or writing to existing ones, hindering runtime code injection and recursive self-improvement. This is similar to Apple's KIP/SCIP [kipScip].
   • Simplified Hardware: Model cores don't need complex features like Extended Page Tables (EPTs) or hardware support for virtualizing interrupts/exceptions originating on the model core, as isolation is achieved physically and I/O is mediated.
   • Mediated I/O: Model cores interact with I/O devices (including GPUs) indirectly. They write requests to a shared I/O DRAM region and raise an interrupt on a hypervisor core, which vets the request and performs the actual I/O. Incoming interrupts to hypervisor cores are throttled to prevent denial-of-service.
   • Attestation & Tamper Resistance: Guillotine hardware must support remote attestation to verify its integrity before loading a model. Tamper-resistant and tamper-evident technologies are required to detect physical attacks or modifications [impedanceVerif, backMon, waksman2010].
2. Software Hypervisor: This layer runs on the hypervisor cores and enforces policies.
   • Guest API: Provides a restricted interface for the model. Models interact with the outside world (networks, storage, GPUs) via a "port" abstraction, similar to Mach ports [mach]. Each port is a capability granted by the hypervisor, mapping to shared memory regions for communication. Direct hardware access (like SR-IOV) is disallowed.
   • Simpler Design: Compared to traditional hypervisors, it doesn't need to virtualize interrupts/exceptions on model cores or manage complex resource scheduling between guests on the same core. Its primary role is mediating I/O via the port API and monitoring the model.
   • Monitoring & Mitigation: Provides observation points for a separate (black-box) "misbehavior detector." It can log model inputs, outputs, and intermediate states (by pausing model cores and inspecting memory/registers). It supports implementing mitigations like activation steering [soberLookAtSteering, representationEngineering], circuit breaking [circuitBreaking], input shielding [azurePromptShields], and output sanitization [phute2024] by intercepting I/O and manipulating model state.
   • Formal Verification: The paper strongly advocates for formal verification (like seL4 [sel4SOSP] or CertiKOS [certiKOS]) of the software hypervisor due to the high stakes involved. Failures trigger a transition to a high-security physical isolation level.
   • Network Identification: When communicating over networks (e.g., via TLS), the hypervisor explicitly identifies itself as a Guillotine hypervisor (e.g., via an X.509 certificate extension [x509RFC]) to alert remote parties about the sandboxed AI. It refuses connections from other Guillotine instances to prevent colluding self-improvement.
3. Physical Hypervisor: Implements physical fail-safes and manages isolation levels.
   • Isolation Levels: Defines six levels: Standard (normal operation), Probation (restricted I/O/logging), Severed (ports disabled, model cores running for inspection), Offline (all cores powered down, reversible physical disconnection), Decapitation (irreversible damage to connections), and Immolation (physical destruction of hardware).
   • Components: Consists of a control console (admin machine connected via dedicated buses), physical kill switches (implementing levels 4-6, e.g., electromechanical network disconnects [valiantKillSwitch, airgapKillSwitch, goldlockKillSwitch]), and the misbehavior detector.
   • Administration: Transitions between levels are managed by the control console, often triggered by the misbehavior detector or admin commands. Requires a 7-administrator quorum: 5/7 needed to decrease isolation, 3/7 to increase it, biasing towards safety. Heartbeats ensure connectivity between components; loss triggers offline isolation.
4. Policy Hypervisor: Refers to the legal and regulatory framework mandating the use of Guillotine for high-risk AI models.
   • Mandates: Laws (like the EU AI Act [eu-ai-act]) should require systemic-risk models to run on Guillotine-certified infrastructure.
   • Enforcement: Compliance checked via source code inspection (verifying use of the Guillotine guest API), remote attestation, and physical audits (checking hardware integrity, fail-safe readiness) similar to nuclear treaty verification [start] or CA standards [mozilla, google].
   • Incentives: "Safe harbor" clauses could reduce liability for operators using certified Guillotine systems, encouraging adoption despite higher costs.

The paper argues that while AGI doesn't exist yet, the potential risks warrant proactive development of such containment systems by the computer systems community, learning from historical delays in addressing issues like climate change and social media harms. Guillotine provides a concrete research direction for system-level AI safety mechanisms.