Skip to content
Kernwall
Kernwall
Book a demo

Pre-release · 2027 pilots

Platform · for your engineers

Five signed layers, from firmware to audit.

Kernwall OS is one signed system in five layers: a hardware root of trust, an immutable OS, a pinned model runtime, a way across your air gap and an engine that writes your evidence. Read them bottom to top, the way your appliance boots.

01Hardware root of trust

Trust starts in firmware, not on your network.

Your appliance proves what it booted before it unseals your data.

Boot chain · kernwall-2027.01
  1. KeysOwn PK/KEK/db, enrolled at the factory (pending)
  2. Kernelkernwall-2027.01.efi · signature in db (pending)
  3. MeasurePCR 11 matches the policy signed with the release (pending)
  4. Rootdm-verity root hash 9c4e…21b0 (pending)
  5. DataLUKS2 volume unsealed by this TPM (pending)

booting…

Expand spec

Each update replaces the signed image and its pre-signed policy together. Your patched appliance still unseals its data; an altered one doesn't.

Secure Boot
Own PK/KEK/db enrolled at the factory; shim for servers that ship a Microsoft-only db
Boot chain
Signed unified kernel image, PCR 11 policy pre-signed with systemd-measure
Data volume
LUKS2 sealed to the signed PCR policy, so updates don't force a reseal
Attestation
Continuous TPM + IMA attestation; optional confidential computing with a local GPU verifier
Hardware
A planned compatibility list of OEM servers, plus an own-brand fanless Edge box

02Immutable OS

An OS you replace, never patch in place.

A read-only, image-based host with signed A/B updates and automatic rollback.

Host · appliance-01
Root filesystem
read-only · dm-verity
Image
2027.01 · slot A · B standby
Rollback
automatic on failed health check
Kernel
lockdown · signed modules only
GPU driver
NVIDIA open · signed for this kernel
Egress policy
deny-all
Outbound connections
0
Expand spec

On a read-only OS that loads only signed modules, the stock NVIDIA GPU Operator doesn't work. Kernwall builds and signs the drivers for every kernel, so your team doesn't.

Root filesystem
Read-only, dm-verity, root hash bound on the kernel command line
Updates
Signed A/B images with health checks and automatic rollback
Kernel
Lockdown on, signed-only modules
GPU drivers
NVIDIA open modules and AMD amdgpu rebuilt and signed for every kernel
Base
Image-based build on a redistributable, FIPS-inheriting userland (under evaluation)
Cadence
A slow-moving LTS host, versioned and evidenced separately from the model runtime

03Model runtime

Only cleared, signed models run. Nothing downloads.

Pinned engines, cleared models and egress denied by default.

Model catalog · 5 of 19 models
Deploying for
Model, origin, licence and lineageIn EU industry
gpt-oss-120bUS · Apache-2.0 · base modelAllowed
Mistral Small 3.2 24BFR · EU · Apache-2.0 · fine-tune of Mistral Small 3.1 24B BaseAllowed
Llama 3.3 70B InstructUS · llama3.3 · base modelReview
Qwen3-32BPRC · Apache-2.0 · base modelAllowed
plant-sop-70bUS · Apache-2.0 (as claimed) · fine-tune of DeepSeek-R1-Distill-Llama-70BReview⚑ inherited

EU industry · Blocked: Non-commercial · Review: Custom licence

All 19 models, every rule and its source
Expand spec

Stock vLLM sends usage stats, loads assets from a public CDN and stalls without huggingface.co. And scanners alone aren't enough: malicious models have slipped past Hugging Face's own scanning.

Engines
vLLM, SGLang, TensorRT-LLM and llama.cpp as a pinned, signed, CVE-scanned LTS set
Isolation
MIG per tenant or classification level; single node, k3s/RKE2 or Kubernetes for racks
Network
Egress denied by default; an eBPF egress audit proves “0 outbound connections”
Identity
Keycloak (PIV/CAC or AD) with OPA policy on clearance and need-to-know claims
Model ingest
safetensors or GGUF only: no pickle, no unreviewed trust_remote_code
Catalog
Cleared per jurisdiction (US federal, DoD, EU, nuclear), with lineage tracking that flags derivatives of barred bases and a signed AI-BOM

