Attestation-Gated Keys Are Clever. They Still Do Not Own the Building

Confidential computing had a very good 2026. NVIDIA shipped confidential GPUs across Hopper, Blackwell, and now Rubin, with encrypted VRAM and a hardware root of trust that actually holds up under inspection. Intel TDX and AMD SEV-SNP matured into production trust domains. NVIDIA's Remote Attestation Service (NRAS) turned attestation from a research demo into an operational gate: your key only gets released once the platform proves, cryptographically, that it is running the firmware and measurements you expected. If it lies, the key stays locked. That is a real control, and we want to say so plainly before we say anything else.

We are Mickai, a Sovereign Intelligence Operating System that regulated organisations own and run inside their own walls. We have every commercial reason to wave confidential computing away. We are not going to, because pretending a serious control is not serious is how you lose the trust of the one audience that matters here: the security architect who has already read the whitepapers.

What attestation-gated key release actually buys you

The mechanism is elegant. A workload boots inside an encrypted enclave (a TDX trust domain, an SEV-SNP guest, a confidential GPU context). The hardware measures the firmware, the guest image, and the accelerator state, and signs those measurements with a key rooted in the silicon vendor's certificate chain. Your key-release service, NRAS or your own verifier, checks that quote against a known-good policy. Only on a pass does the decryption key reach the enclave. Memory, including VRAM, is encrypted at rest and in use, so a memory-dump attack from outside the enclave yields ciphertext.

For most cloud-AI threat models this genuinely raises the floor. A curious co-tenant cannot read your model weights out of shared memory. A compromised hypervisor cannot silently swap your image without breaking the measurement. A patched-but-untrusted driver stack fails the attestation and never sees the key. If your concern is a noisy-neighbour breach or a run-of-the-mill infrastructure compromise, confidential computing meaningfully shrinks the attack surface. We build attestation into Mickai for exactly these reasons, so this is not grudging respect. It is the same primitive, used well.

Where it stops: the host trust boundary

Here is the honest limit, and it is structural, not a bug. Attestation proves the state of a machine. It does not change whose machine it is.

When a confidential VM attests in a hyperscaler region, the verifier you are ultimately trusting is the cloud provider's and the silicon vendor's. The root of trust is the provider's platform, provisioned by the provider's supply chain, patched on the provider's schedule, and physically resident in the provider's building. Attestation gives you a strong statement of the form "this is the firmware and image you asked for." It cannot give you a statement of the form "no one with lawful or physical access to this datacentre can ever compel, coerce, or reconfigure the trust anchor." Those are different guarantees, and only one of them is cryptographic.

This is the point the marketing tends to blur. Confidential computing narrows the technical insider-threat surface. It does not dissolve the jurisdictional and operational trust you are placing in the party that owns the hardware. As Micky Irons, our founder and CEO, has put it: the sharpest risk in AI infrastructure is not a stranger on the internet, it is a privileged insider at the hyperscaler, and no key-release policy running on that hyperscaler's own root of trust can fully attest away the entity that controls the root.

Three gaps attestation-gated keys leave open

Be specific, because architects deserve specifics.

The host trust boundary. Your attestation is only as sovereign as the verifier and the key-release authority. If both sit inside the provider you are trying to constrain, you have improved the control without relocating the trust anchor. You are still asking the landlord to certify the safe.

Provider jurisdiction. Encrypted VRAM does not answer a lawful-access request, a change of terms, a regional outage, or a government order served on the operator. Data-residency and sovereignty regimes care about who can be compelled, and a confidential VM in someone else's estate remains subject to their governing law and their operator obligations.

Operational access. Firmware updates, attestation-policy definitions, certificate revocation, and break-glass procedures are all operated by the platform owner. The measured-boot chain is trustworthy precisely because the owner curates the known-good values. That curation is a standing operational dependency on the very party the sovereignty question is about.

None of these is a reason to abandon confidential computing. They are the reasons attestation is a component of sovereignty, not a substitute for it.

