MICKAI
Article · 14 June 2026

Confidential Computing Is Not Sovereign Computing

An enclave hides your data while you compute on it. It does not give you the box, the keys, or a record you can prove without the vendor's permission. Those are different problems, and only one of them holds up in court.

Confidential Computing Is Not Sovereign Computing
Author
Micky Irons
Published
14 June 2026
Follow Micky Irons
LinkedInX
confidential computingtrusted execution environmentsovereign AIOpen Audit Recordpost-quantum cryptography

You can encrypt the box. You still do not own it.

There is a quiet sleight of hand in the way the cloud industry talks about confidential computing. The pitch is seductive and, on its own terms, mostly true. A hardware enclave, a trusted execution environment, takes your data while it is being processed and wraps it in a memory region the host operating system cannot read. Even the cloud administrator with root access on the machine cannot peek inside. Your data is protected at rest, in transit, and now, finally, in use. The last gap is closed. The marketing slides show a padlock inside a padlock, and you are invited to relax.

I want to be precise about what this actually buys you, because a lot of buyers are conflating two things that are not the same. Confidentiality is a property of data. Sovereignty is a property of control. An enclave can give you the first while leaving the second entirely in someone else's hands. You can run the most cryptographically airtight workload on earth and still be renting the box, renting the keys, and trusting the vendor's word about what happened inside. That is not a small caveat. For anyone who needs to prove what an automated system did, rather than merely keep it private, it is the whole ballgame. The two properties feel adjacent, so they get sold as if buying one delivers the other. It does not.

What an enclave is, and what it is not

A trusted execution environment (TEE) is a region of a processor that isolates code and data from everything else running on the same machine, including the operating system and the hypervisor. The mainstream implementations, application-level enclaves and virtual-machine-level enclaves, encrypt memory pages with keys held inside the central processing unit (CPU) and refuse to surrender plaintext to anything outside the boundary. Paired with this is remote attestation: the chip produces a signed statement saying, in effect, this is the exact code I am running, and here is a measurement to prove it, signed by a key rooted in the silicon vendor's certificate chain.

That is genuinely useful. It is the difference between hoping the host is honest and getting a cryptographic receipt for the code that loaded. I am not here to dismiss it. Confidential computing solves a real and previously unsolved problem: protecting data while it is being computed on, on infrastructure you do not physically control. If your threat model is a curious cloud operator or a compromised neighbour on shared hardware, an enclave raises the cost of attack considerably.

But notice what the attestation is rooted in. It chains up to the chip manufacturer. The attestation says the silicon vendor vouches that this code ran in a genuine enclave. You are not verifying anything yourself. You are accepting a signature from a party whose business model is selling you the box, validated against a revocation service the same party operates. The trust did not disappear. It moved up the stack, to somewhere you cannot see and cannot audit. That is fine when the vendor and the jurisdiction are aligned with you. It is a structural exposure the moment they are not.

The keys tell the real story

Follow the keys and the illusion thins out fast. The memory-encryption keys that protect enclave pages are generated and held inside the processor. You never touch them, never export them, never rotate them on your own authority. They are an artefact of the vendor's hardware. If the vendor's firmware has a flaw, and enclave technologies have shipped with several over the years, those keys are exposed by a supply chain you do not run. Side-channel research has repeatedly extracted secrets from production enclaves through timing, speculative execution, and power analysis. Each time, the fix arrives as a microcode update from the vendor, on the vendor's schedule, with the vendor's disclosure terms. You are a passenger in your own security posture.

Then there is the attestation key itself, the one that signs the receipt you are trusting. It lives in the vendor's root of trust. The vendor can revoke it. The vendor can be compelled by a legal order in its home jurisdiction to do things with it. The vendor's certificate service can go offline, and when it does, your ability to attest goes offline with it. A security realist asks one question of any trust claim: who can lie to me, and would I be able to tell? With enclave attestation, the silicon vendor can lie to you, or be forced to, and you would have no independent way to know. That is not a confidentiality failure. The data stayed secret. It is a sovereignty failure, and the two are different axes entirely.

Renting the box is a governance decision, not just a billing one

When you run a confidential workload in a hyperscale cloud, you have made a contract with at least three parties whose interests are not yours: the cloud operator who owns the datacentre, the silicon vendor who owns the trust root, and the jurisdiction whose laws bind both. The enclave protects you from the first reading your memory. It does nothing about the other two. A government order can compel a provider to alter behaviour at the orchestration layer that sits outside the enclave: who gets scheduled, what network path is allowed, when a machine is seized, whether your attestation service answers at all. The plaintext stayed inside the box. The box stayed inside someone else's building, under someone else's law. Confidentiality is silent on every one of those levers, because none of them require anyone to read your memory to hurt you.