04Cross-gap delivery

Updates cross the gap as one file.

One signed bundle carries OS, drivers, models and evidence across the gap.

Import station · models-2027.01.oci
  1. SignatureML-DSA-87 + LMS · TUF root v3 (pending)
  2. Scansafetensors, GGUF · 0 KEV-listed CVEs (pending)
  3. Re-signSite key · A/B rollout with rollback (pending)

Waiting for the bundleNothing reaches your appliance until every check passes.

Expand spec

New US National Security System acquisitions must be CNSA 2.0 compliant from 1 Jan 2027. Kernwall signs post-quantum from day one, so you never re-plumb your update chain.

Bundle
OCI artifact, TUF-signed, CNSA 2.0-ready signatures (LMS / ML-DSA)
Contents
OS image, signed drivers, runtime containers, chunked model shards, SBOMs, scan reports, GPU attestation manifests and revocation data, eval reports
Transport
USB or data diode into an import station that verifies, re-scans and re-signs with the site key
Time
A monotonic “last trusted time” floor in every bundle, so expiry checks work offline
Interop
Works alongside Zarf rather than replacing it

05Accreditation engine

Your assessor reads records, not promises.

Kernwall writes your evidence as it runs, not a consultant afterwards.

Audit · chain intact · TPM-anchored
Audit records, newest first

Chat completion

process.eng · 09:41:07

Model
gpt-oss-120b@3f9c…e1a2
Prompt
sha256:9a0e…71c4
Response
sha256:5d12…b0e8
Retrieved
SOP-CMP-014 · EQ-LOG 2026-10-27
Previous
7be2…11d

Evidence pack · Q1 2027 · OSCAL and CycloneDX

  • component-definition.json
  • assessment-results.json
  • poam.json
  • sbom-2027.01.cdx.json

Mapped to NIST SP 800-53, CRA Annex I, ISO 27001, IEC 62443-4-2, AI Act Art. 12

Expand spec

Your ATO, and your NIS2 and DORA duties, stay yours: no vendor can hold them for you. The engine gives you a faster path there: faster ATO, never “ATO included”.

Audit chain
Every prompt, retrieval and tool call, hash-linked and anchored to TPM quotes
Each record
User identity, model digest, prompt and response hashes, retrieved document IDs
Scheduled checks
OpenSCAP and STIG scans on the running system
Output
OSCAL component definitions, assessment results and POA&M items
Mapped to
NIST SP 800-53, CRA Annex I, ISO 27001, IEC 62443-4-2, AI Act Art. 12
TPM 2.0 · SECURE BOOT01Hardware root of trust02Immutable OS03Model runtime2026.10 · VERIFIED04Cross-gap deliveryKERNWALL05Accreditation engine
TPM 2.0 · SECURE BOOT01Hardware root of trust02Immutable OS03Model runtime2026.10 · VERIFIED04Cross-gap deliveryKERNWALL05Accreditation engine

In depth

Break each layer yourself.

Tamper with the boot chain, follow the drivers, change where you deploy and walk one release across the gap.

  1. PK/KEK/dbverified
    Secure Boot keys

    Keys enrolled in firmware at the factory. Only images signed under them start.

  2. UKIverified
    Signed kernel image

    Kernel, initrd and command line in one signed file. The command line carries the root hash.

  3. PCR 11verified
    Measured boot

    The TPM records the image that booted. Its expected value is pre-signed with the release.

  4. dm-verityverified
    Verified root

    Each block of the read-only OS is checked against that root hash as it is read.

  5. LUKS2 · TPMverified
    Sealed data

    Your data volume unlocks only on this TPM, after a boot that matches a signed policy.

Try to tamper with it
Every link holds, so the TPM releases the data key and the model server starts. Nothing here needed a network.
Boot log · console
secure bootkernwall-2027.01.efi · signature in db ✓
pcr 11matches the policy signed by the release key ✓
dm-verityroot hash 9c4e…21b0 from the signed command line ✓
luks2data volume unsealed by this TPM ✓
model server up · outbound connections: 0
Fig. 1The boot chain. Pick a tampering attempt to see which link refuses it.
GPU driver lifecycle

