A trading-adjacent agent routes an order, a servicing agent adjusts a customer's account, a controls agent files an exception — and when someone asks on whose authority, the honest answer in most estates is a service account, a shared API key, or a session token that outlived the session. The companion teardown to this piece, Who authorised it is a question with a regulatory answer and no technical one, walks the evidence that supervision has an owner for that question and the stack has no field for it. I am going to take that as established. What follows is the design I would build against it, in the one sector that both needs it most and has already written most of its structure into binding rules.

The reason to start here is not that banks are the largest buyers. It is that in April 2026 the banking agencies withdrew the framework everyone assumed would eventually specify agent controls, and in the same document told institutions to determine those controls themselves. That is an uncomfortable position to be handed, and the cleanest mandate available to build a primitive rather than wait for one.

The ground the design has to stand on

On 17 April 2026 the Board of Governors of the Federal Reserve System, the Federal Deposit Insurance Corporation and the Office of the Comptroller of the Currency issued a shared document titled Supervisory Guidance on Model Risk Management. The Federal Reserve distributes it as the attachment to SR 26-2; the OCC issues it as Bulletin 2026-13; the FDIC circulates it with FIL-15-2026. Three delivery vehicles, one text. That matters for a reason I will come back to, because the summaries the agencies wrote around the shared text are not identical to it.

The supersessions are worth keeping straight, because they are frequently merged into one list and they are three separate lists. The Federal Reserve's SR 26-2 supersedes SR 11-7 (4 April 2011) and SR 21-8 (9 April 2021). OCC Bulletin 2026-13 rescinds four OCC issuances: the Model Risk Management booklet of the Comptroller's Handbook; OCC Bulletin 1997-24, Credit Scoring Models: Examination Guidance, including its appendix on safety and soundness and compliance issues; OCC Bulletin 2011-12; and OCC Bulletin 2021-19, the BSA/AML interagency statement on model risk management and request for information. The FDIC's FIL-15-2026 rescinds FIL-22-2017 and FIL-27-2021. SR 11-7 was never an OCC issuance and the OCC did not rescind it; anyone who tells you otherwise has read a summary of a summary. SR 11-7 is superseded, and it should now be cited only as superseded.

The sentence this whole piece hangs on is footnote 3 of the shared guidance, and it is four sentences long. Three of them are routinely dropped, and the third is the one that changes the argument.

Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. 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.
— Supervisory Guidance on Model Risk Management, 17 April 2026, footnote 3 — the shared interagency text, distributed as the SR 26-2 attachment

Read the third sentence twice. The agencies removed agentic systems from the scope of the framework and, in the next breath, assigned the institution responsibility for determining the appropriate governance and controls over them. That is not an exemption. It is a transfer of the specification problem from the supervisor to the supervised — and since the institution is the party that will have to defend whatever it determines, the transfer runs in the direction of more work, not less.

Outside the framework, twice over The layer where authority actually passes between agents falls outside the April 2026 guidance on two independent grounds. THE ORCHESTRATION LAYER Planner decides the next step Router selects an agent Dispatcher executes the tool call Policy engine permits or denies This is where authority passes from one component to the next. CARVE-OUT ONE — FOOTNOTE 3 Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance. The agent is outside because it is agentic. Interagency guidance, 17 April 2026. CARVE-OUT TWO — THE DEFINITION The term model excludes deterministic rule-based processes and software where there are no statistical, economic, or financial theories underpinning their design or use. A dispatcher is not a model to begin with. WHAT THE AGENCIES HAND BACK — SAME FOOTNOTE, THIRD SENTENCE 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. The carve-out moves the specification problem to the institution. Footnote 1 keeps the enforcement hook: supervisory action may still result.

There is a second carve-out sitting underneath the first, and it is easy to miss because it is not about AI at all. The guidance defines what it means by a model, in Section II: the term 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 expressly 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. A planner is not that. A router is not that. A tool dispatcher, a retry policy, a policy engine that permits or denies a call — none of those is a complex quantitative method applying financial theory to produce estimates. They are software.

So the layer at which authority actually passes from one component to another falls outside the framework on two independent grounds: it is agentic, and it was never a model to begin with. Both carve-outs are in the agencies' own text. Neither of them touches the obligation attached to the underlying action.

