Clear deployment and verification boundaries.
Review current key-custody, network, data, retention, telemetry, supply-chain, and support boundaries. Every claim links to the artifact that backs it.
Relevant for AI agent workflows, APIs, MCP systems, enterprise reviews, and any workflow where verification must survive beyond the original vendor boundary.
What runs where, and who holds what.
| Open source | Supported self-host | |
|---|---|---|
| Where it runs | Your infrastructure | Your infrastructure |
| Key custody | You. Local or your KMS. | You. Local or your KMS. |
| Interaction data | Processed in your environment (self-hosted) | Processed in your environment (under agreement) |
| Support | Community (GitHub) | Under agreement |
| Verification | Offline, no callback | Offline, no callback |
Originary does not host verification, custody keys, or store your records. Anything not listed here is not offered. Verification never requires Originary to be online in any mode.
Answers your review team will ask for.
| Procurement fact | Current position |
|---|---|
| Hosting mode | Self-hosted. The software runs in your infrastructure; Originary operates no hosted verification service. |
| Key custody | Yours. The issuer generates and holds its Ed25519 keys locally or in your KMS. Originary never holds signing keys. |
| Data processed by Originary | None from verification, which runs in your environment. Website only: consent-gated analytics and what you send through the contact form. |
| Retention | Website data is kept only as long as needed for the stated purpose and legal obligations, then deleted or anonymized. |
| Subprocessors | Processors for hosting, payments, and support under contractual safeguards. Some support operations are performed by an India affiliate under SCCs and DPAs. |
| Data residency | Not applicable to verification, which never leaves your environment. Website processing may occur outside your country with the safeguards described in the privacy policy. |
| Certifications held | None. No SOC 2, ISO 27001, or comparable third-party audit has been completed, and none is claimed. |
| SLA and support | No SLA on the open-source protocol; support there is community-based via GitHub. Support scope and response commitments apply only where set out in a written agreement. |
| Incident process | Report to security@originary.xyz. Reports are acknowledged within 5 business days and triaged by severity. |
| Responsible contact | security@originary.xyz for security, privacy@originary.xyz for data requests, contact@originary.xyz for everything else. |
| Evidence | The security page, the privacy policy, and the public repository at github.com/peacprotocol/peac. |
See also protocol mappings and AI compliance evidence. Each row states the current position rather than a roadmap commitment. If your review needs something not listed here, contact us and we will answer it directly.
What composes with PEAC, and how far it goes.
Each row states what actually exists in the open repository at v0.16.3. A shipped adapter or mapping is code you can read and run; a documented composition is a written mapping with conformance vectors; an example is a runnable demonstration. Nothing is listed without an artifact behind it.
| System | Status | Evidence in the repository |
|---|---|---|
| MCP | shipped_mapping | packages/mappings/mcp, packages/mcp-server, examples/mcp-gateway-receipts |
| x402 | shipped_adapter | packages/adapters/x402, examples/x402-paid-resource-records |
| OpenTelemetry | shipped_adapter | packages/telemetry-otel, docs/guides/telemetry-otel-correlation.md |
| A2A | shipped_mapping | packages/mappings/a2a, examples/a2a-gateway-pattern |
| MPP / paymentauth | shipped_mapping | packages/mappings/paymentauth, examples/mpp-payment-record |
| UCP | shipped_mapping | packages/mappings/ucp, examples/ucp-webhook-express |
| ACP | shipped_mapping | packages/mappings/acp, examples/acp-session-lifecycle |
| AP2 | documented_composition | docs/specs/AP2-COMPOSITION.md, specs/conformance/interop/ap2-open-mandate-hash |
| Stripe | documented_composition | docs/interop/SIGNED-RECORDS-INTEROP-MATRIX.md, integrator-kits/stripe-projects |
| Cloudflare | example | surfaces/workers/cloudflare, examples/cf-policy-x402-terms |
No partnership, certification, or endorsement is implied. These are interoperability surfaces PEAC composes with, not relationships with the organizations behind them. Product names, logos, and brands belong to their respective owners. Each row is verifiable at github.com/peacprotocol/peac, and the dated per-row detail lives in that repository's interop matrix.
Verification model
Every interaction record is a signed JSON Web Signature (JWS). When a record is issued, the issuer signs the claims payload with their private key. Any verifier, your code, a third-party auditor, or an offline script, can verify the signature using the issuer's published public key.
Verification does not call Originary. After issuer key resolution, records can be verified locally or offline according to the verifier's cache, expiry, and revocation policy. In explicit-resolution mode the verifier retrieves the issuer's published JWKS once, only when the caller authorizes it, then validates signatures locally; strict offline mode takes a supplied key and performs no network request. If the issuer is temporarily unreachable, verifiers may use previously cached public keys. The signed record carries the fields needed to confirm what happened, when, and who attested to it.
What a verified record does and does not establish.
Verification checks the record's structure, signature, issuer information, and bound digests against the supplied verification material.
Verification does not independently prove that every relevant real-world event was captured, that the issuer's statements were truthful, or that an underlying system correctly enforced its policy.
Cryptography and key management
PEAC uses Ed25519, a widely deployed modern signature scheme standardized in RFC 8032. Keys are compact (32-byte public keys) and verification is fast.
You bring your own keys. Generate and store signing keys under infrastructure you control, using an Ed25519-compatible KMS or HSM where appropriate. In the current self-hosted workflow, Originary does not receive or store private signing keys. Issuers distribute public keys through infrastructure they control or out of band; the documented Originary verification flow uses a public key supplied by the verifier.
Portability and offline verification
Signed records are standard JWS tokens. They are not stored in a proprietary database or locked to an Originary account. You can export them, archive them, move them between systems, or store them in your own infrastructure. Any conforming JOSE implementation can check the Ed25519 signature; full PEAC validation also checks the PEAC record profile, required fields, and applicable semantic constraints.
Offline verification works by design. Once you have the issuer's public key (from their JWKS endpoint or cached locally), you can verify any record without network access. There is no license server, no token refresh, and no API call required to confirm a signature.
The PEAC protocol is designed for multiple independent implementations. Your records are not tied to Originary's software. Any conformant implementation can issue, verify, and process the same records.
Data handling boundaries
Originary's tooling operates locally by default. The signing libraries, verification functions, and protocol SDK run in your environment. They do not send interaction data, record contents, or business payloads to Originary servers.
- Private signing keys
- Interaction payloads and business data
- Record contents and claims
- Verification results and decisions
- Public keys (JWKS endpoint)
- Issuer configuration (peac-issuer.json)
- Policy metadata (peac.txt)
- Signed records you choose to share
Originary does not run a hosted verification service, dashboards, or record storage. If you engage Originary for a scoped pilot or supported self-host, data handling for that engagement is covered in our Privacy Policy.
Responsible disclosure
If you discover a security vulnerability in the PEAC protocol, any Originary product, or this website, please report it to security@originary.xyz. We acknowledge reports within 5 business days and coordinate fixes before public disclosure.
Our machine-readable security policy is published at /.well-known/security.txt per RFC 9116. The PEAC protocol repository accepts security reports through GitHub Security Advisories.
Legal identity and stewardship
Originary™ is the software and developer-tools brand of Poem, Inc., a Delaware corporation. Originary publishes and maintains PEAC Protocol, not its gatekeeper. The protocol specification, reference implementation, conformance suite, and all core tooling are published under the Apache-2.0 license.
Stewardship means we maintain the specification, publish test vectors, and ensure interoperability. It does not mean we control who can implement, extend, or build on the protocol. Anyone can build a conformant implementation without permission, payment, or partnership with Originary.
The protocol is designed to reach 1.0 with multiple independent implementations. Our goal is a standard that outlasts any single company, including ours.
Resources and policies
Direct links to policies, specifications, verification endpoints, and corporate information.
Security
Responsible disclosure policy and security reporting guidelines.
Protocol
PEAC protocol specifications and AI preference frameworks.
Verification
Tools and services for signature validation and evidence verification.
Legal
Terms, privacy policy, and compliance documentation.
Security architecture
How the system is built to keep your data and keys safe.
Portability
Export and interoperability guarantees for your records and keys.
Questions about security, compliance, or verification?
contact@originary.xyz