Signed GPU drivers are table stakes: Ubuntu already ships Canonical-signed NVIDIA modules that load under Secure Boot. Offline, the hard part is keeping four moving parts in step, under your keys, with a record your assessor can read.

Mirrored package streams
  • Kernel packages, matched to one ABI
  • Signed NVIDIA module packages for exactly that kernel
  • CUDA userspace at a compatible branch
  • The model runtime container built against it
  • Each mirrored and kept in step by your team
One measured image (Kernwall OS design)
  • Kernel, NVIDIA open modules, CUDA and runtime built and tested together
  • Modules signed with your keys, so your own Secure Boot db still boots them
  • Every version recorded in the boot measurement and the AI-BOM
  • Crosses the gap in the same bundle as models and evidence
Deploying for
Show

US federal civilian: 19 models · 8 allowed · 7 need review · 4 blocked

ModelOriginLicence (model card)LineageIn US federal civilian
gpt-oss-120b model card (opens in a new tab)OpenAI · 117B MoE
USApache-2.0Base modelAllowed
gpt-oss-20b model card (opens in a new tab)OpenAI · 21B MoE
USApache-2.0Base modelAllowed
Granite 4.0 H Small model card (opens in a new tab)IBM · 32B
USApache-2.0Base modelAllowed
Phi-4 model card (opens in a new tab)Microsoft · 15B
USMITBase modelAllowed
Mistral Small 3.2 24B model card (opens in a new tab)Mistral AI · 24B
FR · EUApache-2.0
  • fine-tune of Mistral Small 3.1 24B Base (FR · EU)
Allowed
Gemma 3 27B model card (opens in a new tab)Google · 27B
USGemma termsBase modelReview
  • Custom licence
Nemotron Nano 9B v2 model card (opens in a new tab)NVIDIA · 9B
USNVIDIA Open Model License
  • pruned from Nemotron Nano 12B v2 (US)
Review
  • Custom licence
Llama 3.3 70B Instruct model card (opens in a new tab)Meta · 71B
USllama3.3Base modelReview
  • Custom licence
Command A model card (opens in a new tab)Cohere · 111B
CanadaCC-BY-NC-4.0Base modelBlocked
  • Non-commercial
DeepSeek V3-0324 model card (opens in a new tab)DeepSeek · 685B MoE
PRCMITBase modelBlocked
  • DHS DeepSeek order
  • PRC origin
DeepSeek-R1-Distill-Llama-70B model card (opens in a new tab)DeepSeek · 71B
⚑ Inherited restriction
PRCMIT
  • weights from Llama 3.3 70B Instruct (US)
Blocked
  • DHS DeepSeek order
  • PRC origin
  • Custom licence via Llama 3.3 70B Instruct
plant-sop-70bLocal integrator · 71B
⚑ Inherited restriction
USApache-2.0 (as claimed)
  • fine-tune of DeepSeek-R1-Distill-Llama-70B (PRC)
  • weights from Llama 3.3 70B Instruct (US)
Blocked
  • DHS DeepSeek order via DeepSeek-R1-Distill-Llama-70B
  • PRC origin via DeepSeek-R1-Distill-Llama-70B
  • Custom licence via Llama 3.3 70B Instruct
Qwen3-32B model card (opens in a new tab)Alibaba · 33B
PRCApache-2.0Base modelReview
  • PRC origin
Kimi K2 Instruct model card (opens in a new tab)Moonshot AI · 1T MoE
PRCModified MITBase modelReview
  • PRC origin
  • Custom licence
Qwen3-Embedding-8B model card (opens in a new tab)Alibaba · 8B
PRCApache-2.0
  • fine-tune of Qwen3-8B Base (PRC)
Review
  • PRC origin
BGE-M3 model card (opens in a new tab)BAAI · 0.6B
PRCMITBase modelReview
  • PRC origin
