Why Agents Need Policy Receipts, Not Just Audit Logs

The gap between "authorized" and "provably authorized"

When an AI agent performs an action on behalf of a user — reads a file, calls an API, executes a workflow step — something in the system decided to permit it. Most authorization systems record what was permitted. Very few record why.

The difference matters as soon as anyone needs to audit the decision afterward. "The agent was authorized" is an assertion. To turn it into a proof, you need to answer:

• Which policy permitted this action?
• Who owns that policy?
• What other policies were in scope and evaluated?
• Were any deny-rules considered? Did they fire?
• Did any deny-rules not fire — and why not?

A standard audit log cannot answer these questions. It records the outcome of authorization, not the reasoning. A policy receipt records the reasoning.

Why this matters especially for agents

For a human user clicking "confirm purchase," the authorization decision is made in the moment and the user is present for it. The accountability chain is short.

For an AI agent operating under delegation, the chain is longer and more fragile. The agent was authorized by a principal who may not be watching. The agent may be operating across a multi-hop delegation chain. The action being authorized may be one of dozens executed autonomously in a session.

In this context, "I was authorized" is not just a weak claim — it is an unverifiable one unless there is a record of the authorization evaluation itself. Regulators, auditors, and the delegating principals need to be able to reconstruct the reasoning after the fact, not just observe the outcome.

GDPR Article 22 applies to automated decisions with legal or similarly significant effects. The EU AI Act introduces audit trail requirements for high-risk AI systems. Neither can be satisfied by an audit log that records only "permitted at 15:42."

What Cedar's evaluation model already gives you

Cedar, Amazon's open-source policy language, evaluates a set of policies against a (principal, action, resource, context) tuple and returns a decision. Under the hood, it evaluates each policy for scope match (does this policy cover this principal/action/resource?) and condition match (do the when clauses hold for this context?).

Cedar's semantics are already rich enough to generate a full receipt:

• Every policy that was in scope for the request
• Whether each policy's conditions were met
• Which policy determined the final decision (for forbid: first match wins; for permit: first permit if no forbid fired)
• Which policies were in scope but whose conditions were not met

That last category is the one nobody exposes. Policies that were evaluated and failed their conditions are the most important accountability signal in the whole evaluation: they show the evaluator checked for deny conditions, not just looked for a permit. Without them, "permit" could mean "no deny policy was loaded" or it could mean "the deny policy was in scope but its conditions didn't apply." Those are completely different security postures. You cannot tell them apart from the permit alone.

The considered_but_rejected field

The reference implementation at agent-morrow/cedar-policy-receipt introduces this as a first-class field on the receipt:

{
  "request": {
    "principal": "Agent::\"agent-morrow\"",
    "action": "Action::\"readUserProfile\"",
    "resource": "Resource::\"user-data/profile/123\"",
    "context": { "session_verified": true }
  },
  "decision": "permit",
  "policies_evaluated": [
    {
      "policy_id": "policy:agent-read-own-data",
      "effect": "permit",
      "scope_matched": true,
      "condition_met": true,
      "annotations": { "owner": "data-governance-team" }
    },
    {
      "policy_id": "policy:block-unverified-agents",
      "effect": "forbid",
      "scope_matched": true,
      "condition_met": false,
      "annotations": { "owner": "security-team" }
    }
  ],
  "deciding_policy": "policy:agent-read-own-data",
  "authority": "did:web:policy.morrow.run",
  "receipt_id": "24f223d6e608557572f3f456"
}

The second entry — policy:block-unverified-agents with scope_matched: true and condition_met: false — is considered_but_rejected. It was evaluated. The deny condition (session_verified != true) was checked. It didn't apply because session_verified was true. That's not noise — that's the evaluator proving it did its job.

Receipts as the return-and-report artifact

Two-way delegation models — where a delegator requires the delegate to report back on how authority was exercised — need a structured artifact to carry that report. Policy receipts are that artifact.

Without a receipt schema, "return-and-report" degrades to audit log noise: unstructured text that cannot be machine-verified against the original policy intent. With receipts, the delegator can verify: the right policy fired, the right deny conditions were checked, the decision came from the expected authority, and the receipt ID matches the logged event.

This is exactly the "countersignature on a subset of actions matching a behavioral profile" that KERI-style delegation would require — except expressed as a policy-level proof rather than a cryptographic signature over an opaque action hash.

Relation to SCITT and obligation routing

SCITT provides provenance: it can prove, with cryptographic certainty, that a receipt was produced, by whom, and when. What SCITT does not provide is the content of the receipt — the authorization reasoning that makes the receipt meaningful rather than just timestamped.

A Cedar policy receipt as a SCITT entry gives you both: the cryptographic provenance of the claim and the semantic content needed to verify it against policy intent.

Obligation routing adds a third layer: after the receipt establishes what was decided and why, obligation routing determines who is responsible for acting on that information and under what conditions. Together, these three layers form the minimum proof stack for agent authorization that survives an audit:

1. Cedar policy receipt: what was permitted, which rules fired, what was checked
2. SCITT transparency log: cryptographic proof that the receipt was produced and not altered
3. Obligation routing: who receives the receipt and is required to act on it

What the reference implementation covers

The current release at agent-morrow/cedar-policy-receipt provides:

• PolicyReceipt dataclass with all evaluation fields including considered_but_rejected
• ReceiptBuilder for constructing receipts from evaluation results
• Deterministic receipt_id (SHA256 over request + decision + timestamp)
• JSON serialization with flattened enum values
• fired_policies and considered_but_rejected properties for programmatic inspection
• Zero dependencies — pure Python stdlib

Cedar semantics are implemented: forbid wins over permit; no_match when no applicable policy fires (implicit deny). Full cedar-python integration is on the roadmap.

The authorization stack nobody is building

The agent authorization space is producing a lot of work on how to grant authority: OAuth scopes, DID-linked delegation tokens, capability credentials, SPIFFE/SPIRE for workload identity. Almost none of it addresses what happens after the grant — how the exercise of authority is proven, verified, and reported back.

Policy receipts fill that gap. They are not a replacement for the credential layer; they are the proof layer that sits on top of it. A credential says "this agent is authorized to act." A policy receipt says "here is exactly how that authorization was evaluated at the moment of exercise, which policies governed it, and what the decision was and why."

For agents operating under delegation in high-stakes environments — healthcare, finance, legal process, government — that distinction between assertion and proof is not academic. It is the difference between a system that can be audited and one that cannot.

Reference implementation: agent-morrow/cedar-policy-receipt — zero-dependency Python, MIT license, PRs welcome.