PaperlayerView exact revision on arXiv

Source-linked AI summary

PCM: A Proof-Carrying Message Protocol for Verifiable Multi-Agent Communication

Bravish Ghosh

arXiv:2610.39109v1cs.CEcs.AIcs.CRcs.MA

TL;DR

Receivers in multi-agent systems often have only the sender's word for claims, while channel authentication does not verify what happened. PCM carries independently checkable evidence and narrowing authority chains; on a benchmark of 712 lies, it accepts 10, all involving stale evidence.

  • Problem

    Agent-message protocols authenticate communication but do not let receivers independently verify what the sender claims happened.

    Source: §1 · p. 2

  • Method

    PCM attaches signed records from an append-only log the agent cannot write, which receivers check offline alongside person-rooted grant chains that can only narrow.

    Source: §1 · p. 2, §15 · p. 41

  • Results

    PCM accepts 10 of 712 lies (1.4%; 95% CI 0.8–2.6%), all stale-evidence cases, while two independent verifiers agree on all 926 verdicts.

    Source: §1 · p. 4

  • Takeaways & Limitations

    PCM separates doubt from falsity: a claim the verifier cannot establish remains testimony rather than becoming proof or being treated as false.

    Source: §15 · p. 41

    The evaluation used one machine, an in-process signer and executor, local HTTP hosts, and specification-based protocol models rather than their SDKs.

    Source: §12.8 · p. 37

Abstract

from arXiv · show

When one AI agent tells another that "the tests passed" or "a person approved this refund", the receiver has only the sender's word. A2A and MCP authenticate the channel, but the sender is the party in doubt, so a prompt-injected agent can launder fabricated facts and authority through a multi-agent system. We present Proof-Carrying Messages (PCM), a protocol in which each claim carries evidence: records from an append-only Merkle log that the agent cannot write, with inclusion proofs, signed by an attesting signer the agent cannot control. Receivers check messages offline and give each claim a three-valued result: proven, unproven or failed. A claim that rests only on the agent's own report is never proven. Authority travels as grant chains rooted in a recorded human approval, and the chains can only narrow. We specify four claim types, a typed caveat algebra, replay rules that survive restarts, and strict readings that make independent verifiers agree, and we prove the resulting security properties. On a pre-specified benchmark of 926 messages from real runs, 712 of them lies in 16 classes, PCM accepts 10 lies, all of them stale evidence (1.4%, 95% CI 0.8-2.6%). Plain A2A accepts all 712, and models of six deployed protocols (A2A with signed Agent Cards, uAgents, RFC 9421, SCITT, AP2, Verifiable Intent) accept 504-712. Two independent verifiers agree on all 926 verdicts, and verification takes about 1 ms.

1 Introduction

PCM addresses the gap between authenticating who sent a message and verifying what the sender claims happened. It carries signer-backed evidence and authority chains for independent checking, while distinguishing uncertainty from falsity.

The problem

  • A2A and MCP standardize agent messaging, but leave receivers without a way to independently verify claims about what the sender did.Authenticating the channel does not establish a sender's claims when the sender is the party in doubt.Source: §1 · p. 2

Our approach

  • PCM attaches cryptographic evidence of events recorded by a party other than the agent, checked offline by receivers as proven, unproven, or failed.The signer controls keys and records tool calls in an append-only Merkle log; messages carry records with inclusion proofs.Source: §1 · p. 2
  • Grant chains root in a named person's approval of exact terms, and each later link can only narrow the authority it inherits.The signer checks delegations before signing, and the receiver checks the full chain.Source: §1 · pp. 2–3

Contributions

  • PCM specifies four claim types, typed caveats, restart-safe replay rules, strict deterministic readings, and proofs of security properties.Its benchmark uses 926 messages from real signer runs, including 712 lies in 16 classes labelled from ground truth.Source: §1 · p. 3

Headline results

  • 10 of 712 lies (1.4%; 95% CI 0.8–2.6%) are accepted by PCM, all due to stale evidence; two independent verifiers agree on all 926 verdicts.The other 702 lies are rejected (626) or flagged accept-unproven (76); deployed-protocol models accept 70.8–100% of the lies.Source: §1 · p. 4

