Where Confidential Computing Stops: Threats and Side Channels

Confidential computing changes the cloud execution boundary, but its protection is meaningful only against a defined set of attackers and observations. This discussion asks what a hardware TEE is meant to make economically or logically impractical, which threats remain outside that promise, and how information can leak through behavior even when direct memory access is blocked. The result is a risk model the reader can use to test a confidential AI design without turning “protected” into a synonym for “invulnerable.”

The need for that discipline follows directly from the key-release path. A workload may receive its model key only after the platform has produced acceptable evidence and a relying party has approved the state. That sequence reduces the chance that a privileged cloud component will simply read the model during execution. It does not answer whether an attacker can observe timing, exploit a protocol, deny service, compromise a client, or learn from an output. Those are different paths to harm and have to be diagnosed separately.

Start with the adversary, not the feature

The Confidential Computing Consortium describes the goal in deliberately qualified terms. Confidential computing aims to reduce the ability of a platform owner, operator, or provider to access data and code inside a TEE during execution until that path is not economically or logically viable for the attackers being considered. “Being considered” matters. A nation-state adversary, a casual privileged administrator, and an academic researcher may have different resources, time horizons, and reasons to pursue an attack. A design can substantially raise the barrier for one class without claiming to stop every class.

This goal is also about a particular state: data and code during execution. A confidential AI workload may use an encrypted model and an attested VM, but its model still has a lifecycle before and after the protected computation. It is provisioned, transported, stored, loaded, used, and eventually cleared. Storage and transport can be relevant to the system even when the TEE is not the component providing their protection. Migration between TEE environments, workload placement, and the security of the requesting client can also affect the result. The threat model prevents the execution boundary from absorbing responsibilities that belong elsewhere.

The first in-scope category is software attack. The host operating system, hypervisor, firmware, BIOS, and other software stacks may be privileged relative to the workload. Confidential computing is designed to address the possibility that such software is compromised or acts against the workload’s interests. For the model owner, the question is whether those layers can read or alter the model and input while they are inside the protected execution path. The answer depends on the silicon and TEE implementation; the general threat model says these host-side paths are relevant, not that every TEE mitigates them identically.

The second category is protocol attack. Attestation is a protocol, not just a hardware feature, and a weakness in it can undermine the decision that follows. If evidence can be forged, altered, replayed, or misinterpreted, a key-release service may authorize the wrong environment. Workload and data transport create another protocol boundary.