Authority Receipts: Cryptographic AI Audit

The Problem: Accountability Without Visibility

Autonomous agents make decisions and take actions without human oversight. When something goes wrong, how do you know what happened? Traditional logging systems record events in plain text files. These files can be edited, deleted, or corrupted. A bad actor or a buggy agent could modify the logs to hide its actions.

Even if logs are honest, they are often verbose and hard to parse. Tracing through thousands of log lines to reconstruct what an agent did is tedious and error-prone. When a regulator asks "what exactly did this agent do on April 3rd at 14:30?", you need to be able to prove your answer.

Authority Receipts solve this. Every action generates a signed, immutable record. The signature proves that the record was created by ExecLayer and has not been modified. The ledger structure proves that records have not been reordered or deleted. Together, they create an audit trail that can be verified cryptographically.

What Is An Authority Receipt?

An Authority Receipt is a structured record of a single executable event. It contains:

• The canonical intent (what the agent tried to do, in standardized form)
• The policy evaluation result (approved, denied, or pending threshold signatures)
• The tier classification (standard, high-risk, requires approval)
• Any threshold signatures that were collected
• The adapter binding (which framework the agent is using)
• A unique nonce (prevents replaying the same receipt)
• A timestamp (when the action was evaluated)
• A cryptographic signature (proves the receipt has not been modified)

Here is a real-world example:

{
  "receipt_id": "auth_recv_1a2b3c4d5e6f7g8h",
  "timestamp": "2026-04-03T14:30:15.123Z",
  "canonical_intent": {
    "action_type": "data_mutation",
    "operation": "update",
    "resource_type": "database_table",
    "resource_id": "customers",
    "affected_rows": 1,
    "agent_capability": "update_customer_record"
  },
  "policy_evaluation": {
    "approved": true,
    "rule_id": "customer_update_standard",
    "tier": "standard",
    "evaluation_time_ns": 47
  },
  "agent_binding": {
    "agent_id": "crm_update_agent_01",
    "agent_role": "data_processor",
    "framework": "langchain",
    "adapter_version": "1.2.0"
  },
  "threshold": {
    "required": 0,
    "collected": 0,
    "signers": []
  },
  "nonce": "0x7a2c9f5e3b1d4a6c",
  "merkle_index": 4521,
  "ledger_hash": "0x92f14e8a3c6b1d7f2a5e9c3d8b1a4e6f",
  "signature": "0x48a9c3f1e7b2d5a9c4e1f8a3b6c9d2e5f8a1b4c7d0e3f6a9b2c5d8e1f4a7b"
}

The receipt is JSON, which is human-readable but also machine-parseable. The signature is generated using ECDSA with SHA-256 hashing. The merkle_index and ledger_hash tie the receipt to the append-only ledger, preventing tampering.

The Three Core Benefits

1. Forensic Analysis: Reconstructing What Happened

When an agent takes an unexpected action, forensic analysis answers the question: "Exactly what did the agent try to do, and was it authorized?"

Suppose a sales agent charged a customer $500 when it should have only charged $50. You query the receipt ledger for all actions by that agent. You find the receipt for the charge. The canonical intent shows amount_cents: 50000. The policy evaluation shows that the rule "sales_agent can charge if amount < 50000" approved it. So the authorization was correct.

But the agent charged the wrong amount. That is a different problem: the agent incorrectly calculated the amount, not that ExecLayer approved something it should not have. The receipt proves this cleanly.

Example scenario: A service is built incorrectly and an agent is able to request actions that should not be possible. You go back to the audit trail and find all the receipts for that agent. The receipts show which actions were approved and which were denied. You can see exactly where the vulnerability was (maybe a rule was too permissive) and when it was exploited.

2. Compliance Reporting: Proving Every Action Was Governed

Regulators often ask: "Can you prove that every critical action in your system was authorized?" Without Authority Receipts, proving this is hard. You can show logs, but logs can be forged. You can claim that you have governance, but claims are not proof.

