What Confidential Computing Actually Changes
This chapter explains the mechanism that makes data-in-use protection possible: a trusted execution environment, remote attestation, and a policy-controlled decision about whether a model key may be released. The useful outcome is a precise mental model. Readers should be able to say what a TEE keeps away from privileged cloud software, what an attestation report can establish, and why the key—not the word “confidential”—is the point at which the owner’s policy becomes enforceable.
The previous distinction between stored protection and processing protection gives us the starting condition. An AI model and its input must eventually be usable by a processor. Confidential computing does not eliminate that requirement. It changes the execution context in which the requirement is met, and it gives a remote party a way to decide whether that context is acceptable before sending it a secret.
Isolation is a boundary, not a promise about the whole cloud
A trusted execution environment, or TEE, is a hardware-enforced region in which selected code and data can run with protection from privileged system software outside the region. In an ordinary virtual machine, the guest operating system is separated from other guests, but the hypervisor remains a powerful part of the platform. A confidential-computing design tries to prevent that privileged layer from directly reading or modifying the protected workload’s memory during normal operation.
For AI, the distinction is concrete. The model owner can keep the model encrypted before deployment. The input can arrive over an encrypted connection. Once both reach the workload, the model still needs to operate on readable values. A TEE is intended to make those readable values visible to the authorized code inside the protected region rather than to the host’s ordinary privileged software. This is why the mechanism addresses the processing gap identified earlier.
The boundary has two sides. On the inside are the code and data the design has placed under hardware enforcement: potentially the model, input, and runtime state needed for inference. On the outside are the operating system or hypervisor, cloud management functions, and any storage, API, network, or accelerator path that the particular implementation has not included. The exact boundary is therefore a property of a deployment, not a synonym for “the cloud workload.”
That distinction prevents a common overstatement. Saying that an AI workload runs confidentially does not, without further detail, prove that every byte associated with it is protected. It does not automatically cover a tool server, a vector store, a device path, or an output after it leaves the TEE. It says that a defined portion of the computation is designed to receive hardware-enforced protection. The security question then becomes: can the owner identify that portion, and can they check that the expected code is actually running there?
Attestation makes the boundary inspectable
Remote attestation is the answer to the second question. The protected environment produces evidence that a remote party can evaluate. In the NIST model, an attestation report includes measurements of the virtual machine’s initial state—such as firmware, bootloader, operating system, and application code—along with a platform identifier. The report is signed by an attestation key rooted in hardware and vouched for by the processor manufacturer.
A measurement is a cryptographic representation of a state or component. It is useful because a verifier can compare it with an expected value. If the code or configuration differs from what the owner approved, the resulting evidence should not satisfy the same policy. Attestation therefore does not ask a remote party to trust a visual claim in a dashboard. It supplies evidence that can be checked against conditions defined in advance.
The process has an important direction of trust. The workload is running in a machine that the user does not physically control. It sends evidence outward. A verifier checks the signature and measurements, then passes the result to a relying party—the owner or a service acting for the owner. The relying party decides what the result means for this secret and this workload. The cloud provider can supply the platform and its attestation capability, but the provider’s assertion is not the final authorization to read the model.
This separation is valuable because different questions belong to different actors. Hardware can enforce isolation. The attestation service can report evidence about the platform and measured state. The relying party can define which code versions, revocation conditions, or data-pipeline states are acceptable. A key-management service can honor the resulting decision. No single component needs to be treated as the owner of every part of the trust judgment.
The negative path is as important as the successful one. If the evidence cannot be authenticated, the measurements do not match, or the platform state fails the owner’s conditions, the process should stop before the key is released. A verifier’s positive result is not an instruction to expose the model automatically; it is an input to the relying party’s policy decision. Conversely, a policy decision to release a key does not enlarge the hardware boundary. It authorizes the measured workload to use a secret under the conditions that were checked. The workload’s other connections—such as a storage service, an API, or an accelerator—still need to be considered separately if they carry model data or intermediate state.
There is also a time dimension. The NIST description centers on measurements of an initial state, while the owner’s policy includes code versions and revocation conditions. That makes lifecycle management part of trust: an approved configuration can change, become obsolete, or be withdrawn. A deployment that never updates its expectations may reject legitimate maintenance; one that updates them without a disciplined policy may accept a state the owner did not intend. Attestation supplies evidence at a point in the workflow. It does not relieve the owner of deciding which evidence remains acceptable as the workload evolves.
The sequence shows why attestation is more than an audit report. It participates in the authorization path. A report that is never connected to a decision about secrets may describe a trustworthy environment without protecting anything valuable. The useful arrangement is “proof before plaintext”: evidence is checked before the model key or another sensitive secret is made available.
The owner’s policy is the missing half of attestation
An attestation report does not contain a universal answer to the question “is this workload safe?” It contains evidence. The relying party supplies the decision rule. They may require a particular measured application, a current platform security state, or an acceptable code version. They may also account for revocation and the integrity of the data pipeline. The important point is that the policy is tied to the secret being protected and to the computation that will use it.
Imagine two workloads with the same broad purpose. One runs the approved model and code on the expected platform state. The other has a different measurement because its application changed, its configuration was altered, or the platform no longer meets the owner’s condition. Both may answer a network request. Only the first should qualify for the key under a policy that names the approved state. If the evidence does not match, the safe outcome is not a warning followed by ordinary access; it is withholding the secret.
This is also why a relying party cannot simply evaluate the hardware label. A TEE-capable machine is a capability, not proof that the intended application is inside it or that the current configuration meets the owner’s requirements. Attestation connects the hardware-backed mechanism to a particular measured workload. Policy connects that evidence to an authorization decision.
The arrangement creates governance as well as cryptography. The owner must know what state they are willing to trust, how changes are approved, how an obsolete or revoked state is rejected, and which service is responsible for interpreting evidence. A measurement that is too broad may approve more code than intended. A measurement that is too narrow may prevent legitimate updates. The source describes these lifecycle choices as part of the relying party’s role; it does not reduce them to a single vendor setting.
The key must arrive protected too
Once policy permits access, the decryption key still needs to travel from its custodian to the workload. Sending it as ordinary plaintext through the surrounding infrastructure would reopen the very gap the TEE was meant to close. The reference workflow therefore wraps the key so that the intended workload can recover it inside the protected boundary.
In the NIST reference architecture, the workload creates an RSA key pair and makes its public key available as part of the attestation-held data. The private key remains with the workload service. The attestation service evaluates the evidence, and the Key Broker Service and Key Management System apply their respective release policies. If those checks succeed, the key-management side returns the model’s decryption key in a wrapped response. The workload uses its private key to recover the response and then uses the wrapped material to obtain the decryption key inside the protected environment.
The exact services and cryptographic arrangement belong to that prototype; they are not requirements that every confidential-computing deployment must copy. The general mechanism is what matters: the secret is bound to an attested requester, protected while it is delivered, and usable only after the workload has crossed the policy gate. The model can then be decrypted in the TEE rather than on an unprotected host path.
This gives the security claim a causal shape:
- A workload starts in a platform with a TEE capability.
- The platform and workload produce evidence about their measured state.
- A verifier checks the evidence, and the relying party interprets it through a release policy.
- A key service releases only a protected form of the model key when the policy allows it.
- The workload recovers the key inside the protected boundary and processes the model and input there.
The list is short, but each step has a failure meaning. Without isolation, privileged software may remain able to inspect the processing memory. Without usable attestation, the remote owner cannot reliably distinguish the approved state from an altered one. Without policy, evidence does not control access. Without protected delivery, the key can be exposed between its custodian and the workload. Without a complete boundary analysis, the model may be protected while a related memory, device, or I/O path is not.
What a successful attestation still cannot prove
The most important limit is semantic. Attestation can establish that measured code is running on a genuine platform in the reported configuration. It cannot establish that the code’s goals are benign, that the model was not poisoned before measurement, or that a document supplied as input contains no hostile instruction. If an approved agent reads a malicious document and follows it, hardware isolation may ensure that the infrastructure operator cannot read the agent’s memory. It does not ensure that the agent will make a wise decision.
The same distinction applies to an external service. A tool or peer may have an authenticated identity, yet return misleading information. A protected runtime may preserve the confidentiality of a prompt while still allowing the model to produce an unsafe output that is intentionally sent to an API. Identity evidence is not behavioral trust, and a valid signature is not a guarantee of truthfulness.
Confidential computing is therefore best understood as a way to narrow and verify one powerful threat boundary: access by privileged infrastructure software to the protected computation. It can also contribute to stronger execution and memory guarantees when the relevant code and state are inside the measured boundary. It is not, on its own, a general solution for prompt injection, model alignment, availability, or every path by which data leaves the workload.
The next step is to stop looking at the architecture as a static collection of components and follow it through time. A model is provisioned, attestation evidence is generated, a policy is evaluated, a key is released or denied, inference runs, outputs may cross the boundary, and sensitive state should be cleared. That lifecycle is where assumptions about patching, freshness, cleanup, and downstream handling become visible.