Limitations

  • PCM does not make a compromised agent honest or prove that a claim still holds; the signer remains part of the trusted computing base.The evaluation attributes every remaining error to these stated limits.Source: §1 · p. 4

2 Background

The background situates PCM among agent protocols, transparency logs, canonicalization methods, and capability systems. These provide relevant mechanisms, but do not by themselves supply PCM's independent checking of sender claims.

Agent protocols

  • A2A and MCP carry agent messages and tool interactions, but neither lets a receiver independently check what the sender did.ANP authenticates requests and addresses replay, while AP2 and Verifiable Intent carry signed purchase mandates.Source: §2 · p. 4

Transparency logs

  • Certificate Transparency uses append-only Merkle logs and signed checkpoints, while witnesses can make inconsistent log histories detectable.SCITT generalizes transparency logs to signed statements about supply-chain artefacts.Source: §2 · p. 4

Canonical JSON

  • JCS maps JSON values to unique byte strings, allowing PCM implementations that parse the same value to hash and sign the same bytes.Source: §2 · p. 5

Capability tokens

  • Macaroons, Biscuit, and UCAN support offline attenuation through caveats, with the delegating party holding the attenuation key.Biscuit expresses caveats and policies in Datalog.Source: §2 · p. 5

Proof-carrying code and provenance

  • Proof-carrying code shifts trust from an untrusted producer to a small checker, while SLSA says build platforms—not build steps—should generate provenance.PCM's T1/T2 distinction is described as the per-claim analogue of the SLSA principle.Source: §2 · p. 5

Running example

  • The running example pairs a $120 refund request with a person-approved grant capped at $200 for order 81, and an approval claim citing that approval.The amounts are represented as integer cents, and the example comes from a real signer conformance vector.Source: §2 · p. 5

3 System and Threat Model

PCM defines the parties and trust boundaries for checking claims, then states its adversary, goals, non-goals, and deployment assumptions. Its security depends on trusting the signer and attesting parties, not the sending agent.

3.1 Parties

  • A run is a session within a log, and the attesting signer binds it to a transport identity, stores events in an append-only Merkle log, and signs messages and grants.Receivers pin trusted log keys and keep replay state.Source: §3.1 · p. 5

3.2 Adversary

  • The adversary fully controls the sending agent and may compose claims, select evidence, report T1 results, replay messages, and write files accessible to the agent.It cannot control the signer, its keys or log, make attesting parties falsify reports, or impersonate a configured person to the signer.Source: §3.2 · pp. 5–6

3.3 Goals

  • PCM's goals include authentic message origin, evidence soundness, no self-attestation, attenuated authority, at-most-once delivery, deterministic verdicts, and honest progress.Source: §3.3 · pp. 6–7

3.4 Non-goals

  • PCM does not establish trustworthy agent intentions, current state, absence of undisclosed events, confidentiality, or safety against a compromised signer or leaked log key.Source: §3.4 · p. 7

3.5 Assumptions

  • The security model assumes sound cryptography, an honest signer and attesting parties, clocks aligned within the replay window, and shared replay state across receiver replicas.The signer is the trusted computing base and must be operationally separated from the agents it records.Source: §3.5 · p. 7

4 Protocol Overview

PCM routes tool activity through an attesting signer and sends signed messages with log evidence for offline verification. Its strict envelope, typed schemas, claim evidence, grants, and structured outcomes define how that verification proceeds.

4 Protocol Overview

  • The signer records tool calls, distinguishing agent-reported T1 results from executor- or gateway-attested T2 results, while observers record network effects.The signer signs messages and the receiver checks their evidence offline against pinned keys; the agent never holds a signing key.Source: §4 · p. 7, Figure 2 · p. 8

4.1 The envelope

  • PCM refuses malformed envelopes using strict JSON rules, including rejection of duplicate names, invalid timestamps, and integer fields encoded as non-integers.Source: §4.1 · p. 8

4.2 Intents and content-addressed schemas

  • An intent references a shared, typed schema by name and document hash, and argument matching permits no conversions or undeclared fields.Every non-optional field must be present.Source: §4.2 · pp. 8–9