Two further sentences from the guidance make the position precise, and they need to be quoted from the guidance rather than from the agencies' summaries of it. The first, from the Introduction: 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. Note the trailing words. The FDIC's own FIL-15-2026 Highlights renders the same sentence with the word alone inserted — non-compliance with this guidance alone — and the OCC bulletin's Highlights carries it without. The guidance document is the authority. A banking reader who checks the primary text against a version quoted with alone will find a mismatch, and in this sector being caught out on a word is how a whole argument loses its footing.

The second sentence is footnote 1, which is attached to the non-enforceability sentence and does the opposite work. It cites the agencies' own rules on the status of supervisory guidance — 12 CFR Part 4, Subpart F, Appendix A for the OCC; 12 CFR Part 262, Appendix A for the Board; 12 CFR Part 302, Appendix A for the FDIC — and then adds: However, supervisory action may result for any violations of law or unsafe or unsound practices stemming from insufficient management of model risk. The framework is disclaimed in the sentence and the enforcement hook is retained in the footnote to it. That is the whole basis for reading this as a deferral rather than an exemption, and it is not an inference I am supplying — it is in the document.

One piece of background worth stating once so it does not get overclaimed later. Supervisory guidance in US banking has never had the force of law. The 2023 interagency third-party guidance says so in terms: Supervisory guidance does not have the force and effect of law and does not impose any new requirements on banking organizations. So the April 2026 non-enforceability sentence is not a novel concession — it is the standing status of all supervisory guidance, restated. What is genuinely new in April 2026 is the scope carve-out, not the non-enforceability.

The natural response is that a specification is coming, so the sensible thing is to wait. That reading does not survive contact with what the agencies actually committed to. OCC Bulletin 2026-13's Background section says the agencies will continue to consider additional measures to address model risk management consistent with broader supervisory and other goals, and then: For example, the agencies plan to issue in the near future a request for information that addresses model risk management generally and considers, in particular, banks' use of AI, including generative AI and agentic AI and AI-based models. A request for information is a consultation step. It precedes a proposal, which precedes a comment period, which precedes a rule or a piece of guidance. And the lead-in clause is doing real work: the agencies describe themselves as continuing to consider measures, not as drafting one.

As of 18 August 2026 — four months after the announcement — that request for information has not been published. A Federal Register document query restricted to the OCC, the Federal Reserve System and the FDIC, for documents published on or after 17 April 2026, returns two documents matching artificial intelligence: an anti-money-laundering and countering-the-financing-of-terrorism proposed rule published 9 July 2026, and a payment-system-risk notice published 26 May 2026. Neither is a model-risk-management request for information. The query is reproducible, it is dated, and anyone can re-run it. The consultation step announced in April has not begun. The agencies committed to considering measures and to issuing a request for information, and nothing beyond that has been committed to at all — so whatever eventually specifies agent controls in this sector is several procedural steps further away than most institutions appear to assume. Every one of them deploying agents in the interval is determining its own controls, whether or not it has decided to.

Four premises, and the fifth this sector forces

The general primitive rests on four statements, argued at length elsewhere and restated here compactly so that a reader who rejects one can say which.

  1. Carried, not ambient. A component acts on authority handed to it for a stated purpose, never on authority it happens to possess by virtue of where its process is running.
  2. Every hop mints a weaker credential naming its parent. No new credential means no edge to record and no boundary to enforce; no named parent means a pile of grants with no ancestry, which answers who acted and never on whose authority.
  3. Verifiable without replay. What is presented at the boundary must be sufficient on its own — no issuer call, no telemetry join, no reconstruction after the fact.
  4. Monotone attenuation. A child cannot exceed its parent, because the only constructor available computes an intersection. Over-delegation stops being a mistake to avoid and becomes a state with no route to it.

This sector adds a fifth, and it is the one that gives the design its shape here rather than anywhere else.

Five: the root of every chain is a named natural person. Not a role. Not a team. Not a service principal that a role owns. A person of record, identified by something that survives a change of login and a change of mailbox, holding a mandate that predates the agent and would exist if the agent were switched off tomorrow. The consequence is that the walk from any action to an accountable individual terminates at a person by construction rather than by convention, and terminates in a bounded number of steps that a verifier can count.

That premise is not an aesthetic preference. It is what the guidance's own governance section already expects. Under Roles and Responsibilities, the April 2026 text states that sound governance practices delineate the individual(s) responsible for key activities throughout the model lifecycle, from development through validation and ongoing monitoring. Individuals, delineated, per activity. An ambient-context handoff between agents destroys exactly that: after two hops there is no individual delineated for anything, because the handoff carried context and not authority, and context does not have an owner.

The same section addresses delegation outward: For banking organizations that use external resources to help manage model risk, sound practice involves maintaining proper oversight and integrating that work into broader model risk management activities. Organizations benefit from clearly defining roles and responsibilities when delegating these activities. Clearly defined roles at the point of delegation is premise two, written for humans. All this design does is make it true of the machine hops as well.

Now the strongest objection, at full strength, before the design rather than after it — because it is a good objection and I do not have a clean answer to it.

You are proposing that a named managing director stands at the head of a credential chain whose downstream hops are decided at runtime by a model. In practice one of two things happens. Either that person refuses to sign anything they cannot enumerate in advance, and the agent programme does not ship; or they sign a root grant broad enough that the agent never fails, at which point the chain terminates at a person who has, in any meaningful sense, authorised nothing. You have not created accountability. You have created a signature block.

That is correct about the failure mode, and I will come back to it in the failure analysis rather than pretending the design defeats it. What I claim is narrower and I think it holds. In an ambient-authority system, the broad grant is a configuration value: it has no author, no timestamp, no review, and it is discoverable only by reading the deployment history of a file. In a carried-authority system, the broad grant is a signed root with a named person on it, a scope written down in the same vocabulary the desk uses, and a date. It does not prevent the wide grant. It makes the wide grant a document. Most of what governance does, in this sector and every other, is convert absences into documents so that somebody can look at them later and ask why.

What the premises force

The general consequences of the first four are worked through in the sector-neutral piece and I will not repeat them. What is worth doing here is asking what they force in a bank, because two of them bind differently in this sector than anywhere else, and the fifth has no analogue outside it.

Verifiable without replay is usually argued on latency and availability grounds. In this sector the binding reason is different and much stronger: an examiner asking for evidence a year after the fact is, functionally, an offline verifier. If establishing that an action was authorised requires the running system to answer, the evidence has a dependency on a platform that may by then have been decommissioned, migrated, or rewritten by a team that has since dispersed. Evidence whose validity expires with an environment is not evidence; it is a demonstration. The reason to insist that a chain verifies from the bundle plus one cached key is that the bundle survives the environment, and in a regime with multi-year retention obligations that is the property that actually matters.

Monotone rules out the flow most teams reach for first — the child states what it wants and something decides whether to grant it — because that flow can produce a child holding more than its parent whenever the deciding component is wrong, misconfigured or persuaded, and one of the components in an agent system is a language model inside a tool loop, which is a category of thing that can be persuaded. There is a familiar analogue on any trading floor: nobody raises their own limit by asking the risk system nicely for a bigger one. The limit comes down from a mandate, and the only move available below it is to use less of it. That is the whole of monotonicity, and the sector has run on it for decades in the human case.

Root is a person rules out the two shortcuts that make every other premise cosmetic: a root grant minted for a service account, and a root grant minted by an automated provisioning path with no human anywhere in it. In the reference package the root constructor takes a natural person as its parameter type, so a workload identity cannot be passed to it — the call does not compile. That is a small piece of type discipline doing a disproportionate amount of work. The alternative is a runtime check, and a runtime check is precisely the sort of control that gets relaxed at the end of a delivery quarter by someone who intends to put it back.

The sector already wrote this rule down

The reason to make this argument in banking and capital markets first is not that the regulators asked for it. It is that they already mandated the same structure, for humans and for firms, in binding rules that have been in force for years. The design below is not novel. It is an existing regulatory pattern applied to a new class of actor.

SEC Rule 15c3-5 is attenuated delegation, already compulsory. The Market Access Rule starts from exclusivity. Paragraph (d) requires that the risk management controls and supervisory procedures shall be under the direct and exclusive control of the broker or dealer. Then it opens one narrow door. Paragraph (d)(1) permits a broker-dealer to reasonably allocate, by written contract, after a thorough due diligence review, control over specific regulatory risk management controls and supervisory procedures described in paragraph (c)(2) to a customer that is itself a registered broker or dealer — and only where the allocating firm has a reasonable basis for determining that the customer has better access ... such that it can more effectively implement the specified controls.

Count the properties. The delegation must be explicit. It must be written. It must be preceded by diligence. It must be scoped to enumerated controls rather than granted wholesale. It may only go to a counterparty of a qualifying class. And then paragraph (d)(2) closes it: Any allocation of control pursuant to paragraph (d)(1) of this section shall not relieve a broker or dealer ... from any obligation under this section. Capability moves outward. Responsibility does not attenuate. That is a carried, attenuated, parent-naming grant with non-diminishing accountability at the root — adopted as a rule in this sector in November 2010, with compliance phased in from July 2011.

There is a further paragraph worth reading beside the design. Rule 15c3-5(c)(2)(iii) requires controls reasonably designed to restrict access to trading systems and technology that provide market access to persons and accounts pre-approved and authorized by the broker or dealer. Pre-approved and authorised, by name. An agent that reaches a trading system through an inherited service account is not a pre-approved and authorised person or account; it is a hole in the population the control was designed over.

The same rule about accountability exists for third parties, in plain words. The 2023 interagency third-party guidance states the non-delegable principle without hedging: Whether activities are performed internally or via a third party, banking organizations are required to operate in a safe and sound manner and in compliance with applicable laws and regulations. A banking organization's use of third parties does not diminish its responsibility to meet these requirements to the same extent as if its activities were performed by the banking organization in-house. That is the supervisory statement of monotonicity, and it predates the AI question by years.

The April 2026 guidance adds the opacity case, which matters because a great many agent components in a real estate are somebody else's. Its vendor section: 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. Not being able to see inside a component is expressly not a reason the principles stop applying. Transfer that to a hosted tool endpoint or a third-party agent in a chain and the design consequence is immediate: you cannot inspect it, so the control has to be what you hand it, not what you hope it does. A call grant scoped to one action, one resource and thirty seconds is a control you can evidence. A shared credential and a contractual assurance is not.

Rule 613 is a carried identifier across every handoff, including the internal ones. The Consolidated Audit Trail is the closest thing in existing regulation to an authority graph, and it is instructive precisely because of what the SEC chose. Rule 613(c)(1) requires an accurate, time-sequenced record of orders beginning with the receipt or origination of an order ... and further documenting the life of the order through the process of routing, modification, cancellation, and execution. The field list in (c)(7) is where the design lesson sits. At origination: the Customer-ID for each customer, the CAT-Order-ID, and the CAT-Reporter-ID of the broker-dealer receiving or originating the order. For each routing event, both ends — the CAT-Reporter-ID of the party routing the order and the CAT-Reporter-ID of the party to which it is being routed. And, in a clause that reads like it was written for this problem: If routed internally at the broker-dealer, the identity and nature of the department or desk to which an order is routed.

Every hop names a sender and a receiver, internal hops included, and a stable originating identifier travels the whole way. The sector's answer to attribution across handoffs, for order flow, is a carried identifier rather than reconstruction after the fact — arrived at by a regulator with considerable practical experience of how badly reconstruction goes.

The data model

A grant is the only thing that travels. It carries the root principal, a permission set, a caveat set, a pointer to its parent, and a seal binding it to the chain above. Four properties are load-bearing, and the fourth is the one this sector adds:

  1. Widening is not an operation. `attenuate` returns an intersection, and nothing in the package returns a superset. Over-delegation is not refused at runtime — there is no function that would perform it.
  2. A child's seal is keyed by its parent's. Holding a child gives you the terminal value and no way to invert it, so a holder can extend the chain downward and cannot climb it. That is what makes the parent pointer structural rather than a claim the child chose to include.
  3. Stated authority is never trusted. The permission list written on a grant is there for the holder and for the record. The verifier walks from the root and recomputes, so a link claiming more than the chain permits is evaluated on the chain. Without this, the invariant depends on every minting party being honest, and one of them is a model deciding what to call next.
  4. The root principal travels on every link. Not looked up in a directory at verification time — carried, and checked for consistency at every hop. A verifier in a resource server that has no access to the institution's HR system can still name the accountable individual, which is the difference between an artefact that can be handed to a reviewer and one that requires a live integration to interpret.

The caveat vocabulary is where the sector shows up in the types. A general-purpose delegation package carries expiry, audience and invocation limits. A banking one also carries a notional cap, an instrument-class list, a venue list and a second-authoriser obligation, because those are the terms in which a mandate is actually written on a desk. Getting that vocabulary right is not cosmetic: if the caveats do not map onto the language the first line of defence already uses, the root grant becomes a translation exercise, and translation exercises are where scope quietly widens.

Configuration

@authority/delegation — the banking instantiation

The core of the reference package as it is instantiated for this sector. Four files: the principal and grant types, the monotone constructor, the offline verifier that also returns the accountable individual, and the property test that is the only reason to believe any of it. Cryptography, identifier generation, clock and resource-pattern containment are all injected, because a delegation library must not choose an institution's key management and must not parse a desk's resource namespace.

The fifth premise is enforced here and nowhere else. `mintRoot` takes a `NaturalPerson`, so a workload identity cannot be passed to it — not because a check rejects it, but because the call does not typecheck. A runtime check is a control someone can relax under delivery pressure; a parameter type is a control someone has to rewrite the function to relax, which leaves a diff.

src/principal.ts
/** A person of record inside the institution. Not a login, not a service account, not a role.
 *  Identified by something that survives a change of login, mailbox or directory entry. */
export interface NaturalPerson {
  readonly kind: "natural-person";
  readonly personnelId: string;
  readonly legalName: string;
  /** The standing mandate under which this person may issue a root grant at all. Exists
   *  independently of the agent, and would exist if the agent were switched off. */
  readonly mandateRef: string;
}

/** Everything that is not a person. Present so the type system can refuse it as a root. */
export interface WorkloadIdentity {
  readonly kind: "workload";
  /** SPIFFE-shaped by convention; opaque to this package. */
  readonly spiffeId: string;
}

export type Principal = NaturalPerson | WorkloadIdentity;

export const isNaturalPerson = (p: Principal): p is NaturalPerson =>
  p.kind === "natural-person";

export interface Permission {
  /** Verb in the resource server's namespace, e.g. "order:route". Compared, never parsed. */
  readonly action: string;
  /** Resource pattern in the resource server's grammar. Compared via an injected predicate. */
  readonly resource: string;
}

export type Caveat =
  | { readonly kind: "expires-at"; readonly epochMillis: number }
  | { readonly kind: "audience"; readonly resourceServer: string }
  | { readonly kind: "max-invocations"; readonly count: number }
  /** Desk vocabulary. Minor units as bigint: no float ever touches a notional. */
  | { readonly kind: "notional-cap"; readonly currency: string; readonly minorUnits: bigint }
  | { readonly kind: "instrument-class"; readonly classes: readonly string[] }
  | { readonly kind: "venue"; readonly venues: readonly string[] }
  /** A second named person must discharge this before the action is permitted. */
  | { readonly kind: "second-authoriser"; readonly personnelId: string; readonly challenge: string };

export interface Authority {
  readonly permissions: readonly Permission[];
  readonly caveats: readonly Caveat[];
}

export interface Grant {
  readonly id: string;
  /** null only at the root. A child's seal depends on its parent's, so this cannot lie. */
  readonly parentId: string | null;
  /** Carried on every link rather than looked up, so a verifier needs no directory. */
  readonly root: NaturalPerson;
  readonly issuer: Principal;
  readonly subject: Principal;
  /** Convenience for the holder and for the record. The verifier recomputes instead. */
  readonly authority: Authority;
  readonly issuedAtEpochMillis: number;
  /** Terminal MAC of the chain, base64url. */
  readonly seal: string;
}

/** Resource-pattern containment. Injected because the grammar belongs to the resource server. */
export type Covers = (parentPattern: string, childPattern: string) => boolean;

/** Safe default for a caller with no pattern grammar. Narrower than most callers want, which
 *  is the correct direction for a default to be wrong in. */
export const exactMatch: Covers = (parent, child) => parent === child;

export interface Env {
  readonly mac: (key: Uint8Array, message: Uint8Array) => Uint8Array;
  readonly newId: () => string;
  readonly nowEpochMillis: () => number;
}

Encoding, the property-test arbitraries and the MAC implementation are omitted for length, not because they are trivial: canonical serialisation in particular is a security-relevant component, because two encodings of the same logical grant that differ by a byte produce two different seals, and a verifier that accepts either has a malleability bug rather than a formatting inconsistency.

The control path, hop by hop

