Audit Logs Tell You What Happened. Receipts Prove Who Authorized It.

What Audit Logs Actually Capture

Audit logs record execution. They tell you what happened: which process called which API at what time, with what parameters, and what the result was. A good audit log is comprehensive, append-only, and timestamped. In a post-incident review, it's invaluable for reconstructing the sequence of events.

But audit logs are inherently after-the-fact. They record what a system did. They do not — and cannot — record whether a human authorized what the system did before it did it. The log entry agent-service: deploy initiated, target=production, image=v2.1.0 tells you the deploy happened. It tells you nothing about authorization.

This gap is invisible in traditional systems because we assume that if a process reached the deploy step, something upstream authorized it. An engineer clicked a button. A CI check passed. A reviewer approved the PR. Authorization is implicit in the execution path.

With AI agents, that assumption breaks. The agent decides to deploy based on its own reasoning. "Tests pass, looks good, merging" is not the same as "a specific human authorized this specific deploy." The log shows execution. Authorization may not exist.

Three Ways Audit Logs Fail for AI Agent Authorization

1. Logs can be generated without authorization existing. A logging system records what happens. If an AI agent deploys without human approval, the log still records the deploy. The log entry looks identical to one where a human explicitly authorized the action. There is no field that says "this was authorized" vs "this was autonomous." Authorization and logging are separate systems, and one does not imply the other.

2. Logs are after the fact. By the time you read the log entry showing an unauthorized deploy, the deploy has already happened. Logs enable forensics. They do not enable prevention. For irreversible actions — production deploys, database writes, infrastructure changes — forensics is cold comfort. You needed the authorization check before execution, not after.

3. Logs cannot prove a negative. If an AI agent takes an unauthorized action, the log shows the action. What the log cannot show is that authorization was absent — the absence of an authorization entry isn't the same as proof that authorization didn't happen elsewhere, through some out-of-band mechanism. Proving an action was unauthorized requires proving the receipt doesn't exist, which requires a positive record of what was authorized, not just what happened.

What a Signed Receipt Is

A receipt is a cryptographic artifact issued before execution. It is the proof that a specific human authorized a specific action within a specific scope and time window. It is not a log entry. It is not a database record. It is an independently verifiable token.

A Permission Protocol receipt looks like this:

{
  "id": "rcpt_dg_7f3a9b2c",
  "action": "deploy",
  "scope": {
    "repository": "myorg/api-service",
    "sha": "abc123def456",
    "environment": "production"
  },
  "authorizedBy": "[email protected]",
  "issuedAt": "2026-04-02T14:30:00Z",
  "expiresAt": "2026-04-02T15:30:00Z",
  "signature": "ed25519:a9f3c2b1...",
  "publicKey": "pp_pk_8a7b..."
}

The Ed25519 signature covers the canonical JSON of the receipt body. Anyone with the public key can verify the signature — offline, without a network call, without trusting any intermediary. The receipt is specific: it names the exact repository, the exact commit SHA, and the exact environment. It cannot be reused for a different commit or a different environment.

This is fundamentally different from a log entry. The receipt is a proof of authorization, not a record of execution. It exists before the action. The action cannot proceed without it (in a properly gated system). And it can be verified offline with the public key and receipt body, even if the authorization service is unavailable.

The Temporal Difference: Before vs. After

This is the most important distinction. Receipt-based authorization is a before-execution primitive. The receipt must exist before the action can execute. The enforcer (a GitHub Action, a deploy script, an infrastructure controller) checks for the receipt at the gate. No receipt = no action. The authorization happens before execution, or the execution doesn't happen.

Audit logs are an after-execution primitive. The log entry is created when the action executes. There is no enforcement at the logging boundary. You can add a log entry that says "authorization checked: yes" without that actually being true. You cannot issue a valid signed receipt without actually going through the authorization service.

Consider what happens when you try to fake each one:

• Faking a log entry: Append a record to your logging system. Requires write access to logs, which many agents have.
• Faking a receipt: Forge an Ed25519 signature without the private key. Computationally infeasible. The agent cannot do this regardless of its permissions.

The cryptographic foundation is what makes receipts meaningful as an authorization primitive. A log entry's integrity depends on the integrity of the logging system. A receipt's integrity depends on the laws of mathematics.

What Good Looks Like: Both Systems, Each in Their Role

Receipts and audit logs are complementary, not competing. They serve different purposes in the authorization lifecycle:

Receipts handle the before: Issue before execution. Verify at the enforcement boundary. Block if absent. This is the governance layer — the mechanism that prevents unauthorized actions from executing in the first place.

Audit logs handle the after: Record what executed. When, with what parameters, by which process. This is the forensic layer — the mechanism that lets you reconstruct what happened when something goes wrong.

In a well-governed AI agent system, you want both. The receipt system ensures unauthorized actions don't happen. The audit log system records what did happen. The receipt ID appears in both: the receipt exists before execution, and the receipt ID is logged when the action executes. This gives you a complete chain: "Sarah authorized deploy abc123 to production (receipt ID: rcpt_dg_7f3a9b2c), and that deploy executed at 14:35 (logged with receipt ID: rcpt_dg_7f3a9b2c)."

What "Authorization Proof" Actually Means for Compliance

When a compliance auditor or security reviewer asks "who authorized the production deploy on April 2 at 14:35?" they need a specific answer. Not "the CI system allowed it" or "the PR was approved" or "the audit log shows it happened." They need: who made the authorization decision, when, for what exact scope, with what expiration, and what is the cryptographic proof of that decision.

A signed receipt answers all of these directly. The receipt is the authorization proof. It is not reconstructed from logs, not inferred from CI status, not assumed from access control configuration. It is a specific artifact that exists because a specific human explicitly authorized a specific action.

You can see what a live receipt looks like at permissionprotocol.com/r/demo — a real signed receipt with a verifiable Ed25519 signature, for a demonstration deploy action. That's what your compliance auditor gets to look at, instead of a log search.

The Architecture Implication

If you're running AI agents in production systems, your architecture needs a receipt layer, not just a logging layer. The receipt layer is external to the agent, cryptographically enforced, and fail-closed. It is not a better logging system. It is a different primitive at a different point in the execution lifecycle.

The how it works page walks through the full architecture — how receipts are issued, how the enforcement boundary works, and how the receipt ID flows through from issuance to execution to audit. The short version: receipts live before the action, logs live after, and connecting them by receipt ID gives you a complete, auditable, cryptographically-grounded record of what was authorized and what happened as a result.