Technical report / Version 1
Owner-Approved Provisioning of a Model-Key Broker: Binding the broker's configuration, receiving key and policy epoch before the model key leaves the owner
OPAQUE Systems
Abstract
A model owner can require workload attestation before a key broker releases a decryption key, and still lose control if the deployment operator can change the broker itself: its trust roots, its list of accepted model manifests, or the owner key it trusts. This report describes provisioning in the other direction. The owner treats the broker as a recipient. Before sending the model key, the owner appraises a signed attestation report that commits to the broker's launch measurement, a digest of the configuration the broker actually constructed, a fresh receiving key, the model identity and the policy epoch. A separate deployment approval pins the build artifacts and launch parameters. The receiver installs one owner-authenticated envelope, serves workloads, and refuses every path after retirement. We evaluate the implementation in the Weight Custody Manifest library, released in weight-custody-manifest 0.28.4 and later. All 84 existing tests pass, and removing the configuration or measurement check makes 5 and 3 specific tests fail. A retired receiver in its own process refused all four API paths, and an old envelope would not install in a replacement. Across separate owner processes sharing one epoch store, a stale live owner, a restarted stale owner and a same-epoch substitution were all refused, and a killed policy admission left the floor unchanged. Every number was reproduced on October 1, 2026 at the evaluated revision and at current main.
What this report contributes
An owner-side provisioning protocol that appraises the broker as a recipient, binding its configuration, fresh receiving key, model identity and policy epoch before the model key leaves.
Evidence and limits
- Software-only, on one Windows host. Attestation reports are synthetic SNP-format reports from a generated certificate chain; no SEV-SNP hardware or real model key was used.
- Whether approved build inputs determine the receiver that actually runs needs a hardware launch experiment with an independently predicted measurement. It has not been run.
- The owner epoch store needs rollback-protected storage: restoring or deleting it let a stale owner provision again. Secure erasure of retired key material is not established.
The source package preserves the recorded inputs and results. Every experiment was rerun on October 1, 2026 in a fresh environment at the evaluated revision and at current main. No independent replication is claimed.
Read the current specification and implementation guidance. This report describes an earlier design and evaluation; the current specification governs implementation.
Cite this report
Imran Siddique. Owner-Approved Provisioning of a Model-Key Broker: Binding the broker's configuration, receiving key and policy epoch before the model key leaves the owner. AgenTrust technical report, version 1, 2026.
Download BibTeX / Download CITATION.cff
@techreport{agentrust2026modelkeybrokerprovisioning,
title = {Owner-Approved Provisioning of a Model-Key Broker: Binding the broker's configuration, receiving key and policy epoch before the model key leaves the owner},
author = {Imran Siddique},
institution = {AgenTrust},
year = {2026},
type = {Technical report},
note = {Version 1; not peer reviewed},
doi = {10.5281/zenodo.23091296},
url = {https://agentrust-io.com/research/model-key-broker-provisioning/v1/}
}
Version history
Version 1, October 1, 2026: First public edition. Evaluates Weight Custody Manifest db8f106; every count was reproduced on October 1, 2026 at that revision and at main 5ef8c12.
Based on an internal study drafted September 23, 2026 and rerun September 27, 2026.
File checksums. Published version files are retained; substantive revisions receive a new version.
Questions and corrections
Open an issue in the project repository and identify the report version and section.