An enterprise wants an agent to answer questions over sensitive internal records. It can keep the records on its own infrastructure, run inference locally, and give the agent access to approved tools. The model provider has a separate requirement: its confidential weights should be usable only by an approved serving application.
Both requirements are reasonable. The deployment question is how to let the customer operate the infrastructure while making access to the model conditional on a verifiable release policy.
That decision happens before the agent's first inference request. It also needs to survive software updates, expired authorization, and changes to the model itself.
In my earlier AAIF article, Verifiable Evidence at the MCP Boundary, the question was what another party could verify about a tool call. Model custody concerns a different boundary: which serving runtime receives access to the weights behind an agent's inference endpoint. These controls can coexist in an agent deployment. Neither replaces the other's job.
Put the release conditions beside the model
A model signature helps establish which artifact a publisher signed. A deployment also needs a decision about whether a particular runtime may unlock that artifact now. Keeping those decisions explicit gives builders and operators separate checks they can inspect.
Weight Custody Manifest (WCM) is one proposed approach, published as an open, pre-1.0 specification. Its manifest identifies the model weights and carries a policy signed by the builder and custodian. The policy includes approved serving-image measurements and required platform evidence. A measurement is a cryptographic identifier for the software state the verifier expects.
For the enterprise agent, this creates a concrete handoff. The model provider approves a serving stack. The custodian operates a key-release service. The serving runtime presents evidence that must satisfy the agreed policy before it receives access to the model key. The agent then calls that serving runtime for inference.
The policy travels with the model's identity, so a reviewer can inspect which artifact and software configuration the parties approved. WCM also defines an optional connection to OpenSSF Model Signing, binding artifact provenance to the weights named by the manifest.
Make the release belong to this runtime
The protected deployment uses a trusted execution environment, a hardware-supported boundary designed to isolate a workload from software outside it. Attestation is signed evidence about that environment and its measured software, checked against trusted platform keys.
The key broker issues a fresh, single-use challenge. The requesting runtime supplies attestation evidence bound to that challenge. Where the policy requires a GPU, the verification includes GPU evidence as well as the CPU-side evidence.
The broker checks the approved manifest, evidence, measurements, freshness, and applicable revocation state. The release also needs to reach the runtime that supplied the evidence. WCM's channel-binding mechanism ties an ephemeral transport public key to the attestation and seals the model key to it. Relaying somebody else's acceptable evidence should not give the relay a readable model key.
For implementers, this separates three responsibilities: deciding which manifests are trusted, verifying evidence against configured trust roots, and delivering the key to the admitted runtime. Each responsibility needs an explicit configuration and an observable failure path.
An approved measurement identifies an expected software state; it does not establish that the software is safe. The serving application must also be reviewed for paths that could export plaintext weights or keys. An attested application with an approved export function still has that function.
One changed measurement produces a different decision
The public closed-weight example is a small way to explore the policy decision. It creates a manifest, signs it with builder and custodian keys, verifies those signatures, and pins the resulting manifest identity at the broker.
The example first supplies the approved serving measurement. It then supplies a different measurement representing a modified serving stack. Both attempts obtain a fresh challenge. The second attempt should fail because the new measurement is absent from the manifest's accepted set.
In the local run for this article, using reference SDK version 0.28.2, joint-signature verification returned True. The approved request returned key released = True. The changed measurement returned key released = False, with the reason measurement not in accepted_measurements.
Figure: The manifest stays fixed while the reported serving measurement changes. This is a software policy check using synthetic evidence and a placeholder key; it neither loads model weights nor runs a hardware enclave.
The example uses a software provider that constructs synthetic evidence. It establishes the reference gate's response to the two inputs. It does not demonstrate hardware confidentiality or the sealed-key transport described above. The broker's pinned manifest matters here: a caller-supplied policy cannot establish its own authority simply by carrying valid signatures.
The accompanying conformance run passed 91 vectors across manifest signatures, release gating, runtime custody, and derivative lineage. This is a reference self-test, not independent certification. Its CPU quote vectors use synthetic certificate roots, and its portable vectors do not cover GPU cryptographic verification.
Keep authorization current
The initial release is only the beginning of custody. WCM specifies renewable authorization: the protected runtime must renew within the configured cadence, and a lapse requires it to stop serving and wipe its held key. Deployment teams need to connect those mechanisms to the serving loop and a suitable time source. A Python state transition alone cannot establish production memory zeroization.
This affects ordinary operations. A serving-image update changes what must be approved. A revoked measurement should be refused. A failed renewal needs a defined service response. Revocation can prevent later authorized use within the enforced custody boundary; it cannot retract a copy already extracted from that boundary.
Fine-tuning adds another decision. WCM's derivative lineage links a new manifest to its parent. The lineage checks can reject missing parents, forbidden derivatives, expanded permissions, or a revoked ancestor. That provides a reviewable path from an approved base model to a deployed derivative. Freeform legal terms still require interpretation; putting them in a signed document does not make every term executable.
An open format needs independent implementations
WCM's public repository contains the specification, schema, reference SDK, conformance vectors, and reference key-release service under Apache-2.0. An operated custody service and its protected-runtime implementation are separate. Reading or implementing the protocol does not require adopting one vendor's hosted service.
That separation permits independent implementation; it does not establish interoperability by itself. Common fixtures can expose disagreements about signatures, stale evidence, or derivative rights. Agreement across independently built implementations would provide stronger evidence than one implementation passing its own suite. How such a format should evolve and be governed remains a community question, not a conclusion established by this article.
WCM remains a design under review, and its public documentation says not to rely on it for production. A protected deployment depends on real quote verification, trusted keys, channel binding, workload isolation, renewal enforcement, and the platform's security assumptions. Against a hostile party with physical control of the hardware, WCM does not claim cryptographic custody; the specification instead documents physical hardening and accountability controls. Custody evidence also says nothing by itself about whether an agent's answer is correct or its next tool call is authorized.
For agent-platform teams, the practical distinction is between permission to call an inference endpoint and permission for its runtime to unlock a particular model. Keeping both decisions explicit gives the model provider and deploying organization a shared record of what was approved, the conditions for continued access, and the evidence supporting each release.
OPAQUE contributes to WCM; its operated custody service and protected-runtime implementation are separate from the open specification. The specification, reference SDK, threat model, and portable test vectors are available in the public repository.
Share
Author
Imran Siddique
