how it works

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.

Six surfacesOne primitiveOne verification pathOffline verification
Surface 01 of 06

API call

A metered response you can hold onto. The API answers, and the answer carries its own signed evidence.

what happens

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.

the record binds
  • 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.
actors: agent client, api.vendor.example
agent clientapi.vendor.example
GET /reports/q3
200 OK - PEAC-Receipt: eyJhbG...
record issued: resource + request/response digests + policy bound
verified offline - by any party - years later - no vendor login
It said something different yesterday

A response edited after the fact fails the bound digest. The record freezes what was actually served.

Metering and usage disputes

Each call yields its own receipt. Usage claims reconcile against signed records, not counters in one side's database.

Those were not the terms

The policy digest pins the exact published terms in force at call time.

Surface 02 of 06

MCP tool run

Every tool call, signed at the source, carried inside the protocol's own metadata. No changes required.

what happens

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.

the record binds
  • 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"].
actors: mcp host (agent), tool server
mcp host (agent)tool server
tools/call - search_flights { args }
result - _meta carries the signed record
record binds tool name + args digest + result digest + manifest ref
prove which tool, which inputs, which output, per call
Silently swapped tools

If the tool definition changes, new calls bind a different manifest ref. Drift becomes visible and datable.

Altered results downstream

A result modified after the run fails its bound digest even though the signature still verifies.

Which agent did what

Per-call records with issuer, time, and trace correlation reconstruct the run without server logs.

Surface 03 of 06

Agent action

Approvals that bind. Actions that chain. An agent's run becomes a verifiable sequence, not a story.

what happens

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.

the record binds
  • 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.
actors: agent, approver (human or policy)
agentapprover (human or policy)
proposal - digest A (sha256:9c41...)
approval record - binds digest A
execute - must bind digest A
records linked: approved to invoked - parent_jti chain
proposal changed? digest B not equal to A: denied record - fail closed
every action ran exactly as approved, or it did not run
Approval reused for a different action

The modified action hashes to a different digest, so verification fails and the flow emits a denial instead.

Silent extra actions

The run summary seals a record count and a Merkle root. An absent record is detectable, not deniable.

Delegation disputes

Delegated-observed records with delegation chain context show who handed work to whom.

Surface 04 of 06

Gateway decision

The decision is the evidence. Allow, deny, redact: each one signed, reasoned, and provable.

what happens

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.

the record binds
  • 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.
actors: app / agent, gateway, recipient
app / agentgatewayrecipient
content produced - sha256:7f3a...
policy check - pii detected: redact - reason: pii_email
delivered redacted - sha256:e01b...
decision record - allow + redact - policy digest - produced not equal to delivered
prove what left the boundary without revealing it
The gateway never blocked it

A signed deny with a reason code and timestamp settles what was refused, and when, and why.

Redaction disputes

The produced and delivered digest pair proves content was changed in transit, and exactly which bytes were delivered.

Which policy version applied

The policy digest pins it without publishing the policy itself.

Surface 05 of 06

Payment event

The money moves on the rail. The evidence moves with you: offer, payment, delivery, acknowledgment.

what happens

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.

the record binds
  • 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.
actors: buyer agent, seller api
buyer agentseller api
GET /dataset
402 - signed offer
payment settles on the rail, not on PEAC
200 - content + settlement receipt
payment record - preserves offer + receipt artifacts - 12.50 USD
counterparty acknowledgment links back - each record verifies offline
Paid but denied, or served but unpaid

Offer, settlement, and delivery records make each leg separately provable. The classic 402 dispute pair dissolves.

Double charge and replay

Unique ids plus the bounded replay guard classify a re-presented record as replayed, not fresh.

We never received it

A delivery digest, and the counterparty's own acknowledgment record, answer it with signatures, not assertions.

Surface 06 of 06

Provisioning event

What the agent stood up, on the record, with secrets structurally excluded.

what happens

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.

the record binds
  • 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.
actors: agent, cloud provider
agentcloud provider
create service account + api key
created - secret: sk_live_9f2...
redaction: secret never captured, reference + digest only
credential-observed record - account / resource / budget trail
prove the lifecycle, never the secret
Shadow infrastructure

Resources an agent quietly stood up appear in the observed trail with issuer and time: discoverable, datable, attributable.

Secrets leaking through audit logs

Impossible by construction here: the schema rejects captured material before anything is signed.

Who created this account

Issuer, delegation context, and the linked action chain answer it without grepping provider logs.

What v0.16.2 adds

Broader evidence coverage, same wire format.

PEAC v0.16.2

Portable evidence beyond single signed records: the wire format stays stable while evidence coverage broadens.

Paid resource recordsPaid MCP tool recordsLinked counterparty acknowledgmentsMerkle commitment helpersExternal evidence anchoringAgent spend attributionAgent run lineage recordsConsented action recordsRuntime lineage exports

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

Logs stay local. Signed records travel.