4.3 Claims, evidence and grants at a glance

  • Claims use one of four typed forms and may carry log records with inclusion proofs; grants specify allowed intents and caveats in person-rooted chains.The closed message's signature binds its members, including evidence and grants, so nothing can be added after signing.Source: §4.3 · p. 9, Figure 3 · p. 9

4.4 Outcomes

  • The verifier returns a structured result: accept means required checks are proven, accept-unproven means nothing failed but some claim rests on the sender's word, and reject must not be acted on.The result also reports skipped checks, which make it an audit result rather than a basis for action.Source: §4.4 · p. 9

5 Formal Model of Claims and Verdicts

PCM formalizes what evidence a verifier may trust and how each claim maps to proven, unproven, or failed. Its rules constrain records, evidence, and message verdicts so the same inputs yield consistent results.

5.1 Notation and primitives

  • For signed objects, PCM uses Ed25519 and canonical JSON bytes with a protocol tag that cannot be supplied on the wire.Distinct message and grant tags prevent a signature under one tag from verifying under the other.Source: §5.1 · p. 10

5.2 Logs, records and evidence

  • A log is a signer-appended sequence of tenant- and run-scoped records; evidence binds records to a signed checkpoint with inclusion proofs.Evidence checks also bind records to the sender’s run and tenant and reject duplicate sequence numbers.Source: §5.2 · p. 10

5.3 Committed arguments and openings

  • Openings let a sender reveal only the arguments needed to check a claim while leaving other disclosed decisions hidden behind commitments.The commitment is verified against the opened arguments and salt.Source: §5.3 · p. 11

5.4 Who wrote a record: tiers

  • Attestation depends on who wrote a record: signer-written approval and observer records, or gateway T2 results, are attested; other tool results are T1.The verifier reads tier from signer-set top-level fields, not data the reporting agent can fill.Source: §5.4 · p. 11

5.5 Three-valued claim semantics

  • Only opened, non-denied decisions with identifiers can match; a claim is proven only when an attested T2 result reports success.A T1 result is the agent’s own report and yields unproven, while a non-successful result yields failed.Source: §5.5 · p. 12

5.6 Verdicts

  • A message is rejected for failed replay, schema, grant, or claim checks; otherwise unproven claims or unmet required types produce accept-unproven.Level 1 verifiers never prove claims, and claim results are independent of evidence-record order.Source: §5.6 · pp. 12–13

6 The Four Claim Types

PCM fixes four claim checkers that connect claims to specific evidence and deterministic matching rules. The rules reject ambiguous interpretations and distinguish missing or uncertain support from a proven event.

6 The Four Claim Types

  • PCM 0.1 fixes a closed vocabulary of four claim types, each with specified arguments, a checker, and conformance vectors for its outcomes.New types require corresponding schema arguments, exact checker rules, and vectors.Source: §6 · p. 13, Table 2 · p. 14

6.1 tests_passed: exactly one test command

  • A tests_passed claim requires an exact shell-command match and a command that qualifies as a test command, not merely a successful shell exit.PCM rejects shell operators and other characters that can make shell parsing differ from word splitting.Source: §6.1 · p. 13

6.2 approved_by: binding approval to what was decided

  • An approved_by claim requires linked approval, approval-request, and policy-decision records; covers additionally checks that the approval matches the request.The checker returns the approved tool and opened arguments as a conformance field.Source: §6.2 · pp. 14–15, Figure 4 · p. 15

6.3 reached_host: a connection, not an attempt

  • A reached_host claim can be proven by a positive egress observation or an attested matching HTTP call; an attempted or denied connection is insufficient.An HTTP error status also cannot be proven from the call record because the evidence profile records only ok.Source: §6.3 · p. 16

6.3.1 Canonical hosts

  • Hosts are compared in a single canonical form, and where specified readers disagree PCM leaves the host unparsed rather than matching it.IPv4 addresses must use four decimal octets without leading zeros.Source: §6.3.1 · pp. 16–17, Figure 5 · p. 16

6.4 file_written: whose path rules?

  • A file_written claim requires an opened Write call whose full content hashes to the claimed digest and whose path matches under the claim’s path rules.Relative claims fail; a relative path in the record can leave the match unproven because the working directory is not recorded.Source: §6.4 · p. 17

