Whose Root of Trust Is It: Confidential Computing Versus Operator-Owned Silicon

Confidential computing has become the default answer whenever a regulated organisation asks how it can run sensitive workloads on infrastructure it does not fully control. The pitch is compelling: memory is encrypted while in use, a hardware enclave isolates the workload from the host operating system, and a signed attestation proves that the code inside the enclave is the code you expected. For a CISO weighing a cloud migration, or an NHS trust deciding where patient data may be processed, it looks like a clean resolution to years of unease.

Yet the question that matters in 2026 is not whether the memory is encrypted. It is whose signature sits at the bottom of the trust chain. As the EU AI Act reaches full application on 2 August 2026, as the UK Sovereign AI programme presses for compute and models under national control, and as ISO/IEC 42001 pushes management-system accountability into procurement, the party that mints the attestation stops being a footnote and becomes the whole question.

What confidential computing actually proves

An enclave attestation is a statement, signed by the silicon vendor, that a given piece of code is running unmodified inside a genuine piece of that vendor's hardware. The relying party checks the signature against a vendor certificate chain and, satisfied, releases secrets into the enclave. The mechanism is real and the cryptography is sound. What is often unstated is that every link in that chain terminates at a key the vendor generated, holds and can revoke.

That is reasonable for its original purpose: letting a tenant distrust the cloud host while still trusting the chipmaker. The vendor is the neutral referee between two adversaries. The difficulty arrives when the buyer's threat model is broader. If the concern is a subpoena served on the vendor, a firmware update pushed under legal compulsion, or an export-control action against the certificate infrastructure, the referee is no longer neutral. Confidential computing answers the question it was designed to answer, not the one many regulated buyers now ask: will the machine keep obeying its owner if the vendor is compelled to intervene.

The trust anchor is a governance decision, not a chip feature

Where the root of trust lives is usually framed as a technical detail. It is not. It is a governance decision quietly delegated to a supply chain. When the anchoring key belongs to a vendor, that vendor becomes a party to every attestation your auditor relies on, whether or not it is named in your data-protection impact assessment.

A vendor-rooted enclave depends on a provisioning service, a revocation service and a certificate authority, all operated outside the buyer's jurisdiction. An attestation valid on Monday can fail on Tuesday because something changed upstream that the operator neither saw nor authorised. For a system of record in health, defence or critical national infrastructure, that is a dependency the accounting officer cannot fully describe, and one you cannot describe is one you cannot govern.

Operator-owned silicon: burning the anchor at first power-on

There is a different way to place the anchor. Instead of relying on a key the vendor minted before the hardware ever reached the buyer, the operator personalises the silicon root of trust at first power-on, on the buyer's premises, under the buyer's control. A device-unique key is generated inside the secure element and never leaves it; the public half is enrolled by the operator. From that moment the machine attests to an identity the owner created, not one assigned in a factory the owner never visited.

This is the design principle behind Mickai, our Sovereign Intelligence Operating System, a SIOS that runs offline on operator-owned hardware. Every action it takes is sealed against a hardware-attested identity established by the operator, not issued by a third party. The enclave still protects data in use; the difference is that the bottom of the trust chain now terminates inside the customer's estate, so an attestation cannot be silently invalidated by a party the customer never contracted with. Vendor-rooted computing verifies that the vendor's hardware runs your code; operator-rooted silicon verifies that your hardware, personalised by you, runs your code, without asking any certificate service for permission.

“Encryption in use protects the data; the location of the trust anchor decides who ultimately governs the machine.”

Offline verifiability and the zero-egress perimeter

An anchor the operator owns is only as sovereign as its independence from the outside world. If verifying an attestation still requires a call to a remote service, the sovereignty is nominal. Offline verifiability is therefore structural: the relying party must check an attestation against locally held roots, with no outbound connection. We pair that with a zero-egress inbound perimeter, so data and instructions may enter under policy while nothing about the workload, the model or the sealed record leaves. The system can then prove its integrity to an internal auditor during a network outage.

Sealing what the machine did, so an auditor can replay it

A root of trust is the foundation, not the whole building. Its value is realised when every consequential action is written into a tamper-evident record chained back to that identity. We seal each action into a post-quantum signed audit chain, with each entry referencing the last and signatures chosen to survive the arrival of cryptographically relevant quantum computers. When an autonomous agent acts, the accountable question is not only what it did but whether the record can be trusted and independently replayed. A chain rooted in vendor-held keys inherits the vendor's revocation risk; one rooted in operator-owned silicon does not, and that is the difference between accountability and assertion.

What a serious buyer should actually test

None of this argues that confidential computing is a mistake, only that the buyer should read the trust chain to its end before treating an enclave as a sovereignty control. The right questions are procurement questions, answerable on paper before any deployment.

• Who generated the key at the bottom of the attestation chain, and can any external party revoke or reissue it without the operator's consent?
• Can an attestation be verified fully offline, against roots the operator holds, with no call to a remote service?
• If a vendor were compelled by law or export control to act, which of the buyer's guarantees would survive, and which would quietly lapse?
• Is the record of what the system did sealed against a key the operator owns, and can an auditor replay it independently?

These questions do not have marketing answers; they have architectural ones, and the architecture is either present or it is not. Much of what makes an operator-owned anchor practical, from the personalisation flow to the sealed audit chain, sits within the 104 filed UK patent applications, approximately 2,340 claims, owned by Mickai LTD, all filed and patent pending rather than granted.

Where this goes next

The regulatory direction of travel in 2026 rewards operators who can describe their trust dependencies precisely and control them locally. As the EU AI Act's obligations bite and sovereign-AI programmes ask where compute and models actually sit, the buyers who fare best will answer one question without hedging: if every external party disappeared tomorrow, would this machine still prove its own integrity to us? What is changing is the recognition that encryption in use and ownership of the trust anchor are two different guarantees, and only the second is a sovereignty control. Any serious buyer should treat the location of that anchor as a first-order requirement, and ask who, in the end, holds the key.