Whisper large-v3 model card (opens in a new tab)OpenAI · 1.5B
USApache-2.0Base modelAllowed
Parakeet TDT 0.6B v2 model card (opens in a new tab)NVIDIA · 0.6B
USCC-BY-4.0Base modelAllowed
Voxtral Mini 3B model card (opens in a new tab)Mistral AI · 4.7B
FR · EUApache-2.0Base modelAllowed
The rules behind these statuses
  • Non-commercialLicenceBlocked

    Non-commercial licence: it can't run in a commercial deployment at all.

  • DHS DeepSeek orderUS orderBlocked

    DeepSeek is out of federal civilian systems, including third-party products built on DeepSeek technology.

  • Llama AUPLicenceNot applied here

    The Llama use policy forbids military use and “nuclear industries or applications”. Meta's waiver names US and allied governments, but private suppliers only in the US and Five Eyes. An EU defense supplier needs Meta's written confirmation.

  • PRC originExample policyReview

    PRC-origin weights or lineage need a documented exception, and defense sites refuse them.

  • Custom licenceLicenceReview

    A custom licence needs a legal review for each deployment.

Fig. 2The model catalog. Pick where you deploy and every status recomputes from the rules below.Cards read 29 Oct 2026
Why lineage, not the licence field

DeepSeek-R1-Distill-Llama-70B's card lists MIT, yet its own notes say the weights come from Llama 3.3 70B. A scanner that reads only the licence field misses the Llama terms, and misses that a fine-tune of it is still built on DeepSeek technology. Kernwall checks lineage, so both show. This illustration leaves out weights digests and eval scores rather than invent them, and your accreditor, not this table, sets the real policy.

Why egress stays denied for a cleared model

On 26 Oct 2026 Cohere, which sells competing models, reported that an open-weight model in its sandbox read the machine's DNS settings and tried to upload a probe string to a cloud bucket, after its own reasoning said it would use no tools. The sandbox blocked it. It happened in fewer than one call in 100,000, and nobody has shown it was deliberate. The weights were the published ones, so a signature or a scan would have passed them. That is why Kernwall denies egress for every model on your appliance, cleared or not, and audits that the count stays at zero.

Build · step 1 of 6

Built twice, signed once

On the connected side, Kernwall builds every release twice, on independent builders. It signs the bundle only if the bytes match: OS image, GPU drivers, runtime, model shards and evidence together.

release@build — connected side
$ kernwall release build --lock 2027.01.lock
builder-asha256:5e1c…a907
builder-bsha256:5e1c…a907 · reproducible ✓
$ kernwall release sign --tuf --keys ml-dsa-87,lms
targetsos, drivers, runtime, 3 model shards, sbom, vex, evals ✓
bundlerelease-2027.01.oci · expires 2027-07-01
Fig. 3One release, from the build farm to a running appliance.

On top of the stack · Own Your Intelligence loop

Base models come and go. Your evals stay.

Your evals and data are the asset. Base models are replaceable.

Why it matters

LoRA adapters don't carry over between base generations, and open bases turn over every few weeks. Quantization loss depends on the model and the task, so Kernwall checks it against your own evals.

  1. Production failures
  2. Eval set
  3. Re-fit adapters on the new base
  4. Eval gate
  5. Promote or roll back
Durable assets
Versioned datasets, eval suites and verifiers that outlive any one base model
New base import
Adapters re-fitted, eval gate run, then promoted or rolled back
Quantization
Runs on site; calibration data never leaves the building
Evidence
Every quantized or tuned artifact is a new signed model with its own eval report in the AI-BOM

Build or buy

What Ubuntu Pro ships, and what you build.

Ubuntu Pro and Ansible are the right first question. Canonical ships more for disconnected sites every year; here is what you get, and what your team still builds on top.

Canonical already ships, offline

  • Enterprise Store. An on-premise proxy for snaps and charms with an offline mode, so updates can be carried in by hand. Included in Ubuntu Pro.

  • Ubuntu Pro offline. An air-gapped contract server and local mirrors serve Pro entitlements inside an isolated network.

  • Inference snaps. Silicon-optimised model packages that run entirely offline once installed.

  • Signed NVIDIA modules. Canonical-signed, prebuilt GPU kernel modules that load under Secure Boot.

