The Cloud Can Run Your AI Without Holding Its Secrets
Confidential computing for cloud AI is the subject of this series, and this opening focuses on the moment ordinary cloud security leaves a sensitive workload exposed: while a model is running. The practical question is not simply whether a provider encrypts stored files or network traffic, but whether the provider’s operating environment must also receive the model and its inputs in readable form during inference. By the end of this series, the reader should be able to trace that question through hardware isolation, attestation, policy, and controlled key release—and judge what those mechanisms still leave outside their boundary.
Imagine an organization that has trained a model to assess a sensitive record. The model may be valuable intellectual property; the record may contain medical, financial, or proprietary information. Sending the workload to the cloud may provide the storage, computing capacity, and scale the organization needs. It may also place the model and record on infrastructure administered by people and software outside the organization’s direct control. The cloud is not necessarily malicious for this to matter. A privileged administrator, a compromised hypervisor, a vulnerable host component, or an exposed diagnostic path can become a route to data that was meant to be protected.
That tension gives confidential computing its subject and its stakes: protecting data and code while they are being used in a shared or otherwise insufficiently trusted execution environment. The central idea is a change in the trust boundary. Instead of assuming that every layer surrounding the workload can see plaintext and will protect it correctly, the design uses hardware-enforced isolation and evidence about the workload’s state to make access to secrets conditional.
The part of the workload that encryption leaves exposed
Security discussions often divide data into three states. Data moving across a network is in transit. Data held in a database, disk, or object store is at rest. Data being transformed by a processor is in use. Encryption has become common for the first two states, but conventional computation generally requires the processor to work on readable values. A model file can be encrypted in storage and an inference request can be encrypted on its way to a service; at some point, the service still has to load usable model parameters and input values into memory to calculate an answer.
That moment is not a minor technical footnote. It is where the cloud’s ordinary privilege model becomes relevant. The operating system manages processes and memory. The hypervisor manages virtual machines. Infrastructure software can have broad administrative authority. If the model and the input are readable in those layers during computation, encryption around the edges has not closed the execution-time exposure. It has protected the journey to the computation and the place where the result rests, but not necessarily the computation itself.
Confidential computing addresses this missing state by performing the computation in a hardware-based, attested trusted execution environment, usually called a TEE. The relevant promise is that unauthorized entities cannot view or alter data and code while they are being used inside that environment, according to the implementation’s threat model. For a cloud AI workload, the protected assets are therefore twofold. The model contains parameters, algorithms, and accumulated research effort. The input may contain the information that makes the inference valuable—or makes it sensitive. Protecting only one of them can leave the other as a route to loss.
The relationship among the three data states is easier to see as a path:
The diagram is not saying that a TEE magically converts every input and output into protected data. It shows the design problem: the execution boundary is added after the familiar protections, and access to the model key is made a decision rather than an automatic consequence of placing a workload on a VM. If the conditions for that decision are not met, the workload should not obtain the material needed to run the protected inference.
Confidential computing changes who must be trusted
The Confidential Computing Consortium defines confidential computing as protecting data in use by performing computation in a hardware-based, attested TEE. That definition matters because it names both halves of the idea. Hardware supplies an isolation boundary below the ordinary host software stack. Attestation supplies evidence that another party can examine before deciding whether to trust the environment. The result is not merely “encryption while running,” and it is not limited to one cloud provider, one processor, or even the cloud as a setting.
The hardware boundary changes who must be trusted with plaintext. In a conventional stack, an organization may have to rely on the operating system, hypervisor, platform operator, and administrators to preserve the confidentiality and integrity of active data. A hardware-backed TEE is intended to reduce that dependence. The cloud provider may still supply the machine, schedule the VM, maintain the service, and influence availability, but the model owner can try to keep the provider’s privileged infrastructure from becoming an automatic reader of the model or the inference data.
That reduction is not the same as eliminating trust. The organization now has to rely on the TEE’s hardware and firmware, its attestation roots, the software that collects and interprets evidence, the reference values used by policy, and the workload code that runs inside the boundary. The meaning of “trusted” becomes more specific. It refers to a set of properties and conditions rather than to a blanket judgment about the whole cloud.
Those properties include confidentiality, integrity of the data being used, and integrity of the code performing the computation. Some TEEs also provide code confidentiality, authenticated launch, general programmability, attestability, or recovery after a component is repaired. The details vary. An AI service cannot safely infer capabilities from the word “enclave” alone; it has to ask what is protected, what can run, what evidence is available, and which failures can be recovered.
The other important change is that the TEE does not have to hand its secrets to the cloud simply because it has launched. A workload can present evidence about its hardware and software state. A verifier can check the evidence and compare measurements with expected values. A relying party—such as the application owner or a service acting on that owner’s behalf—can then apply a policy: is this the approved code, on the expected kind of platform, in an acceptable state? Only that decision should lead to the key-release step that makes the encrypted model usable.
This is the basic trust chain that will govern the rest of the discussion. Hardware enforces a boundary. Attestation describes the environment. Policy decides whether the description is acceptable. Key management enforces the decision. The AI workload then performs its inference inside the boundary, rather than treating the cloud host as a place where an unrestricted plaintext copy can be left behind.
A trust chain, not a secure box
The NIST reference architecture makes this logic concrete through an encrypted machine-learning model and sample health data. Its prototype uses a TEE-capable virtual machine, remote attestation, a relying-party service, a key management system, and a key broker. The named implementation uses Intel TDX and related services, but NIST presents it as one possible approach, not as a universal recipe or an endorsement of particular products. What transfers beyond that example is the relationship among isolation, evidence, authorization, and key custody.
The architecture can be understood as four linked conditions. First, the workload needs a platform that can provide the intended confidential-execution capability. Second, it needs a way to produce and verify evidence about the platform and the code that started there. Third, a relying party must translate that evidence into a policy decision about what the workload may access. Fourth, the key-release path must deliver only the material that an approved workload can use to decrypt its model or inputs. A VM with confidential hardware but no meaningful appraisal process leaves the owner unable to tell whether the requester is the workload they intended. Evidence without an authorization policy proves something without deciding what it permits.
This is why the subject is more demanding than a secure box placed around a program. The strength of the design lies in the links and their ownership. The model owner must decide which state is acceptable. The verifier must validate authentic and timely evidence. The key authority must enforce the release condition. The application must still handle data, outputs, logs, and errors responsibly. Each link can be well designed while the overall result remains weak if the assumptions do not line up.
The same discipline applies to the limits. The consortium explicitly rejects the idea of absolute security. Confidential computing aims to make certain provider-side paths to data and code economically or logically unviable during execution, not to solve every threat. Side channels may reveal information through timing, power, caching, or other behavior. Availability attacks remain a separate concern. Storage, transport, migration, client security, application bugs, and lifecycle decisions can all matter. A platform may also need revocation and recovery when a trusted component is found to be flawed.
The first useful question, then, is not “Is the cloud trusted?” It is “Which party should be able to access which asset, at what point in the workload’s life, and what evidence should justify that access?” For confidential AI, that question keeps both the model and the data in view. It also makes the next technical distinction unavoidable: before an attestation report can authorize a key, we need to understand exactly what a trusted execution environment promises, and where that promise stops.