Technical report / Version 1
+Technical report / Version 2
OPAQUE Systems
-Agent Manifest proposes a signed record of the artifacts that define an AI agent, including its system prompt, model, policy, tools, retrieval corpus, memory, decision trace, delegation, supply chain, and human approvals. Artifact digests and canonical serialization make changes to the recorded baseline detectable when a verifier has the relevant artifacts and trusted keys. The design composes SPIFFE identities, RFC 8785 canonicalization, Ed25519 signatures, an optional ML-DSA-65 profile, and hardware-attestation bindings. This technical report describes the original model and preserves the recorded Ed25519 software benchmarks, delegation checks, and tamper probes. Signed metadata alone does not prove that the recorded configuration was used during execution. The evaluation does not measure post-quantum performance or establish live hardware provenance; continuous verification of mutable memory and retrieval state is outside its scope. Current SDK behavior and normative requirements are maintained separately.
A signed baseline for agent artifacts, with recorded Ed25519 benchmarks, delegation checks, and tamper probes.
The source package preserves the recorded inputs and results. No new experiment run or independent replication is claimed for this edition.
+The source package preserves the recorded inputs and results. The benchmark was rerun at the inferred revision on October 1, 2026 with the SDK clock frozen at the original run time. 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.
Imran Siddique. Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents. AgenTrust technical report, version 1, 2026.
-Download BibTeX / Download CITATION.cff
@techreport{agentrust2026agentmanifest,
+Cite this report
Imran Siddique. Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents. AgenTrust technical report, version 2, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026agentmanifest,
title = {Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents},
author = {Imran Siddique},
institution = {AgenTrust},
year = {2026},
type = {Technical report},
- note = {Version 1; not peer reviewed},
- doi = {10.5281/zenodo.23001698},
- url = {https://agentrust-io.com/research/agent-manifest/v1/}
+ note = {Version 2; not peer reviewed},
+ url = {https://agentrust-io.com/research/agent-manifest/v2/}
}
Version history
Version 1, September 27, 2026: Separates signed-baseline checks from proof of runtime use, states evaluation limits, and adds the publication scope and patent notice.
+Version history
Version 2, October 1, 2026: Corrects the signature pre-image description, the tamper-probe field list, the per-hop delegation figure and the conformance test count, records that the evaluated verifier did not authenticate human approvals, and adds an October 2026 rerun. Results unchanged.
+Version 1, September 27, 2026: Separates signed-baseline checks from proof of runtime use, states evaluation limits, and adds the publication scope and patent notice.
Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
-File checksums. Published version files are retained; substantive revisions receive a new version.
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.
Version 1, September 27, 2026: Separates signed-baseline checks from proof of runtime use, states evaluation limits, and adds the publication scope and patent notice.
+Version 2, October 1, 2026: Corrects the signature pre-image description, the tamper-probe field list, the per-hop delegation figure and the conformance test count, records that the evaluated verifier did not authenticate human approvals, and adds an October 2026 rerun. Results unchanged.
+Version 1, September 27, 2026: Separates signed-baseline checks from proof of runtime use, states evaluation limits, and adds the publication scope and patent notice.
Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 2
+OPAQUE Systems
+Agent Manifest proposes a signed record of the artifacts that define an AI agent, including its system prompt, model, policy, tools, retrieval corpus, memory, decision trace, delegation, supply chain, and human approvals. Artifact digests and canonical serialization make changes to the recorded baseline detectable when a verifier has the relevant artifacts and trusted keys. The design composes SPIFFE identities, RFC 8785 canonicalization, Ed25519 signatures, an optional ML-DSA-65 profile, and hardware-attestation bindings. This technical report describes the original model and preserves the recorded Ed25519 software benchmarks, delegation checks, and tamper probes. Signed metadata alone does not prove that the recorded configuration was used during execution. The evaluation does not measure post-quantum performance or establish live hardware provenance; continuous verification of mutable memory and retrieval state is outside its scope. Current SDK behavior and normative requirements are maintained separately.
A signed baseline for agent artifacts, with recorded Ed25519 benchmarks, delegation checks, and tamper probes.
The source package preserves the recorded inputs and results. The benchmark was rerun at the inferred revision on October 1, 2026 with the SDK clock frozen at the original run time. 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.
Imran Siddique. Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents. AgenTrust technical report, version 2, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026agentmanifest,
+ title = {Agent Manifest: Portable, Hardware-Attestable Identity and Provenance for AI Agents},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 2; not peer reviewed},
+ url = {https://agentrust-io.com/research/agent-manifest/v2/}
+}
+Version 2, October 1, 2026: Corrects the signature pre-image description, the tamper-probe field list, the per-hop delegation figure and the conformance test count, records that the evaluated verifier did not authenticate human approvals, and adds an October 2026 rerun. Results unchanged.
+Version 1, September 27, 2026: Separates signed-baseline checks from proof of runtime use, states evaluation limits, and adds the publication scope and patent notice.
+Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+Technical report / Version 2
OPAQUE Systems
-Agent observability conventions describe model, tool, and agent operations, but governance facts are commonly fragmented across policy engines, approval stores, cost modules, and audit systems. Copying those facts into ordinary traces creates two hazards: sensitive payload capture and the false inference that sampled operational telemetry is complete audit evidence. This technical report describes AgenTrust Telemetry, a backend-neutral contract for six governance event families: policy decisions, approval lifecycles, usage, classified data flows, action execution, and evidence lifecycle. The contract correlates with W3C Trace Context and OpenTelemetry without installing a provider, exporter, or competing tracing model. A metadata-only profile rejects prompts, outputs, source code, tool arguments and results, credentials, and authorization tokens by key. Durable run and action identifiers survive process and asynchronous handoffs; propagated metadata remains untrusted and does not confer identity or authority. An optional accumulator accepts events before lossy export and can be finalized into a separately verifiable TRACE record. Its completeness status is a producer assertion that the accumulator records but does not measure. The evaluated release, 0.1.0-alpha.2, ships Python and TypeScript reference SDKs over shared schemas and a portable conformance set of six valid and seven invalid fixtures. At that commit 111 Python unit tests pass and all 13 fixtures produce their expected verdicts, on September 3, 2026 and again when rerun for this edition. A defect found after the evaluation let an edited evidence snapshot be signed; it is reported beside the results it qualifies. The contribution is not another agent tracing convention; it is a narrow semantic boundary between operational observation and governance evidence whose completeness must be stated rather than inferred.
A backend-neutral contract for six governance event families that keeps lossy operational telemetry separate from evidence whose completeness is stated.
The source package preserves the recorded inputs and results. The Python results were rerun at the evaluated commit for this edition; the TypeScript suite was not rerun. 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.
Imran Siddique. From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract. AgenTrust technical report, version 1, 2026.
-Download BibTeX / Download CITATION.cff
@techreport{agentrust2026agentrusttelemetry,
+Cite this report
Imran Siddique. From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract. AgenTrust technical report, version 2, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026agentrusttelemetry,
title = {From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract},
author = {Imran Siddique},
institution = {AgenTrust},
year = {2026},
type = {Technical report},
- note = {Version 1; not peer reviewed},
- doi = {10.5281/zenodo.23022882},
- url = {https://agentrust-io.com/research/agentrust-telemetry/v1/}
+ note = {Version 2; not peer reviewed},
+ url = {https://agentrust-io.com/research/agentrust-telemetry/v2/}
}
Version history
Version 1, September 27, 2026: Aligns claims with the evaluated code, positions the contract against prior governance telemetry work, and adds a post-evaluation findings section.
+Version history
Version 2, October 1, 2026: Corrects the statement that approval digests prevent an approval from being attached to another action, which the reference finalizer does not check, and restores the bold type that the version 1 build dropped. Results unchanged.
+Version 1, September 27, 2026: Aligns claims with the evaluated code, positions the contract against prior governance telemetry work, and adds a post-evaluation findings section.
Revises a manuscript dated September 3, 2026.
-File checksums. Published version files are retained; substantive revisions receive a new version.
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.
Version 1, September 27, 2026: Aligns claims with the evaluated code, positions the contract against prior governance telemetry work, and adds a post-evaluation findings section.
+Version 2, October 1, 2026: Corrects the statement that approval digests prevent an approval from being attached to another action, which the reference finalizer does not check, and restores the bold type that the version 1 build dropped. Results unchanged.
+Version 1, September 27, 2026: Aligns claims with the evaluated code, positions the contract against prior governance telemetry work, and adds a post-evaluation findings section.
Revises a manuscript dated September 3, 2026.
File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 2
+OPAQUE Systems
+Agent observability conventions describe model, tool, and agent operations, but governance facts are commonly fragmented across policy engines, approval stores, cost modules, and audit systems. Copying those facts into ordinary traces creates two hazards: sensitive payload capture and the false inference that sampled operational telemetry is complete audit evidence. This technical report describes AgenTrust Telemetry, a backend-neutral contract for six governance event families: policy decisions, approval lifecycles, usage, classified data flows, action execution, and evidence lifecycle. The contract correlates with W3C Trace Context and OpenTelemetry without installing a provider, exporter, or competing tracing model. A metadata-only profile rejects prompts, outputs, source code, tool arguments and results, credentials, and authorization tokens by key. Durable run and action identifiers survive process and asynchronous handoffs; propagated metadata remains untrusted and does not confer identity or authority. An optional accumulator accepts events before lossy export and can be finalized into a separately verifiable TRACE record. Its completeness status is a producer assertion that the accumulator records but does not measure. The evaluated release, 0.1.0-alpha.2, ships Python and TypeScript reference SDKs over shared schemas and a portable conformance set of six valid and seven invalid fixtures. At that commit 111 Python unit tests pass and all 13 fixtures produce their expected verdicts, on September 3, 2026 and again when rerun for this edition. A defect found after the evaluation let an edited evidence snapshot be signed; it is reported beside the results it qualifies. The contribution is not another agent tracing convention; it is a narrow semantic boundary between operational observation and governance evidence whose completeness must be stated rather than inferred.
A backend-neutral contract for six governance event families that keeps lossy operational telemetry separate from evidence whose completeness is stated.
The source package preserves the recorded inputs and results. The Python results were rerun at the evaluated commit for this edition; the TypeScript suite was not rerun. 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.
Imran Siddique. From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract. AgenTrust technical report, version 2, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026agentrusttelemetry,
+ title = {From Agent Observability to Governance Evidence: A Privacy-Constrained Telemetry Contract},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 2; not peer reviewed},
+ url = {https://agentrust-io.com/research/agentrust-telemetry/v2/}
+}
+Version 2, October 1, 2026: Corrects the statement that approval digests prevent an approval from being attached to another action, which the reference finalizer does not check, and restores the bold type that the version 1 build dropped. Results unchanged.
+Version 1, September 27, 2026: Aligns claims with the evaluated code, positions the contract against prior governance telemetry work, and adds a post-evaluation findings section.
+Revises a manuscript dated September 3, 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 2
+Technical report / Version 3
OPAQUE Systems
The Agent2Agent (A2A) protocol moves tasks between agents, and its Signed Agent Card lets a client check that a domain owner issued a card. The card does not bound the authority a delegating agent passes on, establish what code a peer runs, keep a task payload from the peer's host, or leave an offline record of who delegated what to whom. This technical report describes cA2A (Confidential A2A), a trust profile layered on A2A rather than a new transport. It composes four mechanisms: signed delegation credentials whose scope can only narrow at each hop, appraisal of a peer's attestation evidence before a task is sent, a payload sealed to the channel key that evidence vouches for, and a signed per-hop provenance record linked to its parent. Attenuated delegation and provenance binding are covered by prior capability-token work and IETF drafts; the contribution here is their composition on A2A with an open implementation. We state six properties and report software experiments rerun against ca2a 0.3.1: attenuation checks over 5,400 generated chains, rejection of in-chain replay and cross-chain splicing, intersection of delegated scope with local policy, sealed-payload behavior at the cryptographic layer, structural checks on linked provenance records, and a cross-operator attestation protocol exercised with synthetic evidence. Chain verification cost about 0.22 ms per hop in this environment. These results do not show that a peer's key is confined to attested code or that attestation works across independent operators. Recorded hardware runs cover one-directional appraisal of an Intel TDX peer by an AMD SEV-SNP peer in another cloud and a same-operator mutual SEV-SNP diagnostic; mutual attestation between independent operators has not been demonstrated.
A trust profile on A2A composing narrowing delegation credentials, peer attestation appraisal, sealed payloads and linked per-hop provenance records.
The source package preserves the recorded inputs and results. The software experiments were rerun against ca2a 0.3.1 for this edition; no hardware run was repeated. No independent replication is claimed.
+The source package preserves the recorded inputs and results. The software experiments were rerun against ca2a 0.3.1 on September 27 and again on October 1, 2026; no hardware run was repeated. 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.
Rishabh Poddar; Aaron Fulkerson; Imran Siddique. cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A. AgenTrust technical report, version 2, 2026.
-Download BibTeX / Download CITATION.cff
@techreport{agentrust2026ca2a,
+Cite this report
Rishabh Poddar; Aaron Fulkerson; Imran Siddique. cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A. AgenTrust technical report, version 3, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026ca2a,
title = {cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A},
author = {Rishabh Poddar and Aaron Fulkerson and Imran Siddique},
institution = {AgenTrust},
year = {2026},
type = {Technical report},
- note = {Version 2; not peer reviewed},
- doi = {10.5281/zenodo.23086110},
- url = {https://agentrust-io.com/research/ca2a/v2/}
+ note = {Version 3; not peer reviewed},
+ url = {https://agentrust-io.com/research/ca2a/v3/}
}
Version history
Version 2, October 1, 2026: Corrects the claim that the chain checks close cross-workflow splicing: a credential carries no task or execution field, so a delegate can reuse a valid chain across tasks. Scopes the confused-deputy claim to a single chain and cites history-based access control, provenance-based access control and PIC. Results unchanged.
+Version history
Version 3, October 1, 2026: Adds the caller-attestation relay that ca2a 0.4.0 fixed (GHSA-xxj2-p57x-x954), which affects the evaluated release, corrects four statements, including that a transparency log does not make omission detectable, and restores bold and italic type. Results unchanged.
+Version 2, October 1, 2026: Corrects the claim that the chain checks close cross-workflow splicing: a credential carries no task or execution field, so a delegate can reuse a valid chain across tasks. Scopes the confused-deputy claim to a single chain and cites history-based access control, provenance-based access control and PIC. Results unchanged.
Version 1, September 27, 2026: Narrows claims to what the code validates, reruns the experiments on ca2a 0.3.1, corrects three citations, and adds a post-evaluation findings section.
Revises a draft dated July 2026.
-File checksums. Published version files are retained; substantive revisions receive a new version.
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.
Version 2, October 1, 2026: Corrects the claim that the chain checks close cross-workflow splicing: a credential carries no task or execution field, so a delegate can reuse a valid chain across tasks. Scopes the confused-deputy claim to a single chain and cites history-based access control, provenance-based access control and PIC. Results unchanged.
+Version 3, October 1, 2026: Adds the caller-attestation relay that ca2a 0.4.0 fixed (GHSA-xxj2-p57x-x954), which affects the evaluated release, corrects four statements, including that a transparency log does not make omission detectable, and restores bold and italic type. Results unchanged.
+Version 2, October 1, 2026: Corrects the claim that the chain checks close cross-workflow splicing: a credential carries no task or execution field, so a delegate can reuse a valid chain across tasks. Scopes the confused-deputy claim to a single chain and cites history-based access control, provenance-based access control and PIC. Results unchanged.
Version 1, September 27, 2026: Narrows claims to what the code validates, reruns the experiments on ca2a 0.3.1, corrects three citations, and adds a post-evaluation findings section.
Revises a draft dated July 2026.
File checksums. Published version files are retained; substantive revisions receive a new version.
Version 2, October 1, 2026: Corrects the claim that the chain checks close cross-workflow splicing: a credential carries no task or execution field, so a delegate can reuse a valid chain across tasks. Scopes the confused-deputy claim to a single chain and cites history-based access control, provenance-based access control and PIC. Results unchanged.
+Version 3, October 1, 2026: Adds the caller-attestation relay that ca2a 0.4.0 fixed (GHSA-xxj2-p57x-x954), which affects the evaluated release, corrects four statements, including that a transparency log does not make omission detectable, and restores bold and italic type. Results unchanged.
+Version 2, October 1, 2026: Corrects the claim that the chain checks close cross-workflow splicing: a credential carries no task or execution field, so a delegate can reuse a valid chain across tasks. Scopes the confused-deputy claim to a single chain and cites history-based access control, provenance-based access control and PIC. Results unchanged.
Version 1, September 27, 2026: Narrows claims to what the code validates, reruns the experiments on ca2a 0.3.1, corrects three citations, and adds a post-evaluation findings section.
Revises a draft dated July 2026.
File checksums. Published version files are retained; substantive revisions receive a new version.
Technical report / Version 3
+OPAQUE Systems
+The Agent2Agent (A2A) protocol moves tasks between agents, and its Signed Agent Card lets a client check that a domain owner issued a card. The card does not bound the authority a delegating agent passes on, establish what code a peer runs, keep a task payload from the peer's host, or leave an offline record of who delegated what to whom. This technical report describes cA2A (Confidential A2A), a trust profile layered on A2A rather than a new transport. It composes four mechanisms: signed delegation credentials whose scope can only narrow at each hop, appraisal of a peer's attestation evidence before a task is sent, a payload sealed to the channel key that evidence vouches for, and a signed per-hop provenance record linked to its parent. Attenuated delegation and provenance binding are covered by prior capability-token work and IETF drafts; the contribution here is their composition on A2A with an open implementation. We state six properties and report software experiments rerun against ca2a 0.3.1: attenuation checks over 5,400 generated chains, rejection of in-chain replay and cross-chain splicing, intersection of delegated scope with local policy, sealed-payload behavior at the cryptographic layer, structural checks on linked provenance records, and a cross-operator attestation protocol exercised with synthetic evidence. Chain verification cost about 0.22 ms per hop in this environment. These results do not show that a peer's key is confined to attested code or that attestation works across independent operators. Recorded hardware runs cover one-directional appraisal of an Intel TDX peer by an AMD SEV-SNP peer in another cloud and a same-operator mutual SEV-SNP diagnostic; mutual attestation between independent operators has not been demonstrated.
A trust profile on A2A composing narrowing delegation credentials, peer attestation appraisal, sealed payloads and linked per-hop provenance records.
The source package preserves the recorded inputs and results. The software experiments were rerun against ca2a 0.3.1 on September 27 and again on October 1, 2026; no hardware run was repeated. 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.
Rishabh Poddar; Aaron Fulkerson; Imran Siddique. cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A. AgenTrust technical report, version 3, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026ca2a,
+ title = {cA2A: Confidential Agent-to-Agent Delegation as a Profile on A2A},
+ author = {Rishabh Poddar and Aaron Fulkerson and Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 3; not peer reviewed},
+ url = {https://agentrust-io.com/research/ca2a/v3/}
+}
+Version 3, October 1, 2026: Adds the caller-attestation relay that ca2a 0.4.0 fixed (GHSA-xxj2-p57x-x954), which affects the evaluated release, corrects four statements, including that a transparency log does not make omission detectable, and restores bold and italic type. Results unchanged.
+Version 2, October 1, 2026: Corrects the claim that the chain checks close cross-workflow splicing: a credential carries no task or execution field, so a delegate can reuse a valid chain across tasks. Scopes the confused-deputy claim to a single chain and cites history-based access control, provenance-based access control and PIC. Results unchanged.
+Version 1, September 27, 2026: Narrows claims to what the code validates, reruns the experiments on ca2a 0.3.1, corrects three citations, and adds a post-evaluation findings section.
+Revises a draft dated July 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+A key broker that gates model-key release on attestation checks code identity. It does not see how a designated memory region behaves while the release request is in flight. We describe a supplementary predicate implemented in Weight Custody Manifest. A runtime derives page-specific values and two traversal orders from a secret and the broker's challenge, writes every logical page, reads every page back, and signs a transcript of declared geometry, page counts, a readback commitment and a mismatch flag. The broker accepts the transcript only if it carries the current challenge, reports no mismatch and verifies under a pinned key, in addition to its existing release policy. At a pinned revision, 35 local tests across the memory sweep and broker modules passed on September 4, September 27 and October 1, 2026. A controlled aliased adapter yields an authentic negative transcript, which shows why signature verification and release approval have to be separate checks. We also analyze a retained 256 MiB protected-guest receipt without treating it as a fresh end-to-end key-release experiment. The predicate gives a bounded observation over a declared logical range. It does not prove full model-memory coverage, defeat a physical-owner attack or establish that memory stays unchanged after the check.
A supplementary key-release predicate: a challenge-bound, signed write/read sweep of a declared memory range, accepted only when fresh, mismatch-free and signed by a pinned key.
The source package preserves the recorded inputs and results. Tests and probes were rerun at the pinned revision on October 1, 2026 in a fresh environment. 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.
Imran Siddique. A Challenge-Bound Memory-Consistency Predicate for Model-Key Release. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026challengeboundmemorysweep,
+ title = {A Challenge-Bound Memory-Consistency Predicate for Model-Key Release},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/challenge-bound-memory-sweep/v1/}
+}
+Version 1, October 1, 2026: First public edition. Revises a manuscript dated September 4, 2026; tests and probes were rerun on September 27 and October 1, 2026 and compared with main of September 30.
+Revises a manuscript dated September 4, 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+A key broker that gates model-key release on attestation checks code identity. It does not see how a designated memory region behaves while the release request is in flight. We describe a supplementary predicate implemented in Weight Custody Manifest. A runtime derives page-specific values and two traversal orders from a secret and the broker's challenge, writes every logical page, reads every page back, and signs a transcript of declared geometry, page counts, a readback commitment and a mismatch flag. The broker accepts the transcript only if it carries the current challenge, reports no mismatch and verifies under a pinned key, in addition to its existing release policy. At a pinned revision, 35 local tests across the memory sweep and broker modules passed on September 4, September 27 and October 1, 2026. A controlled aliased adapter yields an authentic negative transcript, which shows why signature verification and release approval have to be separate checks. We also analyze a retained 256 MiB protected-guest receipt without treating it as a fresh end-to-end key-release experiment. The predicate gives a bounded observation over a declared logical range. It does not prove full model-memory coverage, defeat a physical-owner attack or establish that memory stays unchanged after the check.
A supplementary key-release predicate: a challenge-bound, signed write/read sweep of a declared memory range, accepted only when fresh, mismatch-free and signed by a pinned key.
The source package preserves the recorded inputs and results. Tests and probes were rerun at the pinned revision on October 1, 2026 in a fresh environment. 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.
Imran Siddique. A Challenge-Bound Memory-Consistency Predicate for Model-Key Release. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026challengeboundmemorysweep,
+ title = {A Challenge-Bound Memory-Consistency Predicate for Model-Key Release},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/challenge-bound-memory-sweep/v1/}
+}
+Version 1, October 1, 2026: First public edition. Revises a manuscript dated September 4, 2026; tests and probes were rerun on September 27 and October 1, 2026 and compared with main of September 30.
+Revises a manuscript dated September 4, 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+Technical report / Version 2
OPAQUE Systems
-cMCP (Confidential MCP) proposes a gateway for policy evaluation at the Model Context Protocol tool-call boundary. The gateway evaluates Cedar policies before dispatch and emits signed records binding policy measurements, session identifiers, and tool-call evidence. Its design combines policy hashing, monotonic session sensitivity, tool-catalog pinning, and audit-chain checks. This technical report preserves software-only experiments for those mechanisms, including synthetic healthcare call traces and simulated attestation paths. The measurements illustrate behavior under the stated inputs and assumptions; they do not validate a hardware TEE, establish complete information-flow tracking, or show that every tool invocation was captured. Hardware provenance requires independent attestation appraisal and signing-key binding. Replay and omission detection additionally depend on freshness checks and an expected session or log boundary. The report distinguishes these deployment requirements from the software behavior measured here.
A gateway design combining policy evaluation, session sensitivity, tool-catalog pinning, and signed tool-call records.
The source package preserves the recorded inputs and results. No new experiment run or independent replication is claimed for this edition.
+The source package preserves the recorded inputs and results. Every experiment was rerun on October 1, 2026 at the measured revision 6f12cce and at current main; correctness results are unchanged. 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.
Rishabh Poddar; Aaron Fulkerson; Imran Siddique. cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls. AgenTrust technical report, version 1, 2026.
-Download BibTeX / Download CITATION.cff
@techreport{agentrust2026cmcp,
+Cite this report
Rishabh Poddar; Aaron Fulkerson; Imran Siddique. cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls. AgenTrust technical report, version 2, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026cmcp,
title = {cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls},
author = {Rishabh Poddar and Aaron Fulkerson and Imran Siddique},
institution = {AgenTrust},
year = {2026},
type = {Technical report},
- note = {Version 1; not peer reviewed},
- doi = {10.5281/zenodo.23001694},
- url = {https://agentrust-io.com/research/cmcp/v1/}
+ note = {Version 2; not peer reviewed},
+ url = {https://agentrust-io.com/research/cmcp/v2/}
}
Version history
Version 1, September 27, 2026: Narrows the abstract to the measured software behavior, corrects the false-discovery terminology, and adds the publication scope and patent notice.
+Version history
Version 2, October 1, 2026: Corrects the REPORT_DATA size, the session-claim nonce, when the catalog check runs, trial counts, two citations and two performance figures, names the measured revision and its advisories, and restores bold and italic type. Correctness results unchanged.
+Version 1, September 27, 2026: Narrows the abstract to the measured software behavior, corrects the false-discovery terminology, and adds the publication scope and patent notice.
Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
-File checksums. Published version files are retained; substantive revisions receive a new version.
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.
Version 1, September 27, 2026: Narrows the abstract to the measured software behavior, corrects the false-discovery terminology, and adds the publication scope and patent notice.
+Version 2, October 1, 2026: Corrects the REPORT_DATA size, the session-claim nonce, when the catalog check runs, trial counts, two citations and two performance figures, names the measured revision and its advisories, and restores bold and italic type. Correctness results unchanged.
+Version 1, September 27, 2026: Narrows the abstract to the measured software behavior, corrects the false-discovery terminology, and adds the publication scope and patent notice.
Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 2
+OPAQUE Systems
+cMCP (Confidential MCP) proposes a gateway for policy evaluation at the Model Context Protocol tool-call boundary. The gateway evaluates Cedar policies before dispatch and emits signed records binding policy measurements, session identifiers, and tool-call evidence. Its design combines policy hashing, monotonic session sensitivity, tool-catalog pinning, and audit-chain checks. This technical report preserves software-only experiments for those mechanisms, including synthetic healthcare call traces and simulated attestation paths. The measurements illustrate behavior under the stated inputs and assumptions; they do not validate a hardware TEE, establish complete information-flow tracking, or show that every tool invocation was captured. Hardware provenance requires independent attestation appraisal and signing-key binding. Replay and omission detection additionally depend on freshness checks and an expected session or log boundary. The report distinguishes these deployment requirements from the software behavior measured here.
A gateway design combining policy evaluation, session sensitivity, tool-catalog pinning, and signed tool-call records.
The source package preserves the recorded inputs and results. Every experiment was rerun on October 1, 2026 at the measured revision 6f12cce and at current main; correctness results are unchanged. 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.
Rishabh Poddar; Aaron Fulkerson; Imran Siddique. cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls. AgenTrust technical report, version 2, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026cmcp,
+ title = {cMCP: Verifiable Policy Enforcement for AI Agent Tool Calls},
+ author = {Rishabh Poddar and Aaron Fulkerson and Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 2; not peer reviewed},
+ url = {https://agentrust-io.com/research/cmcp/v2/}
+}
+Version 2, October 1, 2026: Corrects the REPORT_DATA size, the session-claim nonce, when the catalog check runs, trial counts, two citations and two performance figures, names the measured revision and its advisories, and restores bold and italic type. Correctness results unchanged.
+Version 1, September 27, 2026: Narrows the abstract to the measured software behavior, corrects the false-discovery terminology, and adds the publication scope and patent notice.
+Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 2
+Technical report / Version 3
OPAQUE Systems
-This paper states conditions under which tool calls and agent handoffs preserve an authorized plaintext-holder boundary. This requires a protected channel bound to an appraised workload, restricted authority, enforceable downstream information-flow rules, and control over every other plaintext sink. A signature on an execution record or a valid hardware quote alone cannot establish these conditions. If a recipient cannot satisfy them, the sender must withhold the data or obtain authorization for a precisely described disclosure. This paper develops a conditional composition argument, a proposed handoff contract, and component experiments that expose failures of appraisal, supervision, and outcome inference. A composed software harness joins provisioning, diagnostic model computation, a confined agent, a mediated tool, delegated peer authentication, and exact-output disclosure. Its paired mutations expose earlier leaks despite successful final delivery; a rerun on September 27, 2026 reproduced all 36 recorded observations. All results are software results with synthetic attestation and a single operator. AgenTrust supplies relevant identity, key-release, gateway, delegation, and evidence primitives, but its present components do not demonstrate the complete property. The distinction matters most at remote tools, CPU-GPU transfers, operator-controlled key brokers, runtime changes, and audit systems.
A conditional composition argument and proposed handoff contract for when tool calls and delegations preserve an authorized plaintext-holder boundary.
The source package preserves the recorded inputs and results. The composed software experiment was rerun for this edition; no hardware run was repeated. 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.
Imran Siddique. Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation. AgenTrust technical report, version 2, 2026.
-Download BibTeX / Download CITATION.cff
@techreport{agentrust2026confidentialhandoffs,
+Cite this report
Imran Siddique. Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation. AgenTrust technical report, version 3, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026confidentialhandoffs,
title = {Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation},
author = {Imran Siddique},
institution = {AgenTrust},
year = {2026},
type = {Technical report},
- note = {Version 2; not peer reviewed},
- doi = {10.5281/zenodo.23074670},
- url = {https://agentrust-io.com/research/confidential-handoffs/v2/}
+ note = {Version 3; not peer reviewed},
+ url = {https://agentrust-io.com/research/confidential-handoffs/v3/}
}
Version history
Version 2, September 30, 2026: Adds the missing citation to the Forough, Kogias and Haddadi survey that lists multi-hop attestation as an open challenge (arXiv:2605.03213). Results unchanged.
+Version history
Version 3, October 1, 2026: Qualifies the section 7.6 mutual-appraisal result after advisory GHSA-xxj2-p57x-x954, notes that ca2a-runtime 0.3.1 is affected, and updates two redirected links. Results unchanged; the portable composed cases were rerun on October 1, 2026.
+Version 2, September 30, 2026: Adds the missing citation to the Forough, Kogias and Haddadi survey that lists multi-hop attestation as an open challenge (arXiv:2605.03213). Results unchanged.
Version 1, September 27, 2026: Reframes the draft as a bounded software edition, records the rerun, updates dependency status and corrects two references.
Revises a discussion draft dated September 19, 2026.
-File checksums. Published version files are retained; substantive revisions receive a new version.
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.
Version 2, September 30, 2026: Adds the missing citation to the Forough, Kogias and Haddadi survey that lists multi-hop attestation as an open challenge (arXiv:2605.03213). Results unchanged.
+Version 3, October 1, 2026: Qualifies the section 7.6 mutual-appraisal result after advisory GHSA-xxj2-p57x-x954, notes that ca2a-runtime 0.3.1 is affected, and updates two redirected links. Results unchanged; the portable composed cases were rerun on October 1, 2026.
+Version 2, September 30, 2026: Adds the missing citation to the Forough, Kogias and Haddadi survey that lists multi-hop attestation as an open challenge (arXiv:2605.03213). Results unchanged.
Version 1, September 27, 2026: Reframes the draft as a bounded software edition, records the rerun, updates dependency status and corrects two references.
Revises a discussion draft dated September 19, 2026.
File checksums. Published version files are retained; substantive revisions receive a new version.
Version 2, September 30, 2026: Adds the missing citation to the Forough, Kogias and Haddadi survey that lists multi-hop attestation as an open challenge (arXiv:2605.03213). Results unchanged.
+Version 3, October 1, 2026: Qualifies the section 7.6 mutual-appraisal result after advisory GHSA-xxj2-p57x-x954, notes that ca2a-runtime 0.3.1 is affected, and updates two redirected links. Results unchanged; the portable composed cases were rerun on October 1, 2026.
+Version 2, September 30, 2026: Adds the missing citation to the Forough, Kogias and Haddadi survey that lists multi-hop attestation as an open challenge (arXiv:2605.03213). Results unchanged.
Version 1, September 27, 2026: Reframes the draft as a bounded software edition, records the rerun, updates dependency status and corrects two references.
Revises a discussion draft dated September 19, 2026.
File checksums. Published version files are retained; substantive revisions receive a new version.
Technical report / Version 3
+OPAQUE Systems
+This paper states conditions under which tool calls and agent handoffs preserve an authorized plaintext-holder boundary. This requires a protected channel bound to an appraised workload, restricted authority, enforceable downstream information-flow rules, and control over every other plaintext sink. A signature on an execution record or a valid hardware quote alone cannot establish these conditions. If a recipient cannot satisfy them, the sender must withhold the data or obtain authorization for a precisely described disclosure. This paper develops a conditional composition argument, a proposed handoff contract, and component experiments that expose failures of appraisal, supervision, and outcome inference. A composed software harness joins provisioning, diagnostic model computation, a confined agent, a mediated tool, delegated peer authentication, and exact-output disclosure. Its paired mutations expose earlier leaks despite successful final delivery; a rerun on September 27, 2026 reproduced all 36 recorded observations. All results are software results with synthetic attestation and a single operator. AgenTrust supplies relevant identity, key-release, gateway, delegation, and evidence primitives, but its present components do not demonstrate the complete property. The distinction matters most at remote tools, CPU-GPU transfers, operator-controlled key brokers, runtime changes, and audit systems.
A conditional composition argument and proposed handoff contract for when tool calls and delegations preserve an authorized plaintext-holder boundary.
The source package preserves the recorded inputs and results. The composed software experiment was rerun for this edition; no hardware run was repeated. 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.
Imran Siddique. Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation. AgenTrust technical report, version 3, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026confidentialhandoffs,
+ title = {Confidentiality Across Agent Handoffs: Conditions for preserving an inference guarantee through tools and delegation},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 3; not peer reviewed},
+ url = {https://agentrust-io.com/research/confidential-handoffs/v3/}
+}
+Version 3, October 1, 2026: Qualifies the section 7.6 mutual-appraisal result after advisory GHSA-xxj2-p57x-x954, notes that ca2a-runtime 0.3.1 is affected, and updates two redirected links. Results unchanged; the portable composed cases were rerun on October 1, 2026.
+Version 2, September 30, 2026: Adds the missing citation to the Forough, Kogias and Haddadi survey that lists multi-hop attestation as an open challenge (arXiv:2605.03213). Results unchanged.
+Version 1, September 27, 2026: Reframes the draft as a bounded software edition, records the rerun, updates dependency status and corrects two references.
+Revises a discussion draft dated September 19, 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+An operator presses the kill switch on an agent. What is actually true a second later, a day later, and after someone restarts the gateway? We study this at one place where the answer can be tested: the cMCP tool gateway, which stores an identity block durably, closes the governed session with a signed claim, and signs every later refusal so that it names that claim by digest. Recovery takes an explicit operator action with a separate credential. On the pinned source, 86 selected tests pass, and removing the durable block lookup or the refusal signature check makes 17 and 2 of them fail. A block written once is seen by 20 of 20 reopened store connections. With four slow tool calls in flight, an operator trip admits nothing new in three different timing cases: calls sent 54 to 71 ms after the trip starts, and after it returns, are refused with a receipt that verifies. The same experiment measures what a trip does to work already admitted. Cooperative calls finish or are cancelled at the drain deadline, but a call running in a worker thread completes its effect about 1.2 s after the trip has returned, while its caller receives HTTP 500. A prototype challenge-response check, written for this study, lets a verifier ask whether the block is in force now, which an archived refusal cannot answer. All results were rerun on October 1, 2026 from a fresh environment and match the earlier records, and the same harness passes on current cMCP main.
A tested account of what a tool-gateway kill switch establishes: a durable block, signed refusals that name the closing claim, explicit recovery, and the fate of work already admitted.
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.
Imran Siddique. When an Agent Kill Switch Trips: Durable blocks, linked refusals and work already in flight at a tool gateway. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026durableshutdownblocks,
+ title = {When an Agent Kill Switch Trips: Durable blocks, linked refusals and work already in flight at a tool gateway},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/durable-shutdown-blocks/v1/}
+}
+Version 1, October 1, 2026: First public edition. Evaluates cMCP 2cdb168; results were rerun on October 1, 2026 from a fresh environment, and the same harness passes on main a3f61e1.
+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.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+An operator presses the kill switch on an agent. What is actually true a second later, a day later, and after someone restarts the gateway? We study this at one place where the answer can be tested: the cMCP tool gateway, which stores an identity block durably, closes the governed session with a signed claim, and signs every later refusal so that it names that claim by digest. Recovery takes an explicit operator action with a separate credential. On the pinned source, 86 selected tests pass, and removing the durable block lookup or the refusal signature check makes 17 and 2 of them fail. A block written once is seen by 20 of 20 reopened store connections. With four slow tool calls in flight, an operator trip admits nothing new in three different timing cases: calls sent 54 to 71 ms after the trip starts, and after it returns, are refused with a receipt that verifies. The same experiment measures what a trip does to work already admitted. Cooperative calls finish or are cancelled at the drain deadline, but a call running in a worker thread completes its effect about 1.2 s after the trip has returned, while its caller receives HTTP 500. A prototype challenge-response check, written for this study, lets a verifier ask whether the block is in force now, which an archived refusal cannot answer. All results were rerun on October 1, 2026 from a fresh environment and match the earlier records, and the same harness passes on current cMCP main.
A tested account of what a tool-gateway kill switch establishes: a durable block, signed refusals that name the closing claim, explicit recovery, and the fate of work already admitted.
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.
Imran Siddique. When an Agent Kill Switch Trips: Durable blocks, linked refusals and work already in flight at a tool gateway. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026durableshutdownblocks,
+ title = {When an Agent Kill Switch Trips: Durable blocks, linked refusals and work already in flight at a tool gateway},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/durable-shutdown-blocks/v1/}
+}
+Version 1, October 1, 2026: First public edition. Evaluates cMCP 2cdb168; results were rerun on October 1, 2026 from a fresh environment, and the same harness passes on main a3f61e1.
+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.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+An answer an agent writes from a confidential record keeps the record's restrictions, even when it reads like a harmless summary. This report describes a release path for that case. An owner signs the exact output bytes together with the recipient, purpose, source scope, inherited labels, policy version and a validity interval. A gate checks the signer's authority for that scope, verifies the signature, and commits a request identifier to a persistent ledger before it calls the one registered delivery adapter. If the acknowledgment is lost, the attempt stays consumed and the outcome is reported as unknown. Nothing is sent twice. We evaluate the implementation in cMCP, which ships in cmcp-runtime 0.6.0 and later. All 46 existing tests pass, and removing either of two controls makes specific tests fail. In 20 rounds of 16 concurrent attempts, every round delivered once. In 10 rounds of 8 competing sender processes, every round produced exactly one recorded receipt. Process kills on both sides of the ledger commit, lock timeouts, a corrupted ledger and a dropped acknowledgment never produced a second receipt; with replay consumption removed, all 9 of those cases fail. Every number was reproduced on October 1, 2026 at the evaluated revision and at current main.
A release gate that ties owner-signed exact output bytes to a scoped, persistent, single-attempt decision and reports an uncertain delivery as unknown instead of repeating it.
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.
Imran Siddique. Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes, consumed once before delivery. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026exactoutputdisclosure,
+ title = {Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes, consumed once before delivery},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/exact-output-disclosure/v1/}
+}
+Version 1, October 1, 2026: First public edition. Evaluates cMCP 2cdb168; every count was reproduced on October 1, 2026 at that revision and at main a3f61e1.
+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.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+An answer an agent writes from a confidential record keeps the record's restrictions, even when it reads like a harmless summary. This report describes a release path for that case. An owner signs the exact output bytes together with the recipient, purpose, source scope, inherited labels, policy version and a validity interval. A gate checks the signer's authority for that scope, verifies the signature, and commits a request identifier to a persistent ledger before it calls the one registered delivery adapter. If the acknowledgment is lost, the attempt stays consumed and the outcome is reported as unknown. Nothing is sent twice. We evaluate the implementation in cMCP, which ships in cmcp-runtime 0.6.0 and later. All 46 existing tests pass, and removing either of two controls makes specific tests fail. In 20 rounds of 16 concurrent attempts, every round delivered once. In 10 rounds of 8 competing sender processes, every round produced exactly one recorded receipt. Process kills on both sides of the ledger commit, lock timeouts, a corrupted ledger and a dropped acknowledgment never produced a second receipt; with replay consumption removed, all 9 of those cases fail. Every number was reproduced on October 1, 2026 at the evaluated revision and at current main.
A release gate that ties owner-signed exact output bytes to a scoped, persistent, single-attempt decision and reports an uncertain delivery as unknown instead of repeating it.
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.
Imran Siddique. Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes, consumed once before delivery. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026exactoutputdisclosure,
+ title = {Exact-Output Disclosure for Agent Workflows: Owner approval of exact bytes, consumed once before delivery},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/exact-output-disclosure/v1/}
+}
+Version 1, October 1, 2026: First public edition. Evaluates cMCP 2cdb168; every count was reproduced on October 1, 2026 at that revision and at main a3f61e1.
+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.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+One agent appraises a peer, delegates a task to it, and gets an HTTP response back. Appraising the peer before sending says nothing about who wrote that response. A relay can swap the body, replay an answer from another call, or turn an error into a success. We study the strict response-authentication mode of the cA2A runtime, which binds the appraised peer key, the complete request and a fresh request occurrence into a key that can verify exactly one response, once. It authenticates success and denial bodies, binds the status the caller will act on, and reports an unknown outcome whenever verification or transport fails, instead of guessing. On the pinned source, 57 selected tests pass, including loopback HTTP exchanges, and removing the MAC comparison or the single-use consumption makes 4 and 3 of them fail. In 20 rounds of 16 concurrent verifications, exactly one response is accepted per round. With separate caller, relay and peer processes and the connection cut before dispatch, after execution, mid-body, or with the caller killed, the client submits once, reports unknown, and a restarted caller cannot accept the captured response. A control client that resends once on a transport error makes the peer execute one business operation twice. The authentication is for the live caller: the caller can compute the same MAC, so a stored response is not proof of peer authorship to a third party. All results were rerun on October 1, 2026 from a fresh environment and match the earlier records, and the same harness passes on current cA2A main.
A strict response-authentication mode that binds the appraised peer key, the complete request and a fresh occurrence into a single-use key, and reports unknown outcomes instead of guessing.
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.
Imran Siddique. Authenticating the Answer in an Agent Handoff: Single-use, request-bound response authentication and the outcome a caller cannot know. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026handoffresponseauthentication,
+ title = {Authenticating the Answer in an Agent Handoff: Single-use, request-bound response authentication and the outcome a caller cannot know},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/handoff-response-authentication/v1/}
+}
+Version 1, October 1, 2026: First public edition. Evaluates cA2A fc22c64; results were rerun on October 1, 2026 from a fresh environment, and the same harness passes on main 19407fb.
+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.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+One agent appraises a peer, delegates a task to it, and gets an HTTP response back. Appraising the peer before sending says nothing about who wrote that response. A relay can swap the body, replay an answer from another call, or turn an error into a success. We study the strict response-authentication mode of the cA2A runtime, which binds the appraised peer key, the complete request and a fresh request occurrence into a key that can verify exactly one response, once. It authenticates success and denial bodies, binds the status the caller will act on, and reports an unknown outcome whenever verification or transport fails, instead of guessing. On the pinned source, 57 selected tests pass, including loopback HTTP exchanges, and removing the MAC comparison or the single-use consumption makes 4 and 3 of them fail. In 20 rounds of 16 concurrent verifications, exactly one response is accepted per round. With separate caller, relay and peer processes and the connection cut before dispatch, after execution, mid-body, or with the caller killed, the client submits once, reports unknown, and a restarted caller cannot accept the captured response. A control client that resends once on a transport error makes the peer execute one business operation twice. The authentication is for the live caller: the caller can compute the same MAC, so a stored response is not proof of peer authorship to a third party. All results were rerun on October 1, 2026 from a fresh environment and match the earlier records, and the same harness passes on current cA2A main.
A strict response-authentication mode that binds the appraised peer key, the complete request and a fresh occurrence into a single-use key, and reports unknown outcomes instead of guessing.
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.
Imran Siddique. Authenticating the Answer in an Agent Handoff: Single-use, request-bound response authentication and the outcome a caller cannot know. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026handoffresponseauthentication,
+ title = {Authenticating the Answer in an Agent Handoff: Single-use, request-bound response authentication and the outcome a caller cannot know},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/handoff-response-authentication/v1/}
+}
+Version 1, October 1, 2026: First public edition. Evaluates cA2A fc22c64; results were rerun on October 1, 2026 from a fresh environment, and the same harness passes on main 19407fb.
+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.
Open an issue in the project repository and identify the report version and section.
AgenTrust Research
Technical reports with open source, recorded experiments, and explicit limits. Read the work, inspect the evidence, and cite a specific version.
Runtime evidence
A portable format for runtime claims, with recorded measurements of signing, verification, record size, and conformance fixtures.
Read the reportTool-call enforcement
A gateway design combining policy evaluation, session sensitivity, tool-catalog pinning, and signed tool-call records.
Read the reportAgent identity
A signed baseline for agent artifacts, with recorded Ed25519 benchmarks, delegation checks, and tamper probes.
Read the reportModel weight custody
A portable custody contract binding exact weights, measured workload, fresh channel-bound release, renewable authority, terminal evidence and derivative lineage.
Read the reportDelegation evidence
A trust profile on A2A composing narrowing delegation credentials, peer attestation appraisal, sealed payloads and linked per-hop provenance records.
Read the reportGovernance telemetry
A backend-neutral contract for six governance event families that keeps lossy operational telemetry separate from evidence whose completeness is stated.
Read the reportConfidential handoffs
A conditional composition argument and proposed handoff contract for when tool calls and delegations preserve an authorized plaintext-holder boundary.
Read the reportGovernance telemetry
A source-side contract that accepts each governance event into a run-scoped cryptographic prefix before operational export, keeping export failures separate from evidence failures.
Read the reportRuntime evidence
A portable format for runtime claims, with recorded measurements of signing, verification, record size, and conformance fixtures.
Read the reportTool-call enforcement
A gateway design combining policy evaluation, session sensitivity, tool-catalog pinning, and signed tool-call records.
Read the reportAgent identity
A signed baseline for agent artifacts, with recorded Ed25519 benchmarks, delegation checks, and tamper probes.
Read the reportModel weight custody
A portable custody contract binding exact weights, measured workload, fresh channel-bound release, renewable authority, terminal evidence and derivative lineage.
Read the reportDelegation evidence
A trust profile on A2A composing narrowing delegation credentials, peer attestation appraisal, sealed payloads and linked per-hop provenance records.
Read the reportGovernance telemetry
A backend-neutral contract for six governance event families that keeps lossy operational telemetry separate from evidence whose completeness is stated.
Read the reportConfidential handoffs
A conditional composition argument and proposed handoff contract for when tool calls and delegations preserve an authorized plaintext-holder boundary.
Read the reportGovernance telemetry
A source-side contract that accepts each governance event into a run-scoped cryptographic prefix before operational export, keeping export failures separate from evidence failures.
Read the reportModel weight custody
A supplementary key-release predicate: a challenge-bound, signed write/read sweep of a declared memory range, accepted only when fresh, mismatch-free and signed by a pinned key.
Read the reportHuman oversight
A two-domain signing boundary: the issuer signs the oversight requirement with approvals normalized to empty, and each human signs an approval bound to a manifest and scope.
Read the reportDisclosure control
A release gate that ties owner-signed exact output bytes to a scoped, persistent, single-attempt decision and reports an uncertain delivery as unknown instead of repeating it.
Read the reportModel weight custody
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.
Read the reportTool-call enforcement
A tested account of what a tool-gateway kill switch establishes: a durable block, signed refusals that name the closing claim, explicit recovery, and the fate of work already admitted.
Read the reportDelegation evidence
A strict response-authentication mode that binds the appraised peer key, the complete request and a fresh occurrence into a single-use key, and reports unknown outcomes instead of guessing.
Read the reportModel serving
A routing gate for confidential model hosts: the Kubernetes Service exists only from a verified first admission receipt for one session, and a durable per-session ledger keeps revoked sessions unroutable.
Read the reportThese reports preserve historical designs and software evaluations. A signature, an attestation result, and an execution-completeness claim establish different properties. Each paper page identifies the evidence evaluated and the limits that remain.
For implementation, follow the current project specifications linked from each report. Paper text is available under CC BY 4.0; code retains its project license.
Technical report / Version 1
+OPAQUE Systems
+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.
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.
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.
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},
+ url = {https://agentrust-io.com/research/model-key-broker-provisioning/v1/}
+}
+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.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+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.
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.
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.
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},
+ url = {https://agentrust-io.com/research/model-key-broker-provisioning/v1/}
+}
+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.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+A confidential model host has to exist before it can attest, so the Pod comes first. The open question is when clients may reach it. This report describes a mechanism that answers it with evidence. A planner produces a bootstrap Pod that holds only encrypted model material, and produces the Kubernetes Service that routes to it only after it has verified a signed admission receipt for that exact hosting session: pinned signer key, first position in the receipt chain, and equality with six application bindings (tenant, model, encrypted artifact, workload, policy, transport). A signed, terminal lifecycle receipt for the same session removes the route. Because the planner keeps no state, a controller carries a durable, monotonic per-session ledger, so a session that has been revoked can never be routed again from its old admission. We evaluated the planner in an internal repository at two commits, and a reference implementation published with this report. The planner passed its 6 selected tests, rejected six correctly signed receipts that each carried one wrong binding, and, as expected for a stateless component, still accepted an old admission after revocation. The controller, run against a fake Kubernetes API in which every action is a fresh process, kept every revoked session unroutable across all 12 cases of its test matrix. Removing the ledger check, or keeping the ledger in memory, failed 7 of 12 cases. Restoring an old copy of the ledger reopened a revoked session, so the ledger itself needs rollback protection. The evidence is software only; no cluster, confidential GPU or model inference was used.
A routing gate for confidential model hosts: the Kubernetes Service exists only from a verified first admission receipt for one session, and a durable per-session ledger keeps revoked sessions unroutable.
The source package preserves the recorded inputs and results. Every experiment was rerun on October 1, 2026 in a fresh environment against both evaluated commits and the reference implementation. No independent replication is claimed.
+No separate specification exists for this mechanism. The reference implementation in the source package is the implementation guidance.
Imran Siddique. Receipt-Gated Model Serving: Routing to a confidential model host only after a signed admission receipt. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026receiptgatedmodelserving,
+ title = {Receipt-Gated Model Serving: Routing to a confidential model host only after a signed admission receipt},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/receipt-gated-model-serving/v1/}
+}
+Version 1, October 1, 2026: First public edition. Evaluates an internal planner at two commits and a published reference implementation, rerun on October 1, 2026, and fixes a revocation-chaining defect found after the September 27 draft.
+Based on an internal study drafted September 23, 2026; an internal draft followed on September 27, 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the AgenTrust public issue tracker and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+A confidential model host has to exist before it can attest, so the Pod comes first. The open question is when clients may reach it. This report describes a mechanism that answers it with evidence. A planner produces a bootstrap Pod that holds only encrypted model material, and produces the Kubernetes Service that routes to it only after it has verified a signed admission receipt for that exact hosting session: pinned signer key, first position in the receipt chain, and equality with six application bindings (tenant, model, encrypted artifact, workload, policy, transport). A signed, terminal lifecycle receipt for the same session removes the route. Because the planner keeps no state, a controller carries a durable, monotonic per-session ledger, so a session that has been revoked can never be routed again from its old admission. We evaluated the planner in an internal repository at two commits, and a reference implementation published with this report. The planner passed its 6 selected tests, rejected six correctly signed receipts that each carried one wrong binding, and, as expected for a stateless component, still accepted an old admission after revocation. The controller, run against a fake Kubernetes API in which every action is a fresh process, kept every revoked session unroutable across all 12 cases of its test matrix. Removing the ledger check, or keeping the ledger in memory, failed 7 of 12 cases. Restoring an old copy of the ledger reopened a revoked session, so the ledger itself needs rollback protection. The evidence is software only; no cluster, confidential GPU or model inference was used.
A routing gate for confidential model hosts: the Kubernetes Service exists only from a verified first admission receipt for one session, and a durable per-session ledger keeps revoked sessions unroutable.
The source package preserves the recorded inputs and results. Every experiment was rerun on October 1, 2026 in a fresh environment against both evaluated commits and the reference implementation. No independent replication is claimed.
+No separate specification exists for this mechanism. The reference implementation in the source package is the implementation guidance.
Imran Siddique. Receipt-Gated Model Serving: Routing to a confidential model host only after a signed admission receipt. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026receiptgatedmodelserving,
+ title = {Receipt-Gated Model Serving: Routing to a confidential model host only after a signed admission receipt},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/receipt-gated-model-serving/v1/}
+}
+Version 1, October 1, 2026: First public edition. Evaluates an internal planner at two commits and a published reference implementation, rerun on October 1, 2026, and fixes a revocation-chaining defect found after the September 27 draft.
+Based on an internal study drafted September 23, 2026; an internal draft followed on September 27, 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the AgenTrust public issue tracker and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+Human approval often arrives after an agent manifest has been issued. If the issuer signs the approval collection as immutable content, nobody can attach an approval later without a new signature. If the issuer leaves the whole oversight record unsigned, anyone can weaken the requirement. We analyze a two-domain construction: the issuer signs the oversight requirement while normalizing only its approvals array to empty, and each human separately signs an approval bound to a manifest and scope. A verifier reconstructs the issuer pre-image and evaluates human evidence on its own terms. Agent Manifest uses this pre-image for version 0.1 manifests; its version 0.2 COSE envelope reaches the same split by carrying approvals in the unprotected header. At a pinned Agent Manifest revision, 74 signing and delegation/HITL tests passed on September 4, September 27 and October 1, 2026. Separate probes confirm requirement binding and appendability. At the pinned revision they also show that the human signature did not cover the outer authenticator-method label. A later upstream change binds that label, and the same probe fails against two later revisions, including the October 1 main branch. The result is a precise signing boundary and a list of the identity, action and authenticator evidence a runtime still needs before it acts on an approval.
A two-domain signing boundary: the issuer signs the oversight requirement with approvals normalized to empty, and each human signs an approval bound to a manifest and scope.
The source package preserves the recorded inputs and results. Tests and probes were rerun at the pinned revision on October 1, 2026 in a fresh environment. 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.
Imran Siddique. Requirement-Preserving Human Approvals for Signed Agent Manifests. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026requirementpreservinghumanapproval,
+ title = {Requirement-Preserving Human Approvals for Signed Agent Manifests},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/requirement-preserving-human-approval/v1/}
+}
+Version 1, October 1, 2026: First public edition. Revises a manuscript dated September 4, 2026; tests and probes were rerun on September 27 and October 1, 2026, and the probes were run against two later revisions.
+Revises a manuscript dated September 4, 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+OPAQUE Systems
+Human approval often arrives after an agent manifest has been issued. If the issuer signs the approval collection as immutable content, nobody can attach an approval later without a new signature. If the issuer leaves the whole oversight record unsigned, anyone can weaken the requirement. We analyze a two-domain construction: the issuer signs the oversight requirement while normalizing only its approvals array to empty, and each human separately signs an approval bound to a manifest and scope. A verifier reconstructs the issuer pre-image and evaluates human evidence on its own terms. Agent Manifest uses this pre-image for version 0.1 manifests; its version 0.2 COSE envelope reaches the same split by carrying approvals in the unprotected header. At a pinned Agent Manifest revision, 74 signing and delegation/HITL tests passed on September 4, September 27 and October 1, 2026. Separate probes confirm requirement binding and appendability. At the pinned revision they also show that the human signature did not cover the outer authenticator-method label. A later upstream change binds that label, and the same probe fails against two later revisions, including the October 1 main branch. The result is a precise signing boundary and a list of the identity, action and authenticator evidence a runtime still needs before it acts on an approval.
A two-domain signing boundary: the issuer signs the oversight requirement with approvals normalized to empty, and each human signs an approval bound to a manifest and scope.
The source package preserves the recorded inputs and results. Tests and probes were rerun at the pinned revision on October 1, 2026 in a fresh environment. 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.
Imran Siddique. Requirement-Preserving Human Approvals for Signed Agent Manifests. AgenTrust technical report, version 1, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026requirementpreservinghumanapproval,
+ title = {Requirement-Preserving Human Approvals for Signed Agent Manifests},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 1; not peer reviewed},
+ url = {https://agentrust-io.com/research/requirement-preserving-human-approval/v1/}
+}
+Version 1, October 1, 2026: First public edition. Revises a manuscript dated September 4, 2026; tests and probes were rerun on September 27 and October 1, 2026, and the probes were run against two later revisions.
+Revises a manuscript dated September 4, 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 2
+Technical report / Version 3
OPAQUE Systems
-An operational telemetry backend can lose events through sampling, retention and exporter failures. Its observations therefore cannot, by themselves, establish complete governance evidence. We describe a source-side acceptance boundary in AgenTrust Telemetry: validate a metadata-constrained event, check context correlation, accept an isolated representation into a run-scoped cryptographic prefix, and only then attempt operational projections. In a durable configuration, an external callback must acknowledge persistence before the local prefix advances. Export failures remain distinct from evidence failures. We formalize the conditional ordering property and test its limits, including acknowledgment loss and an empty accumulator declared complete. At a pinned source revision, 111 Python tests and 13 portable conformance fixtures produced expected results on September 4 and again on September 27, 2026. Four additional probes demonstrate both the useful separation and the absence of automatic completeness or distributed exactly-once persistence. The contribution is a precise contract for acceptance before export, with explicit trust and recovery obligations, rather than a claim that a hash chain proves every event occurred.
A source-side contract that accepts each governance event into a run-scoped cryptographic prefix before operational export, keeping export failures separate from evidence failures.
The source package preserves the recorded inputs and results. Tests, fixtures and boundary probes were rerun at the pinned commit for this edition. No independent replication is claimed.
+The source package preserves the recorded inputs and results. Tests, fixtures and boundary probes were rerun at the pinned commit on September 27 and October 1, 2026. 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.
Imran Siddique. Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry. AgenTrust technical report, version 2, 2026.
-Download BibTeX / Download CITATION.cff
@techreport{agentrust2026telemetryevidenceacceptance,
+Cite this report
Imran Siddique. Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry. AgenTrust technical report, version 3, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026telemetryevidenceacceptance,
title = {Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry},
author = {Imran Siddique},
institution = {AgenTrust},
year = {2026},
type = {Technical report},
- note = {Version 2; not peer reviewed},
- doi = {10.5281/zenodo.23074733},
- url = {https://agentrust-io.com/research/telemetry-evidence-acceptance/v2/}
+ note = {Version 3; not peer reviewed},
+ url = {https://agentrust-io.com/research/telemetry-evidence-acceptance/v3/}
}
Version history
Version 2, September 30, 2026: Adds the missing citation to Crosby and Wallach's tamper-evident history trees (USENIX Security 2009). Results unchanged.
+Version history
Version 3, October 1, 2026: Adds the defect in the pinned revision's TRACE finalizer that the truncation argument depends on, and cites the Internet-Draft that already chains agent audit records over RFC 8785 bytes. Results unchanged.
+Version 2, September 30, 2026: Adds the missing citation to Crosby and Wallach's tamper-evident history trees (USENIX Security 2009). Results unchanged.
Version 1, September 27, 2026: Adds the rerun, a later-revision probe result, a comparison with prior logging systems in place of the filing notes, and corrected patent and RFC references.
Revises a manuscript dated September 4, 2026.
-File checksums. Published version files are retained; substantive revisions receive a new version.
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.
Version 2, September 30, 2026: Adds the missing citation to Crosby and Wallach's tamper-evident history trees (USENIX Security 2009). Results unchanged.
+Version 3, October 1, 2026: Adds the defect in the pinned revision's TRACE finalizer that the truncation argument depends on, and cites the Internet-Draft that already chains agent audit records over RFC 8785 bytes. Results unchanged.
+Version 2, September 30, 2026: Adds the missing citation to Crosby and Wallach's tamper-evident history trees (USENIX Security 2009). Results unchanged.
Version 1, September 27, 2026: Adds the rerun, a later-revision probe result, a comparison with prior logging systems in place of the filing notes, and corrected patent and RFC references.
Revises a manuscript dated September 4, 2026.
File checksums. Published version files are retained; substantive revisions receive a new version.
Version 2, September 30, 2026: Adds the missing citation to Crosby and Wallach's tamper-evident history trees (USENIX Security 2009). Results unchanged.
+Version 3, October 1, 2026: Adds the defect in the pinned revision's TRACE finalizer that the truncation argument depends on, and cites the Internet-Draft that already chains agent audit records over RFC 8785 bytes. Results unchanged.
+Version 2, September 30, 2026: Adds the missing citation to Crosby and Wallach's tamper-evident history trees (USENIX Security 2009). Results unchanged.
Version 1, September 27, 2026: Adds the rerun, a later-revision probe result, a comparison with prior logging systems in place of the filing notes, and corrected patent and RFC references.
Revises a manuscript dated September 4, 2026.
File checksums. Published version files are retained; substantive revisions receive a new version.
Technical report / Version 3
+OPAQUE Systems
+An operational telemetry backend can lose events through sampling, retention and exporter failures. Its observations therefore cannot, by themselves, establish complete governance evidence. We describe a source-side acceptance boundary in AgenTrust Telemetry: validate a metadata-constrained event, check context correlation, accept an isolated representation into a run-scoped cryptographic prefix, and only then attempt operational projections. In a durable configuration, an external callback must acknowledge persistence before the local prefix advances. Export failures remain distinct from evidence failures. We formalize the conditional ordering property and test its limits, including acknowledgment loss and an empty accumulator declared complete. At a pinned source revision, 111 Python tests and 13 portable conformance fixtures produced expected results on September 4 and again on September 27, 2026. Four additional probes demonstrate both the useful separation and the absence of automatic completeness or distributed exactly-once persistence. The contribution is a precise contract for acceptance before export, with explicit trust and recovery obligations, rather than a claim that a hash chain proves every event occurred.
A source-side contract that accepts each governance event into a run-scoped cryptographic prefix before operational export, keeping export failures separate from evidence failures.
The source package preserves the recorded inputs and results. Tests, fixtures and boundary probes were rerun at the pinned commit on September 27 and October 1, 2026. 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.
Imran Siddique. Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry. AgenTrust technical report, version 3, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026telemetryevidenceacceptance,
+ title = {Acceptance Before Export: A Bounded Evidence Contract for Governance Telemetry},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 3; not peer reviewed},
+ url = {https://agentrust-io.com/research/telemetry-evidence-acceptance/v3/}
+}
+Version 3, October 1, 2026: Adds the defect in the pinned revision's TRACE finalizer that the truncation argument depends on, and cites the Internet-Draft that already chains agent audit records over RFC 8785 bytes. Results unchanged.
+Version 2, September 30, 2026: Adds the missing citation to Crosby and Wallach's tamper-evident history trees (USENIX Security 2009). Results unchanged.
+Version 1, September 27, 2026: Adds the rerun, a later-revision probe result, a comparison with prior logging systems in place of the filing notes, and corrected patent and RFC references.
+Revises a manuscript dated September 4, 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 2
+Technical report / Version 3
OPAQUE Systems
-TRACE (Trust, Runtime Attestation, and Compliance Evidence) proposes a portable record for claims about AI agent runtimes: workload identity, model, policy, data class, tool transcript, build provenance, and appraisal. It composes RATS/EAT, signatures, and transparency evidence into a format that a relying party can evaluate against its own trust policy. A valid signature establishes integrity and possession of the signing key; hardware origin additionally requires verified attestation and a binding from that evidence to the key. This technical report describes the original design and preserves the recorded software evaluation of agentrust-trace 0.2.0 and trace-tests 0.2.0. The evaluation measures canonicalization, Ed25519 signing and verification, record size, and fixture outcomes. It does not measure silicon certificate-chain appraisal or establish that the recorded runtime claims are true. The current normative specification and its implementation limits are maintained separately.
TRACE (Trust, Runtime Attestation, and Compliance Evidence) proposes a portable record for claims about AI agent runtimes: workload identity, model, policy, data class, tool transcript, build provenance, and appraisal. It composes RATS/EAT, signatures, and transparency evidence into a format that a relying party can evaluate against its own trust policy. A valid signature establishes integrity and possession of the signing key; hardware origin additionally requires verified attestation and a binding from that evidence to the key. This technical report describes the original design and preserves the recorded software evaluation of agentrust-trace (trace-spec revision 523f8cc, whose signing code is release 0.3.0) and trace-tests 0.2.0. The evaluation measures canonicalization, Ed25519 signing and verification, record size, and fixture outcomes. It does not measure silicon certificate-chain appraisal or establish that the recorded runtime claims are true. The current normative specification and its implementation limits are maintained separately.
A portable format for runtime claims, with recorded measurements of signing, verification, record size, and conformance fixtures.
The source package preserves the recorded inputs and results. No new experiment run or independent replication is claimed for this edition.
+The source package preserves the recorded inputs and results. The benchmark was rerun at the identified revisions and at current main on October 1, 2026; the report keeps the original numbers. 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.
Rishabh Poddar; Aaron Fulkerson; Imran Siddique. TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance). AgenTrust technical report, version 2, 2026.
-Download BibTeX / Download CITATION.cff
@techreport{agentrust2026trace,
+Cite this report
Rishabh Poddar; Aaron Fulkerson; Imran Siddique. TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance). AgenTrust technical report, version 3, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026trace,
title = {TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)},
author = {Rishabh Poddar and Aaron Fulkerson and Imran Siddique},
institution = {AgenTrust},
year = {2026},
type = {Technical report},
- note = {Version 2; not peer reviewed},
- doi = {10.5281/zenodo.23024103},
- url = {https://agentrust-io.com/research/trace/v2/}
+ note = {Version 3; not peer reviewed},
+ url = {https://agentrust-io.com/research/trace/v3/}
}
Version history
Version 2, September 28, 2026: Corrects the related-work statement that transparency-log registration makes omitted events detectable, which contradicted the conclusion, and removes three en dashes. Results unchanged.
+Version history
Version 3, October 1, 2026: Corrects the identification of the evaluated SDK and five bibliography entries, narrows the conformance-module descriptions, states that the evaluated vectors use the v0.1 profile URI, fixes the install command and restores bold and italic type. Results unchanged.
+Version 2, September 28, 2026: Corrects the related-work statement that transparency-log registration makes omitted events detectable, which contradicted the conclusion, and removes three en dashes. Results unchanged.
Version 1, September 27, 2026: Clarifies the signature and hardware-evidence boundary, corrects the description of saved conformance outcomes, and preserves the historical measurements.
Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
-File checksums. Published version files are retained; substantive revisions receive a new version.
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.
Version 2, September 28, 2026: Corrects the related-work statement that transparency-log registration makes omitted events detectable, which contradicted the conclusion, and removes three en dashes. Results unchanged.
+Version 3, October 1, 2026: Corrects the identification of the evaluated SDK and five bibliography entries, narrows the conformance-module descriptions, states that the evaluated vectors use the v0.1 profile URI, fixes the install command and restores bold and italic type. Results unchanged.
+Version 2, September 28, 2026: Corrects the related-work statement that transparency-log registration makes omitted events detectable, which contradicted the conclusion, and removes three en dashes. Results unchanged.
Version 1, September 27, 2026: Clarifies the signature and hardware-evidence boundary, corrects the description of saved conformance outcomes, and preserves the historical measurements.
Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
File checksums. Published version files are retained; substantive revisions receive a new version.
Version 2, September 28, 2026: Corrects the related-work statement that transparency-log registration makes omitted events detectable, which contradicted the conclusion, and removes three en dashes. Results unchanged.
+Version 3, October 1, 2026: Corrects the identification of the evaluated SDK and five bibliography entries, narrows the conformance-module descriptions, states that the evaluated vectors use the v0.1 profile URI, fixes the install command and restores bold and italic type. Results unchanged.
+Version 2, September 28, 2026: Corrects the related-work statement that transparency-log registration makes omitted events detectable, which contradicted the conclusion, and removes three en dashes. Results unchanged.
Version 1, September 27, 2026: Clarifies the signature and hardware-evidence boundary, corrects the description of saved conformance outcomes, and preserves the historical measurements.
Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
File checksums. Published version files are retained; substantive revisions receive a new version.
Technical report / Version 3
+OPAQUE Systems
+TRACE (Trust, Runtime Attestation, and Compliance Evidence) proposes a portable record for claims about AI agent runtimes: workload identity, model, policy, data class, tool transcript, build provenance, and appraisal. It composes RATS/EAT, signatures, and transparency evidence into a format that a relying party can evaluate against its own trust policy. A valid signature establishes integrity and possession of the signing key; hardware origin additionally requires verified attestation and a binding from that evidence to the key. This technical report describes the original design and preserves the recorded software evaluation of agentrust-trace (trace-spec revision 523f8cc, whose signing code is release 0.3.0) and trace-tests 0.2.0. The evaluation measures canonicalization, Ed25519 signing and verification, record size, and fixture outcomes. It does not measure silicon certificate-chain appraisal or establish that the recorded runtime claims are true. The current normative specification and its implementation limits are maintained separately.
A portable format for runtime claims, with recorded measurements of signing, verification, record size, and conformance fixtures.
The source package preserves the recorded inputs and results. The benchmark was rerun at the identified revisions and at current main on October 1, 2026; the report keeps the original numbers. 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.
Rishabh Poddar; Aaron Fulkerson; Imran Siddique. TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance). AgenTrust technical report, version 3, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026trace,
+ title = {TRACE: Trust, Runtime Attestation, and Compliance Evidence (A Portable Attestation Format for AI Agent Runtime Governance)},
+ author = {Rishabh Poddar and Aaron Fulkerson and Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 3; not peer reviewed},
+ url = {https://agentrust-io.com/research/trace/v3/}
+}
+Version 3, October 1, 2026: Corrects the identification of the evaluated SDK and five bibliography entries, narrows the conformance-module descriptions, states that the evaluated vectors use the v0.1 profile URI, fixes the install command and restores bold and italic type. Results unchanged.
+Version 2, September 28, 2026: Corrects the related-work statement that transparency-log registration makes omitted events detectable, which contradicted the conclusion, and removes three en dashes. Results unchanged.
+Version 1, September 27, 2026: Clarifies the signature and hardware-evidence boundary, corrects the description of saved conformance outcomes, and preserves the historical measurements.
+Based on a manuscript originally dated June 23, 2026, with later recorded experiments. That manuscript date is not presented as a verified publication date.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 1
+Technical report / Version 2
OPAQUE Systems
-Deploying proprietary model weights into infrastructure controlled by a customer reverses the usual confidential-computing trust problem: the model builder, rather than the infrastructure owner, supplies the secret. Existing confidential-computing stacks can attest workloads and release secrets, while model-signing systems authenticate model artifacts. Neither capability alone specifies continuing custody of a particular weight artifact after release. This technical report describes the Weight Custody Manifest (WCM), a vendor-neutral protocol and conformance model that binds an exact weight digest, an approved workload measurement, attestation policy, a fresh transport key, renewable authorization, terminal refusal and wipe evidence, and derivative lineage. WCM distinguishes cryptographic custody against software adversaries from accountability-grade controls when the infrastructure operator physically owns the machine. The evaluated Python reference implementation, version 0.28.0, supplies 91 portable conformance vectors across four levels. Its test suite produced 618 passing tests and three skips on September 3, 2026, and the same counts when rerun at the same commit for this edition. Two later findings bound those results: a published advisory showed that the evaluated key broker did not require GPU confidential-compute mode before release, and the SEV-SNP platform used for the hardware run does not enable the ciphertext hiding that the cryptographic-custody claim against a hypervisor-privileged operator requires. The contribution is a portable artifact-to-runtime custody contract with explicit lifecycle evidence, derivative accountability, and conformance, not a new attestation primitive or a certification of any deployment.
Deploying proprietary model weights into infrastructure controlled by a customer reverses the usual confidential-computing trust problem: the model builder, rather than the infrastructure owner, supplies the secret. Existing confidential-computing stacks can attest workloads and release secrets, while model-signing systems authenticate model artifacts. Neither capability alone specifies continuing custody of a particular weight artifact after release. This technical report describes the Weight Custody Manifest (WCM), a vendor-neutral protocol and conformance model that binds an exact weight digest, an approved workload measurement, attestation policy, a fresh transport key, renewable authorization, terminal refusal and wipe evidence, and derivative lineage. WCM distinguishes cryptographic custody against software adversaries from accountability-grade controls when the infrastructure operator physically owns the machine. The evaluated Python reference implementation, version 0.28.0, supplies 91 portable conformance vectors across four levels. Its test suite produced 618 passing tests and three skips on September 3, 2026, and the same counts when rerun at the same commit for this edition. Later findings bound those results. The evaluated key broker compared the approved workload measurement with an unsigned evidence field rather than the signed report, and did not require GPU confidential-compute mode before release; both are fixed in later releases. The SEV-SNP platform used for the hardware run does not enable the ciphertext hiding that the cryptographic-custody claim against a hypervisor-privileged operator requires. The contribution is a portable artifact-to-runtime custody contract with explicit lifecycle evidence, derivative accountability, and conformance, not a new attestation primitive or a certification of any deployment.
A portable custody contract binding exact weights, measured workload, fresh channel-bound release, renewable authority, terminal evidence and derivative lineage.
The source package preserves the recorded inputs and results. The software results were rerun at the evaluated commit for this edition; the hardware runs were not repeated. No independent replication is claimed.
+The source package preserves the recorded inputs and results. The software results were rerun at the evaluated commit on September 27 and October 1, 2026; the hardware runs were not repeated. 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.
Imran Siddique. Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights. AgenTrust technical report, version 1, 2026.
-Download BibTeX / Download CITATION.cff
@techreport{agentrust2026weightcustodymanifest,
+Cite this report
Imran Siddique. Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights. AgenTrust technical report, version 2, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026weightcustodymanifest,
title = {Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights},
author = {Imran Siddique},
institution = {AgenTrust},
year = {2026},
type = {Technical report},
- note = {Version 1; not peer reviewed},
- doi = {10.5281/zenodo.23020644},
- url = {https://agentrust-io.com/research/weight-custody-manifest/v1/}
+ note = {Version 2; not peer reviewed},
+ url = {https://agentrust-io.com/research/weight-custody-manifest/v2/}
}
Version history
Version 1, September 27, 2026: Adds a post-evaluation findings section, corrects the descriptions of the three skipped tests and of the memory-sweep receipt, fixes two citations, and records a software rerun at the evaluated commit.
+Version history
Version 2, October 1, 2026: Adds the verification defects fixed in WCM 0.28.5 and 0.29.0, attributes the SEV-SNP attestation break to Battering RAM rather than BadRAM, states that sealed release is a broker setting, and restores bold and italic type. Software rerun with the same counts.
+Version 1, September 27, 2026: Adds a post-evaluation findings section, corrects the descriptions of the three skipped tests and of the memory-sweep receipt, fixes two citations, and records a software rerun at the evaluated commit.
Revises a manuscript dated September 3, 2026.
-File checksums. Published version files are retained; substantive revisions receive a new version.
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.
Version 1, September 27, 2026: Adds a post-evaluation findings section, corrects the descriptions of the three skipped tests and of the memory-sweep receipt, fixes two citations, and records a software rerun at the evaluated commit.
+Version 2, October 1, 2026: Adds the verification defects fixed in WCM 0.28.5 and 0.29.0, attributes the SEV-SNP attestation break to Battering RAM rather than BadRAM, states that sealed release is a broker setting, and restores bold and italic type. Software rerun with the same counts.
+Version 1, September 27, 2026: Adds a post-evaluation findings section, corrects the descriptions of the three skipped tests and of the memory-sweep receipt, fixes two citations, and records a software rerun at the evaluated commit.
Revises a manuscript dated September 3, 2026.
File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Technical report / Version 2
+OPAQUE Systems
+Deploying proprietary model weights into infrastructure controlled by a customer reverses the usual confidential-computing trust problem: the model builder, rather than the infrastructure owner, supplies the secret. Existing confidential-computing stacks can attest workloads and release secrets, while model-signing systems authenticate model artifacts. Neither capability alone specifies continuing custody of a particular weight artifact after release. This technical report describes the Weight Custody Manifest (WCM), a vendor-neutral protocol and conformance model that binds an exact weight digest, an approved workload measurement, attestation policy, a fresh transport key, renewable authorization, terminal refusal and wipe evidence, and derivative lineage. WCM distinguishes cryptographic custody against software adversaries from accountability-grade controls when the infrastructure operator physically owns the machine. The evaluated Python reference implementation, version 0.28.0, supplies 91 portable conformance vectors across four levels. Its test suite produced 618 passing tests and three skips on September 3, 2026, and the same counts when rerun at the same commit for this edition. Later findings bound those results. The evaluated key broker compared the approved workload measurement with an unsigned evidence field rather than the signed report, and did not require GPU confidential-compute mode before release; both are fixed in later releases. The SEV-SNP platform used for the hardware run does not enable the ciphertext hiding that the cryptographic-custody claim against a hypervisor-privileged operator requires. The contribution is a portable artifact-to-runtime custody contract with explicit lifecycle evidence, derivative accountability, and conformance, not a new attestation primitive or a certification of any deployment.
A portable custody contract binding exact weights, measured workload, fresh channel-bound release, renewable authority, terminal evidence and derivative lineage.
The source package preserves the recorded inputs and results. The software results were rerun at the evaluated commit on September 27 and October 1, 2026; the hardware runs were not repeated. 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.
Imran Siddique. Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights. AgenTrust technical report, version 2, 2026.
+Download BibTeX / Download CITATION.cff
@techreport{agentrust2026weightcustodymanifest,
+ title = {Weight Custody Manifest: Portable, Attestation-Gated Custody for Proprietary Model Weights},
+ author = {Imran Siddique},
+ institution = {AgenTrust},
+ year = {2026},
+ type = {Technical report},
+ note = {Version 2; not peer reviewed},
+ url = {https://agentrust-io.com/research/weight-custody-manifest/v2/}
+}
+Version 2, October 1, 2026: Adds the verification defects fixed in WCM 0.28.5 and 0.29.0, attributes the SEV-SNP attestation break to Battering RAM rather than BadRAM, states that sealed release is a broker setting, and restores bold and italic type. Software rerun with the same counts.
+Version 1, September 27, 2026: Adds a post-evaluation findings section, corrects the descriptions of the three skipped tests and of the memory-sweep receipt, fixes two citations, and records a software rerun at the evaluated commit.
+Revises a manuscript dated September 3, 2026.
+File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
{esc(q["origin"])}
\n' if q.get('origin') else '' evidence = q.get('evidence_note', 'No new experiment run or independent replication is claimed for this edition.') + # Code outside a public GitHub repository (a reference implementation in the source package) + # has no issue tracker of its own; corrections then go to the organization's public tracker. + on_github = q['code'].startswith('https://github.com/') + code_label = 'Project code' if on_github else 'Reference implementation' + issues = q['code'] + '/issues' if on_github else 'https://github.com/agentrust-io/.github/issues' + spec = (f'Read the current specification and implementation guidance. This report describes an earlier design and evaluation; the current specification governs implementation.
' + if q.get('spec') else 'No separate specification exists for this mechanism. The reference implementation in the source package is the implementation guidance.
') rows=''.join(f'Version {h["version"]}, {human_date(h["date"])}: {esc(h["changes"])}
\n' for h in reversed(history)) body=f'''Technical report / Version {n}
@@ -121,15 +128,15 @@ def paper_page(p, v=None):{esc(q['abstract'])}
{esc(q['contribution'])}
The source package preserves the recorded inputs and results. {esc(evidence)}
-Read the current specification and implementation guidance. This report describes an earlier design and evaluation; the current specification governs implementation.
{esc('; '.join(q['authors']))}. {esc(q['title'])}. AgenTrust technical report, version {n}, 2026.
Download BibTeX / Download CITATION.cff
{esc(citation(q))}File checksums. Published version files are retained; substantive revisions receive a new version.
Open an issue in the project repository and identify the report version and section.
Open an issue in the {'project repository' if on_github else 'AgenTrust public issue tracker'} and identify the report version and section.