Agents cross boundaries.
Logs don't.
PEAC defines portable signed records for API calls, MCP tool runs, agent actions, gateway decisions, provisioning workflows, and commerce observations.
Systems issue records when work happens. Customers, operators, auditors, and partner systems can verify those records independently without seeing internal logs or trusting a central authority.
How it works
/.well-known/peac.txtPEAC-Receipt: eyJ...verifyLocal(record, key)What you have vs. what PEAC adds
Essential debugging and visibility inside your system boundary.
Distributed traces and metrics. The standard for internal observability.
Signed, portable records any party can verify without seeing internal logs. No central authority.
Why PEAC exists
When systems disagree, logs are not neutral.
Your API has logs.
Your customer has logs.
The agent runtime has traces.
The gateway has events.
The payment rail has its own state.
The auditor sees screenshots.
PEAC gives the interaction a portable signed record
A record that can be verified outside the system that produced it. Both sides hold the same artifact. No central authority arbitrates the truth.
Protocol flow
How PEAC works
Publish verification metadata
Expose policy, issuer, key, and verification metadata where clients and verifiers can find it.
/.well-known/peac.txtIssue a signed record
Attach a signed interaction record to an API response, MCP tool result, gateway decision, provisioning action, or commerce observation.
PEAC-Receipt: eyJ...Verify independently
Any party can verify issuer keys, signatures, timestamps, audience, expiry, typed claims, and evidence references.
verifyLocal(record, key)Export evidence
Package records, policy snapshots, keys, and verification output for audit, dispute review, incident reconstruction, or handoff.
peac bundle verifyProtocol scope
What PEAC standardizes
PEAC stays narrow. It standardizes portable signed records and the verification surfaces around them.
Record format
A portable signed representation of an observed interaction.
Claims and extensions
Typed fields for access, commerce, identity, provenance, lifecycle, provisioning, and other domain-specific evidence.
Verification
Local verification of signatures, issuer keys, timestamps, audience, expiry, typed claims, and evidence references.
Discovery
A predictable way to publish policy and verification metadata where clients and verifiers can find it.
Carriers
Conventions for carrying records through HTTP headers, MCP metadata, A2A messages, gateway events, and evidence bundles.
Conformance
Fixtures, requirement IDs, and verification behavior that keep implementations aligned across runtimes and languages.
Complementary by design
Where PEAC fits
PEAC adds proof where logs stop. It works beside the systems teams already use.
Debug and operate one system from the inside.
Correlate traces and metrics across services.
Identify callers and control access.
Coordinate tools, agents, and agent-to-agent exchanges.
Authorize, capture, and settle funds.
Create services, credentials, projects, and runtime configuration.
PEAC complements each system above without replacing it.
Start here
Add records where verification matters first.
Start with one boundary. An API response, MCP tool call, gateway event, provisioning workflow, or local verifier is enough.
Use cases
Records for work that crosses systems.
API records
Return signed records with API responses so customers can verify what happened without seeing your logs.
MCP tool records
Attach verifiable records to tool responses so agents and operators can inspect the same artifact.
Agent action records
Preserve signed evidence for delegated work, approvals, denials, lifecycle events, and runtime handoffs.
Gateway export records
Record gateway decisions and export evidence without turning PEAC into the gateway or policy engine.
Provisioning evidence
Record observed project setup, credential sync, resource creation, and provider workflow evidence without storing secrets.
Commerce observations
Bind signed records to upstream commerce artifacts while preserving strict boundaries around authorization, capture, refund, and settlement.
What PEAC is not
PEAC is useful because it stays narrow. It records and verifies observed interactions. It does not become the runtime around them.
Current release
v0.14.4: Composition Surfaces
Active development, pre-1.0. The core record format, verification behavior, and TypeScript packages are stable for integration work.
Public surface
What v0.14.4 added
Composition recipes, runtime composition examples, edge verification guidance, Go middleware parity work, and a committed-fixture .NET quickstart verifier.
PEAC is pre-1.0, but the core record format, verification behavior, conformance fixtures, and TypeScript packages are stable enough for integration work.
Common questions
Who is PEAC for?
Developers, protocol implementers, API providers, agent builders, gateway teams, platform teams, and auditors who need portable proof of what happened across system boundaries.
Does PEAC replace logs or OpenTelemetry?
No. Logs and traces remain essential inside your system. PEAC adds a signed record that another party can verify independently, without seeing your internal observability stack.
Does PEAC replace auth?
No. Auth decides who can act. PEAC records what happened and what claims were made about the interaction after access was granted.
Does PEAC handle payments?
No. Payment rails authorize, capture, and settle funds. PEAC can record commerce observations only when the upstream artifact supports the claimed event. It does not synthesize finality.
Does verification require Originary or a hosted service?
No. PEAC records can be verified locally with issuer keys or bundled verification artifacts. No central authority is required.
Is PEAC production-ready?
PEAC is pre-1.0. The record format, verification behavior, conformance fixtures, and core TypeScript packages are stable enough for integration work. Library APIs may still evolve. The current release is v0.14.4 with 290 conformance requirements across 32 sections.
Production-ready standard
Portable proof that survives
organizational boundaries.
290 conformance requirements. Deterministic offline verification. No central authority, no vendor lock-in. Both sides hold the same signed artifact: verifiable independently, usable in audit, dispute, and incident review.
Apache-2.0. Deploy on your infrastructure. Integrate at any boundary: API, MCP, agent, gateway, provisioning, or commerce.