Comparison
Logs vs Cryptographic Receipts
Observability tells you what happened. Cryptographic receipts prove it. When an auditor or regulator asks "show me the evidence," logs are a starting point — receipts are the answer.
Every enterprise collects logs. Few can answer the five questions auditors actually ask.
Who requested it? Not just a service account — the full identity chain from human to agent to tool. Who authorized it? The PDP decision with the policy reference, not a 200 OK. What exactly happened? Per-parameter provenance, not a summarized event. Can it be disputed? Tamper-evident cryptographic fingerprinting, not a mutable log line. Where's the evidence? A signed, hash-chained receipt — not a Splunk query.
Two approaches to evidence
Logs and receipts serve different purposes — most production environments need both
Logs & Observability
Operational visibility
Essential for debugging, monitoring, and incident response. Logs capture system events, metrics track performance, and traces correlate requests across services.
Limitation: Logs are mutable, often aggregated, and capture system events — not authorization decisions. They answer "what did the system do?" but rarely "who authorized it and can you prove it?"
Cryptographic Receipts
Audit-grade proof
Each receipt is a JWS-signed, hash-chained evidence pack that captures the request, the authorization decision, the execution, and the outcome — all in a single tamper-evident record.
Strength: Receipts are immutable, self-contained, and verifiable. An auditor can validate the hash chain, confirm the signature, and trace every action to a policy decision — without querying a SIEM.
Detailed comparison
Where logs end and receipts begin
| Dimension | Logs / Observability | Cryptographic Receipts |
|---|---|---|
| Integrity | Mutable — can be edited, rotated, or aggregated after the fact | JWS-signed, hash-chained — tampering breaks the chain and is detectable |
| Identity context | Service account or IP address — the delegation chain is usually lost | Full identity chain snapshot: audience, scopes, provider, token hash, delegation path |
| Authorization decision | HTTP status code (200/403) — no policy reference or constraint context | PDP decision (Allow/Deny/SSC) with policy hash, constraints, and obligations |
| Parameter detail | Request body logged (if enabled) — often redacted or truncated | SHA-256 hash of shaped parameters with per-parameter provenance trail |
| Schema version | Not captured — API version may appear in URL or header | Tool/model schema hash pinned at execution time |
| Cost attribution | Derived from cloud billing — aggregated, delayed, approximate | Recorded per action with cost_usd — chargeback and showback ready |
| Dispute resolution | Weak — requires reconstructing events from multiple log sources | Strong — self-contained, verifiable, with cryptographic fingerprint matching |
| Chain of custody | Depends on SIEM ingestion pipeline — gaps possible | Hash chain (prev_hash) links each receipt to prior receipt for that agent |
| Regulatory readiness | SOC 2 / SOX — requires additional tooling to map logs to controls | Maps directly to SOX controls, EU AI Act Articles 14 & 53 transparency requirements |
Anatomy of a receipt
Four layers captured in every signed evidence pack
Request
Action, parameters, requestor identity, and full delegation chain
Decision
PDP verdict (Allow/Deny/SSC), policy hash, constraints, and obligations
Execution
Method, target system, shaped parameters (SHA-256 hashed), timestamp, schema hash
Evidence
Cryptographic fingerprint, JWS signature (RS256), hash chain link to prior receipt
Where receipts are emitted
Both ARIA gateways emit signed receipts on every governed action — permit or deny
ARIA Shield
BFF for AI models & browser sessions
Receipts cover LLM proxy calls, budget enforcement events, content security decisions, and OAuth Vault token brokering — every interaction between the client and the AI model layer.
MCP Gateway
Tool-execution authorization
Receipts cover every tool invocation — schema pin validation, plan discipline checks, AuthZEN constraints, parameter shaping, and per-action cost attribution.
Both gateways delegate authorization to the same OpenID AuthZEN 1.0 PDP. Receipts share a common format regardless of the enforcement surface, and all are stored in the Receipt Vault.
Frequently asked questions
Common questions from compliance leads and architects
Do receipts replace our SIEM?
No. Logs and receipts serve different purposes. Logs power operational monitoring, alerting, and incident response. Receipts provide the audit-grade evidence that logs cannot — signed proof of who authorized what, under which policy, with which parameters. Most organizations feed receipts into their SIEM alongside logs for a complete picture.
What makes the hash chain tamper-evident?
Each receipt includes a prev_hash field linking it to the prior receipt for that agent. Modifying or deleting any receipt in the chain breaks the hash sequence, making tampering detectable without relying on an external blockchain or append-only storage.
How do receipts help with EU AI Act compliance?
Articles 14 and 53 require transparency, traceability, and record-keeping for AI systems. Receipts capture the full decision trail — who requested the action, which policy authorized it, what parameters were used, and the cryptographic proof — providing the record-keeping backbone these regulations demand.
Can receipts be used for chargeback and FinOps?
Yes. Every receipt includes a cost_usd field recorded at execution time — not derived retroactively from cloud billing. This supports per-action chargeback and showback across business units, teams, or individual agents.
Are denied actions also receipted?
Yes. Both ARIA Shield and MCP Gateway emit receipts on the deny path as well as the permit path. Denied-action receipts are critical for audit — they prove the system was enforcing policy even when it blocked a request.
Where are receipts stored?
The Receipt Vault provides tamper-evident, hash-chained storage with decision context, policy hash, schema hash, and spend attribution. Receipts can also be exported to your existing SIEM or compliance platform.
What about the structured audit events in the activity feed?
EmpowerNow also emits structured governance events — domain-named audit records streamed to the analytics pipeline and surfaced in the activity feed. These are not the same as raw logs or cryptographic receipts. Think of it as three layers: operational logs for debugging and monitoring, structured audit events for timelines, dashboards, and automation triggers, and cryptographic receipts for signed, verifiable proof of authorization decisions. Most deployments use all three.
Related pages
Go deeper on the architecture behind receipts
See receipts in action
Walk through a live receipt chain — from agent request to signed evidence pack.