Still left to your team

  • A measured, immutable image. The pieces above install onto a mutable server. Your team still turns kernel, drivers, CUDA and runtime into one image that boots measured and rolls back.

    Kernwall OS: Layer 02 · Immutable OS

  • A rule for which models may run. Models arrive through a store channel. Jurisdiction, licence and lineage checks before a model loads are yours to write and enforce.

    Kernwall OS: Layer 03 · Model runtime

  • One file across the gap. OS, drivers, models and evidence each move through their own channel, on their own schedule, under someone else's keys.

    Kernwall OS: Layer 04 · Cross-gap delivery

  • The assessor's evidence. Nothing above writes the IEC 62443, CRA or OSCAL records. Playbooks get the box running; your team still writes the paperwork by hand, for every update.

    Kernwall OS: Layer 05 · Accreditation engine
Not instead of Ubuntu

Ubuntu Pro FIPS is one of two candidate bases for Kernwall OS, licence terms to confirm. Kernwall OS is what goes on top: the image, the model rule, the bundle and the evidence, built once and signed. Not a rival distro.

Compared

Four ways to run AI on your data.

Your four real options, side by side. The Kernwall OS column is the design target for the first release, not a shipped product.

Cloud APIHosted frontier modelsDIY stackUbuntu Pro + NVIDIA AI Enterprise + consultantsHyperscaler disconnectedGDC air-gapped, Azure Local disconnectedKernwall OSDesign target
Data egressCloud APIEvery prompt and document leaves the site.DIY stackNone if built right, but stock vLLM sends usage stats and fetches from public hosts until each call is found and closed.Hyperscaler disconnectedNone at runtime once disconnected.Kernwall OSDenied by default. An eBPF egress audit records zero outbound connections.
Vendor remote accessCloud APIThe provider operates the whole system.DIY stackWhatever your integrator and support contracts allow.Hyperscaler disconnectedMicrosoft's EU answer is EU-partner oversight of its engineers' remote access. Google says GDC air-gapped can't be remotely shut down by Google.Kernwall OSNo vendor access path by design. Updates arrive only as signed bundles you carry in.
JurisdictionCloud APIThe provider's, under its terms of service.DIY stackSplit across each component's vendor.Hyperscaler disconnectedUS vendors, with US-controlled signing and update chains.Kernwall OSEU-built. Signing and update chain under EU control.
Minimum footprintCloud APINothing on site.DIY stackOne GPU server.Hyperscaler disconnectedMulti-node: Azure Local disconnected needs a dedicated management cluster.Kernwall OSOne box, from a desk-side unit to a rack node.
Time to first modelCloud APIMinutes, with an API key.DIY stackAn integration project: drivers, runtime, models, identity, logging.Hyperscaler disconnectedA sales-led rollout with the vendor.Kernwall OSDay 1 after delivery, served offline.
Offline update pathCloud APINot applicable: the provider updates for you.DIY stackStitched together: Canonical ships offline tooling for the OS; models, GPU drivers and evidence each move separately. What Ubuntu coversHyperscaler disconnectedThe vendor's own channel and signing keys.Kernwall OSOne signed bundle of OS, drivers, models and evidence, by USB or data diode. A/B with automatic rollback.
Accreditation evidenceCloud APIThe provider's own reports, which cover the provider, not your use of it.DIY stackWritten by your team or consultants.Hyperscaler disconnectedStrongest for US government: GDC air-gapped holds DoD IL6.Kernwall OSGenerated by the system: OSCAL, STIG scans, mappings to CRA, IEC 62443 and the AI Act. Certifications on a dated roadmap. See the roadmap
Model choiceCloud APIThe provider's models.DIY stackAny open-weight model. Provenance checks are on you.Hyperscaler disconnectedOwn models first. Open-weight support announced 20 Oct 2026.Kernwall OSAny open-weight model from a provenance-cleared catalog, on NVIDIA or AMD.
Categories, not vendors · as of 29 Oct 2026
Where we don't fit

For US classified work at cloud scale, a hyperscaler's air-gapped region is the better answer today. Kernwall OS is designed for you if you need one accredited box, inside your wall, with no vendor holding a key to it.

Still being written

Next on this page.

Specified, but not yet drawn here. A design-partner call walks you through them.

  • A sample signed eval report

The OpenAI-compatible API, with a curl request, is in the last step of the offline install guide.

Book a demoRead the threat model