Sovereign deployment
Run a closed model inside nationally controlled infrastructure while making weight release conditional on an approved, attested workload.
- 0.27.0Python SDK
- 91Conformance vectors
- 2Demo outcomes: allow / deny
- ScopeHardware evidence and limits
-
- Checked with the published 0.27.0 package: 32 L1, 37 L2, 12 L3, and 10 L4 vectors pass. This is the reference implementation's self-test, not independent certification or a hardware deployment test. The runner prints its uncovered cases.
-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.
-The closed-weight example supplies an approved serving measurement, then changes it. These are selected output lines from the software demo below. It uses mock evidence and a placeholder key; it does not load a real model or demonstrate hardware isolation, sealed transport, or expiry.
-
-
-
-
-
- manifest signature : True
- approved enclave : key released = True
- unapproved enclave : key released = False
- why : measurement not in accepted_measurements
- One custody contract, three deployment pressures
-
- 01
- 02
- 03
-
-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 in a protected deployment
-
-
-
-
-
-
- 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
-The broker must authenticate the manifest and verify the required certificate chains, signatures, revocation state, measurements, freshness, and channel binding. A structural check of mock evidence does not establish hardware provenance.
-
-
-
- 5
-
-
- The broker seals the key to the workload
-With channel binding configured, a successful release seals the model key to the attested transport key. The receiving workload opens it inside its protected boundary. The local example does not configure this transport path.
-
-
-
- 6
-
-
- Authorization expires
-The runtime must enforce renewal deadlines and stop serving on lapse. Wiping the managed key buffer cannot erase plaintext or key copies that escaped that buffer. Production enforcement requires a trusted time source and control of the serving runtime.
-Separate artifact delivery from key release
-Artifact path: the builder distributes encrypted weights and a signed manifest to the workload. The key broker holds or controls the decryption key separately.
-
-
- RequestWorkloadGet broker challenge
Bind evidence to challenge and transport key
- →
- Bind evidence to challenge and transport key
DecisionKey brokerCheck trusted manifest and evidence
Deny on mismatch
- →
- Deny on mismatch
ResponseSame workloadOpen key sealed to its transport key
Renew authorization or stop
- Renew authorization or stop
This is the intended hardware deployment path. The workload's protected boundary, quote verification, channel binding, trusted time, and stop/wipe behavior must be configured and validated. The local demo runs broker and workload logic in one ordinary Python process.
-The reference SDK is already installable
-Use Python 3.11+ and Git. This example needs no cloud account, GPU, model download, or API key. Keep WCM in its own environment because other AgenTrust packages may require a different cryptography version.
- -
-
-
-
-
-
-
-
- 1
-
-
- Install from PyPI
-
-
- Terminal
-python -m venv .venv-wcm-
Activate it with source .venv-wcm/bin/activate in Bash, or .venv-wcm\Scripts\Activate.ps1 in PowerShell. Then install the version used here:
-
- Terminal
-python -m pip install "weight-custody-manifest==0.27.0"-
-
-
- 2
-
-
- Run the portable conformance suite
-Expected: L1 32/32, L2 37/37, L3 12/12, and L4 10/10 PASS. CPU quote vectors use synthetic certificate roots; GPU cryptographic verification is not covered by these vectors. Read the printed NOT COVERED lines.
-
-
- Terminal
-wcm conformance-
-
-
- 3
-
-
- Run the closed-weight allow/deny example
-Run the script directly using the active WCM environment. It needs only the WCM SDK installed above.
-
-
- Terminal
-git clone https://github.com/agentrust-io/demos -cd demos -python demo-07-closed-weight/run.py-
Expected: joint signature True, approved release True, then unapproved release False because the measurement is not accepted. Both cases use synthetic attestation; labels such as "enclave" in the output do not mean hardware was used.
Next, run python demo-06-weight-custody/run.py for checkpoint integrity, python demo-08-derivative-lineage/run.py for lineage, or python demo-09-sovereign-threshold/run.py for quorum reconstruction.
What the demo proves, and what deployment requires
-The local run demonstrates signature verification and release-policy decisions with mock evidence. Protecting real model weights requires a separately validated hardware deployment.
- -| Against | What you get |
|---|---|
| Local software demo | Checks the reference protocol in an ordinary process. The operator can inspect its memory. Mock attestation provides no hardware-rooted confidentiality. |
| Protected runtime | Requires verified platform evidence, trusted keys, channel binding, workload isolation, and enforced renewal. Platform configuration, firmware, side channels, and the serving application's export paths affect the result. |
| Physical hardware owner | Do not assume weight extraction is impossible. Published physical attacks motivate additional hardening and operator assumptions. A valid signature alone cannot distinguish an authorized key from an extracted one. |
Assess the complete deployment. The RAND weight-security report provides threat-model context; it is not a certification of WCM. Passing the reference suite does not assign a deployment an attacker-resistance tier.
The published SDK includes hardware-specific verification paths and recorded-fixture tests. The portable conformance run above uses synthetic CPU quote evidence and excludes GPU cryptographic verification. Neither it nor the demo validates your hardware, protected-memory sweep, or production zeroization. Review the package's hardware notes and validate those properties on the target runtime.
-RAND weight-security report ↗TEE.fail research ↗BadRAM research ↗Guarantee scope and limits ↓
-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.
Contribute a profile →Security researchers
Challenge the threat model, fixtures, hardware assumptions, and explicit non-goals.
Challenge the threat model →Standards contributors
Review the manifest, portable evidence, conformance levels, and interoperability boundaries.
Join the review →Public source and documentation
-Available publicly: the Python SDK on PyPI, its bundled conformance vectors, the demos repository, and integration examples. The instructions above use SDK 0.27.0; later releases may change the API or expected results.
-Public since September 8, 2026: the specification repository includes the source, schemas, conformance suite, threat model and contribution guide. Browse the documentation. WCM remains pre-1.0; public availability does not establish production readiness.
-Open protocol, implementation ecosystem. The specification, schema, conformance suite, reference SDK, threat model, and reference key-release service are available under Apache-2.0. Vendors may build interoperable hosted services and protected-runtime implementations.
Weight Custody Manifest
+WCM now lives at wcm.agentrust-io.com, with the specification, SDK, conformance suite and threat model in agentrust-io/weight-custody-manifest.
+If your browser did not move you automatically, open the documentation.
+