Confidential AI-First OS.

x0ne OS is a Debian-based distribution for cybersecurity and AI security, offensive and defensive. It runs AI on your own machines, or on confidential cloud GPUs with x0ne Engine.

Confidential mode: your prompts are processed in a VM with encrypted memory, on a GPU in confidential mode. The hardware signs a proof, and your computer checks it before sending anything.

Download x0ne OS

ISO Live USB Container Google Cloud
More
qcow2 VM microVM Other clouds

checksums and signature, apt repository, handbook

Latest news

  1. 287 tests pass, 7 suites11 expected failures with a written reason, 3 skipped. First boot, text banner, boot splash, microVM launcher.
  2. Handbook onlineOne task per page.
  3. microVM boots in 0.64 sTo the login prompt, under Firecracker.
  4. First build: 88 tests passDebian 13 base, 8 metapackages, built in containers.

Debian security news

  1. Loading…

Others AI and AI security

  1. Loading…
Why x0ne OS

Attack, defend, and run AI at home

One Debian system for security work and local AI. No cloud required.

Offense and defense

Offensive and defensive security tools, for and with AI. Install them as metapackages, as needed.

On-premise AI

Run models on your own machines with x0ne Engine. Your data stays with you.

Debian stable underneath

Debian 13 (trixie) and its security support. x0ne OS adds one signed repository.

Maintained by AI agents

Agents will watch Debian security advisories, rebuild and test. A human signs every release.

Verifiable builds

Reproducible builds today. Signed packages and images, with an SBOM, come next.

A real handbook

One task per page, exact commands. Read the handbook.

Philosophy

Built to be run by an AI agent

x0ne OS is built to be operated by an AI agent, with a human in charge. The agent itself, the x0ne Harness, is not packaged yet (0.2). Planned: a VM started with its own screen, driven by the agent, watched live by a human.

What the agent gets

  • State it can read: the hardening audit answers in JSON (x0ne-hardening status --json, watch --json).
  • Changes it can undo: settings move by drop-ins in /etc/x0ne/hardening.d, never by editing a shipped file.
  • Little power: x0ne-agent adds an agent user without root rights, with rootless podman.
  • Throwaway work in microVMs.

What stays human

  • The release key, generated on an offline machine.
  • Every release signature: the passphrase comes from a person at the terminal, never from a file.

Hardening and the live audit, in the handbook

Manual

The short version

x0ne OS, as a manual page.

X0NE-OS(7)x0ne ManualX0NE-OS(7)
NAME
x0ne OS, the confidential AI-first OS
SYNOPSIS
apt install x0ne-base x0ne-ai-local x0ne-ai-redteam x0ne-engine
DESCRIPTION
A Debian-based system for cybersecurity and AI security, offensive and defensive, and for running AI locally.
BASE
Debian 13 (trixie), with Debian's signed kernel.
MAINTENANCE
Designed to be maintained by AI agents, with human sign-off on every release. The maintainer agent is planned.
OPERATION
By an AI agent, with a human in charge. The agent is not packaged yet (0.2).
ARCHITECTURES
amd64. arm64 later.
INTERFACE
Headless first. A desktop comes as one more metapackage.
SEE ALSO
x0ne OS Handbook, x0ne harness, x0ne Engine, x0ne.training, HackMachina
Download

Get x0ne OS

No public release yet. First the amd64 live ISO and the signed repository, then the microVM, container and VM images. Cloud images, the installer and arm64 come later. Always check the signature before you use an image.

ImageForStatus
amd64 ISOLive system for a USB key. BIOS, UEFI and Secure Boot. Builds today, bit for bit reproducible.Next
microVMQEMU microvm and Firecracker. Login in under 1.5 s.Next
VM image (qcow2)QEMU/KVM, libvirt and test labs.Next
ContainerThe minimal system as x0ne-os:base, for CI pipelines and test labs. 3.9 MB more than Debian slim, for sudo. Run the container image.Next
Checksums and keySHA256 sums of every image, their signature, and the key that signs them.Next
Cloud imagesOVHcloud and Scaleway first. See Clouds.Later
Installer, arm64Network installer (builds today, unattended install tested), and the live ISO for 64-bit ARM.Later

Humans sign every release.

verify an image
$ gpg --verify SHA256SUMS.sig SHA256SUMS
$ sha256sum --check --ignore-missing SHA256SUMS
microVM first

A full VM at container speed

