Permission receipts: making authority a first-class platform primitive

The companion teardown on this site — "Your platform logs what the agent did. Your customer is being asked what it was allowed to do." — establishes the gap, and I am not going to re-argue it. In one paragraph: a platform that runs agents on a customer's behalf emits records of effects, and the question arriving from supervisors, counterparties and internal assurance functions is about authority. Those are different facts. The same effect is reachable from many different grants; the policy that produced the grant changes; and the identity that performed the action tells you who acted, not what they were permitted to do. Reading authority out of an effect log is an inference dressed as a record. This piece is about the artefact that would make it a record, and it is written for the people who would have to ship it.

I want to be honest about the scale of the claim up front, because the argument does not need to be inflated and is weaker if it is. The individual pieces of this design all exist already, in production, in adjacent domains. What does not exist — as a published standard from any of the platform vendors, so far as I can find — is the requirement that the artefact be emitted at all, and that the action path refuse to proceed without it. The engineering here is ordinary. The commitment is not.

What has to be true

Four constraints. Each one eliminates a family of designs, and I want to take them in the order that makes the eliminations visible, because the interesting thing about this problem is how few designs survive it.

First: the authority record must be produced by the thing that decides, at the moment it decides. Any record assembled after the action is a reconstruction. It may be an accurate reconstruction — often it will be — but its accuracy depends on the reconstructor having access to a policy that has not changed, an evidence set that has not been garbage-collected, and a request context that was fully captured. All three assumptions decay, and they decay silently. The only moment at which every input to the verdict is simultaneously in hand is the moment the verdict is reached. If you do not capture it there, you are not capturing it.

This is not a hypothetical capability. Open Policy Agent's decision logs already carry exactly this shape: each event records a decision_id described in the documentation as a "Unique identifier generated for each decision for traceability", the input, the result, the path, a timestamp, and a bundles map whose revision field is "Revision of the bundle at the time of evaluation." The policy version is recordable at the decision point rather than inferable afterwards, and has been for years. AWS Verified Permissions goes further at the response layer: its IsAuthorized call returns not only ALLOW or DENY but determiningPolicies — "The list of determining policies used to make the authorization decision" — alongside an errors array. The evaluation rationale exists in the response payload at the instant of decision. What the API reference does not say is whether that response is persisted anywhere by the service, and I am not going to assert either way; the document simply does not address it.

Second: verification must not require the platform to participate. If a customer's only route to proving what an agent was permitted to do is to ask the platform, then the platform is in the trust path permanently, and the proof is worth exactly what the reader thinks of the platform. That is fine for a support ticket and useless for the situations that actually generate the demand: a supervisory examination, a dispute with a counterparty, an incident review conducted by a party the platform has no relationship with. A customer in Mumbai or Riyadh or Charlotte may be answering to an authority that has never heard of the platform and has no reason to accept its word. The proof has to stand on its own.

This single constraint kills most of the obvious designs. A centralised attestation service does not survive it: the verifier has to call the service, the service can be unavailable, the service can be compelled, and the proof degrades to the service's own credibility. A query API over an audit store does not survive it either, for the same reason plus a worse one — the store's operator can decide what the query returns. What survives is a self-contained artefact and a verifier that makes no network calls at all.

Third: the verdict must be reproducible from the artefact. Offline verification is worth little if all it establishes is that somebody signed something. The useful property is stronger: a third party holding the receipt, the named policy and the evidence can re-run the evaluation and reach the same verdict, or discover that they do not. That requires the artefact to name its policy precisely enough to fetch the exact bytes, to commit to the evidence rather than merely gesture at it, and to be serialised deterministically so that two independent implementations hash the same decision identically.

Deterministic replay of an authorization decision is not aspirational. Cedar, the policy language behind AWS Verified Permissions, was designed for it: the paper reports "a sound and complete logical encoding, which enables precise policy analysis", and its authors state that they "modeled Cedar in the Lean programming language, and used Lean's proof assistant to prove important properties of Cedar's design" — including confirming that refactoring a set of policies does not change the authorized permissions. At least one shipping cloud policy engine was built so that a stated policy against a stated request gives a stated answer, every time. That is an explicit design goal someone pursued, not a happy accident, and it is the property this design leans on.