With Authority Receipts, you can generate a compliance report that shows:

• From date X to date Y, agent role R performed N actions.
• All N actions are recorded in the append-only ledger.
• Each receipt shows the canonical intent, the policy that governed it, and the decision (approved or denied).
• The receipts are cryptographically signed and their signatures verify.
• The merkle hashes form an unbroken chain, proving nothing was inserted, deleted, or reordered.

The regulator can verify the cryptographic signatures themselves. They do not have to trust your claim that the logs are accurate. The cryptography proves it.

3. Dispute Resolution: Who Authorized This?

When actions require threshold signatures (approval from multiple stakeholders), the receipt records every signature. This resolves disputes about who approved what.

Scenario: An agent wanted to delete customer data. The policy requires approval from both the privacy officer and the legal officer. The agent generated a signing request. The privacy officer approved it. But the legal officer is on vacation. Should the deletion proceed anyway?

The Authority Receipt shows:

{
  "threshold": {
    "required": 2,
    "collected": 1,
    "signers": [
      {
        "signer_id": "privacy_officer_01",
        "signer_name": "Alice Chen",
        "timestamp": "2026-04-03T14:35:22Z",
        "signature": "0x1a2b3c4d..."
      }
    ],
    "pending_signers": ["legal_officer_01"]
  }
}

The receipt proves that Alice approved it and that legal approval is still pending. The system can enforce the policy: do not allow the deletion until both signatures are collected. The receipt is cryptographic proof of the approval state.

Cryptographic Guarantees

Authority Receipts use cryptographic techniques to guarantee integrity and non-repudiation:

ECDSA Signatures

Each receipt is signed using ECDSA (Elliptic Curve Digital Signature Algorithm) with a private key held by ExecLayer. The signature proves that the receipt was created by ExecLayer and has not been modified since. If even one byte of the receipt is changed, the signature becomes invalid.

ECDSA is industry-standard. It is used by Bitcoin, Ethereum, and TLS. It is cryptographically secure: discovering the private key from the public key or forging a signature is computationally infeasible with current technology.

Append-Only Merkle Ledger

Authority Receipts are stored in an append-only ledger. Each receipt has a merkle_index (its position in the ledger) and a ledger_hash (the hash of the entire ledger up to that point). The merkle structure creates a chain:

Receipt 1: merkle_index=0, ledger_hash=H(Receipt 1)
Receipt 2: merkle_index=1, ledger_hash=H(H(Receipt 1) + Receipt 2)
Receipt 3: merkle_index=2, ledger_hash=H(H(Receipt 2) + Receipt 3)
...

If someone tries to modify Receipt 2, its hash changes. This invalidates the ledger_hash for Receipt 3. To cover up the change, they would need to also modify Receipt 3, which invalidates Receipt 4, and so on. Modifying any past receipt requires modifying all future receipts, which is detectable.

The ledger_hash of the most recent receipt is the "ledger root". This single value depends cryptographically on every receipt ever generated. If any receipt is modified, deleted, or reordered, the ledger root changes. ExecLayer publishes the ledger root periodically (daily, for example), creating a checkpoint. If you have a checkpoint from a specific date, you can verify that all receipts up to that date have not been modified.

Nonce: Preventing Replay Attacks

A nonce is a unique value included in each receipt. Even if an attacker somehow copies an old receipt, the nonce proves that it is a historical record, not the current action. The system can verify that nonces are strictly increasing.

How Authority Receipts Work in Practice

Here is the full flow:

1. An agent requests to execute an action (e.g., "update customer record").
2. ExecLayer intercepts the action at the execution boundary.
3. The action is canonicalized into SovereignIR (standardized form).
4. The policy is evaluated against this canonical form.
5. The evaluation result is recorded (approved, denied, or pending threshold signatures).
6. An Authority Receipt is created with all details.
7. The receipt is signed using ECDSA.
8. The receipt is appended to the Merkle ledger.
9. If approved (and not pending signatures), the action is allowed to proceed.
10. If denied, the agent receives an error message showing the denial receipt.
11. If pending signatures, the system waits for approvers and updates the receipt as signatures arrive.