x0ne OS as a microVM: its own kernel and hardware isolation, no firmware, no PCI. Target: login in under 1.5 s, measured on each release. Builds from source, not published yet. Measured on 2026-10-09, 20 boots each: login prompt in 0.64 s under Firecracker, 0.85 s under QEMU microvm.

Small by default

x0ne OS starts from a minimal Debian base, with no recommended packages. Everything else is a metapackage you add when the job needs it.

The same base ships as a container image and as a VM image.

Two kinds

  • Interactive: a shell in a fresh VM, one per agent, lab or test.
  • Service: one service per microVM. It boots, serves, and holds nothing else.
  • CPU only: Firecracker and QEMU microvm do not pass a GPU through.

Run as a microVM, in the handbook

On-premise AI

Your models, your machines

x0ne Engine is the inference engine of x0ne OS. On your own machines it runs as a lab build, not confidential; confidential serving needs an Intel TDX host, and an NVIDIA H100 or H200 in confidential mode for the GPU. x0ne OS builds the system around it. Planned for later.

What you get

  • x0ne Engine, in Rust. CPU and NVIDIA GPUs.
  • One model store, shared read-only by services, containers and VMs.
  • Inference services with no outbound network.
  • llama.cpp and Ollama: optional, never installed by default.

Measured, not promised

Benchmarks are targets today, not results. Measured numbers ship with each release, with the hardware they ran on.

On-premise AI · GPUs, in the handbook

Confidential computing

Prove the machine, then send the prompt

x0ne OS runs as a confidential VM guest: Intel TDX, with NVIDIA Hopper GPUs in confidential computing mode; AMD SEV-SNP is planned. Boot is measured, and each release publishes its launch measurements. Next.

  1. ChallengeThe client sends a fresh nonce.client
  2. ReportThe VM returns signed CPU and GPU reports.confidential VM
  3. CompareAgainst the measurements published for this release.client
  4. SendMatch: the prompt or the model key goes in.only if it matches
  5. RefuseNo match: nothing is sent.otherwise

Works with x0ne Engine, which refuses to serve outside a verified trusted execution environment. Confidential computing, in the handbook.

Hardening

Hardened by default

What the build and test suites check today, image by image. Each line has a test behind it. How to verify each one yourself, and its limits, in the handbook.

Chain of trust

  • One apt repository, signed; every apt source names the key (Signed-By).
  • Release file with SHA-256 sums, valid seven days. apt refuses a rogue key, a tampered index or package, an expired Release.
  • Live ISO, installer and package lists in a signed SHA256SUMS; a truncated image fails the check.
  • Reproducible packages and ISO: same inputs, byte-identical output.
  • A package list per image, boot chain included; no fixable critical CVE at build time.
  • Packages: lintian clean, root-owned, no setuid, no world-writable file; no private key in any image.

Boot and disk

  • Secure Boot with Debian's signed shim, GRUB and kernel: live ISO, installer, dedicated-server image.
  • LUKS2 full-disk encryption, argon2id, on installed systems.
  • Remote unlock over SSH from the initramfs: one key, one command, no forwarding.
  • SSH host keys made at build time and printed: no trust on first use.
  • The passphrase from the install medium is replaced at first login; the old one is refused.
  • Kernel lockdown integrity under Secure Boot; microcode in the early initramfs.

Accounts and access

  • Root locked, no default user, no usable password, in every image.
  • First boot creates one sudo account: hashed credential only, 12 characters minimum, never logged.
  • No SSH server installed; nothing listens at boot (tcp=0 udp=0).
  • Where sshd is installed: public keys only, no root login; RSA keys refused at build.
  • Serial console: a login prompt, never a shell; no rescue shell in the microVM initrd.
  • Secrets never on a command line; install media are private and hold no clear account password.

Updates

  • Debian security updates and the x0ne stable channel, daily, no automatic reboot. Nothing else upgrades on its own.
  • The x0ne repository never overrides a Debian package (NotAutomatic, priority 100).
  • Recommended packages off: fewer packages installed.
  • Two channels, stable and edge; edge is opt-in.
  • Third-party source (Google Cloud SDK): vendored key, pinned to its own packages.

Confidential VM

  • One UKI booted directly, dm-verity root, every writable path in RAM.
  • Expected measurements published; the TPM event log is replayed against them in the test suite.
  • nftables: inbound TCP 443 and ICMP only; forwarding dropped.
  • Inference service: own user, one capability, strict systemd sandbox, allow-listed devices.
  • No sshd, no guest agent, no cloud-init, no console login.