Fourth, and this is the one that makes it a platform problem rather than an application problem: the platform must be unable to forge the receipt and unable to read the policy. A multi-tenant platform occupies an awkward position. Its customers want it to help them prove things, and simultaneously do not want it to be able to fabricate those proofs, and also do not want to hand it their authorization policy, which for a bank or an insurer or a government supplier is among the more sensitive artefacts they own. A design that requires the platform to hold the signing key fails the first. A design that requires the platform to evaluate the policy fails the second. Both failures are structural: no amount of access control on the platform's side fixes an arrangement where the platform could, if it chose, produce a document that verifies.

Take those four together and the shape is forced. The decision point runs where the tenant chooses, on a policy the platform never reads. It emits a signed artefact whose signature the platform cannot produce. The artefact commits to its inputs by digest rather than carrying them. The verifier is a program that runs on someone else's laptop with the network unplugged.

What follows, and what has to be borrowed

Given those constraints, the components assemble themselves, and almost every one of them is borrowed from a domain that solved a version of this problem earlier. I would rather name the borrowings than present the result as invention.

Content addressing comes from software supply chain. The in-toto attestation framework binds a claim to an artefact by digest rather than by name: "Each element MUST have `digest` set", and "Subject artifacts are matched purely by digest, regardless of content type." That is the established pattern for making a signed statement about a specific immutable thing, and it transfers directly. A permission receipt is a signed statement about a specific decision taken on specific evidence, and naming the evidence by path or identifier would let the evidence change underneath the claim. Naming it by digest does not.

Deterministic serialisation comes from a published RFC and is not optional. RFC 8785, the JSON Canonicalization Scheme, exists for exactly this reason: "Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable." A content-addressed receipt over a JSON decision record has no choice here. Without deterministic property ordering and constrained serialisation, two conforming implementations will hash the same decision to two different identifiers, and the whole scheme fails in the least detectable way — it works in one implementation's test suite and silently disagrees in production.

The delegation chain format already exists, along with the rule about how to use it. RFC 8693, OAuth 2.0 Token Exchange, published January 2020, defines it: "A chain of delegation can be expressed by nesting one `act` claim within another. The outermost `act` claim represents the current actor while nested `act` claims represent prior actors." It also constrains it, and the constraint is more interesting than the format. The RFC says that "the consumer of a token MUST only consider the token's top-level claims and the party identified as the current actor by the `act` claim. Prior actors identified by any nested `act` claims are informational only and are not to be considered in access control decisions." The chain is audit material by design. A receipt should follow the same discipline: the verdict is a function of the current principal and the capability set it holds, and the chain records how it got there without contributing to whether it may act.

Attenuation-only delegation comes from capability systems that predate the current wave by a decade. Macaroons, published at NDSS 2014, established credentials that carry their own constraints: they "embed caveats that attenuate and contextually confine when, where, by who, and for what purpose a target service should authorize requests", using nested chained HMACs so that delegation is decentralised and the receiving service can verify the confined authority without a central authorization server. UCAN 1.0.0 carries the same property into a signed-token form where each delegation may only attenuate what it received, chains are signed at every hop, and tokens are identified by content identifiers. The design point in both is that a third party can check the chain without contacting the issuer — precisely the second constraint above, solved over a decade ago in another domain.

The container format for a signed, time-bounded, independently checkable assertion is standardised. The W3C Verifiable Credentials Data Model v2.0 reached Recommendation on 15 May 2025 and defines a verifiable credential as "a tamper-evident credential whose authorship can be cryptographically verified", binding issuer, subject, temporal validity through validFrom and validUntil, a credential status, and a cryptographic proof. A permission receipt is structurally a verifiable credential about a decision rather than about a subject's attributes, so a team that would rather reuse a serialisation than define one has a Recommendation-track option. I specify a bare claim set below because it is easier to read, not because the VC container is wrong.

And the answer to "how do I know you did not issue a second one quietly" comes from transparency logging. RFC 9162, Certificate Transparency version 2.0, states its own security property with unusual precision: "The logs do not themselves prevent misissuance, but they ensure that interested parties (particularly those named in certificates) can detect such misissuance." The append-only property "is achieved using Merkle Trees, which can be used to efficiently prove that any particular instance of the log is a superset of any particular previous instance and to efficiently detect various misbehaviors." Sigstore's Rekor is the same pattern in production for signed metadata rather than certificates: "an immutable, tamper-resistant ledger of metadata generated within a software project's supply chain", built so that "auditors can monitor the log for consistency, meaning that the log remains append-only and entries are never mutated or removed." Borrow the property, and borrow the honesty about what the property is — detection, not prevention.