The chain, top to bottom Six layers. The root is a person, every hop below it is strictly no wider, and the record is written whether or not anyone reads it. LAYER WHAT IT HOLDS AUTHORITY CARRIED 0 — ROOT A named person An accountable individual holding a supervisory mandate. There is no constructor that mints a root for a service account, a team alias, a robot user or a deployment identity. 1 — MANDATE Desk grant Scoped to a desk or business line. Notional cap, instrument-class list, venue list, validity window. Issued by a person, to a system, in a signed act with a timestamp. 2 — AGENT Task grant Scoped to one task, taken from the desk grant by intersection. Shorter window, narrower instrument list, lower cap. Names its parent structurally: the seal depends on the parent seal. 3 — TOOL Call grant Scoped to a single call against a single resource server. Single-use caveat, audience caveat, and an expiry in seconds. A third-party agent gets one of these and never the desk grant. 4 — ENFORCE Verifier Sits at the resource server. Verifies offline, with no call home. Recomputes the running intersection from the root rather than trusting the authority field written on the grant it was handed. 5 — EVIDENCE Authority record Append-only. One row per hop, written at issue time, not at query time. Granting party and receiving party both named on every row, including internal hops, and cross-referenced to the trace for context. Monotone means non-increasing. A child holds less than its parent, or the same — never more, because no function exists that would widen it.

Six layers, and the discipline is in which of them are allowed to make a decision.

Layer 0 — the root. A named person mints a root grant against a per-institution key. This is a human-facing act with a form, an approver and a record, because it is the only point in the whole system where authority is created rather than narrowed. It should feel like signing something, and it should be rare. If a team is minting root grants weekly, the scoping is wrong one layer down.

Layer 1 — the mandate grant. Scoped to a desk or business line in the desk's own vocabulary: notional cap, instrument classes, venues, a validity window that expires without anyone intervening. This is the layer where the first line of defence should be able to read the grant and say whether it matches the mandate they already run — and if they cannot read it, the caveat vocabulary is wrong.

Layer 2 — the agent grant. One task, taken from the mandate grant by intersection. Short window, narrower instrument list, lower cap. This is the first hop where a machine decides the shape of the restriction, and the only thing preventing over-delegation is that the constructor cannot produce it.

Layer 3 — the call grant. Single call, single resource server, single use, an expiry measured in seconds. A third-party agent or a hosted tool endpoint receives one of these and never receives anything higher. This is where the vendor-opacity argument lands: you cannot inspect the component, so the control is what you handed it.

Layer 4 — the verifier. At the resource server. Recomputes the running intersection from the root, checks the caveats against the request, and returns both a decision and the accountable person. It makes no network call. A resource server that must ask a central service whether a grant is real has re-created the dependency the third premise exists to remove.

Layer 5 — the record. Append-only, one row per hop, written when the grant is issued rather than assembled when someone asks. Both parties named on every row, internal hops included — which is Rule 613's answer, applied to a different kind of handoff. The record is the deliverable. Everything above it exists to make the record true.

Two ideas hold that stack together, and the rest is the engineering required to make them survive a model deciding the middle: only the top layer creates permission, and every layer below it can subtract and do nothing else; and the bottom layer writes down what happened while it happens, rather than working it out on request.

What an examination actually asks for

An examination is not a design review. The distinction is the whole reason this design is shaped the way it is, and it is the thing most agent-governance material gets wrong: it produces architecture diagrams for an audience that will ask for records.

What the examiner asks, and what the chain returns A constructed illustration. No real transaction, institution or examination is depicted. THE REQUEST Show me one action this system took last quarter, who authorised it, and that the authorisation was no wider than the mandate they held. ACTION Order routed one venue, timestamped CALL GRANT Single use one venue, seconds of life AGENT GRANT One task narrower list, shorter window DESK GRANT One desk notional cap, class list ROOT A person named, with a mandate on file Each arrow is a parent identifier, and the seal of the child depends on the seal of the parent. The walk terminates at a person by construction. WHAT THE CHAIN RETURNS A bounded walk of four links. The same answer on every rerun. Child authority compared against parent authority at each hop. Verifiable without access to the running system. WHAT RECONSTRUCTION RETURNS A join across systems whose retention policies differ. An answer that depends on sampling. An inference about intent, rather than a record of a grant. A result that moves when someone rewrites the query. The first is evidence. The second is an argument about evidence. Constructed illustration: the scopes and lifetimes shown are invented to display the shape of the walk, not drawn from any real system.

The figure is a constructed illustration; no real transaction, institution or examination is depicted. What it shows is the shape of the two available answers. A chain returns a bounded walk, the same result on every rerun, an authority comparison at each hop, and a verification needing no access to a running system. Reconstruction returns a join across systems whose retention policies were set independently, an answer sensitive to sampling, an inference about intent standing in for a record of a grant, and a result that moves when somebody rewrites the query.

The difference is less about rigour than about who has to be in the room. A reconstructed answer needs the engineer who knows how to write the query, and it decays every time that engineer changes team. A carried answer is a signed document, which is how this sector has always moved accountability across time.

There is an honest open question underneath this and I am not going to paper over it. Nobody has published a measurement of how attribution accuracy degrades as the number of agent-to-agent handoffs grows. I looked for one — from regulators, from standards bodies, from vendors — and found nothing I would cite. It is a genuinely open empirical question, and the reason it matters is that the entire case for carrying authority rather than reconstructing it rests on an intuition about that curve rather than on a number. I believe reconstruction gets rapidly worse with depth. I cannot show you how rapidly, and anyone who quotes you a figure for it should be asked where it came from.

Failure modes of this design

Seven, in rough order of how likely they are to be the thing that actually goes wrong.

One: the root becomes a signature block. This is the objection quoted above and it is the most probable failure by a wide margin. A named person signs a root grant broad enough that the agent never fails, and thereafter the chain terminates at someone who authorised a category rather than an action. The design does not prevent this. What it does is make the breadth legible: the root grant is a document with a scope written in desk vocabulary, and a reviewer can put it beside the desk's actual mandate and see the gap. The mitigations are unglamorous — cap root grant validity in weeks rather than years, require re-issue rather than extension, and report the ratio of authority granted at the root to authority actually exercised beneath it. None of them is a control. All of them are ways of making the gap visible to someone whose job is to look.

Two: monotone does not mean safe. A narrower authority is not automatically a smaller blast radius. A grant restricted to one instrument class and one venue, held by an agent operating in a loop, can do more damage than a broad grant used once. Monotonicity caps what a delegate may do relative to its parent; it says nothing about frequency, aggregation or correlation across sibling chains. Rate, concentration and aggregate exposure are separate controls, and this design deliberately does not attempt them — it makes them expressible as caveats, which is a different and much weaker claim.

Three: these are bearer credentials unless you add possession binding. A grant that leaks is a grant that works, within its caveats, for whoever holds it. The reference package has a place for a subject public key and a possession proof, and the honest position is that a deployment without one is relying on transport security and process isolation for the property the credential appears to provide. Adding possession binding costs a signature per hop and a key per subject, and it is the first thing I would add after the record is populated — not before, because a possession-bound credential nobody is emitting protects nothing.

Four: revocation and offline verification pull against each other. The third premise says the verifier needs nothing but the chain and a cached key. Revocation says a grant that was valid a moment ago must stop working now. Those cannot both be absolutely true. The available compromises are all unsatisfying: short expiries, which trade revocation latency for issuance volume; a revocation epoch on the root key, which is a blunt instrument that invalidates every descendant at once; and a bloom-style deny set distributed to verifiers, which reintroduces a distribution dependency in a form that fails open. I would ship short expiries plus a root epoch, document the revocation latency as a number, and stop pretending it is zero.

Five: chain depth is a real operational limit. Each link carries two principal identifiers, a permission list, a caveat list and a seal. A chain of eight hops with a handful of permissions per link is a header measured in kilobytes, and intermediate proxies with header-size limits will notice before anything else does. The design's answer is a depth cap enforced at the verifier, which is honest but has an unpleasant consequence: a legitimate deep workflow fails, and the operator's easiest fix is to flatten the chain by granting more at the top. The failure mode of a depth cap is over-delegation, which is the thing the whole design exists to prevent.

Six: the caveat vocabulary will be wrong the first time. Notional cap, instrument class, venue and second authoriser are the four I would start with, and they are the four I would expect to be arguing about six months in. Desk mandates carry conditions this vocabulary cannot express — time-of-day restrictions tied to a specific market calendar, netting conventions, conditions that depend on positions the verifier cannot see. The escape hatch is a third-party caveat that defers to a named service the verifier does not have to model, and the cost of the escape hatch is that it puts a network call back on the path for exactly the decisions that most need to be fast.

Seven: this covers authority and not correctness. A perfectly verified chain establishes that an action was permitted by a named person's mandate. It establishes nothing about whether the action was a good idea, whether the model that chose it was reasoning soundly, or whether the inputs it acted on were accurate. Those are model risk questions, and the April 2026 guidance's conceptual soundness, ongoing monitoring and outcomes analysis principles still describe what to do about them for everything within its scope. Authority is one layer. Presenting it as the answer to model risk would be exactly the overreach this sector is best at detecting.

What it costs

Three kinds: on the request, on the people who run it, and on the migration into an estate that already works.

