From 26155f3a744bb81f5e062024d2c5b57c1c85c28d Mon Sep 17 00:00:00 2001 From: Carlos Hernandez-Vaquero Date: Wed, 17 Jun 2026 22:27:50 +0200 Subject: [PATCH] docs: define external execution evidence verification --- CHANGELOG.md | 5 +++++ LIMITATIONS.md | 3 +++ spec/trace-v0.1.md | 35 +++++++++++++++++++++++++++++++++++ 3 files changed, 43 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index c4f87c5..5bc686f 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -47,6 +47,11 @@ Seven open questions requiring founding-member input before v0.2 are documented Previously `^spiffe://` only; now `^(spiffe://|did:)`. Additive, backward-compatible. DID-native runtimes (e.g. AGT `did:mesh:` identities) no longer require a parallel SPIFFE identity. Closes: microsoft/agent-governance-toolkit ADR-0032, agentrust-io/trace-spec#35. +- Add verification guidance for optional external execution evidence bound by + profile-specific audit-chain entries. A verifier may check controller-signed + receipts when configured with the issuer trust anchor; otherwise the receipt + is unverified addenda and does not affect core Trust Record validity. + Closes: agentrust-io/trace-spec#34. ### Schema diff --git a/LIMITATIONS.md b/LIMITATIONS.md index 1acfd2e..0e12b61 100644 --- a/LIMITATIONS.md +++ b/LIMITATIONS.md @@ -16,6 +16,9 @@ The `policy.bundle_hash` field attests that a specific policy was in force at ru **What happened inside the model** The call transcript records tool invocations, arguments, and responses that are observable at the gateway boundary. It does not record the model's internal chain-of-thought, intermediate reasoning, or context window contents. Reasoning that influences behavior without producing a tool call is not captured. +**Physical execution or functional safety** +TRACE can bind optional downstream evidence, such as a controller-signed receipt attached by a cMCP audit-chain profile. That proves only that a trusted external issuer signed the receipt for the bound call. It does not prove that a physical action occurred, completed successfully, or satisfied functional-safety standards. + **Cross-boundary data propagation** The call graph summary uses temporal adjacency to approximate data flow between tool calls. It cannot definitively prove which specific data from one tool response influenced which subsequent call. The `provenance_disclaimer` field in every call graph summary is required for this reason. diff --git a/spec/trace-v0.1.md b/spec/trace-v0.1.md index c7406b3..0b92404 100644 --- a/spec/trace-v0.1.md +++ b/spec/trace-v0.1.md @@ -90,6 +90,7 @@ TRACE does not protect against: - TEE side-channel attacks (cache, timing, speculative execution, power analysis). - Compromise or coercion of a silicon root vendor or transparency log operator. - Model behavior — prompt injection, jailbreaks, hallucination, alignment drift. TRACE proves what executed and which countermeasures were in force; it does not adjudicate whether the model's output was correct. +- Physical execution or functional-safety compliance. A profile MAY bind evidence from an independent downstream authority, such as a safety controller, but TRACE does not itself prove that a physical action occurred, completed successfully, or satisfied any industrial safety standard. - Availability and denial-of-service. - UX-layer attacks against the human in the loop. @@ -211,6 +212,40 @@ Any party — browser, CLI, in-cluster verifier, third-party auditor — verifie No callback to the issuer. No vendor in the trust path beyond silicon root and transparency log operators. +#### 3.3.1 External execution evidence + +Some profiles bind gateway-observed tool calls to evidence produced by an +independent downstream authority. For example, the cMCP reference +implementation can attach `external_execution_evidence` to an audit-chain entry +when an independent safety controller signs a receipt for a specific MCP call. +That receipt is distinct from the gateway-produced Trust Record and from +`tool_transcript.hash`: the gateway commits to the audit chain, and the +independent authority signs its own statement about one call. + +External execution evidence is OPTIONAL. A Trust Record without such evidence +remains valid if the ordinary verification steps above succeed. A verifier that +does not possess a trust anchor for the external issuer MUST treat a present +receipt as unverified addenda, not as a Trust Record failure. A deployment +profile MAY require a particular external issuer as an additional policy check, +but that requirement is outside the core TRACE validity rule. + +When a verifier is configured with an external issuer trust anchor, it verifies: + +1. The receipt is bound to the intended audit entry, for example by checking + `linked_call_id` against the entry `call_id`. +2. The issuer key identifier resolves to a trusted issuer public key under the + deployment's PKI or trust-anchor policy. +3. The issuer signature verifies over the canonical receipt with the signature + field absent. Unless the profile declares otherwise, canonicalization is RFC + 8785 (JCS). +4. The receipt's `evidence_hash` and `evidence_type` satisfy the profile's + documented computation and registry for that evidence type. + +Verifying external execution evidence establishes only that the trusted +external issuer signed the receipt bound to that call. It does not transform +TRACE into proof of physical execution, successful completion, functional-safety +certification, or regulatory compliance for the downstream system. + ### 3.4 Scope TRACE governs any confidential workload — AI agent execution, regulated data processing, sovereign compute, secure multi-party computation. AI agents are the forcing function and the first reference profile, not the limit of the standard.