Building the evidence layer the next examination will ask for

The companion teardown on this site — “The guidance that would have told you what to build now says agentic is out of scope” — establishes the position, and I am not going to re-argue it here. In one paragraph: the revised interagency Supervisory Guidance on Model Risk Management of 17 April 2026 supersedes the 2011 framework, states that generative and agentic AI models are not within its scope, and declines to set enforceable standards. That is a deferral rather than an exemption, because every obligation attached to the underlying action survives it. What was withdrawn is the document that would have told you which controls satisfy those obligations. This piece is about what a bank builds in that gap, and it is written for the people who would have to ship it — the platform engineers, the model risk function, and whoever owns the agent estate that has quietly grown up around your servicing and origination workflows.

I want to state the scale of the claim honestly, because inflating it makes the argument weaker rather than stronger. Almost every component below already exists in production somewhere: content-addressed signed statements, deterministic serialisation, append-only transparency logs, attenuating delegation chains. What does not exist is any supervisory specification requiring a bank to emit an authority record at all. Neither the 2026 guidance nor the 2011 guidance it replaced contains a record-retention period, a requirement for signed or content-addressed records, or a requirement that an authorisation decision be independently verifiable offline. So this design satisfies no standard. It is a proposal for what a standard would probably contain, and the argument for building it now is that the drafting has not happened yet.

One more piece of scoping, since it determines whether any of this is your problem. The 2026 guidance says it “is expected to be most relevant to banking organizations with over $30 billion in total assets,” and that models used by organizations at or below that threshold “typically are subject to internal risk management and governance practices appropriate for the size and risk profile of these banking organizations,” with a carve-out: it “also may be relevant” to smaller organizations “that have significant exposure to model risk because of the prevalence and complexity of their models or because of activities outside the scope of traditional community banking.” If you are a $12bn bank whose agents touch a capital-markets book, the tailoring language does not protect you and you should read on.

The sentence that is no longer there

The design that follows has an unusual origin: it comes from a deletion. The 2011 guidance, in its Documentation section, said this — “Without adequate documentation, model risk assessment and management will be ineffective. Documentation of model development and validation should be sufficiently detailed so that parties unfamiliar with a model can understand how the model operates, its limitations, and its key assumptions.” That is a reconstruction standard, and it is stated in terms of a stranger. Not an auditor who has been through onboarding, not a validator embedded in the line — parties unfamiliar with the model.

Here is the passage that replaced it, quoted in full so that nothing is hidden by ellipsis. “Adequate documentation helps to support effective model risk management. For example, documentation can help maximize the likelihood of continuity of operations, including supporting the tracking of recommendations, responses, and exceptions; it can also be used to more effectively help manage any model remediation efforts.” Read them next to each other. The 2011 text says what documentation must achieve and names the audience that must be able to achieve it. The 2026 text says documentation helps, and gives operational continuity as its example.

The same pattern appears one section earlier, in the model inventory, and it is worth setting out because the 2011 inventory reads like a specification for the artefact this piece proposes. The 2011 guidance said the inventory should “describe the purpose and products for which the model is designed, actual or expected usage, and any restrictions on use,” that it was useful for the inventory to list “the type and source of inputs used by a given model,” and named among other items “the names of individuals responsible for various aspects of the model development and validation; the dates of completed and planned validation activities; and the time frame during which the model is expected to remain valid.” Purpose. Scope restriction. Input provenance. A named responsible principal. An explicit validity expiry. That is an authority record in everything but name, written fifteen years ago and applied to a different object. The 2026 guidance reduces the inventory to a general statement that it should hold sufficient information to understand model risks.

One further deletion, because it bears directly on how agent authority gets documented. The 2011 guidance said that “line of business or other decision makers should document information leading to selection of a given model and its subsequent validation.” No equivalent sentence appears anywhere in the twelve pages of the 2026 guidance. The requirement that the authorising human decision be written down is not in the current text.

