We build these foundations because we can, and must, do more. An immutable image eliminates many paths to malfunction, but it does little to constrain the runtime behavior, especially under attack. For example, configuration almost always sits outside of signed image data, and that means it sits outside what hardware-backed trust can measure. Hardware can do a lot more than unlock encrypted disks. Shared join tokens remain the (weak) norm for cluster setups; better private key and secret protection is the least we can ask from our machines.

A Foundation Designed Around Integrity

Amutable Foundations is a cohesive system. The build system, the operating system, the delivery mechanism for software updates and configuration, and the control plane all insist: creators must sign and measure every artifact (including configuration) that defines how a machine behaves. A machine should be able to prove which set of artifacts is running and what state it is in at all times.

Achieving this requires evaluating every layer of the system. It’s not possible to just bolt on this kind of trust without a brittle result. Instead, we must engineer how trust crosses each boundary. Security hazards lurk in designs that function (read: the system boots and runs workloads) but don’t adequately protect, which is why we’ve built a team with a comprehensive span of subject matter expertise.

The team at Amutable is not just glueing a system together; we write and maintain the layers it depends on in the kernel, in systemd, and in the tooling that teams use to build and ship Linux images. When we find a gap, we fix it in the layer where it belongs instead of working around it.

How Amutable Foundations Works

We will cover technical details in a follow-up post. But here is the high-level description of how the system works.

Everything starts as a declaration. The composition of the software images (OS and extensions) and the configuration of every machine reside in version control. Nothing about a machine's intended state exists on the machine alone.

Declarations become signed images. The build system constructs software images from pinned inputs into signed reproducible images with an SBOM. Similarly, it compiles configuration into its own signed, integrity-protected images rather than writing loose files. Thus, creators sign, measure, and audit both the applied software and configuration images.

Machines boot only what’s signed, and measure what they boot. The machine verifies firmware, boot loader, kernel, and operating system before running them, and measures them into its TPM or CPU attestation measurements when running as a confidential VM. The machine verifies and measures configuration images when applying them. There’s no package manager and no SSH or interactive shell. The only way to change a machine is to give it a new signed image.

Updates and configuration are controlled and measured as state. Each machine has its own repository, and that repository filters that machine’s view and access to OS releases, configurations, and even hardware enablement. A machine sees what is meant for it and learns nothing about the rest of the fleet. The system checks every download against signed metadata that guards against tampering, replay, mix-and-match, and rollback before applying anything. Updates switch atomically, and the previous version stays available as a fallback.

Machines prove their state. At regular intervals, and at important stages such as boot, each machine produces a signed report, leveraging local hardware to improve the report’s verifiability. The signature covers both the report and the machine’s measurements. So, it shows what the machine is actually running, not what an agent on the system or an out-of-band scanner believes it is running.

The control plane checks reports against predicted state. It checks each report against the hardware root of trust, evaluates measurements, and compares what the machine has proven with what you declared should run. A match means the machine is in its predicted and intended state. A mismatch tells you a specific machine diverged, all backed by cryptographical evidence.

Policy decisions follow from those checks. Rollouts advance only when machines prove they’re in a good state. Systems can base identity, access, and secrets on this verdict, which we will cover in the next section. People operate machines through a structured interface rather than by logging in, so every change takes the same declared, reviewed, signed, and verified path.

Identity and Policy Derived from Proof

Once we have the system in a provable state, we can build other capabilities on top of this secure foundation.

Identity

Today a machine’s identity is usually something it has, not something it is: a host key, a client certificate, an API token, a cloud instance identity. All of these can be copied, leaked, or presented by a machine that has been tampered with. A key on disk proves that someone had access to the key. A metadata document proves that a request came from a particular instance, not what that instance is running. A network address proves very little at all.

We think identity should come from what a machine can verify. A TPM, or a CPU with confidential computing support, can sign a statement about the machine’s measured state: the firmware, boot loader, kernel and operating system it booted, and the configuration it’s running. That evidence is anchored in hardware and can’t be produced by software on the host alone. Bind a machine’s identity to it and node “42” becomes node “42 anchored in hardware, running the release and configuration intended for it.”

Policy

Once we have identity rooted in hardware, policy follows. Operators can base decisions about whether a machine can join a cluster, which secrets it receives, which workloads it is allowed to run, and which services it can reach on proven state instead of on network location or whatever credential happens to be on disk. The system can deny new database credentials to a machine running an outdated configuration. It can keep a machine whose measurements no longer match out of the cluster when it reboots. An auditor asking whether every production machine runs the approved configuration receives a report that is cryptographically verifiable and easy to create.

Remote attestation and hardware roots of trust are not new ideas. What’s been missing is a system that engineers built from the ground up with integrity in mind, rather than settling for weaker approaches, like deployed agents probing the system for state.

Meeting the Moment

Historically, organizations had access to such systems only for bespoke and narrow use cases. Operating and building them presented immense difficulty, requiring special expertise and large budgets. With Amutable Foundations, we aim to make this accessible to all.

We foresee, and are building for, a future where it will be standard practice for Linux machines to be able to prove their state and for access to depend on that proof. Infrastructure that can't prove its state will look like unencrypted network traffic looks today: still around, but only for toy use cases.

The impetus for this future is already here. Authorities have enforced the EU Cyber Resilience Act’s vulnerability reporting obligations since September 2026, and the rest of the regulation follows in December 2027. AI infrastructure is putting valuable models and data on machines that owners don’t physically control.

We treat security, compliance, and reliability as one problem. The system denies access to machines that can’t prove their state. Evidence replaces tedious, cobbled-together compliance reports. The system you run is the system you declared. If drift tries to enter, the system prevents it and revokes access the moment it happens instead of through a much slower process.

Join the Private Preview

We’re opening Amutable Foundations to a select group of design partners. If you run Linux fleets where proving system state matters, we encourage you to sign up.

Design partners work closely with our engineers and help shape the product. You operate your systems and we handle building and maintaining images, running update repositories, the control plane and continuous vulnerability remediation.

Apply for the private preview now. We plan on opening first access in the next few weeks.

Foundations is the first step. Next, we’re bringing this new secure foundation to Kubernetes. for more on that.

If you’re at KubeCon North America in Salt Lake City, in November, come find us at booth 347 near the project pavilion. We’d love to meet you there.

Tags:announcementsecuritylinux

Share: