PEAC: Policy-backed Environment for Agent Coordination
A protocol for cryptographic receipts proving policy compliance, payment, and attribution in machine-to-machine interactions.
Abstract
This document specifies the PEAC Protocol, an open standard for issuing and verifying cryptographic receipts that prove policy compliance in AI agent interactions, API access, and data consumption.
PEAC receipts are Ed25519-signed JSON Web Signatures (JWS) that encode claims about access permissions, payment status, attribution requirements, and regulatory compliance. The protocol defines discovery via well-known policy files, negotiation flows, and receipt verification procedures.
Status of This Document
This is a working draft. The wire format peac.receipt/0.9 is frozen across the v0.9.x series. Breaking changes will only occur in v1.0, which requires multi-implementation consensus.
Table of Contents
1. Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119.
- Receipt
- A cryptographically signed attestation of a completed transaction or policy evaluation.
- Issuer
- The entity that creates and signs receipts. Identified by the
issclaim. - Verifier
- Any party that validates receipt signatures and claims.
- Policy
- A machine-readable declaration of access terms, published at
/.well-known/peac.txt. - PaymentEvidence
- Structured proof of payment including rail, amount, currency, and optional facilitator.
- Attestation
- A generic third-party claim attached to a receipt (e.g., risk assessment, compliance check).
2. Wire Format
PEAC receipts are encoded as JWS Compact Serialization (RFC 7515) with detached payload option available. The receipt MUST be transmitted via the PEAC-Receipt HTTP header.
PEAC-Receipt: <base64url(header)>.<base64url(payload)>.<base64url(signature)>
Header (REQUIRED):
{
"alg": "EdDSA", // MUST be EdDSA
"typ": "peac.receipt/0.9", // MUST be this value
"kid": "peac-2025-12" // Key identifier
}
Payload (REQUIRED fields):
{
"iat": 1735500000, // Unix timestamp (seconds)
"iss": "https://api.example.com",
"amt": 100, // Amount in minor units
"cur": "USD", // ISO 4217 currency
"payment": { // Payment evidence
"rail": "x402",
"facilitator": "daydreams"
}
}Wire Schema (v0.9.21+)
JSON Schema definitions are available at specs/wire/ with Ajv 2020-12 validation and conformance fixtures.
3. Policy Discovery
Agents MUST attempt to fetch policy from these locations in order:
/.well-known/peac.txt(primary)/peac.txt(fallback)
The policy file uses YAML format with the following structure:
version: "peac-policy/0.1"
rules:
- id: allow-licensed
match:
subject_type: [agent, organization]
purpose: [train, inference]
licensing_mode: licensed
decision: allow
receipts: required
- id: allow-crawl
match:
purpose: [crawl, index, search]
decision: allow
- id: deny-unlicensed-training
match:
purpose: [train]
licensing_mode: unlicensed
decision: deny4. Receipt Structure
| Claim | Type | Status | Description |
|---|---|---|---|
| iat | number | REQUIRED | Issued-at timestamp (Unix seconds) |
| iss | string | REQUIRED | Issuer URI |
| amt | number | RECOMMENDED | Amount in minor units (cents) |
| cur | string | RECOMMENDED | ISO 4217 currency code |
| payment | PaymentEvidence | OPTIONAL | Payment evidence with rail and facilitator |
| attestations | Attestation[] | OPTIONAL | Third-party attestations (v0.9.21+) |
| extensions | Extensions | OPTIONAL | Namespaced extension fields (v0.9.21+) |
| prov | object | OPTIONAL | Provenance metadata (C2PA, etc.) |
| aud | string | OPTIONAL | Intended audience |
5. Verification Procedure
Verifiers MUST perform these steps in order:
- Parse JWS: Decode base64url header and payload. Reject malformed tokens.
- Validate header: Confirm
algis “EdDSA” andtypis “peac.receipt/0.9”. - Fetch JWKS: Retrieve public key from issuer's
/.well-known/jwks.jsonmatchingkid. - Verify signature: Validate Ed25519 signature over
header.payload. - Check timestamp: Reject if
iatdiffers from current time by more than 5 minutes. - Validate evidence: Ensure
payment.evidencecontains only JSON-safe values (no NaN, Infinity, cycles).
6. Conformance Levels
- -Parse /.well-known/peac.txt
- -Understand version field
- -Honor usage directive
- -Return proper status codes
- -Use Problem Details (RFC 9457)
- -Include PEAC-Receipt header
- -Enforce rate limits
- -Validate purposes
- -Check attribution requirements
- -Support HTTP 402 flow
- -Issue valid receipts
- -Verify payment evidence
Conformance Harness (v0.9.21+)
The protocol includes a conformance test suite with valid, invalid, and edge-case fixtures. See specs/wire/ for the JSON Schema definitions and test vectors.
7. Evidence & Attestations
PEAC v0.9.21 introduces generic Attestation and Extensions types for extensible evidence attachment.
{
"attestations": [{
"type": "risk_assessment",
"issued_at": 1735500000,
"issuer": "https://risk.example.com",
"data": {
"score": 0.95,
"level": "low"
}
}],
"extensions": {
"acme/tracking_id": "abc123",
"vendor/metadata": { "key": "value" }
}
}Evidence Validation
All evidence fields MUST contain JSON-safe values only. The protocol rejects NaN, Infinity, object cycles, and class instances at issuance time. DoS caps apply: maxDepth (32), maxArrayLength (10k), maxObjectKeys (1k), maxStringLength (64KB), maxTotalNodes (100k).
8. Security Considerations
Key Management
Issuers MUST rotate keys regularly. The kid field enables graceful key rotation. Old keys SHOULD remain in JWKS for verification of existing receipts.
Replay Protection
Verifiers SHOULD implement nonce tracking or timestamp windows to prevent receipt replay attacks. TAP (Trusted Agent Protocol) enforces an 8-minute maximum time window.
JWKS Fetch Security
JWKS endpoints MUST be served over HTTPS. Verifiers MUST validate TLS certificates and SHOULD implement SSRF protections including literal IP blocking.
Fail-Closed Defaults
ISSUER_ALLOWLIST is REQUIRED (500 if empty). Unknown TAP tags are rejected by default. Replay protection is required when nonce is present.
9. Telemetry & Observability
PEAC v0.9.22 introduces telemetry hooks in the issue() and verify() functions with privacy-preserving modes.
Strict Mode
Hash all identifiers. Requires hashSalt. Maximum privacy.
Balanced Mode
Include rail + amounts. Hash sensitive fields. Recommended default.
Custom Mode
Allowlist-based field inclusion. Full control over what is emitted.
import { createOtelProvider } from '@peac/telemetry-otel'
const provider = createOtelProvider({
tracer,
meter,
privacyMode: 'balanced'
})
// Automatically emits spans and metrics
const { jws } = await issue({ ...claims, telemetry: provider })