Live USB

  • Runs from RAM: the medium is never written, nothing survives a reboot, no swap.
  • Authenticated time (NTS) from three operators.
  • x0ne stable channel configured; no Engine or Harness binary pre-installed.

Not done yet, kept in the roadmap: a release key held offline (today a throwaway test key signs everything, nothing is published), a measured-boot general-purpose VM image (the confidential VM image already boots measured), a corresponding-source archive per ISO, an SBOM shipped with each release. Both the key procedure and the measured-boot image have code and tests on a branch.

Clouds

The same system, on your cloud

Cloud images for amd64 and arm64. Your SSH key through cloud-init, no password. Planned for later, in this order.

OrderProviderWhy
1OVHcloud, ScalewayEuropean, sovereign.
2HetznerLow cost: tests, CI, microVMs.
3Google CloudLarge scale and confidential computing: TDX, H100 in confidential mode.
laterAWS, Azure, OpenStackOn demand.

Cloud images, in the handbook

Roadmap
  1. Next

    amd64 live ISO for a USB key, reproducible. Signed apt repository. microVM, container and VM images, with SBOM. Confidential VMs.

  2. Later

    On-premise AI on NVIDIA and AMD GPUs. Cloud images. Installer and arm64. The maintainer agent: it watches Debian, rebuilds and tests, and a human signs each release.

features

What is done, what is next

Written from the repository's FEATURES.toml. On a measured line the date is the first run on a real confidential VM that exercised the feature; on a tested line, the first proof.

Done, measured on hardware 9

  • A confidential VM image, root in read-onlyThe image boots one signed file, a verified read-only root and everything writable in RAM; no SSH server, no agent, no login.
  • The image's reference, computed from the imageA script writes the image's reference (boot file digests, kernel, partition event, firmware policy); its boot measurements matched three real boots.
  • The engine built for the H100, reproduciblyThe image's engine is built with CUDA 13.2 for the H100 and must come out with the same bytes twice.
  • Boot measurements predicted before a bootA script replays an earlier boot's event log with the new digests; three real Google Cloud boots predict each other in the tests.
  • Instance settings and the NVIDIA key, never printedAfter the measured boot, the instance settings and the NVIDIA key reach the engine through files in RAM; the console never sees the key.
  • The console shows service states onlyThe boot report and the status block print unit states and exit codes only, never a journal line; kernel faults are silenced.
  • The firmware's boot events pinned from real bootsThe reference pins the 16 firmware boot events of the a3 machine type from three Google Cloud boots, each replaying to its own proof.
  • The metadata server answers root aloneSince 0.2.8 only root reaches the cloud metadata server; 0.2.7 gave the NVIDIA key to every user of the VM.
  • The host's two ways into the guest's init, closedThe boot command line stops the init from reading a firmware variable the host can write, and closes the host-provided credentials.