It is worth being precise about what is missing rather than sweeping. I read the published documentation for two managed agent surfaces and one emerging telemetry convention, and none defines an artefact recording which authority was evaluated for a given action. Amazon Bedrock AgentCore Observability describes what it provides as "real-time visibility into agent operational performance through access to dashboards powered by Amazon CloudWatch and telemetry for key metrics such as session count, latency, duration, token usage, and error rates", emitted "in standardized OpenTelemetry (OTEL)-compatible format". That is performance and cost telemetry, described as such. Microsoft Entra Agent ID logs agent activity under the base identity type it originates from — blueprint activity as application events, agent identity activity as service principal events, agent user-account activity as user events — adding an agentType property, a blueprintId correlating an instance back to its template, and a new agentSignIn event type. That schema answers who the agent is, and answers it well; it is an identity and operation record, not a record of an authority evaluation. The OpenTelemetry GenAI agent and framework span conventions carry "Status: Development" and define attributes for operation name, provider, agent identity, conversation id, model request parameters, finish reasons and token usage — and no attribute for authorization, permission, policy, approval or consent.

Two platforms and one in-development convention is not a survey, and I am not going to claim that no agent runtime anywhere emits an authority record. The claim is narrower and checkable: in the primary documentation for those three surfaces, the artefact is absent, and the OpenTelemetry conventions in particular are explicitly marked as under development rather than settled.

Two more absences set the baseline the design has to beat. The Model Context Protocol authorization specification, revision 2025-06-18, is careful about token audience: clients "MUST implement Resource Indicators for OAuth 2.0 as defined in RFC 8707", servers "MUST validate that access tokens were issued specifically for them as the intended audience", and "The MCP server MUST NOT pass through the token it received from the MCP client." Every one of those is a good requirement and none produces a record of which authority was evaluated for a given tool call. On the infrastructure side, the record you might hope to fall back on is a deployment choice rather than a platform guarantee: Kubernetes API server auditing requires an audit policy file passed via --audit-policy-file, and "If the flag is omitted, no events are logged"; of its four levels, only RequestResponse records request and response bodies. Google Cloud writes Admin Activity logs that "are always written; you can't configure, exclude, or disable them", while "Data Access audit logs—except for BigQuery Data Access audit logs—are disabled by default because audit logs can be quite large." AWS CloudTrail is blunter: "By default, trails and event data stores do not log data events. Additional charges apply for data events."

There is one encouraging precedent buried in the same Kubernetes documentation. Audit events can carry authorization annotations — authorization.k8s.io/decision and authorization.k8s.io/reason — which is a working example of attaching the decision, rather than only the effect, to the audit record. The documentation references them without fully specifying when they are populated, so I cite them as an existence proof of the pattern and not as a field you can rely on being present.

The claim set, field by field

Every field in the receipt is there because a verifier lacking it could not reach the same verdict offline. That is the admission test, and it is a strict one: this object gets hashed, so every addition changes every identifier ever issued, and a field added for convenience is a migration you will regret.

• *principal* — the acting identity, exactly as the policy engine saw it. Not a display name, not a session id; the string the policy matched on. A verifier that cannot reconstruct the subject cannot replay.
• *capability* — the operation authorised, from a closed vocabulary the tenant controls. Free-text capabilities destroy replay, because two spellings of the same permission evaluate differently.
• *resource* — type, identifier, and the constraint set attached to this grant. The constraints belong here rather than in the policy because they are frequently per-decision: a spend ceiling computed from a remaining balance, a row filter derived from the request.
• *notBefore / expiresAt* — the validity window. Both, always. A receipt with only an expiry cannot be distinguished from one back-dated after the fact.
• *delegation* — the ordered chain, each hop carrying its own capability set. Attenuation-only, checked by the verifier, informational for the verdict per the RFC 8693 discipline.
• *policy* — the bundle name, the revision, and the digest of the exact bytes. The revision alone is not enough: revisions get reused, force-pushed and rebuilt. The digest is what makes "this exact policy" a checkable statement.
• *evidence* — digests of every input the decision consumed that is not already in the claims. Retrieved documents, group membership snapshots, risk scores, the prompt if the prompt was an input to the decision.
• *determinism* — whether the policy read anything outside the committed evidence. This field is the one most teams will want to omit and the one that most protects them, and I treat it at length in the failure modes.
• *decision* — allow or deny. Both are issued; only allow is accepted by the gateway. A signed deny is genuinely useful evidence that a request was made and refused, and throwing it away leaves you unable to prove restraint.
• *determining* — identifiers of the rules that drove the verdict, in whatever form the tenant's engine names them. Opaque to the platform by construction, because the platform cannot read the policy they name.
• *issuer / issuedAt* — who signed and when, so that key rotation and the validity window can be reasoned about together.

And a deliberate omission worth defending: the receipt does not carry the evidence, only digests of it. That is the price of the fourth constraint. A platform holding the evidence can read what the decision was taken on, and for the tenants who most want this artefact that is the exact disclosure they are trying to avoid. Commitment without disclosure is the trade; the failure-mode section is honest about what it costs.

// @authority/receipts — the claim set.
//
// Admission test for every field: could an offline verifier reach the same verdict
// without it? If yes, it does not belong here. This object is hashed, so an addition
// changes every identifier ever issued.

/** "sha-256:" followed by unpadded base64url. The only digest form v1 accepts. */
export type Digest = string;

/** RFC 3339 with a mandatory Z. Local offsets canonicalise differently. */
export type Timestamp = string;

/** One hop of delegation. Capabilities may only shrink from the previous hop. */
export interface DelegationStep {
  readonly principal: string;
  readonly capabilities: readonly string[];
  readonly grantedAt: Timestamp;
}

/** The policy is named and committed to, never carried. The platform must not read it. */
export interface PolicyRef {
  readonly bundle: string;
  readonly revision: string;
  readonly digest: Digest;
}

/**
 * Whether the verdict can be reproduced from what the receipt commits to.
 *  - "closed":   every input the policy read is digested in `evidence`
 *  - "external": the policy consulted live state that is not captured here
 * A receipt that lies about this is worse than one that omits it, because a verifier
 * will replay it, get a different answer, and blame the wrong component.
 */
export type DeterminismClass = "closed" | "external";

export interface ReceiptClaims {
  readonly v: "authority.receipt/1";
  readonly tenant: string;
  readonly principal: string;
  readonly capability: string;
  readonly resource: {
    readonly type: string;
    readonly id: string;
    readonly constraints: Readonly<Record<string, string | number | boolean>>;
  };
  readonly notBefore: Timestamp;
  readonly expiresAt: Timestamp;
  readonly delegation: readonly DelegationStep[];
  readonly policy: PolicyRef;
  readonly evidence: readonly Digest[];
  readonly determinism: DeterminismClass;
  /** Both are issued. Only "allow" is accepted by the gateway. */
  readonly decision: "allow" | "deny";
  /** Rule identifiers as the tenant's engine names them. Opaque to the platform. */
  readonly determining: readonly string[];
  readonly issuer: string;
  readonly issuedAt: Timestamp;
}

export interface LogInclusion {
  readonly log: string;
  readonly index: number;
  readonly proof: readonly Digest[];
}

export interface Receipt {
  /** Content address of the canonical claims. Identical claims, identical id. */
  readonly id: Digest;
  readonly claims: ReceiptClaims;
  /** Ed25519 over the canonical claim bytes, base64url. Never over the id. */
  readonly signature: string;
  readonly inclusion?: LogInclusion;
}

The control path

Eight steps, and the only interesting thing about them is the ordering. Read them as a sequence in which one specific inversion is fatal.

1. *The agent proposes.* It names a capability, a resource and the evidence it intends to act on. It does not act, and it does not get to say whether it may.
2. *The decision point evaluates.* The tenant's policy bundle runs against the request and the evidence. Out comes a verdict, the determining rules, and the revision of the bundle that produced them.
3. *The issuer signs.* Claims assembled, canonicalised, hashed to a content address, signed with the tenant's key. This is the receipt, and it exists before anything has happened in the world.
4. *The log receives the identifier.* Only the identifier goes to the transparency log — never the claims, which would leak tenant operations to whoever operates the log. An inclusion proof comes back.
5. *The agent acts, carrying the receipt id.* Nothing else about the call changes. This is the property that makes migration survivable: the action path gains a header, not a redesign.
6. *The gateway checks and refuses.* Signature, expiry, capability, resource scope. If any check fails, or if there is no receipt at all, the action does not happen. Not logged-and-allowed. Refused.
7. *The effect is performed and recorded.* The effect log you already have keeps doing its job, now correlated to a receipt id, which is what turns two partial records into one complete one.
8. *Someone verifies, later, elsewhere.* A third party with the receipt, the policy bundle and the evidence replays the decision and reaches the same verdict, or discovers a divergence. They call nobody to do it.

The fatal inversion is between steps three and five. If the receipt can be produced after the action — even microseconds after, even by the same process — then it is a description of something that already happened, and the only thing its signature attests is that a component was willing to describe it that way. Every property in this design rests on the receipt existing before the effect does.

Step six carries almost as much weight and gets far less attention. A gateway that logs the absence of a receipt rather than refusing on it makes the unreceipted path the path of least resistance, and traffic migrates toward it. How quickly is not something I have measured, and the claim here is about direction rather than a timetable. I return to this below: it is the largest hidden cost in the design.

Why multi-tenancy eliminates the designs you would otherwise pick

The single-tenant version of this problem is much easier and the easy solution does not generalise, which is why platform teams keep building it and keep discovering it does not satisfy their regulated customers.

The obvious platform design is an authority service: the platform evaluates policy on the customer's behalf, records the decision in a store it operates, and exposes an API for retrieving proofs. It has real advantages — one code path, central enforcement, and the platform can reason about the policy and build analysis on top of it. It also fails both halves of the fourth constraint at once. The platform holds the key, so it can produce any proof it likes; and it reads the policy, so the customer has disclosed their authorization model to a vendor. Neither failure is fixable by contract, because both are statements about capability rather than intent.

The design that survives puts two specific things on the tenant's side of the line and accepts the consequences. The signing key is the tenant's, which means the platform's involvement in a proof is limited to having transported bytes it cannot alter without detection. And the policy is evaluated against a bundle the platform never reads, which means the platform's record of what happened contains a bundle name, a revision and a digest — enough to correlate, not enough to reconstruct.

The consequences are real costs and not everyone will accept them. The platform can never answer "why was this allowed" on the customer's behalf, which is a support burden that moves rather than disappears. It cannot offer policy analysis, linting or optimisation on data it cannot read, which forecloses a plausible product line. And key custody becomes a per-tenant operational concern. These are not avoidable given the constraint — they are the price of it, and a design claiming to avoid them is quietly relaxing it.

Where this breaks

A design piece without an honest failure analysis is marketing, so this is the longest section, ordered by how likely each failure is to bite rather than by how clever it is.

Signed policy is not correct policy. The receipt proves that a decision was made, by whom, under which rules, on what evidence. It says nothing whatsoever about whether those rules were any good. A policy that grants everything to everyone produces beautifully verifiable receipts. What the design actually buys is a change of subject: the argument stops being "trust our logs" and becomes "here is the exact policy that was applied, argue with it." That is a real improvement and it is not correctness, and anyone selling it as correctness should be disbelieved.

Evidence digests commit without preserving. A digest binds the receipt to specific evidence and does not keep that evidence alive. If the tenant loses the retrieved documents, the membership snapshot, the risk score, then the digest is unfalsifiable in both directions — nobody can show the receipt was decided on something other than what it claims, and nobody can show it was decided on what it claims either. The receipt has quietly degraded from checkable to merely signed. This makes evidence retention an obligation the receipt creates and cannot enforce, and it is exactly the kind of obligation that survives a design review and dies in year two of operation.

Non-deterministic policy does not replay, and most real policy is non-deterministic. Policies that consult live state — current group membership, a remaining balance, a fraud score computed at request time, the time of day — cannot be replayed to the same answer later, because the state moved. There are two honest responses and one dishonest one. The honest ones: freeze every consulted input into the evidence set, which makes replay work and is expensive in both latency and storage; or mark the receipt external and accept that verification establishes structure and signature but not the verdict. The dishonest one is to leave the determinism field out, let verifiers replay, and let them conclude that a divergence means fraud when it means Tuesday. That is why the field is mandatory in the claim set.

The interval between decision and action is unrepresented. The receipt is issued at T. The effect lands at T plus some delta. Anything that changes in that window — a revoked role, a closed account, a policy update — is invisible to the receipt, which was correct when it was written and may be wrong when it is used. Short expiry narrows the window and cannot close it, because closing it would require the decision and the effect to be one atomic operation, which they are not and cannot be made to be across a network. This is an ordinary time-of-check-to-time-of-use problem and permission receipts do not solve it. What they do is date-stamp it precisely, which at least lets an investigator establish how wide the window was rather than guess.

