Why now
Agents broke the old security model
Desktop security assumes a human clicks and programs obey. Autonomous agents don't fit that assumption: they browse, write code, move files, and call APIs on your behalf, with whatever access your account has, executing plans nobody reviewed. A model built on one user account, apps trusted by default, and permissions granted forever has no answer for a workload that is itself intelligent, possibly wrong, or hijacked by prompt injection.
Our referrals into frontier-lab security work — Project Glasswing at Anthropic and OpenAI's counterpart efforts — led us to the conclusion that the time for an operating system like Polymer is today: contain every workload structurally, grant capability per task, and make the whole thing visible.
The adversary
Nation-state compromise of modern operating systems is routine
Our developers investigated nation-state spyware deployed against journalists and activists, including NSO Group's Pegasus. The lesson of that work is uncomfortable: well-resourced attackers have had continuous, repeatable access to fully patched mainstream operating systems for years. Zero-click chains against monolithic systems are a product category, not an anomaly. Defense that assumes the OS perimeter holds is defense that has already failed — the design answer is to make each compromise land in a compartment that contains nothing and expires soon.
Threat model
Nothing inside the machine is trusted
PolymerOS treats the computer's own components as hostile. Network cards, USB controllers, and their drivers run in dedicated VMs behind the IOMMU, not in the host kernel; a compromised Wi-Fi stack lands in a compartment that holds nothing. The host itself has no browser, no package manager at runtime, no interpreter an attacker would want. Applications, agents, documents, and devices all start from the same assumption: possibly compromised, contained accordingly.
Permissions
Leases, not grants
Nothing holds standing access. When a task needs a capability, the host broker issues a lease: scoped to an explicit resource list, bound to a wall-clock expiry, tied to one task. When the task ends or the timer runs out, the access no longer exists. An agent refactoring your scripts gets write access to that directory for that refactor, and nothing else, and not for long.
Leases are implemented as bonds: signed records naming issuer, subject, actions, resource, transport, and expiry, bound to the measurement of both ends. Covalent bonds are the durable form, for standing cooperation between known, measured components — your update service, your key store. Temporary bonds are the ephemeral form above: brokered, one-way, quarantined by default.
Where leases come from. In 1999, Sun's Jini got something right that the rest of the industry ignored: every grant of a resource was a distributed lease — time-bounded, actively renewed, released automatically when renewal stopped. Renewal doubled as proof of liveness, so a crashed or partitioned client lost its access by default, with no cleanup code anywhere. The Rio project built autonomic infrastructure on top of it: cybernodes advertising machine capacity, declarative operational strings describing whole distributed applications, provisioners that kept intent and reality matched.
The ideas outlived their platform; we think they were twenty years early.
Integrity
Tampering revokes itself
Integrity is checked before access is granted, not audited after. The chain runs from boot to every running compartment, and it ends in a log nobody can edit.
The polymer
Monomers, linked by bonds
The name is the architecture. A monomer is one VM with one job. A micromer is the smallest kind: a bare-metal Rust or Go appliance with no operating system inside at all. A polymer is what you get when monomers are linked by covalent bonds into a working system — and the bonds, not the monomers, are where the security lives.
Hover a ring: each hexagon is a monomer, and fused rings share covalent bonds — durable, measured cooperation. Dashed bonds are temporary leases, already counting down. Styled after a photograph by Giovanni Crisalfi (Unsplash).
- security-appliance — bond verification, policy root
- admin — privileged operations, human-gated
- observability — append-only event log
- agent-runtime — where your AI agent lives
- job-runner — ephemeral task execution
- dev — development environments
- browser — amnesiac by default
- media-docs — untrusted document handling
- net — the network hardware's own VM
- secrets — sealed keystore, signing
- ssh-agent — shipping today in both Rust and TamaGo Go, VM or USB Armory hardware
- net-security — network policy root
- command — control-plane role module
- attestation — measurement brokering
- wallet — cryptocurrency keys, transaction signing (roadmap)
No OS inside: no shell, no filesystem, no allocator in security paths, one audited crypto dependency. About 28,000 lines of Rust with 328 tests, plus the TamaGo Go appliance.
Why this matters for a crypto wallet. Today your wallet's keys live in the same place as your browser, your extensions, and whatever a malicious dApp or a compromised npm package can reach. One bad signature prompt, one clipboard hijack, one supply-chain exploit, and the keys are gone. Hardware wallets exist precisely because that shared space can't be trusted.
A PolymerOS wallet micromer is a hardware wallet built into the OS: a bare-metal appliance with no browser, no shell, and no network stack, holding your keys where no application can reach them. An app that wants a transaction signed doesn't get the key — it opens a scoped, visible bond and requests a signature, which you approve on a window whose trust border can't be faked. Even if malware owns your entire browser VM, it can't drain the wallet, because the wallet was never in that VM.
Make your own
Monomers are generated, not installed
A monomer is a declarative spec: role, runtime tier, storage mode, network profile, allowed bonds. The generator builds it into a verified VM image on your own machine — describe the appliance you want and it exists. Because every monomer is built from the same content-addressed Nix store, ten monomers don't cost ten operating systems: common packages exist once, shared read-only across compartments, and an update ships one copy of each changed package no matter how many VMs use it.
Comparison
Where it sits among security-focused systems
PolymerOS is a research operating system — the honest column on the right is "not yet." The others are mature systems we respect and borrow from; the rows are where the designs differ.
| PolymerOS | Qubes OS | secureblue | NixOS | Ubuntu | OpenBSD | |
|---|---|---|---|---|---|---|
| Isolation unit | VM per workload (KVM) | VM per domain (Xen) | SELinux + sandboxes | process; systemd units | AppArmor + snap confinement | process; pledge/unveil |
| Drivers off the host | yes — net/USB in VMs | yes — sys-net, sys-usb | no | no | no | no |
| Permissions | task-scoped, time-bound leases | static per-domain policy | static MAC policy | static; declarative | static; user grants | static; per-process |
| Immutable + reproducible OS | yes — Nix, verity-sealed | no — Fedora templates | immutable (ostree); builds not reproducible | reproducible — the reference point | Core only | no |
| Memory-safe isolation layer | Rust VMMs, compositor, appliances | Xen + QEMU in C | C, hardened allocator | C | C | C, decades of auditing |
| Trust visible per window | live: tier, lease, countdown | colored borders (static label) | no | no | no | no |
| AI-agent workload model | first-class (bonds, agent VMs) | none | none | none | none | none |
| Maturity | research — not yet | production since 2012 | production | production; two decades | mainstream | production since 1996 |
Foundations
Standing on proven ideas
Qubes OS proved isolation-by-VM works for real users. PolymerOS carries the pattern onto KVM with Cloud Hypervisor and crosvm instead of Xen: lighter VMs, faster boots, and per-window trust made visible.
The whole OS is declared and built with Nix. Roots are read-only, updates are atomic A/B swaps with rollback, and any build can be reproduced from source and audited. Factory reset is "wipe the state partition" — the OS itself has no drift to reset.
Everything that enforces isolation above the kernel is memory-safe: the VMMs (Cloud Hypervisor, crosvm) in Rust, the COSMIC compositor in Rust, the appliance tier in bare-metal Rust and Go. Memory corruption in privileged C is how most OS exploits start; this layer doesn't have any.
PolymerOS integrates the COSMIC compositor and gives it one extra job: drawing trust. Ring color and weight, role chips, live lease countdowns — compositor-owned pixels no application can fake, on an achromatic desktop where security state is the only color.
Memory safety
The C problem, and what we did about it
Roughly two-thirds of serious OS vulnerabilities are memory-safety bugs in C and C++ — the numbers from Microsoft, Google, and the Chromium project all land in the same range. This is why ISRG's Prossimo is rewriting the internet's critical infrastructure in Rust (TLS, DNS, NTP, sudo), and why Rust for Linux is bringing memory-safe drivers into the kernel itself. PolymerOS applies the same conclusion to the desktop: the layers that enforce isolation are memory-safe now, and the remaining C shrinks release by release.
The foundation
PolymerOS is a distribution of Spectrum OS
Polymer started as a toy. The first version was an experiment by C. Colby Thomson, built on crosvm after watching how Chromebooks run Linux in a VM and wondering what a Chromebook built for targeted people — journalists, activists — would look like. Spectrum OS is where that idea became real engineering. Alyssa Ross developed the same compartmentalized model independently, implemented it better than we could, and did the hard part: the changes went upstream, into Cloud Hypervisor, crosvm, and nixpkgs, instead of piling up in a private fork. That upstreaming work is the only reason a design like this can exist as a small layer on a general-purpose base — and it is why PolymerOS is a security distribution of Spectrum, not another fork.
Good Ancestor donates to Spectrum's development and our patches go upstream first, under upstream's license. Spectrum is an independent project; it does not endorse PolymerOS.
Spectrum needs funding and contributors more than we do. If you fund one thing, fund Spectrum.
Architecture
Four layers, small trusted core
The stack: a minimal musl host whose only job is running compartments. Drivers, networking, and apps live in VMs.
Appliances run on the smallest runtime that can do the job: bare-metal Rust (micromer-minimal) or TamaGo Go (tamago-minimal) for key custody and policy roots, a Hermit unikernel tier (hermit-middle) for services, full Linux VMs (linux-full) for browsers, desktops, and agent runtimes.
Principles
Rules the system never breaks
Privacy
No telemetry. None.
PolymerOS sends nothing home: no analytics, no crash reporting, no "check-ins," no identifiers. There is no server to send it to and no code path that would. For contrast, macOS's background transmissions are documented and measured — application launches, hardware identifiers, and location-correlatable traffic, on by default. Our update client fetches signed files from a static directory; the request contains a version string and nothing else, and the append-only log stays on your machine, readable by you and writable by no one.
Platforms & status
Where it runs today
Apple Silicon, on the latest Asahi Linux foundation, is the flagship native target — a live USB has booted to a visible Spectrum screen on real hardware. amd64 builds in parallel as the parity target.
M1 and M2 families with full OpenGL / GPU acceleration via the Asahi graphics stack; M3 at research level as Asahi support matures. 16K pages, nested KVM validated.
download — coming with the first signed channel
Parity target: full sandboxed CI builds with KVM-backed graphics checks passing. Runs the same compartment model on commodity hardware.
download — coming with the first signed channel
The ssh-agent micromer now has local disposable-dev QEMU evidence: boot and attestation markers passed. Promotion remains blocked on catalog, signing, publication, and hardware validation gates.
The current architecture preview status maps 23 claims to 113 local docs, scripts, templates, source files, and evidence packets with zero missing references.
The preview tracks 2 Monomer targets. Both remain blocked until catalog, artifact-location, launch-policy, and publication gates are satisfied.
The next broad QEMU-L1 live rebuild is blocked by scratch-space policy, so the loop must free space or configure a larger build scratch path before retrying. The launcher supports an explicit disk-backed TMPDIR, but remediation options are status only; the preview does not run cleanup. A read-only 22-core command packet is available and remains blocked until TMPDIR and scratch policy are satisfied. Candidate ranking currently prefers the existing /tmp parent, but the consolidated launch verdict is still blocked. The cleanup scan currently reports no stale scratch candidates; bounded disk review has candidates.
Future goals
Where this is going
Today the signing and attestation primitives are classical (Ed25519, SHA-256). Because micromer keeps cryptography behind narrow traits, the plan is to migrate the signing, bond, and attestation paths to NIST post-quantum algorithms (ML-DSA / ML-KEM) without rewriting the appliances — and to publish the audit when we do.
Apple's MIE brings always-on hardware memory tagging (EMTE) to its newest chips. As it reaches M-series hardware and the Linux kernel's ARM MTE support matures, PolymerOS intends to enforce tag-checked memory across host and guests — hardware watching every allocation.
The kernel is already per-role trimmed and boots per compartment; the next step is kernel choice per compartment — Rust-for-Linux-heavy builds where the ecosystem allows, unikernels where a role needs no Linux at all, and a path to memory-safe kernels as they become production-real.
Release signing moves to a micromer keystore on USB Armory hardware — the OS's own smallest appliance guarding the OS's own keys. The same pattern becomes available to users for their SSH and signing keys.
A library bar to launch any monomer in the catalog, a settings panel over launch policies, and the one-command generator: describe an appliance, get a verified image. Compartmentalization with the friction of opening an app.
A GrapheneOS-derived Android compartment, so Android apps run on the Linux desktop inside the same bond and trust model. Feasibility under active investigation; listed here because we fund the project either way.
Networking terminates in monomers, not in a shared host session — and bonds reach across machines: a built-in Tailscale-style overlay connector so a monomer on your desk and a monomer on your server hold a lease between them with the same scope, expiry, and visibility as a local one.
Declare a polymer that spans machines and let the system place its monomers — a thread from the Rio project's cybernodes and operational strings on Java's Jini, whose distributed leases are the direct ancestor of our bond model. This is lived lineage: our founder built a high-availability operating system on Rio/Jini in the 2000s.
Hardware roots of trust
Small devices you can actually trust
Software attestation needs somewhere solid to stand. PolymerOS anchors its trust chain in small, auditable, open hardware — devices simple enough to reason about completely.
Open-hardware ARM computer with secure boot and a sealed-key store. Runs our TamaGo micromer today (the ssh-agent appliance with its /attest endpoint) and is the working attestation and key custody path.
Bunnie Huang's security-first silicon from the Betrusted lineage (Dabao on Crowd Supply). On the roadmap as an external bare-metal attestation device — a second, independently designed root of trust so no single vendor's silicon is load-bearing.
Open-hardware true random number generator with a health-checkable analog design. Planned as a supported entropy source: micromer's entropy interface is a trait, and hardware entropy binds where fixture entropy sits today.
Built on · inspired by
Proudly built on, and giving back to
We donate to: Spectrum OS, Asahi Linux (Apple Silicon support and the reverse-engineered GPU stack that gives us full graphics on M1 and M2), and GrapheneOS (whose hardening work we study throughout, and whose Android platform we are researching as a future Android-app compartment).
Built on: Cloud Hypervisor and crosvm, COSMIC by System76, Nix and nixpkgs, TamaGo and the USB Armory project, Hermit, and the Asahi kernel lineage. Inspired by: Qubes OS's compartment model and GrapheneOS's hardening discipline. If PolymerOS is useful, they deserve your support too.
Support the work
Free software, funded by people who value it
PolymerOS is built by Good Ancestor, a 501(c)(3) nonprofit, and licensed under the EUPL-1.2 — free to use, study, and modify. If it is useful to you, especially commercially, please donate to fund the work. Organizations that want a derivative without copyleft obligations can ask about a commercial license; proceeds fund the nonprofit.