Confidential AI Needs Attestation Evidence Before Sensitive UK Workloads Move

The Sovereign Cloud

9 September 2026 | By Ashley Marshall

Confidential computing is not a magic privacy label. For sensitive UK AI workloads, the useful question is whether you can prove what ran, where it ran and which controls were active.

The real question is proof, not location

For the last year, many AI infrastructure conversations have started with a familiar question: is the workload in the UK, in the EU, in a private cloud or on a hyperscaler? Location still matters, especially for contractual commitments, sector expectations and operational resilience. But confidential AI changes the more important question. If a business is processing client files, financial records, HR cases or regulated operational data, it needs to know whether the workload ran in an approved environment, with the expected model, policy, firmware and access controls. A regional data centre does not answer that on its own.

The UK government's secure AI infrastructure call for information, published by DSIT with AISI and NCSC, is useful because it names the problem plainly. It asks for better evidence around trusted computing foundations, secure boot, integrity, identity and attestation across the full stack, including hardware, firmware, software, model weights and agent components. It also highlights verifiable confidential compute, protective monitoring, telemetry and ways to evaluate whether these protections actually work. That is the practical shift for UK buyers. The board should not be asking for a vague assurance that data is protected in use. It should ask what evidence proves that protection was active at the moment the AI workload ran.

What this means in practice is simple. A buyer checklist should include attestation evidence alongside data processing terms, ISO certificates and penetration test summaries. It should define which measurements are accepted, how long evidence is retained, who can review it, and what happens when a workload fails attestation. Without that, confidential AI becomes another supplier promise that is hard to verify when something goes wrong.

Confidential computing protects data in use, but it still needs controls around it

Confidential computing is valuable because it targets a gap that ordinary cloud controls do not fully close: data while it is being processed. The Confidential Computing Consortium defines it as protection of data in use by performing computation in a hardware-based, attested Trusted Execution Environment. In plainer terms, the workload should be isolated from other software and administrators on the underlying machine, and a third party should be able to verify that the expected protected environment exists. For AI, that matters because prompts, retrieved documents, embeddings, tool credentials, agent instructions and model outputs can all be sensitive while the system is running.

The misconception is that confidential computing removes the need to trust the supplier. It reduces one category of trust, but it does not remove governance. You still need to know who selected the model, who approved the retrieval sources, what tools the agent can use, how keys are managed, how logs are retained and how incidents are handled. An attested enclave running the wrong workflow is still the wrong workflow. A confidential environment with excessive permissions can still process more data than the business intended. A protected model call with no audit trail will still be hard to defend to a client, insurer or regulator.

For UK businesses, the useful pattern is to treat confidential computing as one layer in a workload placement decision. Put it next to data classification, identity controls, network restrictions, supplier due diligence and operational monitoring. Use it for workloads where the business value justifies the extra evidence burden: legal document review, board packs, acquisition analysis, healthcare triage support, financial reconciliations, sensitive HR casework or regulated client service. Do not use it as a blanket excuse to move every risky workflow faster.

Agentic AI makes attestation more urgent

Attestation becomes more important as AI systems become more agentic. A standard chatbot mainly produces text. An agent can read from systems, write to systems, call tools, branch across tasks and continue working after the initial prompt. NCSC's August 2026 advice on managing the cyber risk of agentic AI is clear that organisations should assess how much autonomy is needed, understand built-in safeguards, add further safeguards where the consequences of failure are above tolerance, and maintain observability, monitoring and emergency shutdown. That advice connects directly to confidential AI because an autonomous workload is only as trustworthy as the environment and permissions around it.

The risk is not just that a model might produce a poor answer. It might access information it should not, take an action outside scope, call a tool in the wrong sequence or continue after a failure condition. NCSC specifically calls out sandboxing, attribution, audit, monitoring and the ability to pull the plug. If that agent is handling sensitive data inside a confidential environment, the buyer also needs proof that the agent's identity, code, approved tools and runtime policy matched the agreed configuration. Otherwise, the confidential part protects a moving target.

What this means in practice is that attestation should include more than the hardware. A useful agentic AI evidence pack should connect the infrastructure measurement to the application release, model version, policy file, tool allowlist, retrieval index, identity used for downstream systems and shutdown control. If the agent changes, the evidence should change. If a supplier cannot explain how those records join together, the buyer should treat the deployment as experimental, not production ready.

Data protection still follows the design choices

The ICO's Tech Futures report on agentic AI makes a point UK leaders should keep close: organisations remain responsible for data protection compliance for agentic AI they develop, deploy or integrate. The report also says that design and architecture affect how data protection law applies and how people exercise their rights. That is exactly why confidential AI evidence needs to be joined to privacy design, not left as a technical appendix.

