PEAC Protocol

Portable signed records for agent, API, MCP, and cross-runtime interactions.

Automated systems call APIs, run tools, make gateway decisions, initiate commerce flows, and provision resources across organizational boundaries.

PEAC lets those systems issue portable signed interaction records so another party can verify what the issuer reported, locally, offline, or across system boundaries, without relying only on screenshots or private logs.

Record locally. Verify across boundaries.

PEAC Protocol is open-source software published and maintained by Originary, with contributions from the community.

This repository contains the official source code, releases, and developer tooling distributed under the Apache-2.0 license.

Verify a record offline

Generate the shipped sample records, then verify one locally with the generated issuer key set. The verification step does not fetch keys or call a remote verifier. pnpm dlx may download the CLI if it is not already cached.

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

Expected:

Signature valid (offline).

• Compare verification paths: docs/guides/verification-options.md
• Wire PEAC into MCP, OpenTelemetry, or a gateway: docs/guides/integration-patterns.md
• Choose a starting point by role: docs/START_HERE.md

What PEAC records

A PEAC record is a signed statement about an interaction or challenge: what the issuing system reported, not an independently established fact.

These are orientation examples, not partnership claims or exclusive integration targets. PEAC records what those systems report; it does not replace them.

At a high level, PEAC records can preserve:

The required Wire 0.2 payload claims are peac_version, kind, type, iss, iat, and jti. The protected JWS header also carries the required signing and type-discrimination parameters, including alg, kid, and typ. Policy, occurred_at, actor, representation, pillars, and extensions are optional or profile-dependent. The normative envelope is defined in docs/specs/WIRE-0.2.md.

A counterparty can verify the record locally with the issuer's public key or through a self-hosted verifier. Records can also be exported into portable bundles for audit, review, dispute, or compliance workflows.

How it works

1. A system observes or reports an interaction
   API call, MCP tool run, agent action, gateway decision,
   payment event, or provisioning event

2. An issuer creates a signed PEAC record
   describing what that issuer reports about the interaction

3. A counterparty verifies the signature, structure, and accepted bindings
   locally, in CI, or through a self-hosted verifier, using the issuer's
   public key

4. The record travels
   audit review, dispute review, compliance workflow, incident
   report, exported bundle, or another system boundary

The issuer is the entity that signs the record. It may be the system that performed the work, an observer, a gateway, an adapter, or a runtime reporting an event; those roles stay separate.

Full loop: docs/HOW-IT-WORKS.md. Artifact vocabulary (record, receipt, bundle, report): docs/ARTIFACTS.md.

What PEAC does not do

PEAC does not authorize actions, validate credentials, process payments, settle transactions, operate agents, assign trust scores, or replace observability systems.

Full boundary, compared surface by surface: docs/WHERE-IT-FITS.md. Protocol scope: docs/WHAT-PEAC-STANDARDIZES.md.

Evidence workflows

Worked, offline-verifiable examples for common evidence shapes. Each adds no new wire format, schema field, or registry entry beyond what already ships. The PEAC records below preserve issuer-reported claims. Any linked payment, timestamp, transparency, or other external proof must also be evaluated under its own verification rules and trust model.