From Evidence to Decryption: How Key Release Enforces Trust

In confidential AI, the key-release path is where a trust claim becomes an access control. This discussion focuses on how a relying party and key-management system decide whether an attested workload may obtain the material needed to use an encrypted model, and how that material moves through the workload without becoming an unrestricted cloud secret. Following the key from provisioning to cleanup gives the reader a concrete way to distinguish platform verification, authorization, protected computation, and operational responsibility.

The question is easy to state: if a model is encrypted before it reaches the cloud, who is allowed to decrypt it? A useful answer cannot be “the VM,” because a VM is a setting rather than an authorization. It must identify the workload, the evidence that describes its state, the policy that makes the state acceptable, and the key custodian that enforces the result. The NIST reference architecture shows one such arrangement, while also making clear that its named services and cryptographic choices are a prototype-specific example.

Authorization must reach the key

A verifier can determine that an attestation report is authentic and that its measurements match expected values. That appraisal still does not answer whether the requesting workload should receive a particular model key. The relying party supplies that judgment. It may be the application owner or an external service acting for the owner, and it can set requirements for the measured application code, approved versions, revocation status, and integrity of the data pipeline.

This division of labor is important because the same platform can host many workloads with different owners and different secrets. A platform state might be acceptable for a low-sensitivity service but not for a model containing proprietary parameters. A code measurement might identify the approved inference service but say nothing about whether the requester is entitled to a different model. The relying party connects the evidence to the asset and the action: this measured workload may receive this key under these conditions.

The NIST example uses a Key Broker Service, or KBS, to evaluate a key-release policy against the attestation token. The token carries values derived from the workload’s attestation evidence. If the comparisons succeed, the KBS contacts a key management system, or KMS. The KMS applies an independent policy before returning the requested key or secret to the KBS. The two decisions are therefore layered. The KBS checks whether the attested request meets its release rule; the KMS checks whether the key itself may be released through its custody policy.

This layering creates a meaningful separation between evidence and possession. A verifier can say, in effect, “the report is authentic and describes an acceptable state.” The relying-party path can say, “that state qualifies for this request.” The KMS can still say, “the key will be returned only under my policy.” If any condition fails, the encrypted model remains unavailable to the workload. Key release is not a reward attached to a successful VM launch; it is the enforcement point where several conditions have to agree.

The response also has to be bound to the workload that presented the evidence. In the NIST flow, the workload service creates an RSA key pair and keeps the private key. It places the public key in the attestation-held data, allowing the KBS to protect the response for that service. The KBS creates an AES symmetric wrapping key to encrypt the KMS-supplied decryption key in the response body. NIST also describes an asymmetric encapsulation option that uses the attester’s public key to protect the response, including the symmetric wrapping key.