6.5 Tool placement as frozen protocol data

  • Tool placement comes from a frozen table of 54 names in six classes; an unlisted tool is unplaced and yields unproven.Argument shape does not determine a tool’s class.Source: §6.5 · p. 17

7 Grants: Person-Rooted, Attenuating Authority

PCM represents authority as person-rooted grants whose typed caveats constrain permitted intent arguments. Delegation and verification preserve those limits across the full grant chain.

7 Grants: Person-Rooted, Attenuating Authority

  • A grant specifies who may send which intent, under caveats and an expiry, and links to its issuer and parent.A root has no parent; a child records the hash of its signed parent.Source: §7 · p. 17

7.1 Typed caveats

  • Caveats constrain fields in the intent schema, with valid operators and values determined by each field’s type.The comparison rules require exact JSON type matches.Source: §7.1 · pp. 17–18

7.2 Narrowing: a sound implication table

  • The implication table is sound, so child caveats that narrow a parent restrict its satisfying arguments; narrowing is transitive.The table is deliberately conservative: bounds do not imply equality, keeping checks to table lookups rather than a solver.Source: §7.2 · pp. 18–19, Table 3 · p. 18

7.3 Root grants come from a person

  • A root grant exists only after a configured person approves its exact terms, with self-approval, expired terms, and other specified cases refused.The root expires no more than 24 hours after issuance, and a run that is held or quarantined cannot receive one.Source: §7.3 · p. 19

7.4 Delegation

  • A child grant needs no new approval, but the signer issues it only when the delegable, unexpired parent permits the caller and the child narrows it.The child cannot outlast its parent.Source: §7.4 · p. 19

7.5 Chain verification

  • Verifiers check every grant in the chain, including that each uses the message-signing key and that intent arguments satisfy every grant.PCM 0.1 has no revocation; grants remain valid until expiry, which is capped at 24 hours for roots.Source: §7.5 · pp. 19–20, Table 4 · p. 20

8 Verification, Replay and Conformance

PCM fixes strict signature and parsing rules, then verifies the envelope, recipient, replay state, schema, grants, and claims in a specified order. Replay protection is bounded and restart-aware; conformance levels and transport bindings define how implementations and deployments use the protocol.

8.1 Signatures and keys

  • One pinned Ed25519 key identifies each log, and PCM fixes signature and base64 validation to avoid small-order-key forgeries and alternate encodings.The signer sets message identity, timestamp, and nonce, and records each signed message in the sender’s run.Source: §8.1 · pp. 20–21

8.2 The verification algorithm

  • The verifier checks the envelope and signature before claims, checks recipient before replay, and spends nonces only after a valid schema check.Its specified order prevents claim processing for forged messages and leaves state unchanged for messages addressed elsewhere or failing schema validation.Source: §8.2 · p. 21, §8.1 · p. 21

8.3 Replay in bounded memory, across restarts

  • Replay state is bounded per sender; arrival-order eviction raises a persistent floor, while a fresh state rejects messages timestamped before its creation.A receiver needs shared replay state across replicas; grant expiry uses the signer-set timestamp, so replay checks are required before acting.Source: §8.3 · pp. 21–22

8.4 Conformance levels and test vectors

  • Level 1 checks message structure and grants while marking evidenced claims unproven; Level 2 adds evidence verification and claim checkers.The 187 conformance vectors specify expected outcomes, including a raw-text parse-error case.Source: §8.4 · p. 22, Table 5 · p. 22

8.5 Transport bindings and versioning

  • PCM messages can be carried as an A2A part, an MCP resource, or an HTTP body, while closed objects and wire-version binding constrain interpretation.The transport bindings are drafts; confidentiality is left to TLS.Source: §8.5 · pp. 22–23

9 Security Analysis

The security analysis formalizes PCM’s guarantees under stated assumptions, including message origin, evidence soundness, authority attenuation, and replay protection. It also catalogs semantic attacks and identifies the signer as a trusted component whose compromise remains consequential.

9.1 Domain separation

  • Message, grant, and checkpoint signatures use disjoint byte-string domains, preventing a signature for one object type from being reused as another.Strict parsing and canonical encodings support the separation.Source: §9.1 · p. 23

