Sovereign deployment
Run a closed model inside nationally controlled infrastructure while making weight release conditional on an approved, attested workload.
Release evidence captured against WCM commit 4af6836. Claims link to their supporting artifact.
The threat model flips when the model leaves your data center
Most deployment security is framed around protecting the customer from the model and its operator. Deploy a frontier model into a customer's own infrastructure, a sovereign cloud, or an air-gapped facility and an additional risk appears: the builder's weights now sit on hardware someone else owns and operates.
WCM answers one question: can a model builder release encrypted weights only to an approved workload, keep that approval short-lived, and retain evidence of what happened? The answer is yes for the reference protocol and the software checks, with one boundary stated plainly rather than buried, which you will find further down this page.
Change the evidence. The key stays closed.
A custody protocol is valuable when it refuses the wrong request. This is the reference path in three outcomes; the runnable demo below reproduces the same fail-closed decisions in software-only development mode.
01 approved workload + fresh attestation RELEASED · key sealed to workload
02 changed serving-image measurement DENIED · WCM-L2-0006
03 authorization window elapsed REFUSED · fresh release required
One custody contract, three deployment pressures
Enterprise and air-gapped
Deliver encrypted weights to customer-operated environments without turning a one-time handoff into permanent authorization.
Regulated model delivery
Carry signed policy, release decisions, renewal state, revocation, and derivative lineage as portable evidence.
Six steps, no plaintext key on the wire
1
The builder signs a manifest
Encrypted weights, plus a signed manifest naming the exact weight and approved-workload measurements.
2
The workload asks for a challenge
A protected workload requests a fresh, single-use challenge from the key broker.
3
Attestation binds the request
CPU attestation, and GPU attestation where required, binds that challenge, the workload measurement, and an ephemeral transport key to the current launch.
4
The broker checks independently
Manifest policy, certificate chain, signatures, revocation state, measurements, freshness, and channel binding. Every check, every time.
5
The key is sealed, not sent
Only if every required check passes, the broker seals the model key to the attested transport key. It never transmits plaintext key material.
6
Authorization expires
The runtime periodically renews. A lapse means stop serving and wipe the in-memory key. Resuming requires a new successful attestation and release.
The host carries ciphertext. Evidence decides release.
1BuilderEncrypted weights
Signed manifest
→
Signed manifest
2Attested workloadFresh challenge
Measured runtime
→
Measured runtime
3Key brokerVerify every gate
Deny on mismatch
→
Deny on mismatch
4Protected runtimeSealed key
Renew or stop
Renew or stop
The reference SDK is already installable
The specification is pre-1.0, but the Python reference implementation is published and you can exercise the protocol locally against synthetic evidence today. We would rather have your feedback while the design can still change than after it is frozen.
1
Install from PyPI
Terminal
python -m pip install weight-custody-manifest
2
Run the portable conformance suite
Language-neutral vectors across four conformance levels, exercising every reportable error code. The runner prints its own remaining limits on every run, so a pass is never read as more than it is.
Terminal
wcm conformance
3
Walk through the runnable demos
The public demos repository covers weight custody, closed-weight release, derivative lineage, and sovereign threshold release. No special hardware required; they run in software-only development mode.
Terminal
git clone https://github.com/agentrust-io/demos cd demos pip install -r requirements.txt python demo.py 6
Two guarantees, never blended
The dishonest version of this page would say the weights are physically impossible to extract. They are not, and the specification says so. WCM names two separate guarantees and does not let them run together.
| Against | What you get |
|---|---|
| Software and remote adversaries Host OS, remote attacker, an operator with software access | Cryptographic custody. One caveat: a malicious hypervisor can extract keys through ciphertext side channels unless AMD SEV-SNP ciphertext hiding is enabled, so that is required for the claim to hold against a hypervisor-privileged operator. |
| An operator who physically owns the hardware | Accountability grade, not cryptographic custody. Current confidential-computing silicon is defeated by cheap, published memory-bus attacks that extract keys and forge attestation. What WCM offers at this tier is cost, detection, containment, legal recourse, and a mandatory physical-hardening tier. |
Placed the way a frontier lab grades it: WCM implements the confidential-computing measure that RAND recommends in Securing AI Model Weights. It holds across the OC1 to OC3 attacker range and, by its own concession, not against an OC4 or OC5 actor who owns the hardware. It is not a security level. A security level is a whole-organization posture, and assigning one to a single control misuses the unit.
Verification paths have been exercised against real silicon across AMD SEV-SNP, Intel TDX, and NVIDIA H100 in confidential computing mode. Two areas are deliberately not claimed yet, because they need evidence from the real protected runtime rather than a more persuasive simulation: protected-boundary hardware evidence for the memory fingerprint sweep, and production zeroization from the actual controller rather than unit tests.
RAND weight-security report ↗TEE.fail research ↗BadRAM research ↗Full threat model ↗
Four ways into the release
Model owners
Evaluate a closed-weight deployment and pressure-test the release policy against your actual threat model.
Evaluate a deployment →Runtime and cloud teams
Add or review an attestation profile and prove what your protected boundary can support.
Follow the release →Security researchers
Challenge the threat model, fixtures, hardware assumptions, and explicit non-goals.
Review open questions →Standards contributors
Review the manifest, portable evidence, conformance levels, and interoperability boundaries.
Join the review →What is available now, and what is coming
The release candidate includes the full specification, threat model, limitations document, manifest JSON Schema, Python reference SDK, portable conformance vectors, and a reproducibly built reference key-release-service image. The SDK is available now; the repository becomes public with the release announcement.
The reference SDK is already on PyPI, and the demos and integration examples above are public today, so you can evaluate the protocol before the specification lands. This is deliberate: the design decisions we most want argued with are cheaper to change now.
Open protocol, implementation ecosystem. The specification, schema, conformance suite, reference SDK, threat model, and reference key-release service will be released under Apache-2.0. Vendors may build interoperable hosted services and protected-runtime implementations.