Marble keyhole and antique key lit by gold rim light against void black, evoking who holds the keys.
Follow the keys. Enclave memory keys live inside the vendor's silicon, generated, held, and rotated on a supply chain the operator does not run.

This matters more, not less, as artificial intelligence (AI) systems take on consequential decisions. The European Union (EU) Artificial Intelligence Act brings its high-risk obligations into force from August 2026, and they are not satisfied by keeping data confidential. They demand records: logging, traceability, human oversight, the ability to reconstruct after the fact how an automated decision was reached. Liability regimes are moving the same way, shifting the burden onto operators to demonstrate what their systems did. Confidentiality answers did anyone see the data. Governance answers can you prove what the system did with it. An enclave is mute on the second question. It is designed to hide what happened, not to let you demonstrate it to a regulator, a court, or a counterparty who does not trust you.

Confidential and verifiable are orthogonal

Here is the distinction I keep coming back to, because once you see it you cannot unsee it. Confidentiality is about preventing observation. Verifiability is about enabling it, on your terms, after the fact, by anyone you choose to convince. These pull in opposite directions, and most confidential-computing architectures optimise hard for the first at the direct expense of the second. The whole point of an enclave is that nothing outside it can observe the computation. Which means that when you later need to prove what the computation did, your only evidence is a log the enclave chose to emit, signed by a key you do not control, attesting to a state you cannot independently reconstruct.

A sealed box that nobody can see into is the same box from which you cannot extract a self-standing proof. You are back to trusting the operator, only now the trust is dressed in cryptography that makes it feel rigorous. The right design goal for accountable AI is not a darker box. It is a record that is independently checkable: a log that anyone can verify, offline, with no live call to the vendor, no trust in the silicon root, no certificate service that has to be up. Confidentiality you can buy from a chip. Verifiability you have to architect deliberately, and almost nobody selling enclaves is architecting it for you, because their product is defined by the opposite instinct.

Sovereignty is owning the box and the keys

So let me say plainly what sovereign computing means, because the word gets abused. It is not a datacentre with a national flag on the brochure. It is not data residency, which only says where the bytes sit, not who controls the machine that processes them. Sovereignty is the combination of three things you must actually hold: control of the physical substrate the work runs on, control of the keys that sign and seal that work, and an evidentiary record that does not depend on anyone above you in the stack to be believed. If any of those three lives with a vendor, you have rented sovereignty, which is to say you do not have it. Renting any leg of that tripod is enough to topple the claim, because an adversary, or a court order, only has to reach the weakest leg.

This is the principle behind how we built Mickai, our Sovereign Intelligence Operating System (SIOS). Mickai is built and in production, not a prototype. It runs on its own silicon substrate, which we call Poseidon, hosting fifty brains, twenty-five domain and twenty-five operational. We are actively training our own models now, fine-tuning and specialising open foundations such as Llama 3.2 and Qwen 2.5 while we build a sealed corpus, and funding scales that work toward fully native weights. The point of running the substrate ourselves is not pride of ownership. It is that the keys, the model, and the record all sit on the same side of the trust boundary as the operator who is accountable for the outcome. You cannot outsource the proof and keep the responsibility.

The record that needs no permission to be believed

The mechanism that turns this from a slogan into something a court could accept is what we call the Open Audit Record (OAR). Every action an AI in the system takes is signed before it executes, not after. The signature is captured ahead of the effect, so there is no window in which a decision happens and the log is written afterward to flatter it. Each record is hash-chained to the one before, append-only, so the history cannot be quietly edited without breaking the chain. The signatures use post-quantum cryptography, the United States National Institute of Standards and Technology (NIST) standard FIPS 204, the ML-DSA-65 lattice scheme, so the proofs do not rot the day a quantum computer can forge today's signatures. Signing before execution is the unglamorous part that matters most, because a log written after the fact is a story the system tells about itself, and a signature captured before the action is a commitment it cannot take back.

The property that matters most, the one that separates this from enclave attestation entirely, is that an Open Audit Record is verifiable offline, in an ordinary web browser, with no trust in the vendor. You do not call our servers. You do not chain up to a silicon manufacturer's certificate. You do not need our attestation service to be online or honest. You take the record and the public keys, run the verification yourself, and either the chain holds or it does not. The audit root is anchored to Bitcoin through Pantheon, a sovereign Layer 1 with a fixed supply of five billion PAN tokens, so the timeline of what was recorded is pinned to an external clock no single party can rewrite. Pantheon is the one part of the architecture still being built. The signed, offline-verifiable record is live today.

