What “Protected While Running” Really Means

The title’s claim can now be answered precisely. Encryption at rest protects stored bytes, and encryption in transit protects moving bytes. Neither one, by itself, determines who can see the model, input, keys, and intermediate state while an AI workload is using them. Confidential computing can protect that active computation from a privileged infrastructure operator when the relevant code and state are inside a hardware-enforced, attested boundary and the decryption key is released only under an acceptable policy. That is a meaningful security property, but it is not an end-to-end description of every AI system.

The practical judgment for this series is therefore conditional: identify the asset, the adversary, the measured boundary, the key-release decision, the paths that leave it, the state that persists, the operational cost, and the evidence still missing. If those elements are not named, “confidential AI” can mean anything from a protected model key to a much broader claim that the supplied evidence does not support.

The exact answer to the processing question

The first distinction is temporal. A model may be encrypted in a registry and a request may travel through an encrypted connection. During inference, however, a processor must use readable values. The model and input become runtime state. Confidential computing does not remove that plaintext step; it is designed to move it into a TEE where hardware restricts privileged software outside the boundary from directly inspecting the protected memory during normal operation.

That protection is strongest against the malicious infrastructure operator described in the supplied survey: the party with hypervisor, cloud-management, scheduling, or physical-platform control. It is relevant to a co-tenant, but not a guarantee against all timing, cache, bus, page-fault, speculative-execution, GPU residual-state, or traffic-analysis leakage. It is not a defense against a malicious document that changes an agent’s plan, a poisoned model measured as an approved artifact, a service that returns misleading information, a denial-of-service decision, or misuse after data leaves the boundary.

This adversary-specific answer is more useful than saying that confidential computing “secures AI.” It tells the owner what the mechanism is for. If the concern is a stolen database, encryption at rest may be sufficient for that concern. If the concern is a network observer, transport protection matters. If the concern is a cloud operator reading model memory or user inputs during inference, a TEE and protected key release address a gap that the other controls do not reach. If the concern is an agent being manipulated by retrieved content, hardware isolation is complementary rather than decisive.

The second distinction is evidentiary. A TEE is not trusted because the word appears in a product description. The NIST reference workflow connects four roles: a TEE-capable execution location, remote attestation, a relying party that interprets evidence through policy, and a key-release process. The workload produces evidence about its platform and measured state. A verifier checks the evidence. The relying party decides whether the state qualifies for this secret. A key service releases protected key material only when the applicable conditions are satisfied. The workload then recovers and uses the key inside the protected environment.

The key-release step is what makes the boundary consequential. A report that is not connected to a secret or an authorization decision can document a platform without preventing access. A policy that releases a key without checking the relevant evidence turns attestation into decoration. A key sent as ordinary plaintext through the host path can reopen the processing gap. The protection claim therefore depends on the chain holding together: isolation, evidence, policy, protected delivery, in-boundary decryption, and controlled execution.

The NIST implementation is a reference prototype, not a universal architecture.