seL4 on AArch64: Proofcraft Completes the Security Proof Stack

When LLMs make answers cheap, the scarce skill is certification — not generation.

On August 21, 2026, Proofcraft announced that confidentiality proofs for seL4 on AArch64 are complete. Functional correctness and integrity were already machine-checked on 64-bit Arm. Confidentiality was the last leg of the security proof stack — and NCSC supported the work.

This is not a consumer AI launch. It is the kind of milestone that matters if you care about trusted foundations while you ship agents on top of whatever model API is cheapest this week.

TL;DR

What seL4 is (one paragraph)

seL4 is a microkernel — the smallest possible OS core — with a formal specification and proofs in Isabelle/HOL. Unlike a general-purpose OS, the goal is a tiny trusted computing base (TCB): the fewer lines that must be correct, the fewer places a bug becomes a security incident.

Proofcraft is the company carrying forward verification work historically associated with the seL4 Foundation and Data61/CSIRO lineage. The Proofcraft news page tracks proof milestones, releases, and verification tooling — not hype cycles.

For the concept in plain language, see explainx.ai’s formal verification dictionary entry.

The three proof pillars (and why confidentiality was last)

Confidentiality is often hardest in real systems because information flow is subtle — side channels, scheduling, and shared caches fight naive isolation stories. Finishing it on AArch64 matters because that ISA is everywhere phones, edge boxes, and automotive stacks touch.

seL4 vs Linux vs hypervisors — where proofs fit

Not every deployment needs a verified microkernel. The choice is about blast radius and evidence requirements:

seL4's niche is the row where regulators, insurers, or safety standards ask for evidence that isolation properties hold — not where a team needs Docker and apt-get.

Linux containers are the default for agent skills and MCP hosts because they ship fast and the TCB is accepted as "good enough." seL4 enters when "good enough" is not auditable — autonomous vehicle ECUs, medical device firmware, defense systems where a kernel bug is a classified incident.

The August 2026 confidentiality completion does not make seL4 easier to deploy than Linux. It makes the security claim defensible on AArch64 — the ISA inside most phones, many edge gateways, and growing automotive stacks.

Side channels and proof limits — read the fine print

Machine-checked confidentiality for seL4 is a major milestone. It is not a guarantee that your system is unhackable:

What the proofs cover: Information flow as specified in the seL4 formal model — data marked confidential does not leak to unauthorized subjects through kernel-mediated operations the spec models.

What they do not cover:

• Microarchitectural side channels — cache timing, speculative execution leaks, power analysis. These require separate mitigation (constant-time code, cache partitioning) and are an active research area on all ISAs including AArch64.
• Hardware bugs — CPU errata, DMA engines, faulty firmware. Proofs assume the hardware matches the model.
• Application-layer leaks — an agent that logs secrets to stdout defeats kernel confidentiality.
• LLM behavior — a model that hallucinates credentials in its output is outside the proof scope entirely.

Proofcraft's work narrows the TCB claim to what mathematics can support. Builders should map that to their threat model: seL4 proves the kernel gatekeeper; it does not prove your agent skills security checklist or your prompt pipeline.

For the parallel with AI trust: OpenAI Astra's Lean certificates prove specific theorems; seL4 proves kernel properties. Both are checkable artifacts in a world of uncheckable model output.

Agent deployment scenarios that care

Most explainx.ai readers will not rebase their stack on seL4 next week. These scenarios are where the August 2026 milestone actually moves procurement and architecture conversations:

On-device agents with key material. An agent that holds API keys, health records, or payment tokens on an edge box benefits from OS-level confidentiality proofs — especially if the device is physically accessible to attackers.

Automotive and robotics stacks. Xiaomi's parallel push into robotics and silicon sits in an industry where mixed-criticality scheduling (see seL4 15.0's dynamic domain scheduler) and verified isolation are procurement requirements, not nice-to-haves.

Sovereign and regulated cloud. France's sovereign AI procurement and similar EU moves favor vendors who can show evidence chains — formal methods at the platform layer complement data residency rules.

Embedded agent hosts on RISC-V. Proofcraft's June 29 MCS-on-RISC-V milestone pairs with the growing RISC-V edge board market. Agents deployed on factory floors or drones may run on ISAs where seL4 verification coverage is expanding.