What owned attestation completes

Mickai's position is not "confidential computing is wrong." It is "confidential computing finishes the job only when you own the root." When the organisation owns and runs the SIOS inside its own walls, air-gapped where the workload demands it, the verifier, the key-release authority, and the physical trust anchor all sit on the organisation's side of the boundary. The same attestation primitives now attest a machine you provision, in your building, under your jurisdiction. Every action Mickai takes carries a cryptographically-signed audit record, so attestation is not a one-time boot gate but a continuous, owned ledger of what the system did.

That is the difference between renting a very good safe in someone else's vault and owning the vault. The lock can be identical. The building is not.

Our patent estate reflects this design directly: 104 filed UK patent applications spanning roughly 2,340 claims across 13 families, with named inventor Mickarle Wagstaff-Irons, building toward examination and grant, cover owned attestation, signed-audit provenance, and sovereign key custody as an integrated system rather than a bolt-on to rented infrastructure.

The honest market picture

We will not tell you that regulation bars you from the cloud. It mostly does not. DORA, the FCA and PRA regimes, the EBA guidelines, the NHS DSP Toolkit, and GDPR all permit cloud with the right controls, and confidential computing is one of those controls done well. The genuine no-cloud bar is workload-level: classified material at SECRET and above, ITAR-controlled data, isolated OT and SCADA environments, and cases where a data-protection impact assessment comes back negative.

For everyone else the driver is preference, not prohibition: control over the trust anchor, cost predictability, and the elimination of data-exfiltration paths you cannot fully audit. That preference addresses a register-backed sovereign market of roughly 16,092 UK and EU institutions (7,933 regulated core plus 8,159 large-private adjacency), against an enterprise-AI-platform software TAM that Verdantix sizes from USD 13bn in 2024 to USD 50.3bn by 2030, about £11.7bn to £39.7bn. Confidential computing and owned sovereignty are not competitors for that market. They are the same escalator, one step apart.

The takeaway

Attestation-gated keys are clever, and we mean that as a compliment. They prove the state of a machine and keep your key locked when the state is wrong. What they cannot do is change whose machine it is. If your threat model tops out at co-tenants and infrastructure compromise, confidential computing may be enough. If it includes the operator, the jurisdiction, and the privileged insider with lawful access to the building, you need the root of trust on your side of the wall. That is what owning the attestation completes, and it is what Mickai is built to be.

Frequently asked questions

Does confidential computing make cloud AI as secure as on-premise?

For a narrow threat model, close. Encrypted VRAM and attestation-gated key release defeat co-tenant memory reads and untrusted-hypervisor tampering. What they do not defeat is trust in the operator who owns the root of trust and the verifier. On-premise, or an owned SIOS, moves that root to your side of the boundary. The cryptography can be identical; the ownership is not.

Is NRAS or vendor attestation enough for a sovereignty requirement?

Attestation is necessary but not sufficient. If the verifier and key-release authority live inside the provider you are trying to constrain, you have strengthened the control without relocating the trust anchor. Sovereignty requires that the attestation root, the key custody, and the physical hardware all sit under your jurisdiction and control.

Are regulated firms legally barred from using the cloud?

Almost never at the firm level. DORA, FCA and PRA rules, EBA guidelines, the NHS DSP Toolkit, and GDPR all permit cloud with appropriate controls. Genuine no-cloud bars are workload-specific: classified data, ITAR, isolated OT and SCADA, or a negative data-protection impact assessment. Most demand for sovereignty is preference, not prohibition.

How does Mickai use attestation differently?

We use the same hardware attestation primitives, but the organisation owns and runs the SIOS inside its own walls, so the verifier, the key-release authority, and the physical trust anchor all sit on the customer's side. Attestation becomes continuous and owned, backed by a cryptographically-signed audit record on every action, rather than a boot-time gate operated by a third party. See our related writing on the insider-threat-at-the-hyperscaler problem and on sovereign key custody for how the pieces fit together.