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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -82,6 +83,7 @@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.
@@ -82,6 +83,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -82,6 +83,7 @@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.
@@ -82,6 +83,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@A shutdown command, a signed refusal and the absence of subsequent effects are different observations. We examine those distinctions using the merged cMCP gateway kill switch and its accompanying policy-key and delegation revocation mechanisms. A reproducible evaluator drives gateway startup, signed agent identity, Cedar evaluation, loopback HTTP tool calls, durable blocks, process restart, recovery and offline receipt verification. The reference run satisfies 27 named assertions. Two targeted implementation weakenings are detected at their intended assertions. Separately, 81 existing cMCP component tests and 38 cA2A revocation tests pass on pinned source revisions. The observed system refuses new tool work through the stopped gateway and retains its block after restart. An admitted call can nevertheless finish during shutdown, a direct tool path can produce an effect while the gateway is stopped, and a historical refusal still verifies after recovery. These counterexamples establish the limits of treating a signed receipt as evidence of continuing or universal shutdown. We propose an evaluator protocol that separates admission, effects, persistence, recovery and freshness, with an explicit role for independent observation. The exercise uses software keys, one operator and no model or confidential hardware.
An evaluator protocol that separates admission, drain, persistence, recovery and evidence at a tool gateway, with counterexamples to reading a signed refusal as proof of continuing shutdown.
The source package preserves the recorded inputs and results. The author repeated every run on September 27 and October 1, 2026 in fresh environments at the pinned revisions. An independent evaluation is under way and will be reported in version 2.
@@ -80,6 +81,7 @@A shutdown command, a signed refusal and the absence of subsequent effects are different observations. We examine those distinctions using the merged cMCP gateway kill switch and its accompanying policy-key and delegation revocation mechanisms. A reproducible evaluator drives gateway startup, signed agent identity, Cedar evaluation, loopback HTTP tool calls, durable blocks, process restart, recovery and offline receipt verification. The reference run satisfies 27 named assertions. Two targeted implementation weakenings are detected at their intended assertions. Separately, 81 existing cMCP component tests and 38 cA2A revocation tests pass on pinned source revisions. The observed system refuses new tool work through the stopped gateway and retains its block after restart. An admitted call can nevertheless finish during shutdown, a direct tool path can produce an effect while the gateway is stopped, and a historical refusal still verifies after recovery. These counterexamples establish the limits of treating a signed receipt as evidence of continuing or universal shutdown. We propose an evaluator protocol that separates admission, effects, persistence, recovery and freshness, with an explicit role for independent observation. The exercise uses software keys, one operator and no model or confidential hardware.
An evaluator protocol that separates admission, drain, persistence, recovery and evidence at a tool gateway, with counterexamples to reading a signed refusal as proof of continuing shutdown.
The source package preserves the recorded inputs and results. The author repeated every run on September 27 and October 1, 2026 in fresh environments at the pinned revisions. An independent evaluation is under way and will be reported in version 2.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -82,6 +83,7 @@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.
@@ -82,6 +83,7 @@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.
@@ -80,6 +81,7 @@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.
@@ -80,6 +81,7 @@