Attestation-Gated Key Release

Attestation on its own produces a document. The document is only a control if something refuses to act without it, and in practice that something is a key. The pattern is simple enough to state in a sentence: secrets are encrypted at rest, and the key manager releases the decryption key only to a party that presents a fresh attestation whose measurements satisfy a policy. Nothing valuable moves until the hardware has vouched for what will receive it.

This is what lets two parties with opposed interests share a computation. A model vendor encrypts weights under a key held in its own KMS and releases it only to an enclave running an inference server it has approved. A customer encrypts its data under a key held in its KMS and releases it to the same enclave measurement. Neither party has to trust the cloud operator, and neither has to trust the other's servers, because both are enforcing against the same measured image.

What the policy actually says

A usable appraisal policy is a conjunction, and every clause is load-bearing:

• the report is signed by an accepted root, and the certificate chain is valid and unrevoked;
• the nonce matches the one this request issued, so the report is fresh;
• the launch measurement is in the allow-list of images this key may be released to;
• firmware, microcode and TCB version numbers are at or above a floor, so known-broken platforms are excluded;
• the debug bit is off and the platform is not in a development configuration;
• for GPU workloads, the GPU evidence is present, verified, and bound to this CVM rather than merely valid on its own.

Dropping the TCB-version clause is the most common shortcut, and the most expensive. Without a floor, an attacker who can run your exact image on a platform with an unpatched security processor gets a valid token, and your key.

The lifecycle problem nobody plans for

Keys released into enclave memory do not stay released. A confidential VM that is migrated, snapshotted or restored is, from the platform's perspective, a new launch with a new report, which is the correct behaviour and a genuine operational burden: live migration of CVMs is constrained, and checkpoint-restore of an enclave holding a released key is not something you get for free. Serving stacks that lean on preemption, spot capacity or fast autoscaling have to re-attest and re-fetch keys on every cold start, which lands on time-to-first-token for the first request after a scale-out event.

Revocation is worse. Once a key has been released to an enclave, "revoking" it means rotating the key and re-encrypting the data, because there is no mechanism to reach inside a running enclave and take a secret back. The realistic design is short-lived keys with frequent re-attestation, so the blast radius of a compromised image is bounded by the lease period rather than by a revocation event.

Where the trust actually concentrates

The pattern's appeal is that it removes the operator from the trust set. It does not remove trust; it relocates it, and the new locations are worth naming.

You now trust the silicon vendor's signing hierarchy, for the reasons covered under remote attestation for AI workloads, and a root-key compromise forges tokens across the fleet (arXiv:2605.12990).

You trust the verifier, which is usually a vendor-operated cloud service. A verifier that is unavailable stops key release, which makes an attestation service a hard dependency in the serving path; a verifier that can be induced to approve bad evidence is a single point of failure for every relying party using it.

Most importantly, you trust whoever chose the measured image. The enclave sees plaintext. A model vendor that controls the allow-list can add an image that exfiltrates customer data and it will attest perfectly, because attestation certifies identity, not behaviour. This is exactly the hole that verifiable transparency exists to close: publishing every approved measurement to an append-only log so that adding a malicious image is at least detectable, and refusing to run against images absent from the log (see verifiable transparency and non-targetability).

When it breaks

Policy drift. Allow-lists maintained by hand accumulate stale measurements, and nobody removes an entry because removing one breaks a node. After a year the allow-list is a list of every image the vendor ever shipped, including the ones with known bugs.

Secrets fetched outside the gate. Workloads routinely need something before attestation completes: a container registry credential, a config service token. Anything the enclave holds at launch was placed there by the host, and is therefore known to the operator. Bootstrap credentials must be scoped to nothing that matters.

The gate protects the key, not the pipeline. Weights decrypted inside an enclave can still be extracted through the model's own interface. Attestation-gated release raises the cost of stealing weights from the filesystem; it does nothing about distillation through the API, which is a different control problem entirely.