On the request. Verification is a MAC and a canonical serialisation per link, plus one caveat evaluation. Linear in depth, small constant, pure computation — no I/O, no network, no lock. That much is a property of the algorithm and I will assert it. A latency figure is a different matter, and I do not have one: this implementation has not been measured under a representative workload. The measurement is specified and scheduled — p50 and p99 across depths one to sixteen, with and without a possession-proof signature, single core — and the prediction under test is that unbound verification stays below the deserialisation cost of the request body it rides on at every depth in that range. It is planned, not performed. Anyone who reads a number into that sentence has read one I did not write, and if the prediction fails I would rather publish the failure than quietly drop the experiment.

Wire cost is the more awkward half and failure mode five gives its shape: depth multiplied by per-link size, carried in a header, meeting limits on intermediate infrastructure that nobody has revisited since it was configured.

On the people. This is the cost that gets left out of the business case. A per-institution root key with a rotation policy and a custodian. A revocation epoch somebody must be able to bump at two in the morning, with a latency written down rather than assumed. An append-only store whose retention is driven by evidence obligations rather than by storage cost, which in this sector means years. A root-grant issuance path with a human-facing surface, because a root grant is a decision and not a configuration value. And a new incident class — the chain does not verify — carrying its own runbook, its own false positives (clock skew against expiry caveats being the first one you will meet), and a fail-open-or-fail-closed choice that has to be made deliberately by somebody senior rather than discovered during the first outage.

On the migration. The hard part is not minting grants; it is that a grant does nothing until something verifies it, and in a bank the things that would verify it are systems of record under change control measured in quarters. So the sequence runs backwards from what people expect. Emit and enforce nothing, letting the record fill until you can see the actual shape of delegation in a live workload, including hops nobody knew existed. Then verify at one boundary you already own, logging failures and permitting the call. Then flip that boundary closed. Then widen. Every step reverses except the last, and the payoff arrives at step one — a complete authority record with no enforcement attached is already the artefact that answers a question the estate previously could not answer at all.

One sector-specific migration note. Where an agent touches order flow, the authority record and the CAT reporting obligation are adjacent but not the same thing, and conflating them in either direction is expensive: the authority record is an internal control artefact, and nothing here changes what is reportable or how. Building both on one pipeline because the field lists rhyme converts a control change into a reporting change.

Weeks for the emit-only step. Quarters for the first boundary that fails closed — and of those quarters, most will be spent not on engineering but on the conversation about who signs off that a verification failure should stop a trade.

If you had a week

Build four things and deliberately skip the rest.

  1. The invariant, with its property test. `Grant`, `attenuate`, `verifyChain`, and the three properties from the last tab. Two days at most, and it is the only part where being wrong is unrecoverable, because everything downstream assumes the invariant holds. Ship the test or you have an intention rather than a guarantee.
  2. One root grant, issued by a real person, for a real desk. Not a fixture. Sit with whoever owns the mandate and write the caveats in the vocabulary they already use. That hour teaches you more about deployability than the rest of the week combined, and the usual outcome is discovering a mandate condition your caveat types cannot express — which is exactly what you want to find in week one instead of month six.
  3. Shadow emission from the dispatcher. Wherever your system hands work between components, write an authority edge and nothing else: no verification, no enforcement, no blocking. Inside a week you will be looking at the real delegation topology of a live workload, which is a picture no dashboard in the estate currently produces.
  4. One cold reconstruction. Pull a single action out of the shadow record, hand the chain to somebody who did not build the system, and ask them to name the accountable individual without asking you anything at all. That is the examination, rehearsed under laboratory conditions. If it fails here, nothing else in this design is worth building yet.

Skip, deliberately: revocation infrastructure, a caveat language, a policy engine, any user interface, third-party discharge, possession binding, chain compaction. All seven are genuine requirements of a genuine deployment, and all seven are ways to consume a week and never once look at the delegation topology. Look at it first. In my experience it changes what people think they are building more reliably than any design review does.

The closing argument is not a security argument. Attenuation caps damage, which is worth something, and the failure analysis above should make clear how much and how little. The argument that carries in this sector is narrower and harder to dismiss: the agencies withdrew the framework that would have specified these controls, said in the same footnote that the institution's own practices should determine them, kept the enforcement hook for unsafe or unsound practices, and have not yet opened the consultation that precedes anything more specific. In that interval, every institution running agents is authoring its own control specification. The only question is whether it authors one deliberately, in a form that can be handed to someone and verified, or discovers after the fact that it authored one by accident, in the shape of whatever its service accounts happened to permit.