That comparison is a textual fact and I assert it as one — both documents were read directly rather than through a summary. What I do not assert is why. No agency has said whether the removal of the reconstruction standard was deliberate, or commented on it at all, and any account of the agencies' intent would be my inference dressed up as a regulatory statement. It is entirely possible that the drafters regarded the reconstruction obligation as adequately carried by other supervisory expectations. The design below does not depend on the answer.

And here is the part of the footnote that most commentary drops, which turns the exclusion from a relief into an assignment. Footnote 3 does not stop at putting generative and agentic AI out of scope. It continues: “Nonetheless, a banking organization's risk management and governance practices should guide the determination of appropriate governance and controls for any tools, processes, or systems not covered in this document. However, the principles described in this guidance apply to traditional statistical and quantitative models and non-generative, non-agentic AI models.” The agencies removed agentic systems from the scope of their specification and, in the same footnote, said the organisation's own practices should determine the controls. That is a transfer of the design problem, not a discharge of it.

What has to be true

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

First: the authority record must be produced by the component that decides, at the instant it decides. Any record assembled after the action is a reconstruction. It may be an accurate reconstruction, and frequently will be, but its accuracy depends on the reconstructor having the policy that was actually in force, an evidence set that has not been aged out, and a request context that was captured completely. All three assumptions decay, and they decay silently — nothing in the system tells you the day the reconstruction stopped being reliable. The only moment at which every input to the verdict is simultaneously in hand is the moment the verdict is reached. Capture it there or do not capture it.

This constraint has an uncomfortable corollary for banks specifically, which is that most of the reconstruction capability in a bank today lives in the heads of the people who built the system. That is precisely the arrangement the 2011 reconstruction standard existed to prevent, and it is the arrangement the 2026 text no longer speaks against. An institution whose answer to “under what authority did this agent move that limit” is a subject-matter expert reading a log has not got a record. It has got a witness, and witnesses leave.

Second: the evidence must be consumable by a party who accepts none of your architectural assertions. This is the constraint that separates an evidence layer from an assurance narrative. A supervisor does not have to accept your account of how your systems fit together, and increasingly will not want to — a diagram is a claim about the world made by the party under examination. What survives that posture is an artefact the examiner can check by operating on it, rather than by believing something about where it came from. Recompute the address, verify the signature, hash the policy bundle, re-run the evaluation, compare the verdict. Every one of those is an operation the examiner performs; none is a proposition they must accept.

The 2026 guidance retains the concept that would consume such an artefact, while defining it as an institutional function rather than a machine-checkable one. It describes “effective challenge,” which “refers to the critical analysis conducted by objective experts who evaluate model risk and effect appropriate changes throughout the model lifecycle, from model development to ongoing monitoring,” performed by people with “the appropriate expertise to conduct a critical and objective challenge, sufficient independence to maintain objectivity, as well as the organizational standing and influence to effect any change.” Note what effective challenge presupposes: something reviewable, which exists, and which the challenger can examine. For an authority decision that was evaluated implicitly and discarded, there is nothing there to challenge. The concept survives and its object does not.

Third: it must not depend on a control framework the current guidance declines to specify. This one is easy to state and hard to internalise. A design whose justification is “this satisfies the model risk framework” is a design built on ground the agencies have removed, twice over. Once because footnote 3 puts generative and agentic AI outside the scope. And a second time, less obviously, because of how the guidance defines its own subject: “the term ‘model’ refers to a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates,” and it “excludes simple arithmetic calculations, such as those found within spreadsheets, as well as deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use.”

Read that against the thing this piece proposes. A deterministic authorisation engine — the component that decides whether the agent may act — is a deterministic rule-based process with no statistical or economic theory underpinning it. It is outside the guidance as an agentic component and outside the guidance as a deterministic one. There is no reading of the 2026 text under which the authority layer of an agentic banking system is a model. Which means no external specification governs it at all, and any control design for it is the institution's own work product, subject only to whatever obligations attach to what the agent actually does.

