Skip to main content
RESEARCH

PEAC Protocol

Policy, Evidence, Attribution, and Consent - an open standard for verifiable agent interactions.

Abstract

PEAC (Policy, Evidence, Attribution, Consent) is a protocol for publishing interaction terms and issuing cryptographically verifiable receipts as durable evidence of what occurred under those terms. The protocol enables API providers to declare policies via discoverable policy files, issue signed receipts for each interaction, and support offline verification without centralized infrastructure. PEAC is designed for the agentic web - where autonomous software agents interact with APIs on behalf of users and organizations - requiring verifiable records of policy compliance, consent, attribution, and optional settlement.

Problem Framing

Current web infrastructure lacks a standardized mechanism for:

  • Policy discovery: No standard way for agents to discover what terms apply before accessing a resource
  • Verifiable evidence: No portable proof of what occurred during an interaction that survives beyond the session
  • Attribution binding: No cryptographic link between a resource access and the principal that authorized it
  • Consent signals: No machine-readable consent records for AI training, scraping, or commercial use
  • Rail-neutral settlement: HTTP 402 exists but lacks a standardized payload and verification mechanism

These gaps become critical as autonomous agents increasingly access APIs on behalf of users, enterprises, and other agents - requiring verifiable audit trails.

Design Goals

1.
Decentralized verification

Receipts verify offline using JWKS. No central authority required.

2.
Rail-neutral

Settlement is optional and adapter-based. PEAC works with any payment rail or none.

3.
Privacy-preserving

Identity can be pseudonymous. Receipts contain only what the issuer chooses to include.

4.
HTTP-native

Uses standard HTTP headers and status codes. No special transport required.

5.
Multiple implementations

Designed for independent implementations. No single vendor has privileged status.

Threat Model

PEAC assumes the following adversarial conditions:

  • Receipt forgery: Mitigated by Ed25519 signatures with issuer-controlled key rotation
  • Replay attacks: Mitigated by unique receipt IDs (jti) and timestamp validation (iat/exp)
  • Key compromise: Mitigated by JWKS key rotation and short-lived receipts
  • Policy tampering: Receipts bind to policy hash at issuance time; changes don't affect issued receipts
  • Denial of evidence: Receipts are portable and can be stored by any party for later verification

Limitations

  • PEAC does not enforce policy compliance - it provides evidence of what the issuer claims occurred
  • Receipt content is issuer-controlled; verifiers trust the issuer's representation
  • Network-level attacks (MITM) require TLS; PEAC operates at the application layer
  • Long-term key compromise invalidates receipts signed with that key (standard PKI limitation)
  • Dispute resolution is out of scope; PEAC provides evidence, not adjudication

Evaluation Plan

PEAC is currently at version 0.9.x (preview). Evaluation milestones before 1.0:

  • Multiple implementations: At least two independent, conformant implementations
  • Production deployment: Real-world usage across multiple API providers
  • Security audit: Independent security review of cryptographic components
  • Interoperability testing: Cross-implementation conformance validation

How to Cite

If you reference PEAC in academic work, please use:

@misc{peac2024, title = {PEAC: Policy, Evidence, Attribution, and Consent for Verifiable Agent Interactions}, author = {PEAC Protocol Contributors}, year = {2024}, url = {https://github.com/peacprotocol/peac}, note = {Open standard, Apache-2.0 license} }

Read the specification

Full protocol specification, test vectors, and reference implementation on GitHub.

View specificationConformance suite