9.2 Origin and evidence

  • A valid message signature authenticates the exact body as signed by the honest log signer for the registered run, with the signer choosing the message ID, timestamp, and nonce.Evidence inclusion proofs establish that records were appended to the sender’s run; valid openings bind committed arguments.Source: §9.2 · pp. 23–24
  • Agent-only T1 tool reports cannot prove claims; proving tool outcomes requires qualifying signer-attested records, while approval claims require linked approval evidence.The result depends on who set the evidence fields, not merely who signed the message bytes.Source: §9.2 · p. 24
  • A proven approval claim binds a configured person’s approval to the actual decision and either the root grant’s exact terms or the intent’s schema-defined tool and arguments.The linkage uses approval and decision identifiers, with committed arguments checked against the message intent.Source: §9.2 · p. 24

9.3 Authority

  • A valid grant chain is rooted in a configured person’s approval, and each delegation narrows permitted arguments and expiry while preserving intent, tenant, and sender constraints.All 11 benchmark grants deliberately re-signed to model a signer bug were rejected.Source: §9.3 · pp. 24–25

9.4 Delivery

  • With a replay window and shared receiver state, each sender’s message receives a non-reject verdict at most once, including across restarts.The theorem assumes the signer timestamp does not exceed the receiver clock at first receipt, with clock skew absorbed by the window.Source: §9.4 · p. 25

9.5 Attack catalogue

  • The attack catalogue highlights three recurring traps: identities are log-relative, agents choose names that must be mapped through trusted rules, and attempts do not establish outcomes.Table 6 condenses 29 attacks, mistakes, and trust assumptions.Source: §9.5 · p. 25, Table 6 · p. 26

9.6 Key compromise and the trusted computing base

  • The signer is trusted to authenticate records, and compromise of its shared log key can forge messages, grants, and checkpoints; checkpoint witnesses limit but do not eliminate that risk.The LLM, prompt, tool outputs, and planning code remain outside the TCB, but the verifier checks what the signer signed, not whether it was right.Source: §9.6 · pp. 25, 27

10 Determinism by Construction

PCM treats deterministic interpretation as a security property because parsers and libraries may disagree about message fields. It specifies strict readings and implementation mechanisms, and independently written verifiers agree on the final benchmark messages.

10.1 The strict-reading principle

  • For fields with potentially divergent readers, PCM proves a value only when all specified readers agree within a syntactically simple set; otherwise decisive external fields yield unproven.Sender-written malformed fields instead fail, and the specification gives fixed guidance for resending ambiguous values.Source: §10.1 · p. 27

10.2 Mechanisms

  • Determinism is implemented through closed strict parsing, stepwise reading rules, frozen and hashed protocol tables, and conformance checks on fields receivers act upon.Earlier library-dependent readings allowed verifiers to disagree or prove something false.Source: §10.1 · p. 27, §10.2 · p. 28
  • After adding the strict-number rule, two independently written verifiers agreed on verdict, reason class, and conformance fields for all 926 final-dataset messages.They had initially disagreed on 5 of 879 messages involving 1e400-style inputs; both also pass all 187 vectors.Source: §10.2 · p. 29

11 Implementation

The implementation includes a signer-backed protocol implementation, an independent verifier, generated specification artefacts, and documented implementation gaps.

Implementation

  • Tracekit 1.5.0 implements PCM 0.1 through signer calls for signing, grant issuance, delegation, and evidence retrieval.Its executor runs tool calls under signer custody and reports T2 results; signer timestamps are assigned when records are appended.Source: §11 · p. 29
  • The standalone pcm-verify 0.1.0 is an independent Level 2 verifier that ships the frozen tool table and tests against every vector.Its 556-test suite also checks specification and README examples tied to vectors; generated schemas and vectors are checked to keep prose aligned with implementation.Source: §11 · p. 29
  • Tracekit replay state is per process, so multi-replica receivers must route each sender to one replica; transport bindings remain drafts and its A2A gateway forwards without verification.Repeated grant requests can also mint grants differing only in timestamp until a pcm.grant call has returned.Source: §11 · p. 30

12 Evaluation: PCM-Lies

PCM accepted 10 of 712 lies, all involving stale evidence, while the remaining lies were rejected or flagged accept-unproven. The evaluation also tested honest progress, verifier agreement, protocol comparisons, benchmark-discovered bugs, cost, and validity boundaries.