Those obligations are not hypothetical, and the agencies took care to preserve them. The relevant sentence in Section I is: “This guidance does not set forth enforceable standards or prescriptive requirements; accordingly, non-compliance with this guidance will not result in supervisory criticism against a banking organization.” It carries a footnote, and the footnote is where the argument turns: after citing the agencies' respective rules on supervisory guidance, it adds — “However, supervisory action may result for any violations of law or unsafe or unsound practices stemming from insufficient management of model risk.” The specification is withdrawn and the enforcement hook stays attached, in the same breath, on the same page. That is the whole case for building the evidence layer now, in the agencies' own words rather than mine.

Fourth: the bank must hold the evidence independently of the vendor whose platform produced it. The guidance is explicit that buying does not discharge the duty, and unusually explicit that opacity is not an excuse. On vendor and third-party products it says: “because certain components may be proprietary, banking organizations may not receive from the vendor the underlying code, data, or methodology that they would have if a model were developed internally. Nevertheless, the principles of model risk management remain applicable.” Apply that to an agent platform. If the only route to proving what your agent was permitted to do runs through your vendor's console, then your evidence has your vendor's availability, your vendor's retention policy, and your vendor's incentives baked into it. In a dispute with that vendor it is worth nothing at all.

Take the four together and the shape is forced, which is the property I care about most in a design. The decision has to be separated from the action, because only then is there a moment at which the record can be written before the fact. The record has to be signed by a key the bank holds, because otherwise the vendor could produce it. It has to commit to its inputs by digest rather than carry them, because the evidence is customer data and the receipt will travel. It has to name its policy by revision and by digest, because a revision string alone can be rebuilt and reused. And the verifier has to be a program that runs with the network disconnected, because the examiner will not, and should not, take your availability on trust.

A point of citation hygiene, because I have seen this written the other way in more than one place, including in earlier working notes of my own. The generative-and-agentic exclusion is not the OCC's alone. It is footnote 3 of the joint interagency guidance whose cover page is headed with all three agencies — the Board of Governors of the Federal Reserve System, the Federal Deposit Insurance Corporation, and the Office of the Comptroller of the Currency — and which the Federal Reserve distributes as the attachment to SR Letter 26-2. Attribute it jointly. The request-for-information sentence is the mirror-image error: that one appears in the OCC's bulletin cover text, not in the twelve pages of the guidance, and it announces a consultation rather than a rule. As of the date on this piece I could not locate such a request for information in the Federal Register, so nothing here treats it as pending or promised guidance.

On the supersession itself, one more precision that gets garbled constantly: each agency rescinded its own issuances. Fed SR 26-2 supersedes SR 11-7 and SR 21-8. OCC Bulletin 2026-13 rescinds the OCC's own items — the Model Risk Management booklet of the Comptroller's Handbook, OCC 1997-24 on credit scoring models, OCC 2011-12, and OCC 2021-19 — and the FDIC rescinded its two financial institution letters, FIL-22-2017 and FIL-27-2021. SR 11-7 is a Federal Reserve designation and is not among the items the OCC bulletin rescinds. If you are citing this in a board paper, get that right; the people reading it will know.

The claim set, field by field

Every field is there because a verifier lacking it could not reach the same verdict without asking you. That is the admission test and it is deliberately harsh, because the object gets hashed: any field added later changes the identifier of every receipt issued afterwards, and a field added for convenience becomes a migration you regret in year two.

• *principal* — the acting identity exactly as the policy engine saw it. Not a display name, not a session identifier; the string the policy matched on. A verifier that cannot reconstruct the subject cannot replay the decision.
• *capability* — the operation authorised, drawn from a closed vocabulary the bank controls. Free-text capabilities destroy replay, because two spellings of the same permission evaluate differently and no one notices until an examination.
• *resource* — type, identifier, and the constraint set attached to this particular grant. Constraints belong here rather than in the policy because in banking they are usually per-decision: a limit computed from a remaining balance, a counterparty filter derived from the request, a cut-off derived from the settlement calendar.
• *notBefore / expiresAt* — the validity window, both ends, always. A receipt carrying only an expiry cannot be distinguished from one back-dated after the fact, which is the single most obvious attack on the whole scheme.
• *delegation* — the ordered chain from the human mandate down to the acting agent, each hop carrying its own capability set. Attenuation-only: a hop may narrow what it received and may never widen it.
• *policy* — the bundle name, the revision, and the digest of the exact bytes. The revision alone is insufficient because revisions get force-pushed, rebuilt and reused. The digest is what makes “this exact policy” a checkable statement rather than a label.
• *evidence* — digests of every input the decision consumed that is not already in the claims: the retrieved documents, the exposure snapshot, the sanctions screening result, the risk score, the customer record as read.
• *determinism* — whether the policy read anything outside the committed evidence. This is the field every team wants to drop and the field that most protects them; it gets a failure mode of its own below.
• *decision* — allow or deny. Both are issued and only allow is accepted by the gateway. A signed deny is genuinely valuable evidence that a request was made and refused, and discarding it leaves you unable to demonstrate restraint.
• *determining* — identifiers of the rules that drove the verdict, in whatever form your engine names them.
• *adverse* — present only where the action would be adverse to a consumer, and carrying the principal reasons in the specific form the law requires. This is the field that makes the record answerable to an obligation that actually binds today.
• *bookOfRecord* — the identifier the core system will write against the resulting entry. This is the join key between the authority record and the effect record, and without it you have two archives that cannot be reconciled.
• *retention* — the retention class, expressed on the record itself, because nothing in the model risk guidance sets one and the class is therefore your assertion rather than a regulator's.
• *issuer / issuedAt* — who signed and when, so that key rotation and the validity window can be reasoned about together years later.

The adverse-action field deserves defending, because it is the one place where this design stops being anticipatory and becomes answerable to law in force. Regulation B, at 12 CFR 1002.9(b)(2), provides: “The statement of reasons for adverse action required by paragraph (a)(2)(i) of this section must be specific and indicate the principal reason(s) for the adverse action. Statements that the adverse action was based on the creditor's internal standards or policies or that the applicant, joint applicant, or similar party failed to achieve a qualifying score on the creditor's credit scoring system are insufficient.” A bank that lets an agent decline an applicant and discards the basis of that decision cannot satisfy that rule, and the model risk deferral does not touch it — fair lending is exactly the kind of obligation footnote 1 preserves. Which is why the issuer below refuses to sign an adverse consumer decision that arrives without specific principal reasons, and refuses the two formulations the rule names as insufficient. It is a small guard and it converts an aspiration into a runtime property.

It is worth being precise about the neighbouring capital-markets requirement too, because it is often cited as though it already covered this ground and it does not. The SEC's 2022 amendments to the broker-dealer electronic recordkeeping rule added an audit-trail alternative to the long-standing write-once-read-many requirement: a firm may instead operate an electronic recordkeeping system that permits the recreation of an original record if it is modified or deleted, and must be able to furnish a record and its audit trail in a reasonably usable electronic format on request. That is a rule about the integrity of the record of effects — it perfects the append-only history of what was written and says nothing about materialising the authority under which the writing was done. The distinction this whole piece rests on is visible there in a regulator's own design choice.

// @authority/receipts — the claim set for a supervised institution.
//
// Admission test for every field: could an examiner reach the same verdict without
// it, and without asking us? If yes, it does not belong here. This object is hashed,
// so any addition changes the identifier of every receipt issued after it.

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

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

/** One hop of delegation, from the human mandate down to the acting agent. */
export interface DelegationStep {
  readonly principal: string;
  readonly capabilities: readonly string[];
  readonly grantedAt: Timestamp;
}

/** The policy is named and committed to, never carried inside the receipt. */
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 not captured here
 * A receipt that misreports this is worse than one that omits it, because a verifier
 * will replay it, get a different answer, and attribute the divergence to the wrong
 * component.
 */