Marble scales of justice holding a chain-linked tablet under gold rim light against void black, evoking verifiable evidence.
Confidentiality hides what happened. A signed, hash-chained, offline-verifiable record lets you prove it, with no faith in the vendor required.

Where confidential computing still earns its place

I am a security realist, not a maximalist, so let me be honest about the caveats and the overlap. Confidential computing is not the enemy of sovereign computing. The two compose well. An enclave is a fine tool for protecting data in use on hardware you control, and there are workloads, multi-party computation across organisations that genuinely distrust each other, or processing regulated data on edge hardware, where a TEE is exactly right. Sovereignty does not mean refusing every primitive a chip vendor offers. It means not mistaking those primitives for the whole of your trust model. Use the enclave to keep the data secret, and use a record you actually own to prove what was done with it. They answer different questions, and a serious architecture answers both.

And sovereignty has costs I will not pretend away. Owning the substrate means owning the maintenance, the physical security, the patching, the failure modes that a hyperscaler would otherwise absorb. It is harder. It is slower to stand up. For plenty of low-stakes workloads it is overkill, and renting an enclave in someone else's cloud is the sane, proportionate choice. The honest position is that the right architecture depends on whether you will ever need to prove what your system did to someone who has no reason to trust you. If the answer is never, confidentiality may be enough. If the answer is ever, you need the record, and the record cannot live on rented trust.

The question to ask your vendor

Strip away the diagrams and the question is simple. When something goes wrong, and with autonomous AI systems something eventually will, can you prove what happened without asking permission from the company you are trying to hold accountable? If the proof depends on the vendor's attestation service being up, the vendor's signing key being uncompromised, and the vendor's jurisdiction staying friendly, then you do not have proof. You have a promise with extra steps. An enclave gives you a very good promise. It does not give you independence from the party making it. The patents behind this approach, 101 filed United Kingdom patent applications carrying roughly 2,234 claims, owned by Mickai LTD with me named as the inventor, exist precisely because that independence has to be engineered, not asserted.

Confidential computing protects your data from prying eyes. That is worth having. But it leaves you renting the box, renting the keys, and trusting a chain of signatures that terminates in someone else's hardware and someone else's law. Sovereign computing is the harder, plainer thing: own the substrate, hold the keys, and produce a record that anyone can check offline, on their own, with no faith in you required. The padlock inside a padlock keeps the world from seeing in. A signed, hash-chained, offline-verifiable record lets you show the world exactly what you did, and prove it. Those are not the same product, and as the regulators arrive and the liability lands, the difference is going to stop being a slide and start being the thing that holds up in court.

Subscribe
Get every new Mickai article by email.

Long-form essays on sovereign AI from Micky Irons. One email per article. No tracking, no marketing, no third parties. Every email includes a one-click unsubscribe link.

Prefer RSS? Subscribe at /articles/feed.xml.

Originally published at https://mickai.co.uk/articles/enclaves-protect-data-sovereignty-owns-the-box. If you operate in a regulated sector or want sovereign AI on your own hardware, the audit form on mickai.co.uk is the entry point.
More articles
15 Jun 2026
The Provenance of a Generated Molecule
A regulator and a court will both ask how an AI-generated drug candidate was derived. The molecule is the hypothesis. The signed, offline-verifiable record of its generation is the asset you can actually defend.
14 Jun 2026
The Logbook That Cannot Be Rewritten: Autonomous Vessels and the Discipline of the Signed Record
A ship's logbook was admissible in court because it was written in real time, in sequence, and could not be quietly rewritten after the fact. Autonomous vessels keep the data and throw away the discipline. Here is what the sea taught us about records, and why the only honest answer is a signed, hash-chained, offline-verifiable account of every decision a machine makes at sea.
13 Jun 2026
The Black Box AI Never Built: Why Every Machine Decision Needs a Flight Recorder
Aviation became the safest way to travel not because crashes stopped, but because every crash became investigable. The flight recorder turned disaster into evidence. Artificial intelligence makes millions of consequential decisions a day and keeps almost no equivalent record. I want to explain why that gap is the central safety problem of the next decade, and what a real fix looks like.
15 Jun 2026
When the Network Runs Itself: The Account Telecoms Regulators Will Demand
In modern telecoms, artificial intelligence makes thousands of operational decisions a minute, and almost none of them are written down in a form anyone can later check. That gap is about to become a regulatory problem. The fix is not a better dashboard. It is a signed, hash-chained, offline-verifiable account of what the network decided and why.