12.1 Methodology

  • The 926-message benchmark used real Tracekit signer runs, event-based labels, and a pre-specified taxonomy of 16 lie classes.The design was a dated planning note without an independent public timestamp; six deployed-protocol receivers were added after results and were not covered by a hypothesis.Source: §12.1 · pp. 30–31, Table 8 · p. 31

12.2 RQ1: Safety

  • 10 of 712 lies were accepted, all involving stale evidence; the other 702 were rejected or flagged accept-unproven.PCM accepted zero lies in each of the six other reported scopes: claims, evidence, authority, delivery, encoding, and messages.Source: §12.2 · pp. 32–33, Figure 7 · p. 33

12.3 RQ2 and RQ3: Honest progress and no self-attestation

  • 76 of 78 honest claims were proven (97.4%), while all 72 T1-only claims were unproven; two honest fetches returning HTTP 404 were rejected.PCM was conservative on true encoding cases, accepting 5, flagging 12 accept-unproven, and rejecting 18.Source: §12.3 · p. 33

12.4 RQ4: Determinism

  • Two independent verifiers agreed on all 926 messages; median verification took 1.22 ms for Tracekit and 0.80 ms for the standalone verifier.Agreement covered verdicts, reason classes, and conformance fields, including raw-text messages handled by each verifier’s strict loader.Source: §12.4 · p. 34

12.5 RQ5: What existing protocols catch

  • The AP2, SCITT, and RFC 9421 stack still accepted 365 lies (51.3%; 95% CI 47.6–54.9%), as these checks do not tie every claim to records.Sender authentication, log inclusion receipts, and mandates each cover different checks, but do not jointly supply PCM’s claim-to-record rule.Source: §12.5 · pp. 34–35, Figure 8 · p. 34

12.6 Findings; 12.8 Threats to validity

  • PCM-Lies found three bugs, which were fixed in the specification and both verifiers; H1 and H2 remained unmet because their causes require format changes.External validity is bounded by one macOS machine, an in-process signer and executor, specification-based protocol models, and the chosen lie taxonomy.Source: §12.6 · p. 35, §12.8 · pp. 37–38

12.7 RQ6: Cost

  • A single-claim PCM message measured 4.2–6.1 KB at the median, and a three-claim message measured 11.7 KB; standalone verification took 0.80 ms median and 1.81 ms at p99.Single-claim messages were 7–13 times the size of the same request without proof; evidence production adds about one second waiting for a covering checkpoint.Source: §12.7 · pp. 35–36, Table 12 · p. 36, Figure 9 · p. 37

13 Discussion and Limitations

PCM 0.1 evidence shows that a call succeeded, but does not by itself establish that the result remains current. The discussion also bounds what proofs establish, what information they disclose, and where trust remains.

13.1 Evidence is not freshness

  • All 10 false accepts arise because existential evidence cannot show that nothing happened afterward; a later draft proposes chained run records and bound claims to address this.The proposed chain exposes later failures or writes; bound claims record the test tree or written file digest.Source: §13.1 · p. 38

13.2 A response is not a failure

  • An HTTP 404 counts as not ok in the 0.1 evidence profile, so honest reached_host claims fail; PCM 0.2 can record protocol status.An egress observer could establish that a connection occurred regardless of its response.Source: §13.2 · p. 38

13.3 Trust in the signer and in executors

  • PCM still depends on a trustworthy signer and executor: a compromised signer can mint claims, and a misclassified executor action could support a misleading tool claim.The specification forbids evidence-profile logs from recording a tool under a different tool class; a future trust member could let receivers pin attesters by class.Source: §13.3 · p. 38

13.4 What a proof does not say

  • A proven claim establishes only what its records support: a command exited 0, but not that the relevant tests ran or that no other call occurred.Receivers must compare the suite with accepted suites; an approved_by claim without covers may not match the current request.Source: §13.4 · pp. 38–39

13.5 Privacy

  • Receivers learn disclosed records and opened decision arguments, but not omitted records or unopened arguments; openings are permanent and attributable.Salts can expose low-entropy arguments to brute force, so senders should disclose only what each claim needs.Source: §13.5 · p. 39