export type DeterminismClass = "closed" | "external";

/**
 * Present only where the action would be adverse to a consumer. The shape mirrors
 * 12 CFR 1002.9(b)(2): reasons must be specific and must name the principal reasons.
 */
export interface AdverseActionBasis {
  readonly subjectRole: "applicant" | "joint-applicant" | "similar-party";
  /** Specific principal reasons. Ordered by contribution, most significant first. */
  readonly principalReasons: readonly string[];
  /** The digest of the disclosure actually delivered, once it has been delivered. */
  readonly noticeDigest?: Digest;
}

/** Retention is the institution's assertion. No model risk guidance sets a period. */
export interface RetentionClass {
  readonly label: string;
  readonly years: number;
  /** The obligation the institution is asserting drives the period, in its own words. */
  readonly basis: string;
}

export interface ReceiptClaims {
  readonly v: "authority.receipt/1";
  readonly institution: 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 verdicts are issued. Only "allow" is accepted by the gateway. */
  readonly decision: "allow" | "deny";
  readonly determining: readonly string[];
  readonly adverse?: AdverseActionBasis;
  /** The identifier the core system writes against the resulting entry. */
  readonly bookOfRecord: string;
  readonly retention: RetentionClass;
  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. The only interesting property is the ordering, and there is exactly one inversion that destroys the design.

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 a vote on whether it may.
2. *The decision point evaluates.* The bank's policy bundle runs against the request and the evidence. Out comes a verdict, the determining rules, the revision that produced them, and — where the action would be adverse to a consumer — the principal reasons.
3. *The issuer signs.* Claims assembled, canonicalised, hashed to a content address, signed with the bank's key. The receipt now exists, and nothing has happened in the world.
4. *The identifier is appended to the index.* Only the identifier. The claims never go to the index, because the claims describe customer activity and the index is the component most likely to be operated somewhere you would rather it were not. An inclusion proof comes back.
5. *The agent acts, carrying the receipt identifier.* Nothing else about the call changes. This is the property that makes the migration survivable: the action path gains a header, not a redesign.
6. *The gateway checks and refuses.* Signature, window, 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.* Your existing book of record keeps doing exactly what it does, now carrying the receipt identifier, which is what turns two partial archives into one reconcilable record.
8. *Someone verifies, later and elsewhere.* An examiner, an internal audit function, a counterparty's counsel, holding the pack, replays the decision and reaches the same verdict or discovers that they do not. They call nobody to do it.

The fatal inversion sits between steps three and five. If the receipt can be produced after the action — even microseconds after, even by the same process, even with impeccable intentions — then it is a description of something that already happened, and its signature attests only that a component was willing to describe it that way. Every property in this design rests on the receipt existing before the effect does. It is worth stating plainly because the tempting implementation, the one that requires no changes to the action path at all, is precisely the one that emits the receipt from the audit tap.

Step six carries nearly as much weight and gets a fraction of the attention. A gateway that logs the absence of a receipt rather than refusing on it makes the unreceipted path the cheapest path, and traffic migrates toward whatever is cheapest to call. I will not give you a timetable for that, because I have not measured it, and an unsourced timetable — a specific horizon paired with a specific majority — is exactly the kind of claim this practice exists to argue against. The direction is what I assert.

Where this breaks

A design piece without an honest failure analysis is marketing with a monospace font. This is the longest section, ordered by how likely each failure is to bite rather than by how interesting it is.

Signed policy is not correct policy. The receipt proves that a decision was taken, by whom, under which rules, on what evidence. It says nothing whatsoever about whether those rules were any good. A policy granting everything to everyone produces beautifully verifiable receipts at high throughput. What the design actually buys is a change of subject: the conversation stops being “trust our controls” 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 shown the door.

It makes the authority reviewable, not the judgement. This is the limitation a model risk officer will find first, and they will be right. The receipt captures whether the agent was permitted to do the thing. It does not capture whether the underlying generative model's reasoning was sound, whether the retrieval surfaced the right documents, or whether the recommendation was appropriate for that customer. Those are model questions and this is not a model control. Anyone who tells a supervisor that a permission receipt addresses model risk in an agentic system has overclaimed, and the overclaim will be caught, and it will damage the credibility of the parts that do hold.

Evidence digests commit without preserving. A digest binds the receipt to specific evidence; it does not keep that evidence alive. If the exposure snapshot, the screening result and the customer record as read at decision time are gone, the digest becomes unfalsifiable in both directions: nobody can show the decision rested on something other than what it claims, and nobody can show it rested on what it claims either. The receipt has silently degraded from checkable to merely signed. That makes evidence retention an obligation the receipt creates and cannot enforce — which is exactly the class of obligation that survives a design review and dies quietly in year two.

Most real banking policy is non-deterministic, and non-deterministic policy does not replay. Policies that consult live state — current exposure, an available balance, a fraud score computed at request time, whether the market is open — cannot be replayed to the same answer later, because the state moved. There are two honest responses and one dishonest one. Honest: freeze every consulted input into the evidence set, which makes replay work and costs latency and storage; or mark the receipt external and accept that verification establishes structure and signature but not the verdict. Dishonest: omit the determinism field, let verifiers replay, and let them read a divergence as fraud when it means Tuesday. That is why the field is mandatory in the claim set rather than optional.

The interval between decision and effect is unrepresented. The receipt is issued at T. The effect lands at T plus a delta. Anything that changes in that window — a revoked mandate, a frozen account, a policy update, a limit breach elsewhere in the book — is invisible to a receipt that was correct when written and may be wrong when used. Short expiry narrows the window and cannot close it, because closing it would require decision and effect to be one atomic operation across a network, which they are not. 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, so that an investigator can establish how wide the window was instead of guessing.

A constructed illustration, to make that concrete — it describes no real institution and no real incident. An agent proposes a payment against an intraday limit; the decision point evaluates against a limit snapshot and issues an allow valid for ninety seconds; in the interval, an unrelated desk consumes the remaining limit; the payment lands and breaches. Every artefact in this design behaves correctly throughout, and the breach happens anyway. The receipt does not prevent it. What the receipt does is make the ninety seconds a matter of record rather than a matter of reconstruction, which is the difference between an investigation that concludes and one that stalls.

One unreceipted path makes the whole arrangement decorative. The batch job that runs at two in the morning against the same core service. The legacy channel the migration never finished. The vendor's own administrative console, which reaches your data through a route your gateway does not sit on. Any one of these means the honest answer to “can every action against this resource be tied to an authority record” is no, and an examiner who finds the exception has learned something true about the estate: that the control is a property of one path rather than of the resource. The costly, unavoidable work in this design is not the cryptography. It is enumerating every route to the resource and putting the gateway in front of all of them.

A signed allow cannot prove that no second allow was issued quietly. Nothing in a signed artefact prevents the issuer from producing another one, back-dated, off to the side. That is what the append-only index is for, and it is worth being exact about what an append-only index buys, because the transparency-log literature is unusually honest on this point and the honesty tends to get lost when the pattern is borrowed. It buys detection, not prevention. An interested party can discover that a receipt was issued outside the ordered history. Nobody is stopped from issuing it.

And the largest one: no supervisor has asked for this. The design satisfies no published requirement, because as established at the top, none exists for this layer. An examiner may look at a signed content-addressed record with a delegation chain and an offline verifier and ask, reasonably, why the bank did not simply extend its existing audit tables and add a decision column. If the answer is that a signed artefact is more impressive, the bank has spent money on a fashion. The answer that holds is narrower: the properties are what matter — written before the fact, checkable without you, bound to exact policy bytes — and if your audit tables give you all three, you already have an evidence layer and you should stop reading. Most do not give you the first.

One open question, stated as open because I would rather publish an unmeasured question than a manufactured number. Nobody appears to have measured what fraction of an agent's actions can have their authorising decision reconstructed from logs alone, as a function of elapsed time and policy churn. I could not find a regulator, standards body or vendor publication that quantifies it. My expectation is that the curve falls sharply in the first quarter after a policy migration, and that expectation is a hypothesis rather than a finding. It is the measurement I most want to run, and until it is run, the honest form of the argument is qualitative.

What it costs

The costs are not where teams expect them, which is why they get discovered late and blamed on the wrong component.

Latency: small, and I have not measured it in a bank. Issuance is one canonicalisation, one hash and one signature over an object of a few hundred bytes to a few kilobytes. On any modern server that is not the expensive part of a decision path that already includes a policy evaluation and, usually, a model call. What I will not do is quote you a millisecond figure, because I have not measured this inside a payments or origination path and a plausible number invented at a desk is worse than no number. The measurement I intend to run is stated plainly: added p50 and p99 latency at the decision point, at a stated request rate, on stated hardware, with the evidence-freezing path both on and off — because freezing live inputs to make a receipt replayable is the one part that could plausibly dominate.

Retention: this is the real bill, and nobody will tell you the number. Neither the 2026 guidance nor the 2011 guidance it replaced sets a retention period for anything like this. So the period is your assertion, which is why it is a field on the record rather than a line in a runbook. And the cost is not the receipts, which are small; it is the evidence they commit to, which is not. A receipt that digests a retrieved document set and a customer record as read has quietly created an obligation to keep those artefacts for as long as the receipt is meant to be checkable. Size that before you build, not after, and size it against the decision mix you actually have rather than the one in the design document.

Migration: the gateway, and only the gateway. Emitting receipts is easy — a shim beside your policy engine. Consuming them is easy — a header on a call. Refusing on their absence is the whole project, because it requires you to know every path to every protected resource, and the honest state of that knowledge in a large bank is partial. Expect the discovery phase to be longer than the build. Expect at least one path that nobody currently owns. That path is not a project risk; it is the finding, and it would have been a finding in an examination too.

Key custody, which becomes a standing operational concern. The whole vendor-independence property rests on the signing key being the bank's. That means key generation, rotation, revocation, and the awkward question of what a receipt signed by a rotated key means five years later. None of this is novel — banks run key custody at scale — but it moves the evidence layer from an application concern to an infrastructure one, and the team owning the agent platform is not the team owning key custody. Budget for that conversation.

And an organisational cost that is easy to miss. The authority layer is not a model, on the guidance's own definition, which means it does not automatically fall to the model risk function — and the model risk function is where the people who understand supervisory evidence sit. Somebody has to decide who owns it. Left undecided, it lands with the platform team, who will build it correctly and describe it in a language no examiner speaks. The most valuable hour in this whole programme is the one where the model risk function writes the reconstruction paragraph it wants to be able to hand over, and the platform team treats that paragraph as the specification.

The strongest argument against building it

I want to put the counter-argument at full strength, because it is a good one and because the version usually offered is a straw man.

It runs like this. The agencies have just told you, in writing, that this guidance sets no enforceable standards and that non-compliance will not result in supervisory criticism. They have put agentic systems outside its scope. They have removed the reconstruction standard rather than strengthening it. Every signal from the supervisory community points toward less prescription in this area for the foreseeable future, not more. Against that backdrop, a bank that builds a cryptographic evidence layer for agentic authority is gold-plating an obligation that does not exist, at a moment when every discretionary technology budget is contested, and the programme will be cancelled in its second year by an executive who reads the same guidance and asks why we are doing this. Meanwhile a competitor spends nothing, ships faster, and is criticised by nobody.

Three answers, in increasing order of weight. The first is the enforcement hook, which is not a matter of interpretation: the footnote attached to the very sentence about enforceable standards preserves supervisory action for violations of law or unsafe or unsound practices stemming from insufficient management of model risk. The relief is from criticism for not following the guidance. It is not relief from consequences for the underlying conduct. Those are different things and the agencies wrote them one after the other.

The second is that at least one obligation in this space binds today and is untouched by any of it. Regulation B requires specific principal reasons for adverse action, and it names two formulations as insufficient. An agentic credit decision whose basis was never materialised cannot produce those reasons after the fact, whatever the state of model risk guidance. That is not anticipatory work. That is a live requirement your agent estate may already be failing, and the receipt is one way to fail it loudly at the moment of decision rather than quietly at the moment of complaint.

The third is the one I find most persuasive and can support least, so I will mark it as reasoning rather than evidence. The agencies' own cover documents announce an intention to seek information on model risk management generally and on banks' use of AI, including generative and agentic AI, in particular. A request for information is a consultation step — it is not a rule, it is not draft guidance, and as of the date on this piece I could not find one published in the Federal Register, so nothing is pending in any concrete sense. But consultations are answered by whoever has something to say, and specifications get written against whatever the answering institutions have already built. A bank that can show a working authority record when that conversation opens is not merely compliant with the eventual result. It is one of the institutions the eventual result gets drafted around. That is a strategic argument rather than a supervisory one, and it should be presented to a board as such.

There is also a version of the counter-argument I concede outright. If your existing audit tables already record the authorising decision at the time it was made, alongside the identity of the policy version and enough of the inputs to re-run it, and if your retention holds those inputs, then you have an evidence layer and the signing is a refinement rather than a requirement. Signing buys you the ability to hand it to somebody who does not trust your database administrators. Whether that matters depends entirely on who you expect to be answering to, and for a domestic bank answering to a familiar examiner it may not. For an institution whose supervisor sits in a different jurisdiction from its vendor — a bank in Mumbai or Riyadh whose agent platform is operated from somewhere else entirely — it matters a great deal, and that is the same design, in the same shape, for a different reason.

What to build first, given one week

The failure mode of this kind of design is the eighteen-month programme that produces a framework document. Here is the version that fits in a week and produces something an examiner could be shown at the end of it.

1. *Day one: pick one action, not one system.* One capability, on one resource type, in one workflow where an agent already acts on something that matters. Resist every instinct toward coverage. The output of day one is a sentence naming the action, and the name of the person who owns the path to it.
2. *Day two: write the verifier first.* Not the issuer. The verifier is the artefact that defines what the other components must produce, and writing it first stops you from designing a claim set around what is convenient to emit. When it compiles, you have a specification. Hand it to the model risk function and ask whether its output would satisfy them; their answer is the requirements document.
3. *Day three: emit beside the existing decision, refusing nothing.* The decision point already reaches a verdict. Emit a receipt alongside it, sign it, store it, and change no behaviour at all. Nothing enforces yet. What you are buying is a week of real receipts issued against real decisions, which is the only way to discover that your policy revisions are not stable identifiers or that half your decisions consult state you never captured.
4. *Day four: correlate.* Write the receipt identifier into the book-of-record entry the action produces. This is the least glamorous day and the one that determines whether the evidence layer is usable, because an authority archive that cannot be joined to the effect archive answers no question anybody actually asks.
5. *Day five: turn the gateway to refuse, for that one capability, and watch what breaks.* It will break something. The thing it breaks is the finding — a path nobody knew reached the resource, a service account that was never in the delegation model, a batch job with its own credentials. Write that down. It is the most valuable output of the week and it is the one you would otherwise have paid an examiner to discover for you.

What you have at the end of the week is one capability whose authority is materialised, verifiable and enforced, and a written list of everything that turned out to reach the same resource by another route. What you do not have is a control framework, a supervisory answer, or coverage. Present it as one action done properly, and a map of the work.

And be clear-eyed about which claim you are making. The agencies removed the sentence that required a stranger to be able to reconstruct how a system reached its result. They did not remove the situations in which somebody will need to. The gap between those two facts is where this design lives, and it will stay open until somebody writes the specification — at which point the institutions that already have the artefact will find their practice described rather than corrected.