Confidential computing reached the GPU. Regulated AI workloads just got a new answer.

Industry reporting this month describes confidential computing expanding from CPUs into GPUs, multi-GPU configurations, containers and agentic workflows, with GPU-based confidential computing named as a principal catalyst for enterprise adoption of what is being called Confidential AI.

For most workloads this is an incremental security improvement. For a specific and commercially significant set, it removes a blocker that architecture could not.

The blocker it removes

Ask a bank, a hospital group or a defence supplier why a given model runs on-premise on hardware they own, and the answer is rarely about latency or cost. It is that the data cannot be processed on infrastructure where another tenant's workload shares the physical device, and no contractual assurance substitutes for that.

CPU enclaves addressed this years ago for conventional processing. Accelerated workloads were left out, which is precisely where models run. The result has been a familiar pattern: regulated organisations buying their own accelerators, at poor utilisation, to run models that a cloud could serve more cheaply and more reliably — because the alternative was not permitted.

The constraint was never technical capability. It was that nobody could make a defensible claim about isolation on a shared GPU.

What it does not remove

A trusted execution environment protects data in use against the host and other tenants. It says nothing about the model's behaviour. An agent operating inside a perfectly attested enclave can still take a harmful action, leak sensitive content through its own output, or be steered by injected instructions in retrieved documents.

This distinction will be lost in the marketing and it matters enormously. Confidential computing answers where the computation happened and who could observe it. Your safety case has to answer what the system did and why that was acceptable. The second question is not addressed by hardware, and a compliance narrative that conflates the two will not survive contact with a serious regulator.

The attestation question to ask vendors

For anyone evaluating this, the useful question is not whether a platform offers confidential GPU compute. It is what exactly is covered by the attestation, and what sits outside it.

Specifically: does attestation cover the GPU alone, or the CPU-GPU data path? In a multi-GPU deployment, does it cover the interconnect between devices? For an agent workflow, does it cover the orchestration layer and the tool invocations, or only the model forward pass? The gaps between those boundaries are where the interesting attacks will live, and they are exactly the places a datasheet tends to be quiet.

The capability is real and it genuinely changes what regulated organisations can deploy. The work of establishing what has actually been proven remains entirely with the buyer.

Written by the Devence Lab research team.