Done, tested 24

  • Debian 13 plus x0ne metapackagesx0ne OS is Debian 13 plus signed x0ne metapackages (keyring, base, hardening, network, agent), built and tested in throwaway containers.
  • One signed apt repository, two channelsOne signed apt repository: a stable channel with the pinned Engine commit and an edge channel with the latest build; nothing published yet.
  • A bootable disk image for UEFI machinesThe qcow2 boots on UEFI with systemd-boot: root locked, no SSH server, hardening and audit on; 268 to 299 MB.
  • A boot splash screenA Plymouth theme with the x0ne honeycomb, logo, progress bar and password field, on the qcow2 and the live ISO.
  • A microVM image: login in 0.64 sA 64 MiB root image reaches the login prompt in 0.64 s under Firecracker and 0.85 s under QEMU microvm.
  • Daily Debian security upgrades, no automatic rebootThe qcow2 and ISO images install Debian's security upgrades daily, from that one origin; nothing else upgrades on its own.
  • Packages that build the same twiceTwo builds with the same source date give byte-identical packages; a test checks it.
  • A base container imagedebian:trixie-slim pinned by digest, plus the keyring and x0ne-base; the x0ne source is present but disabled until publication.
  • Live and installer ISOs on Debian's Secure Boot chainmake iso builds a live ISO and an installer on Debian's signed shim, GRUB and kernel; the live system runs from RAM.
  • An unattended server installermake installer-auto builds a private installer ISO with hostname, user, SSH key, disk and locale; tested unattended under qemu.
  • An encrypted image for OVHcloud servers, unlocked remotelymake byoi builds an encrypted dedicated-server image with remote unlock from the early boot; tested under qemu against a fake OVH API.
  • A plain first-stage image for OVHcloudmake byol builds the one-partition cloud-init qcow2 that OVH's Bring Your Own Linux expects.
  • A launcher, and one service per microVMx0ne-vm starts a microVM with memory, CPU and port options under Firecracker or Cloud Hypervisor, one service per microVM.
  • First boot creates one administrator; root stays lockedImages ship no user and no password; the first boot asks for one administrator account and root stays locked.
  • Engine packages from a pinned commit, fixes checkedEngine packages are built from a pinned commit; the repository refuses an Engine commit that lacks a required security fix.
  • 98 hardening rules, audited livex0ne-hardening applies and reads back 98 rules from ANSSI, CIS and the kernel self-protection project; its audit answers in JSON.
  • The confidential image rebuilt the same from two clonesmake test-cvm rebuilds the image from two fresh clones under two umasks and requires the same root hash, boot file and reference.
  • A server package: firewall, fail2ban, login recordsThe opt-in server package adds a drop-by-default firewall, fail2ban on SSH, login records, strict source checks and a reboot on kernel oops.
  • The source archive of each ISOmake sources builds the corresponding-source archive of an ISO with its manifest; two builds give one SHA-256.
  • The archive key ceremony, rehearsedOffline key generation, rotation and revocation are documented; signing a release is rehearsed with a throwaway key in containers without network.
  • Test coverage of scripts and targets, with a ratchetmake coverage marks each script and target a test reaches; the check fails below the baseline, which only ever rises.
  • One banner per login, as a login messageThe banner is printed once per SSH or console login as the login message, never from su, sudo or a plain shell.
  • The image's sources, and a verifiable distribution treemake cvm-sources builds the image's source archive; make dist publishes reference, measurements and log proof; verify-dist checks them all.
  • No restart loop after a refusalsystemd no longer restarts the engine every 10 s after a refused key or a machine that is not confidential.

Next 6

  • Local AI tools in one packagePlanned: x0ne-ai-local with a local inference runtime and model tools; today the package is partial, as llama.cpp and Ollama are not in Debian 13.
  • AI red-team tools in one packagePlanned: x0ne-ai-redteam with garak and modelscan; today it pulls pipx, a Python venv and safetensors only, the tools not being in Debian.
  • An NVIDIA GPU packagePlanned: an opt-in package for NVIDIA GPUs on your own servers, from an opt-in repository; not built, decision pending.
  • arm64 images, and Secure Boot on the disk imagePlanned: arm64 images and microVMs, and Secure Boot on the qcow2; none exists yet.
  • The x0ne Harness in the apt repositoryPlanned: a Harness package, pinned and built here like the Engine; x0ne OS 0.2 has none yet.
  • A maintainer agent, with human sign-offPlanned: an agent that watches Debian's security advisories, rebuilds and tests; a human signs each release. No code implements it yet.
Replaced 3
  • The banner printed by a shell scriptUp to 0.2.0~beta3 a profile.d script printed the banner in login shells, twice over SSH; the login message replaced it. replaced by One banner per login, as a login message
  • The status block copying the journal to the consoleUp to x0ne-cvm 0.2.4 the status block copied eight journal lines to the console; 0.2.5 prints service states only. replaced by The console shows service states only
  • A CPU-only engine in the confidential imageThe first confidential VM image carried the repository's CPU-only engine, which exited 80 refusing CUDA; the H100 build replaced it. replaced by The engine built for the H100, reproducibly
Documentation

The x0ne OS Handbook

One task per page, exact commands, how to verify and how to undo. Each page says whether it works today or is planned.

Open the handbookStart hereMetapackagesInstall on DebianSecurity modelMaintained by agentsBuild from source

Part of the x0ne family

x0ne AI

x0ne AI models will run locally through x0ne-ai-local.

x0ne harness

The policy cage for agents. Not in the x0ne OS repository yet.

x0ne Engine

Confidential inference: measured on Google Cloud, planned on your own Intel TDX and H100 servers. Its package is x0ne-engine.

x0ne.training

The same x0ne OS, in a VM, for every student.

HackMachina

AI security challenges, to practise what x0ne-ai-redteam tests.

Contact

Talk to us

Questions, partnerships, early users. Write to us.

contact@x0ne.co