High-assurance enclaves for model inference. Running a small on-device model inside a seL4-proved partition is architecturally plausible — the model layer stays statistical, but the key storage and I/O boundary gain verifiable properties.

What security engineers are asking

Common questions from formal-methods and security communities after the Proofcraft announcement:

"Does this subsume TrustZone?" No. TrustZone is hardware-enforced world separation; seL4 is a verified software kernel. They can compose — seL4 as the secure-world OS — but they solve different layers.

"How big is the proof maintenance burden?" Every kernel change requires proof replay. Proofcraft's tooling and the seL4 release cadence (15.0.0 in June 2026) exist to manage that cost. It is real engineering overhead — why general-purpose Linux stays default for fast-moving agent stacks.

"Can I use this for my SaaS agent?" Unlikely directly. Cloud agents on Linux + containers are the economic default. seL4 matters when your customer's RFP asks for verified separation or when you ship firmware, not when you ship a web app.

"Is Isabelle/HOL the only path?" seL4 uses Isabelle/HOL; other verified systems use Coq, Lean, or Dafny. The tooling choice is historical for seL4 — the builder takeaway is proof carry-over on change, not the specific prover.

"How does this relate to evals?" Orthogonal. Eval-driven development tests model behavior; seL4 tests kernel behavior. A full agent stack needs both — plus specification gaming awareness so your evals measure what you think they measure.

2026 context: cheap answers, expensive trust

explainx.ai’s When answers get cheap, trust is the job argued from a mathematician’s perspective: discovery got faster; checking did not retire.

seL4 sits on the opposite side of that split — a system where checking was the project from day one. You do not prompt a microkernel into correctness; you prove invariants and replay them when the code changes.

That does not mean every AI team should run seL4 tomorrow. It means the stack has layers:

┌─────────────────────────────────────┐
│  Agent / app / model (statistical)  │  ← fast, fuzzy, needs evals
├─────────────────────────────────────┤
│  Runtime, sandbox, policy           │  ← containers, WASM, MCP scopes
├─────────────────────────────────────┤
│  OS / hypervisor / TCB              │  ← seL4-class verification lives here
└─────────────────────────────────────┘

When you paste a 400-page OCR export into Claude, the model layer is unverified text. When you run an agent with filesystem tools, the OS layer is part of your blast radius. Proofs at the bottom do not fix hallucinations at the top — they narrow what “system compromise” can mean.

Other Proofcraft milestones (same news feed)

The August 21 post sits beside two June 2026 items worth bookmarking:

June 29 — MCS verified on RISC-V. Mixed-criticality systems scheduling with verification on another major ISA — relevant as RISC-V boards show up in edge and embedded agent hosts.

June 1 — Dynamic domain scheduler in seL4 15.0.0. Real-time mixed-criticality scheduling inside the verified kernel — the kind of feature safety-critical automotive and avionics integrators ask for once correctness proofs exist.

None of these replace your agent skills security review checklist. They extend what “platform” can mean when regulators and insurers ask for evidence, not demos.

What this is not

• Not proof that your LLM is safe — different problem, different math.
• Not automatic deployment — integrators still map seL4 to boards, drivers, and policies.
• Not a reason to skip evals — formal methods at the kernel layer complement eval-driven development, they do not substitute for them.

If you are an AI builder, what to do with this news

1. Know your TCB — list what runs below your agent (OS, container runtime, host hypervisor).
2. Separate “model trust” from “platform trust” — Lean proofs and seL4 proofs attack different layers than RLHF.
3. Watch Proofcraft for releases, not Twitter demos — seL4 15.x and MCS/RISC-V work affect embedded agents long before they trend on HN.

Related on explainx.ai

• When answers get cheap, trust is the job
• Formal verification — dictionary
• OpenAI Astra — ten math proofs with Lean certificates
• Agent skills security threat model
• Specification gaming and Goodhart's law in AI metrics
• Andrew Ng — evaluation-driven development
• OCR It — offline document text for LLM context
• France sovereign AI — trust and procurement context

Sources

• Proofcraft — seL4 confidentiality on AArch64 complete — August 21, 2026
• Proofcraft news — MCS on RISC-V, seL4 15.0 scheduler
• seL4 project

Proof scope and release details follow Proofcraft announcements as of August 24, 2026. This post is explanatory, not security advice for your deployment. Follow @explainx_ai for formal-methods and agent-trust coverage.