The entire process is deterministic and fast. Policy evaluation happens in 50-100 nanoseconds. Receipt generation and signing happen in microseconds. The receipt is appended to the ledger, which is optimized for concurrent writes.

Querying the Ledger

After actions are taken, you query the ledger to understand what happened. ExecLayer provides APIs for common queries:

// Get all actions by a specific agent
GET /api/receipts?agent_id=sales_agent_01&date_from=2026-04-01&date_to=2026-04-03

// Get all denied actions
GET /api/receipts?policy_evaluation.approved=false

// Get all actions affecting a specific resource
GET /api/receipts?resource_id=customers&action_type=data_mutation

// Get a specific receipt by ID
GET /api/receipts/auth_recv_1a2b3c4d5e6f7g8h

// Verify a receipt's signature and ledger position
GET /api/receipts/auth_recv_1a2b3c4d5e6f7g8h/verify

Each response includes the receipt (or receipts) and cryptographic proofs that they are legitimate. You can verify these proofs yourself using ExecLayer's public key, or trust ExecLayer's API to verify them for you.

Comparing to Traditional Logging

Traditional logging systems write text to files. These files are vulnerable to:

• Modification: A bad actor can edit a log file to hide their actions.
• Deletion: A malicious agent can delete log entries.
• Reordering: A sophisticated attacker can reorder log entries to change the narrative.
• Ambiguity: Logs are often inconsistent across different systems, making it hard to reconstruct exactly what happened.

Authority Receipts address each of these:

• Cryptographic signatures prove that receipts have not been modified.
• The Merkle ledger proves that no receipts have been deleted.
• The merkle chain proves that receipts are in their original order.
• The canonical intent format ensures consistent interpretation across all frameworks and agents.

Additionally, Authority Receipts include structured data (JSON), not just text. This makes them queryable and analyzable by machines, not just readable by humans.

Real-World Example: Compliance Audit

A financial services company has deployed autonomous agents that process transactions. A regulator asks: "Can you prove that every transaction over $10,000 was authorized?" Here is how Authority Receipts help:

1. Query the ledger for all transactions where amount_cents > 1000000 in the past year.
2. The system returns 523 receipts.
3. For each receipt, verify the signature and merkle position. All 523 verify correctly.
4. For each receipt, check the policy evaluation. All 523 show approved=true.
5. For each receipt with tier="high_risk", verify threshold signatures. All have the required 2 approvals.
6. Generate a compliance report showing all 523 transactions, their approvals, and cryptographic proofs.
7. The regulator can spot-check any receipt, verify the signature, and confirm it is authentic.

Without Authority Receipts, you would have to manually inspect logs, trust that they have not been modified, and hope you found everything. With Authority Receipts, you have cryptographic proof that every transaction was governed and all actions are accounted for.

Future: Integrating with Blockchain

Authority Receipts are designed to be compatible with blockchain systems. The ledger root (the merkle hash of all receipts) can be periodically published to a blockchain like Ethereum. This creates an external checkpoint that proves the ledger existed at a specific time.

This is future work and not part of the initial release. But it illustrates the vision: a system where autonomous agent actions are not just logged, but cryptographically proven and, if desired, anchored to external immutable systems.

Conclusion: From Logs to Cryptographic Proof

Authority Receipts represent a fundamental shift from traditional logging to cryptographic proof of execution. Instead of trusting that log files are accurate, you can cryptographically verify that actions were taken as recorded. This is essential for safety-critical autonomous systems.

Every agent action generates a receipt. Every receipt is signed. Every receipt is part of an immutable ledger. Together, these create an audit trail that is tamper-proof, queryable, and auditable by regulators or external parties.

This is accountability in the age of autonomous systems.