An unreceipted path makes the whole thing decorative. This is the failure I would bet on. Every real platform has side doors: an administrative console, a break-glass credential, a legacy integration predating the gateway, a batch job someone wrote in 2023. Effects arriving through any of them have no receipt, and their absence is indistinguishable from "the receipt system was down" or "we forgot to instrument that path." The moment absence is ambiguous, the presence of a receipt stops being evidence of authority and becomes evidence of instrumentation coverage. Fixing this is not a receipt-format problem. It is a programme to make the gateway the only way in, and it is far larger than everything else in this piece combined.

A signed allow does not prove no other allow was issued. Non-repudiation runs one way. A receipt proves that a permission was granted; it cannot prove that a second, broader permission was not granted quietly to the same principal at the same moment. That gap is exactly what transparency logging exists for, and RFC 9162 is honest that logs give detection rather than prevention. Two further caveats that get dropped when people invoke transparency logs casually. First, a log that the tenant never monitors provides nothing: the property comes from someone checking consistency proofs, and if nobody checks, the log is a database with good branding. Second, if the platform operates the log, it is in a position to withhold entries, so the tenant either monitors it independently or holds a weaker property than the architecture diagram suggests.

Compromise of the issuing key inverts the entire scheme. Whoever holds the tenant's signing key can mint receipts that verify perfectly, and every property in this design becomes a property of the attacker's output. This is the same exposure any signing system has, and the mitigations are the same and are all partial: hardware custody, short-lived issuer keys with a signed key history so a verifier can bound which key was valid when, and log inclusion timestamps that constrain when a receipt could plausibly have been created. None of them makes a stolen key harmless. They make a stolen key eventually visible, which is a genuinely weaker claim and should be stated as one.

Metadata still leaks, and the fix trades against enforcement. Even with the policy opaque and the evidence reduced to digests, the platform sees capability strings, resource types, principal identifiers and timing. That is a usable shape of a tenant's operations. Hashing capability names with a per-tenant salt closes most of it, and simultaneously destroys the gateway's ability to do anything sensible with the capability field, which was the point of putting it there. Full metadata privacy and platform-side enforcement pull in opposite directions. Pick, document which you picked, and do not tell customers you got both.

And a short list of what this design simply does not address, offered so that nobody has to discover it in an incident. It says nothing about whether the agent's intent was appropriate — an agent manipulated into requesting a permitted action gets a valid receipt for it. It says nothing about the quality or provenance of the evidence, only that specific bytes were used. It does not detect a compromised decision point that is faithfully signing decisions it was tricked into making. And it does not make an autonomous system safe; it makes an autonomous system accountable, and those are different projects that get confused constantly.

What it costs

I have not benchmarked this implementation, so I am going to describe the shape of the cost and mark the measurements as planned rather than produce numbers I cannot stand behind.

Latency: the cryptography is almost certainly not the dominant term. Per decision the added work is one canonicalisation pass, one SHA-256 over a payload in the low kilobytes, and one signature over the same bytes. The prediction under test is that this is small relative to the two operations around it — the durable write of the receipt, and the round trip to the transparency log if it is synchronous. The measurement that would settle it is straightforward: p50 and p99 of decide-to-receipt-available on a fixed workload, run in three configurations — no receipt, receipt with asynchronous log submission, receipt with synchronous inclusion proof — with the canonicalisation, hashing, signing and storage phases timed separately. Until that is run I would not quote a figure, and I would treat any vendor figure quoted without that decomposition as uninformative.

Volume is a design lever, and it is the one that decides whether this is affordable. One receipt per authority decision, not per action and not per model call. What sets the bill is how coarsely you define a decision. A grant covering an agent's whole session for one capability against one resource produces one receipt and a wide blast radius; a grant per tool call produces precise attribution and a great many receipts. Most teams will want something between — per capability exercise, with a short window — and this granularity choice deserves more design attention than the cryptography does, because it is the parameter you cannot change later without re-deriving every identifier.

The industry has already priced the general shape of this trade, which is useful context. AWS CloudTrail's position — "By default, trails and event data stores do not log data events. Additional charges apply for data events" — and Google Cloud's — Data Access logs "are disabled by default because audit logs can be quite large" — are both statements that fine-grained audit at platform scale is expensive enough to be opt-in and metered. A per-decision artefact has to be sized against that reality rather than against a hope that nobody will notice.

