From Boot to Prediction: The Key-Release Lifecycle
This chapter follows a confidential AI workload through time: an encrypted model is provisioned, the running environment presents evidence, policy either releases or withholds a key, inference uses plaintext inside the protected boundary, and the runtime is eventually cleared. The value of this lifecycle view is practical. It shows which party owns each decision, what state exists at each transition, and why a successful prediction is not the end of the security story.
A static diagram of a TEE can make protection look like a permanent property of a machine. The reference workflow described by NIST is more conditional. The workload has to reach an acceptable state, prove that state, receive a secret in a protected form, and then use the secret within the trusted environment. If any gate fails, the model should remain unusable to that workload. If the workload succeeds, new questions appear around outputs, stale state, and cleanup.
From an encrypted artifact to an attested workload
The lifecycle begins before the workload handles a user’s data. The model is prepared in encrypted form, and the materials needed to unlock it are placed under the control of the parties responsible for release. The NIST example uses a workload service, an attestation service, a Key Broker Service, and a Key Management System. Those names describe one reference implementation, not a universal product stack. The underlying responsibilities are more important than the labels.
The first responsibility is to create a protected execution location. A TEE-capable virtual machine is launched, and the workload is placed in it. At this stage, the model should still be an encrypted artifact. A machine can be capable of confidential execution without the particular workload being approved to receive its model key. The ability to create a protected VM is therefore a starting condition, not a successful authorization.
The second responsibility is to produce evidence about the running environment. The workload obtains a quote or attestation report from the TEE. The evidence describes the platform and measured state, including the code and configuration that the verifier is meant to evaluate. In the NIST example, the workload also creates an RSA key pair. Its private key remains with the service, while the public key is included in the data bound to the attestation request. That gives the later response a way to be protected for this requester rather than sent as ordinary plaintext.
The third responsibility is verification. A remote attestation service checks the evidence’s authenticity and evaluates the measurements against expected values. This is where an owner’s abstract requirement—“release the model only to the approved workload on an acceptable platform”—becomes a checkable condition. The attestation service can establish whether the evidence is valid and whether the measured state matches the configured expectations. It does not decide that every workload with a valid signature should receive every secret.
The fourth responsibility belongs to the relying party. The relying party interprets the verified evidence through a release policy. That policy may care about the application measurement, code version, platform security state, revocation status, or the integrity of the data pipeline. The policy is the owner’s statement of what counts as an acceptable recipient for this key. It is also the reason that attestation is an authorization input rather than a decorative certificate.
The denial transition is not a side case. If the evidence cannot be authenticated, the measurements do not match, or the policy rejects the platform or workload state, the key-release path should stop. The workload may still be running as a machine, but it has not become an authorized consumer of the protected model. This difference matters operationally: a failed check should produce an unavailable model, not a model that quietly falls back to an unprotected path without the owner’s approval.
In the successful transition, the key-management side performs another decision. The NIST reference architecture describes the Key Broker Service evaluating the attestation token and then contacting the Key Management System. The KMS applies its own key-release policy, independently of the broker’s policy. Only if those checks allow the request does the KMS return the decryption key to the broker. This separation lets the broker enforce conditions about the attested request while the key custodian retains its own authority over the secret.
The broker does not simply forward a bare key. It wraps the response for the workload using the public key supplied with the attestation-bound request. The architecture also describes a symmetric wrapping key inside the response and an asymmetric encapsulation option for protecting that response. The implementation details are specific to the reference example, but the lifecycle principle is general: the secret remains protected while moving through the surrounding infrastructure and becomes usable only after the intended workload recovers it inside the TEE.
At the end of this first phase, several different things exist at once. The encrypted model may be stored in a registry or deployment image. The key custodian retains the protected model key. The attestation evidence has supported a decision. The workload holds the private material needed to recover its response. None of this yet means that the model is plaintext in ordinary host memory. The transition to that state occurs only after the key has crossed the policy gate and been unwrapped inside the protected environment.
Execution, output, and return to a clean state
When the workload receives the wrapped response, it recovers the needed key inside the TEE and uses it to decrypt the model. The model can now process input data in the protected execution environment. In the demonstration flow, the workload requests an attestation token, requests the model decryption key from the broker using that token, decrypts the model, runs it against sample patient data, and returns a prediction. These actions are one connected chain: the prediction is meaningful as a confidential-computing result only because the key was withheld until the earlier conditions were met.
The transition from encrypted model to usable model changes the exposure profile. Before decryption, the model is a protected artifact whose bytes are not meant to reveal its parameters. During inference, the model and input become active runtime state. The TEE is intended to keep that state away from privileged infrastructure software under the platform’s stated operating assumptions. The protected boundary is doing its most important work at this moment, but it is also carrying the highest-value plaintext.
That state can include more than the original input. Inference creates intermediate values and runtime structures needed to produce the output. The supplied NIST reference focuses on the model and its sample input, not on a universal guarantee for every device buffer, accelerator, log, storage snapshot, or external service. A deployment therefore has to identify where the computation actually runs and what crosses the boundary. The lifecycle does not grant protection to a path merely because the first model-loading step occurred in a TEE.
The output transition is especially important. The reference workflow says the output may be encrypted before it leaves the TEE, depending on the desired level of protection. That is a deployment decision, not an automatic consequence of model confidentiality. If a prediction is returned to an authorized application over an appropriately protected path, the owner may accept a boundary at that point. If the result is written to an unprotected service, passed to a tool, or exposed through a broader application interface, the downstream system becomes part of the security analysis.
The difference can be expressed as two separate claims:
- Runtime claim: while the model and input are inside the measured TEE, the platform is designed to prevent privileged software outside the boundary from directly reading the protected processing state during normal operation.
- Downstream claim: after the output, an intermediate result, or a credential leaves the boundary, its protection depends on the channel, recipient, storage system, and application policy that handle it next.
The first claim is what confidential computing directly addresses. The second requires additional controls. Treating them as one claim hides the transition at which the original protection may stop.
The final state in the NIST demonstration is reset. After the sample model executes, the decrypted model is cleared from memory. That step is easy to understate because it happens after the visible result has been produced. Yet it determines whether plaintext model state remains available for a later memory inspection, accidental reuse, or an unintended process. Clearing the model does not prove that every related copy or output has disappeared from every system; it shows that the reference workload includes an explicit cleanup action for the decrypted model in its own runtime.
Reset also reveals a difference between confidentiality and continuity. A workload can clear its current plaintext model and still have a persistent conversation, a cached intermediate, an output record, or a stored state elsewhere. In a longer-lived service, the owner must decide which state is allowed to persist, which state must be protected again, and which state must be discarded. The survey of agentic AI makes this issue more severe because vector stores, conversation histories, and KV caches can outlive one inference request. The NIST prototype provides a concrete reset step; it does not settle the general lifecycle of every AI application.
Time also affects the meaning of an attestation decision. A report describes evidence available at a point in the workflow, while the relying party may care about current patch state, code versions, and revocation. The survey notes that TEE deployments can be exposed to rollback, replay, or stale state unless additional mechanisms preserve freshness and continuity. A previously approved workload may therefore be the wrong recipient for a new secret if the state being used is old or if the approval has been withdrawn. Confidentiality of memory does not automatically make the memory current.
This is why a key-release lifecycle needs more than a happy-path sequence. Consider three failure situations. First, a platform can start successfully but fail attestation; without the key, it cannot decrypt the protected model. Second, the attestation service can accept the evidence while a relying party or key manager rejects the request under a stricter policy; the workload remains unable to use the secret. Third, the model can run successfully while its output crosses into a system with weaker protections; the inference step may satisfy its runtime claim while the overall application does not satisfy the owner’s privacy goal.
Each situation assigns responsibility differently. The platform supplies the protected execution capability. The verifier evaluates evidence. The relying party defines acceptable state. The key service controls the secret. The workload owns the transitions from wrapped response to in-boundary decryption, inference, output handling, and reset. A secure design must make those ownership boundaries visible, because a failure in one phase should not be misread as a failure—or a guarantee—in another.
The lifecycle therefore ends with a conditional conclusion rather than a permanent label. A model can be encrypted at rest, become usable only after attestation and policy, run inside a protected boundary, produce a result, and have its decrypted copy cleared. That is a meaningful improvement over leaving plaintext memory under the ordinary control of the host. It is not proof that the entire data path, application state, or future request is protected. The next question is how this lifecycle operates inside a large shared environment, where access, storage, schedulers, monitoring, and performance constraints surround the enclave.