Six surfaces. One primitive.
The same signed record structure covers every surface where an agent or automated system acts: one verification path for all of it. Each section below shows what happens, what the record binds, and the failure mode it closes.
API call
A metered response you can hold onto. The API answers, and the answer carries its own signed evidence.
A client, human app, or agent calls an API. The response returns with a signed record in the PEAC-Receipt header: same request, same wire, one extra header. The publisher's terms live at /.well-known/peac.txt, and the record binds a digest of the policy that was in force at the moment of the call.
- resource + method
- request digest
- response digest
- policy digest
- issuer + key id
- time + unique id
Later, anyone can prove: This exact response was served for this exact request, under this exact policy, without the vendor's logs, dashboard, or cooperation.
carrier: PEAC-Receipt header. discovery: /.well-known/peac.txt.A response edited after the fact fails the bound digest. The record freezes what was actually served.
Each call yields its own receipt. Usage claims reconcile against signed records, not counters in one side's database.
The policy digest pins the exact published terms in force at call time.
MCP tool run
Every tool call, signed at the source, carried inside the protocol's own metadata. No changes required.
An agent host calls a tool over the Model Context Protocol. The tool result returns with the record tucked into _meta, a standard MCP extension point, so hosts that do not know PEAC simply ignore it. A separately signed tool-definition manifest pins what the tool was, meaning its name, schema, and version, when it ran.
- tool name
- canonicalized args digest
- result digest
- tool-manifest ref
- trace correlation
- issuer + time
Later, anyone can prove: Which tool version ran, what it received, and what it returned. Per call, offline, across host and server boundaries.
carrier: _meta["org.peacprotocol/receipt_ref"] and _meta["org.peacprotocol/receipt_jws"].If the tool definition changes, new calls bind a different manifest ref. Drift becomes visible and datable.
A result modified after the run fails its bound digest even though the signature still verifies.
Per-call records with issuer, time, and trace correlation reconstruct the run without server logs.
Agent action
Approvals that bind. Actions that chain. An agent's run becomes a verifiable sequence, not a story.
An agent proposes an action, and a human or policy approves it. The approval record binds exactly one proposal digest. The execution record must bind that same digest. If the action changed after approval, the flow emits a denied record and fails closed. Every step links to the previous one, building a per-run lineage chain.
- proposal digest
- approval to execution link
- parent_jti / depends_on
- delegation chain
- outcome kind
- run summary + count
Later, anyone can prove: The action that executed was byte-for-byte the action approved, who delegated to whom, and that the run chain is complete: nothing added, nothing missing.
types: agent-action-approved, -invoked, -denied, -delegated, -cancelled, -timed-out, -observed.The modified action hashes to a different digest, so verification fails and the flow emits a denial instead.
The run summary seals a record count and a Merkle root. An absent record is detectable, not deniable.
Delegated-observed records with delegation chain context show who handed work to whom.
Gateway decision
The decision is the evidence. Allow, deny, redact: each one signed, reasoned, and provable.
Traffic passes a gateway or guardrail: an AI proxy, an MCP gateway, an egress filter. The gateway decides to allow, deny, or route to review, and sometimes redacts on the way through. PEAC records the decision facts: the outcome, a reason code, the digest of the policy that applied, and two content digests, one for what was produced and one for what was delivered.
- decision (allow/deny/review)
- reason code
- policy digest
- produced-content digest
- delivered-content digest
- trace correlation
Later, anyone can prove: The gateway applied a specific policy and delivered something different from what was produced, provable without revealing either content. A signed refusal is evidence too.
types: org.peacprotocol/access-decision. extension: org.peacprotocol/access.A signed deny with a reason code and timestamp settles what was refused, and when, and why.
The produced and delivered digest pair proves content was changed in transit, and exactly which bytes were delivered.
The policy digest pins it without publishing the policy itself.
Payment event
The money moves on the rail. The evidence moves with you: offer, payment, delivery, acknowledgment.
An agent hits a paid resource and gets a 402 response with a signed offer. Payment settles on the rail, such as x402, Stripe, or paymentauth, never on PEAC. The seller then issues a record that preserves the rail's own signed artifacts alongside the amount and the delivery digest. The counterparty can add a linked acknowledgment record.
- rail + amount_minor + currency
- offer artifact (preserved)
- settlement receipt digest
- delivery digest
- acknowledgment triple
- issuer + time + jti
Later, anyone can prove: What was offered, what was paid, and what was delivered: the exact dispute triangle. Replay-guarded, bundle-exportable, and verifiable offline.
types: org.peacprotocol/payment. extension: org.peacprotocol/commerce. rails: x402, Stripe, paymentauth, ACP, UCP, AP2.Offer, settlement, and delivery records make each leg separately provable. The classic 402 dispute pair dissolves.
Unique ids plus the bounded replay guard classify a re-presented record as replayed, not fresh.
A delivery digest, and the counterparty's own acknowledgment record, answer it with signatures, not assertions.
Provisioning event
What the agent stood up, on the record, with secrets structurally excluded.
An agent provisions real infrastructure: accounts, resources, credentials, budgets, subscriptions, and deployments. Each event becomes an *-observed record. The critical property is that credential material is never captured. The schema itself rejects secret values, so the record carries a reference and a digest, and a leak through the evidence layer is structurally impossible. See provisioning records.
- event kind (10 observed kinds)
- provider / account refs
- resource refs
- credential ref, never value
- budget / subscription deltas
- issuer + time
Later, anyone can prove: Every account, resource, credential, and budget an agent created, changed, or removed: the anti-shadow-infrastructure trail, without a single secret in the evidence.
extension: org.peacprotocol/provisioning-lifecycle. kinds: catalog, account, resource, credential, budget, subscription, deployment, and more.Resources an agent quietly stood up appear in the observed trail with issuer and time: discoverable, datable, attributable.
Impossible by construction here: the schema rejects captured material before anything is signed.
Issuer, delegation context, and the linked action chain answer it without grepping provider logs.
Broader evidence coverage, same wire format.
Portable evidence beyond single signed records: the wire format stays stable while evidence coverage broadens.
Broader evidence coverage, not a new payment rail, gateway, or policy engine.
Generate these yourself in one command.
pnpm dlx @peac/cli samples generate -o ./s pnpm dlx @peac/cli verify ./s/valid/basic-record.jws --public-key ./s/bundles/sandbox-jwks.json
Signature valid (offline) - PEAC v0.16.2