Keep a record of why the gateway allowed or blocked a request.
Record important allow, deny, redaction and review decisions so security teams or customers can inspect them later without access to the gateway's private logs.
- Issuer
- https://gateway.vendor.example
- Request
- tools.call market_data
- Decision
- allow - policy applied
- Signature
- Ed25519 e02d7f15...
Gateway logs explain decisions internally. Signed records let others verify them.
A gateway log can help you debug a routing or policy decision internally. It cannot be handed to a customer, auditor, or counterparty as independent proof. A signed record answers the questions that cross the boundary:
- Which policy version applied at that moment?
- Was the request allowed, denied, or modified?
- What content was actually delivered, versus what was produced?
- Which agent or workload spent what through the gateway?
- Can any of this be verified later, without access to our systems?
One gateway decision. One signed record.
- Issuer
- https://gateway.vendor.example
- Request
- tools.call market_data
- Decision
- allow
- Policy
- tool-policy:v2 sha256:4e21b8...
- Produced
- sha256:9a3c1d...
- Delivered
- sha256:9a3c1d...
- Time
- 2026-07-02T09:14:31Z
- Signature
- Ed25519 30cf81d6... kid 2026-07-key1
"_meta": {
"org.peacprotocol/receipt_ref": "sha256:f04d11...",
"org.peacprotocol/receipt_jws": "eyJhbGciOiJFZERTQSIs..."
}Records ride existing gateway response metadata or export as bundles. They travel separately from the gateway that created them.
Decision records that survive the boundary.
A refused or redacted request is still an event.
A signed deny records what was refused, when, and why: the reason code, the policy digest, and the timestamp travel together with the signature.
When the gateway redacts rather than blocks, the record binds the issuer-reported produced and delivered representations. A separate delivery observation is required to establish what the recipient received.
- Issuer
- https://gateway.vendor.example
- Request
- tools.call export_billing
- Decision
- denied - policy_violation
- Policy
- tool-policy:v2 sha256:4e21b8...
- Time
- 2026-07-02T09:16:04Z
- Signature
- Ed25519 e02d7f15... valid
When agent traffic hits a metered or paid endpoint, the record binds who spent what.
Each call yields a signed record binding the caller identity or agent reference, the action, and the observed payment context. Finance and audit review can reconcile agent spend against signed records instead of one side's counters.
- Issuer
- https://gateway.vendor.example
- Agent
- research-agent-v3
- Request
- POST /v1/market-data/search
- Decision
- allow - metered
- Payment
- observed context - x402-style
- Time
- 2026-07-02T09:17:52Z
- Signature
- Ed25519 c9a012ff...
Records compose with what your gateway already touches.
- OpenTelemetry trace correlation: records carry W3C trace context, so a gateway decision links to the same trace in your OpenTelemetry backend via the
peac.record.refspan attribute. - In front of MCP servers: per-tool-call records travel alongside the gateway decision. See /mcp.
- In front of paid or metered endpoints: x402-style payment observation binds the decision to the call it metered. See /agentic-commerce.
- Evidence bundles: export a set of decision records for a dispute or a review, verifiable without access to the gateway.
What Originary does not do here.
- It does not route or proxy traffic.
- It does not enforce or decide policy.
- It does not rate-limit or gate anything.
- It does not replace your gateway, WAF, or observability stack.
- It does not move or settle money.
- It does not score or rank counterparties.
It records the decisions your gateway already makes.
Add records to one gateway route this week.
Start with the route another party already asks about. We will show what the signed record should contain.
npx -y @peac/cli@0.16.4 verify ./gateway-decision.jws --public-key ./jwks.json