Whose Root of Trust Is It? The Attestation Question Nobody Asks Their Cloud Vendor

By Micky Irons

Here is a question I put to security leads the moment the conversation turns to confidential computing, and it lands harder every time. When your GPU attests that it is running trusted code, who is it attesting to, and who wrote the definition of trusted?

In 2026 the answer for most organisations is the same three-letter answer three times over. The attestation service belongs to the provider. The key broker that releases secrets on a successful attestation belongs to the provider. The reference integrity manifest that says which firmware and driver versions count as good belongs to the provider. Three chokepoints, one owner. That is not a security posture. That is a supply chain you do not control, wearing the costume of one you do.

Attestation went mainstream, and almost nobody read the fine print

Attestation-gated inference had a genuinely good year. NVIDIA's remote attestation service, key-broker patterns that gate secret release on a verified device claim, and reference integrity manifests that pin acceptable measurements all moved from research decks into procurement checklists. This is progress. A confidential GPU that can prove it booted signed firmware and is running inside a genuine trusted execution environment is a real defence against a compromised host, a malicious operator, and a whole class of exfiltration attacks. I am not here to talk anyone out of it. I am here to ask what it actually buys you.

The part that gets waved through in the demo is the direction of trust. Attestation produces evidence. Something has to appraise that evidence against a policy and decide yes or no. In the mainstream cloud pattern, the appraiser and the policy both sit with the provider. Your workload asks the provider's service whether the provider's hardware is trustworthy, and the provider's service answers using the provider's manifest. The verifier is not independent of the thing being verified. If you have ever wondered why a vendor is so relaxed about letting you switch attestation on, this is why. It changes nothing about who holds the keys to the definition of good.

The three chokepoints, named plainly

Let me be specific, because security and cryptography leads deserve specifics rather than atmosphere.

The attestation service is the appraiser. It ingests the signed evidence from the device and returns a verdict, and often a token. If your provider operates it, your provider decides what a passing grade looks like, and can change that definition without asking you.

The key broker releases the secret (the model weights, the data-decryption key) on a passing attestation token. If the broker is the provider's, then the provider mediates every release of your own material into your own workload. Revocation, throttling, and the logging of those releases are theirs.

The reference integrity manifest is the rulebook of acceptable measurements. Whoever authors and signs it controls which firmware, microcode, and driver versions are permitted. Rotate the manifest and you can widen or narrow what runs, silently, on the provider's schedule rather than yours.

None of these three is malicious by design. The problem is structural. When all three co-locate with the counterparty whose behaviour you are trying to constrain, attestation stops being a check on the provider and becomes a feature the provider grants you. Sovereignty gets delegated and relabelled as assurance.

In an owned SIOS, the root of trust is yours

This is the intersection almost no one is serving, and it is the whole reason Mickai exists. Mickai is a Sovereign Intelligence Operating System. Regulated organisations own it and run it inside their own walls, air-gapped where the workload demands it, with a cryptographically-signed audit record written on every action. In that model the three chokepoints do not move to a vendor. They stay with you.

The appraiser runs inside your boundary. You hold the manifest and you sign it, so the definition of good is authored by the party that carries the liability. Secret release is brokered against your policy, on your hardware, and the whole exchange lands in an audit record you can hand an examiner without asking anyone's permission. When I say the root of trust is yours, I mean it in the literal cryptographic sense. The anchoring keys and the appraisal policy live where your accountability already lives.

Two Mickai capabilities make this concrete rather than aspirational. Our hardware-bound licensing binds a running instance to specific machine identities using post-quantum signatures, so an instance is cryptographically tied to the silicon you actually own and cannot be silently relocated or cloned. And the signed audit record means every attestation decision, every key release, and every manifest version is written to a tamper-evident log that is yours to keep and yours to produce. That is the difference between trusting a verdict and being able to prove one. If you want the deeper mechanics, our writing on hardware-bound licensing for sovereign AI and on the signed audit record as a compliance primitive both go further than I can here.

What this is not, so I do not oversell it

I will be straight about the market, because over-claiming is how trust gets burned. Almost no regulated organisation is legally barred from cloud. DORA, the FCA and PRA regimes, the EBA guidelines, the NHS DSP Toolkit, and GDPR all permit cloud with the right controls. The genuine no-cloud bar is workload-level: classified material at SECRET and above, ITAR-governed data, isolated OT and SCADA environments, and cases where a data protection impact assessment comes back negative. Everywhere else, this is preference, not prohibition. Organisations choose to hold their own root of trust for control, for cost, and to remove a data-exfiltration path they can never fully audit while it sits with someone else.

That preference addresses a large and countable market. On our register-backed sizing it reaches roughly 16,092 UK and EU institutions, spanning about 7,933 regulated-core organisations plus an 8,159-strong large-private adjacency. It sits inside an enterprise AI-platform software category that Verdantix sizes from USD 13bn in 2024 toward USD 50.3bn by 2030, which is about £11.7bn to £39.7bn at $1.267 to the pound. That is a strong enough case that it does not need embellishment.

The takeaway, and the one question to ask

The mainstream attestation story of 2026 is real and worth adopting. But adopting it inside someone else's cloud does not answer the root-of-trust question. It answers a narrower one (is this GPU genuine) and lets the provider quietly keep the harder one (who decides what genuine means). Owning your SIOS is how you take that decision back.

So here is the question to put to your cloud vendor, in writing, before the next renewal. Who authors and signs the reference manifest my workloads are appraised against, who operates the key broker that releases my secrets, and can I hold and produce the audit record of every one of those decisions myself? If the answer to all three is the vendor, you do not hold the root of trust. You are renting a verdict.

The engineering behind Mickai's approach is protected by 104 UK patent applications spanning roughly 2,340 claims across 13 families, named inventor Mickarle Wagstaff-Irons, filed and building toward examination and grant. I would rather show you the architecture than talk around it.

Frequently asked questions

What is the difference between remote attestation and holding your own root of trust?

Remote attestation proves that a device booted trusted code and is running inside a genuine trusted execution environment. Holding your own root of trust means you own the appraisal: the keys that anchor trust, the reference manifest that defines acceptable measurements, and the key broker that releases secrets. Attestation without ownership of those three tells you the hardware is genuine while leaving the provider in control of what genuine means.

Does using an owned SIOS mean abandoning confidential-computing hardware?

No. The two are complementary. You still want a confidential GPU and its attestation evidence. The difference is that in an owned Mickai SIOS the service that appraises that evidence, the manifest it appraises against, and the broker that releases your secrets all run inside your boundary rather than the provider's, with the signed audit record proving every decision.

Are regulated organisations legally required to run inference on their own infrastructure?

Almost never at the whole-organisation level. Most regimes, including DORA, the FCA and PRA rules, the EBA guidelines, the NHS DSP Toolkit, and GDPR, permit cloud with controls. The genuine no-cloud bar applies to specific workloads such as classified material, ITAR data, and isolated OT or SCADA. For everyone else, holding your own root of trust is a sovereignty preference about control, cost, and exfiltration risk, not a legal mandate.

How does hardware-bound licensing relate to attestation?

Attestation answers whether the code and device are trusted. Hardware-bound licensing answers whether this instance is authorised to run on this specific silicon. Mickai binds an instance to machine identities using post-quantum signatures, so the instance is cryptographically tied to hardware you own and cannot be silently relocated or cloned. Together they close both the trust question and the authorisation question inside your own walls.