Introduction
AI agents are becoming a new class of “user” on the internet. They browse, negotiate, pay, retrieve, transform, and act. They do it fast, at scale, and increasingly without a human watching each step.
That is not just a product shift. It is an infrastructure shift.
In the agent era, the core question stops being “Can the agent do the action?” and becomes:
- Should it have been allowed to do the action?
- Under what terms did it do the action?
- Who (or what) authorized it?
- Was it paid for?
- Can we prove it later without trusting a single vendor?
If we cannot answer those questions with durable evidence, the agent web either centralizes behind gatekeepers or collapses into disputes, fraud, and regulatory dead-ends.
What we need is an open system of record for agent interactions. Originary exists to build and steward that layer.
Built to interoperate
PEAC Protocol (Programmable Environment for Agent Coordination) is designed to sit above payment rails and alongside provenance and preference standards. It does not compete with x402/L402 or any single vendor's stack; it standardizes the evidence object that can reference those systems.
PEAC complements payment rails like HTTP 402 patterns and x402/L402, and works alongside standards like C2PA for provenance and AIPREF for AI preferences. The protocol provides the binding layer that creates verifiable proof across these systems.
“System of record” changes meaning in the agent era
In classic enterprise software, a system of record is where “truth” lives: customer data, transactions, inventories, ledgers.
In the agent era, the unit of truth is different.
It is not “a row in a database.” It is a verifiable interaction:
- what was requested
- what policy applied
- what consent preferences were active
- what was paid (if anything), via which rail
- what was returned
- what attribution/provenance obligations were asserted
- what identities were involved (without leaking private identity)
This is a system of record for decisions and actions, not just data.
And it must be interoperable across:
- different agent frameworks
- different payment rails (HTTP 402, x402/L402, Stripe-like flows, etc.)
- different network surfaces (origin, CDN, gateway, edge workers)
- different storage backends (centralized logs, SIEMs, data lakes, internal ledgers)
If it only works in one vendor's stack, it is not a system of record. It is a product feature.
Why agent interactions break today
The current internet was not designed for autonomous clients operating at machine speed. We built strong primitives for transport (HTTP), identity (TLS), and content addressing (URLs). But agent interactions introduce missing primitives:
1. Policy is not machine-enforceable by default
robots.txt was built for crawling. It is a binary allow/deny mechanism, not an economic and consent policy layer. Agents need “allow, but under these terms.”
Robots.txt says “stop/go.” A system of record needs “go, under this policy hash, with this entitlement/payment proof.”
2. Payment evidence is not naturally tied to access
Even when something is paid for, the proof is often separated from the request and the response. That separation creates disputes.
3. Audit trails are internal and non-portable
Logs help internally, but they are unilateral evidence: one party controls them, their schema varies, and their integrity is hard to prove externally. Receipts create portable, cryptographically verifiable evidence that can be checked by third parties.
4. Consent and preferences are not snapshotted
Agents act under user and enterprise constraints (privacy, retention, purpose limitations, jurisdictional requirements). Without a snapshot, you cannot prove what was agreed to at the time of access.
5. Provenance and attribution are ad hoc
Even when everyone wants “responsible AI,” the web lacks standard evidence objects linking content access to downstream usage and attribution.
In short: agents are arriving with no shared proof layer.
The requirements for a real system of record
A credible system of record for AI agents must meet requirements that are easy to say and hard to ship.
It must be open
If one company controls the format or the verifier, the market will fragment and the incentives will bend toward lock-in. Openness is what lets receipts remain meaningful across vendors.
It must be verifiable
Evidence cannot rely on “trust us.” It has to be cryptographically verifiable later, by third parties, without shared secrets.
It must be privacy-preserving
A system of record cannot become a surveillance layer. It should support selective disclosure and avoid embedding PII in proofs by default.
It must be neutral across rails and stacks
Agents will pay with different mechanisms. Providers will enforce at different layers. A system of record should unify evidence across these realities.
It must be cheap enough to be default
If proof adds massive latency or cost, it will only be used in high-stakes flows. The winning layer is the one that becomes routine.
Cryptographic receipts add overhead, so the format must be compact and the signing/verifying path must be implementable at the edge. PEAC is designed so implementations can optimize issuance (including optional delayed or batched issuance where appropriate) while keeping verification deterministic.
The model: policy + receipts
The simplest way to make the web auditable is to standardize two things:
- A discoverable policy file that tells agents what is allowed and under what terms.
- A cryptographic receipt returned with responses that proves what happened.
That is the heart of the PEAC Protocol (Programmable Environment for Agent Coordination), stewarded by Originary.
Policy: peac.txt
A site or API publishes a machine-readable policy at a well-known path (commonly /.well-known/peac.txt). The policy can express:
- access rules
- pricing and entitlements
- rate limits
- consent requirements
- attribution/provenance expectations
- negotiation or enterprise overrides
This shifts “terms” from PDFs into a format that agents can actually follow.
preferences: /.well-known/aipref.json
access_control: http-402
payments: [x402, stripe]
receipts: required
verify: /.well-known/jwks.json Receipts: PEAC-Receipt
When an agent makes a request, the server can return a receipt (typically via a header such as PEAC-Receipt) that contains a signed evidence object.
At minimum, a receipt is:
- tied to the request and response
- bound to the effective policy (usually via a policy hash)
- signed by the issuer so it can be verified later
Think of it as the missing primitive for the agent web: a portable, verifiable “event record” for access.
HTTP/1.1 200 OK
PEAC-Receipt: eyJhbGciOiJFZERTQSIsInR5cCI6...
Content-Type: application/jsonWhat does a receipt actually prove?
A well-designed receipt should let a verifier prove statements like:
- This response was issued by this service at this time.
- This request matched policy version X (or policy hash X).
- This access was allowed under the declared terms.
- If payment was required, payment evidence exists and is referenced.
- The response returned was associated with those terms.
- Optional: an attribution/provenance pointer was asserted.
It does not need to reveal user identity. It can prove correctness without becoming a tracking vector.
This matters because the future is not “agents doing things,” it is “agents doing things and everyone being able to prove what happened.”
That is what makes commerce, compliance, and trust possible at scale.
A simple end-to-end flow
Here is the basic lifecycle that an open system of record enables:
- Agent requests a resource.
- Server resolves
peac.txtand determines the effective terms. - If payment/authorization is required, the server challenges (often via HTTP 402 patterns).
- Agent satisfies the requirement.
- Server returns the response plus a cryptographic receipt.
- Any verifier (enterprise, auditor, marketplace, dispute resolver, internal compliance team) can validate the receipt later.
The important shift is step (5): proof is emitted at the time of interaction, not reconstructed later from logs.
Why “open” is non-negotiable
Closed systems of record exist today: proprietary logs, proprietary billing dashboards, proprietary bot management platforms.
They work until they don't.
In the agent era, three things make openness mandatory:
Portability
Evidence must survive vendor changes. If a company switches CDNs, gateways, agent frameworks, or payment rails, the proofs must remain meaningful.
Multiparty verification
A single vendor cannot be the only verifier when disputes involve multiple parties. Systems of record are valuable precisely because verification is independent.
Ecosystem scale
Agents will interact with millions of endpoints. The only way this scales is with shared formats and shared verification rules.
If the record layer is proprietary, the internet fragments into walled gardens. That is not the future we want, and it is not the future that wins long-term.
What Originary is building
PEAC is an open protocol. Originary stewards the spec and builds tools and services, but any team can implement and verify PEAC receipts independently.
Originary builds and stewards the open standard layer, and also ships production-grade tooling so teams can adopt it without reinventing crypto and policy enforcement.
1. PEAC Protocol: the open spec
- policy discovery conventions
- policy hashing and determinism
- receipt formats and signing rules
- verification rules
- integration profiles across rails and transports
2. Developer tooling
- SDKs to issue and verify receipts
- middleware for APIs and gateways
- adapters for edge environments
- conformance tooling for interoperability
3. Verification and record services (optional)
Open protocols win when they are easy to adopt. Not everyone wants to run verifiers, key infrastructure, and receipt storage on day one.
- receipt verification endpoints
- receipt storage and export
- audit-ready evidence bundles for enterprise workflows
The protocol stays open. Teams choose whether they want to self-host, use Originary, or use any other provider.
That is what “open system of record” means in practice.
Who this is for
This layer is not just for “AI companies.” It is for anyone who will be interacted with by agents.
Publishers and content platforms
- prove what was accessed and under what terms
- support paid access without losing portability
- enforce attribution/provenance expectations
API providers and SaaS platforms
- make agent access auditable
- bind entitlements and payment to responses
- reduce disputes and fraud
Enterprises deploying agents
- enforce preference and compliance constraints
- audit agent actions across vendors
- produce evidence without relying on internal logs alone
CDNs and edge networks
- emit verifiable receipts at the enforcement layer
- standardize proofs across customer sites and services
If you are building for the agent economy, you will need a proof layer. The question is whether it is proprietary and fragile, or open and durable.
What we believe will happen next
The agent era will force a new baseline:
- Receipts can become a default expectation for high-trust agent interactions, similar to how TLS became baseline for secure transport.
- Policy will be machine-readable, not buried in documents.
- Verification will be a standard enterprise requirement, not a niche security feature.
- Disputes will be resolved with evidence objects, not screenshots and vendor dashboards.
The system of record for AI agents will not be the company with the most traffic. It will be the layer that makes interactions provable across everyone's traffic.
That is the layer Originary is building.
Get started
If you operate an endpoint that agents will touch, you can begin now:
- Publish a policy file (
peac.txt) that expresses access terms in a machine-readable way. - Start returning cryptographic receipts (
PEAC-Receipt) for agent interactions. - Verify receipts inside your own systems, and export them to the places you already trust (SIEM, warehouse, compliance pipelines).
Originary can help you adopt the open standard quickly, whether you self-host or use managed verification.
The agent web is arriving. We should build it so it can be trusted.
Originary is building the open system of record for AI agents.
Frequently asked questions
What is a system of record for AI agents?
A system of record for AI agents is verifiable evidence of agent interactions: what was requested, what policy applied, what consent preferences were active, what was paid, what was returned, and what attribution obligations were asserted - all without leaking private identity.
How is PEAC different from logs?
Logs are unilateral and mutable - one party controls them, their schema varies, and their integrity is hard to prove externally. PEAC receipts are portable and cryptographically verifiable evidence that can be checked by third parties independently.
Does PEAC replace payment rails like x402 or Stripe?
No. PEAC is designed to sit above payment rails and alongside provenance/preference standards. It standardizes the evidence object that can reference x402, L402, Stripe, or any other payment system.
Can I verify PEAC receipts offline?
Yes. Receipts are signed JWS (Ed25519) and can be verified offline by any party with access to the issuer public keys via JWKS. No vendor API is required for verification.
Is Originary required to use PEAC?
No. PEAC is an open protocol. Originary stewards the spec and builds tools and services, but any team can implement and verify PEAC receipts independently. The protocol is Apache-2.0 licensed.
How does PEAC relate to robots.txt?
robots.txt was built for crawling with binary allow/deny. PEAC extends this for the agent economy: instead of just stop/go, it enables "go, under this policy hash, with this entitlement/payment proof."
What overhead does cryptographic receipt signing add?
Cryptographic receipts add overhead, so the format is designed to be compact and the signing/verifying path implementable at the edge. PEAC supports optional delayed or batched issuance where appropriate while keeping verification deterministic.
How does PEAC work with AIPREF and C2PA?
PEAC complements these standards. It can snapshot AIPREF preferences into receipts for auditability, and reference C2PA provenance data. PEAC does not compete with these standards - it provides the evidence binding layer.