The real operational burden is retention, and it is a records problem wearing an engineering costume. Replay requires the exact policy bundle bytes that produced the verdict. That means every policy version you have ever decided under has to remain retrievable for as long as any receipt referencing it might be examined — which, for a regulated tenant, is a period measured in years and set by someone who does not report to engineering. A team that ships receipts without answering the policy-archive question has built a system that verifies beautifully for ninety days and degrades to signature-only afterwards. The same applies, with more force, to the evidence.

Migration is cheap for the format and expensive for the property. Adding a receipt id header to the action path is a small change. Making the gateway refuse on absence is not, because it means enumerating every path that reaches a resource and either routing it through the gateway or documenting it as an exception, and the enumeration is always worse than the estimate. The sequencing that works is a ratchet with no way back: emit receipts in shadow mode and change nothing; then require them on one capability class in one environment; then require by default with a published, shrinking exception list whose length is a metric someone owns. What does not work is a flag that can be turned off under load, because it will be, at the exact moment the evidence would have mattered.

One piece of external context bears on whether this is worth doing now, and it points the opposite way from how it is usually read. OCC Bulletin 2026-13, "Model Risk Management: Revised Guidance," issued 17 April 2026 — the revised interagency guidance whose parallel Federal Reserve issuance is SR 26-2 — supersedes SR 11-7 and SR 21-8. The OCC bulletin states, in its own wording, that generative and agentic AI models are "not within the scope of this guidance", and the agencies have said they plan to issue a request for information addressing model risk management generally and banks' use of AI in particular. A request for information is a consultation step rather than a rule, which places the eventual specification further away rather than nearer. It also states that it does not set forth enforceable standards or prescriptive requirements. Read as an exemption, that is a reason to wait. Read as a deferral — which is what it is — it means nobody is going to hand the industry a control specification for agent authority, and the eventual guidance will be written against whatever the industry has already built. Platforms that have shipped a verifiable authority artefact will be describing their design to the people drafting it. Platforms that have not will be receiving one.

If you had a week

The temptation is to start with the log, because it is the most interesting component. That is the wrong order — it is the one piece that provides nothing until issuance volume exists to misbehave, and it can be added later without changing the claim set. Six things, roughly in this sequence.

1. *Freeze the claim set and the canonicalisation, and write conformance vectors for both.* Everything downstream depends on two implementations hashing the same decision identically. A pinned set of claim objects with their expected canonical bytes and expected identifiers is the artefact that makes a second implementation possible, and it costs an afternoon now against a migration later.
2. *Write the verifier first.* It is the deliverable and it defines what the other components must produce. If the verifier cannot be written in a day, the claim set is wrong — either it is missing something a verifier needs, or it contains something no verifier uses.
3. *Ship the verifier as a standalone package with no network dependency, and test that property.* A verifier that phones home is not a verifier; it is a client. Add a test that runs the verification path with outbound networking disabled and fails the build if anything reaches for a socket. This is the property the entire design is sold on and it is the one most likely to be eroded by a well-meaning convenience feature in month four.
4. *Emit in shadow from exactly one decision point, on one capability class, enforcing nothing.* You are looking for the shape of the volume, the size of the canonical payload, and how often the determinism class comes back external. I would expect that last number to be higher than the team predicts, because policy that consults live state is common — but that is a prediction rather than a result, it is exactly what this step exists to measure, and it is the number most likely to change the plan.
5. *Answer the retention question before enforcing anything.* Where do policy bundles live, for how long, addressed how, and who is accountable when the archive is incomplete. This is not engineering work and it will take longer than the code.
6. *Only then, the gateway.* One capability class, refusing on absence, in one environment, with the exception list published from day one. The exception list is the honest measure of how far you actually are, and it is the number to report rather than the count of receipts issued.

What I would explicitly not do in the first week: build the transparency log, define a bespoke serialisation when the Verifiable Credentials container would do, or attempt to cover every capability at once. The first provides nothing yet, the second is a standards project disguised as a sprint, and the third guarantees that the gateway ships behind a flag that never gets turned on.

Two claims are load-bearing for the whole design, and both are testable rather than rhetorical. The first is that a competent third party, handed only a receipt, a policy bundle and an evidence set, reaches the same verdict as the original decision point without contacting anyone. The second is that the platform transporting the receipt is unable to produce one that verifies. If a design fails either, it may still be a useful improvement to a log, and it is not a permission receipt. Both are properties you can write a test for, which is the strongest argument I have for specifying it this way.