13.6 Implications for LLM agent systems

  • PCM complements defenses against single-agent subversion by bounding what a subverted agent can make others believe; proposed integrations gate claims, check grants in code, and audit pipelines.A draft cache-transfer record can verify declared bytes, but not what the transferred state means.Source: §13.6 · p. 39

14 Related Work

Related work addresses evidence, authorization, agent security, and provenance from different points in the communication pipeline. PCM combines per-claim evidence with offline checks and authority rules.

Proof-carrying code and certified results

  • Unlike proof-carrying code, PCM’s “proof” is a signed record with an inclusion proof, so its assurance depends on trusting the signer; the approaches could compose.PCM borrows the producer-ships-evidence, consumer-checks-it structure of proof-carrying code.Source: §14 · p. 39

Transparency logs

  • Transparency-log inclusion alone does not bind a claim to an event or supply T1/T2, replay, or grant rules; PCM adds these semantics to similar evidence.SCITT checks that a signed statement is in a log, while Certificate Transparency provides the evidence-format reference.Source: §14 · p. 40

Capability-based authorisation

  • Capability systems support holder attenuation, whereas PCM grants are signer-checked, person-rooted, and narrowed using a fixed typed table rather than a general logic.PCM’s incomplete table trades expressiveness for identical verdicts across implementations; its claims about actions complement delegation credentials [32].Source: §14 · p. 40

Agent payment mandates

  • Authorization mandates such as AP2 and Verifiable Intent address whether a purchase was authorized, while PCM addresses what an agent did; their models miss lies about tests, hosts, and files.Proof-Gated Signing constrains what an agent may do, while PCM constrains what other agents believe it did [18].Source: §14 · pp. 40–41

Agent receipts and provenance

  • PCM turns provenance records into evidence checked per claim, with public-key verification and authority and delivery rules beyond audit-focused receipts.Tracekit [19] records sessions for audit; Notarized Agents [16] relies on service receipts; NabaOS [5] uses HMAC receipts; in-toto and SLSA concern supply-chain provenance.Source: §14 · p. 41

Cross-implementation disagreement

  • PCM treats cross-implementation agreement as a design requirement: divergent readings map to unproven and are pinned by test vectors.This responds to parser differentials documented across formats and implementations.Source: §14 · p. 41

15 Conclusion

The conclusion presents PCM as a way to make agents verify claims and authority offline rather than rely on the sender. The worked example and its variations illustrate message evidence, grants, and verdicts.

15 Conclusion

  • On 712 lies built from real runs, PCM accepts only the 10 that its specification says it cannot catch, while models of today’s deployed protocols accept between 504 and 712.Source: §15 · p. 41

A A Complete Worked Example

B Protocol Data

The appendices specify protocol data, outline a design for fresher evidence, describe receiver models, and catalogue conformance vectors.

B Protocol Data

  • The protocol data enumerates accepted test-runner command prefixes and tool-name classes; PCM 0.1 checkers use shell tools for tests_passed and HTTP tools for reached_host.The file_written checker reads only the Write tool.Source: B Protocol Data · pp. 46–47

C Design for Fresh Evidence

  • The fresh-evidence design chains every run record to a signer-set head, letting checkers inspect later calls; bound claims record the test tree or the written file’s path and digest.A later failing suite call can fail tests_passed, while later writes can fail or make file_written unproven.Source: C Design for Fresh Evidence · p. 48
  • The design costs about 1 KB per later record and does not cover suite runs in other runs, writes by other processes, or earlier flaky runs.A cap bounds how long after a call a sender can claim.Source: C Design for Fresh Evidence · p. 48

D Models of Real Protocols

  • The receiver-model appendix specifies Ed25519 keys derived from holder names and seeds, with receivers looking up public keys as their protocol specifies.Table 15 identifies the receiver models used in RQ5.Source: D Models of Real Protocols · p. 48, Table 15 · p. 49

E Conformance Vector Catalogue

  • The conformance catalogue groups 187 vectors by area and marks expected outcomes as accept, accept-unproven, reject, or bad-input.It includes tests_passed vectors and grant/delegation vectors.Source: E Conformance Vector Catalogue · pp. 48–50
Loading 2610.39109v1…