The ICO identifies novel risks including unclear controller and processor responsibilities, overly broad purposes, unnecessary processing of personal information, unintended use or inference of special category data, increased complexity around transparency and information rights, and new cyber security threats. Confidential computing can help with some cyber and confidentiality risks, but it does not automatically define a lawful purpose, minimise data, explain a decision or respond to an access request. If a customer service agent can open every record in the CRM when it only needs one case file, confidential compute does not solve the access problem. If a finance assistant keeps prompts and outputs longer than needed, the protected runtime does not solve the retention problem.

A sensible UK deployment should therefore pair attestation with a privacy impact record. Define the lawful basis, data categories, purpose limits, data minimisation rules, retention period, human review points and rights handling process. Then make the technical evidence prove those decisions were implemented. For example, an attestation record can show the approved policy bundle was loaded, while application logs show which records were retrieved and why. That gives the business a defensible story if a client asks how their information was protected.

What buyers should demand from suppliers

The procurement question should move from 'do you support confidential computing?' to 'show me the evidence I can rely on'. A strong supplier should be able to provide a clear attestation flow, plain-English explanation of what is measured, records showing that approved configurations ran, and a process for failed or missing attestation. They should also be honest about limitations. Side channels, firmware dependencies, accelerator support, logging trade-offs, performance overhead and operational complexity all matter. DSIT's call for information specifically asks for views on technical feasibility, maturity, realistic timelines, performance, cost, operational trade-offs, adoption barriers and assurance methods. Those are buyer questions too.

For most UK SMEs and mid-market firms, the answer will not be to build confidential AI infrastructure themselves. It will be to demand better evidence from managed providers, cloud platforms and AI vendors. Ask whether the workload uses CPU or GPU confidential computing, whether model weights are protected, whether remote attestation is available to customers, whether logs can be exported, whether identities are hardware-bound, whether administrative access can bypass the control, and whether incident response includes attestation failures. If the supplier only answers with brand names and architecture diagrams, keep pushing.

Cost also needs to be treated honestly. Confidential AI may add operational friction and can carry performance or availability trade-offs, depending on the stack. That does not make it unsuitable. It means it should be reserved for workloads where sensitive data, contractual risk, regulatory exposure or client trust justify the control. A lightweight marketing copy generator probably does not need it. An agent reading legal matter files, merger documents or patient communications might.

Build an attestation evidence pack before migration

Before moving a sensitive AI workload, create a small evidence pack. It does not need to be theatrical. It should be a practical operating document that security, operations, legal and business owners can understand. Start with workload classification: what data is involved, why AI is being used, what systems are connected, and what could happen if the workload is misused or exposed. Then add the approved runtime baseline: cloud region, hardware class, confidential computing capability, model and version, retrieval sources, tool permissions, identity, logging, retention and shutdown route.

Next, define the evidence that must exist before the workload runs. That could include remote attestation results, release approval, supplier change notice review, policy hash, model version record, tool allowlist, access review and a test proving the kill switch works. Then define the evidence that must exist after the workload runs: activity logs, retrieval logs, exception records, human approvals, output sampling, data deletion confirmation and incident review triggers. The point is not paperwork for its own sake. It is to make workload placement repeatable, reviewable and explainable.

The counterargument is that this slows adoption. It can, if treated as a heavyweight governance ceremony. But for sensitive workloads, the real delay comes later when nobody can prove why a supplier was trusted, which records were accessed, or whether the promised protected environment was actually used. Confidential AI is a good technical direction. It becomes a business control only when attestation evidence is collected, checked and tied to decisions people are accountable for.

Frequently Asked Questions

What is confidential AI?

Confidential AI usually means running AI workloads in environments that protect data while it is being processed, often using confidential computing and remote attestation. The useful buyer test is whether the supplier can prove the approved protected environment was used.

Is confidential computing the same as data residency?

No. Data residency is about where data is stored or processed. Confidential computing is about protecting data in use and proving that the workload ran in an expected protected environment. A UK region can still need confidential computing evidence for sensitive workloads.

Does confidential AI make a workload UK GDPR compliant?

No. It can support security and confidentiality, but UK GDPR compliance also depends on lawful basis, purpose limitation, data minimisation, transparency, retention, rights handling and processor controls.

What is remote attestation?

Remote attestation is evidence that a workload is running in an approved configuration. In AI, useful attestation should connect the infrastructure state to the model, software, policy and agent components that were allowed to run.

Which AI workloads should use confidential computing first?

Start with workloads involving sensitive personal data, legal or financial documents, regulated client work, high-value intellectual property, board materials or agents with access to operational systems.

What should we ask an AI supplier before moving sensitive workloads?

Ask what is measured, whether customers can access attestation evidence, how failed attestation is handled, which administrators can access what, how logs are retained, and whether model, tool and policy versions are tied to the evidence.

Can confidential AI replace human oversight?

No. It is a technical protection layer. NCSC guidance on agentic AI still points to proportional oversight, sandboxing, monitoring, attribution and emergency shutdown for autonomous systems.

Is this only relevant for large enterprises?

No. SMEs may not build the infrastructure themselves, but they still buy AI services that process sensitive data. They should ask managed providers and SaaS vendors for evidence that sensitive workloads are protected and auditable.