OPAQUE's Weight Custody Manifest lets the decryption key expire unless the runtime re-attests

Start with the renewal loop, since that is where enforcement lives. The weights stay encrypted on the buyer's machine while a separate key broker holds the decryption key ^[5]. A workload that asks for access gets a fresh, single-use challenge, and the protected runtime answers with CPU evidence plus, where required, GPU evidence, binding that challenge to the workload and to an ephemeral transport key ^[6]. The broker validates signatures, measurements, certificate chains and revocation status, then releases a key sealed for that workload ^[7].

That design makes the cadence the number to argue about in review. A builder or custodian can trigger emergency revocation, and the documented sovereign controls can require several parties to approve a shutdown or to reconstruct a split key, but enforcement happens at the next authorization cadence lapse ^[9]. Worst case, a revoked model keeps serving for one full authorization period ^[20]. Shorten the period and you buy faster revocation at the price of more broker round trips and a harder dependency on the broker being reachable. The launch material states no default period ^[23], which is the first thing I would want pinned down in a conformance profile.

OPAQUE draws the boundary itself. These are reference-protocol and software-implementation behaviours, not proof against an operator with physical control of the hardware ^[10]. In a sovereign deployment, that operator is the customer. So the property on offer is that a measured runtime refuses to decrypt outside the manifest, not that the owner of the box can never reach what is in memory. The verified public demo repository uses a software mock attestation provider and requires no attestation hardware ^[13], so the CPU and GPU evidence checks that carry the whole guarantee are the part that demo does not exercise ^[22]. Easy to run, for exactly that reason.

Attested release of secrets is not the new part. According to the same report, Edgeless Systems describes confidential AI deployments that keep model weights inaccessible to infrastructure operators ^[14], and Anjuna Seaglass releases secrets and configurations to attested containers across cloud and on-premises systems ^[15]. What WCM adds is policy content that travels: licensing, lineage, jurisdiction, renewal and revocation in one portable format across infrastructure providers ^[16]. Lineage is the underrated field, because the manifest records the relationship between a base model and its fine-tuned derivatives, and much of the commercial value sits in the tuning rather than the original checkpoint ^[17]. Against OpenSSF Model Signing the split is clean: a signature establishes which model this is, and the manifest governs whether it may decrypt and run in this environment ^[18].

Runtimewire's read is that WCM works as a technical contract between sovereign buyers and model developers only if OPAQUE wins model-lab adoption and proves the production hardware path ^[19], and its account names no lab that has adopted the spec ^[21]. That leaves a buyer one useful move today: put the manifest fields, the authorization cadence and the revocation quorum into the deal text, and treat the published schemas as a reference for what those fields will have to mean once the attestation is real hardware rather than a stub. A licence clause that says "custody per WCM 0.x" is a pointer to a document that says it is not ready to be pointed at ^[12].