Per-action grants a registered principal can review

Eight forty in the morning, and a designated principal opens a queue.

There are fourteen items in it. Each one is a proposed grant: an agent has assembled a new-account application and is asking for permission to submit it. The item shows what the agent would be permitted to do if the grant were approved — submit this application, to this custodian, for this client, once, within the next two hours — and what it consulted to build the draft. It shows the fields the agent populated that the client did not state directly: risk tolerance inferred from a meeting note, funding source inferred from a document. It shows the three fields the validation agent corrected and what they were before.

The principal reads item four, disagrees with the inferred risk tolerance, and rejects it with a sentence. Item five is approved with a condition. The other twelve are approved. The queue empties in eleven minutes, and the thing that just happened is not a log entry: no agent could have submitted anything before it happened, and the record of it was produced by the gate rather than written about the gate later.

That is the whole design, and everything below is the mechanism that makes it true rather than aspirational.

The queue, the fourteen items, the firm and the workflow above are a constructed illustration, assembled from patterns documented in public regulatory material, vendor announcements and platform documentation. It is not a report of any real firm, client, account or deployment, and no part of this piece describes client work. The design that follows is my own and has not been examined by any regulator.

The companion teardown to this piece, Your record names a principal. Securities regulation means the other kind., walks the evidence that FINRA's supervision architecture asks for a reviewer of a specified regulatory category and that an agent chain's record terminates in a service identity instead. I take that as established. What follows is what I would build against it.

The ground the design has to stand on

Three facts constrain this design and one absence shapes where it will be adopted first.

Rule 3110 supplies the human category, and supplies it in binding rule. The member designates an appropriately registered principal with supervisory authority for each type of business in which it engages. It maintains written supervisory procedures covering those types of business and the activities of its associated persons. And its system provides for review by a registered principal, evidenced in writing. This is the rare case where the regime has already specified the hardest part of the design — the terminal object — and the engineering problem is to reach it rather than to invent it.

FINRA has named the agent risks and has not specified the control. Regulatory Notice 24-09 of 27 June 2024 is guidance stating that FINRA's rules are intended to be technology neutral and continue to apply to generative AI, and stating expressly that it creates no new requirements. The GenAI section of the 2026 Annual Regulatory Oversight Report, published 9 December 2025, is an examination-program report written in discretionary register. The blog post of 27 January 2026, "Emerging Trend in GenAI: Observations on AI Agents," is a set of observations naming autonomy, scope and authority, auditability, data sensitivity and domain knowledge, and disclaiming any new obligation. Treat those five as an acceptance test rather than as a requirement, because that is what they are: the risks the regulator has said it is watching for, published before anyone has to satisfy anything.

India assigns the responsibility and leaves the officer unnamed. SEBI Regulation 16C, notified 10 February 2025, places responsibility for the output of artificial intelligence and machine learning tools — in-house or third-party — and for investor data handled by them, on the regulated entity. That is a binding assignment of responsibility for AI output that the United States securities regime does not have in equivalent terms, and it assigns to the entity rather than to an officer. The consultation paper of 20 June 2025 proposes governance guidelines including designated senior management oversight; as a consultation it proposes rather than requires. A firm building this design in India is building the officer the regulation implies and does not name.

The absence is the GCC. I could not verify a securities-specific AI instrument in any Gulf jurisdiction. What exists is posture — a regulator publicising agentic AI across its own supervisory operations, a financial centre stating an AI-native ambition — and posture is not something to design against. I am not going to manufacture an anchor where there is not one. What the absence means practically is that a Gulf firm building this now is building ahead of the instrument rather than against it, which is a different sales conversation and a better engineering position.

Five premises

Four of these are carried from the general primitive and are not original here. The fifth is what this sector forces, and it is the one that changes the shape of everything downstream.

1. Authority is carried, not ambient. Nothing an agent may do comes from the process environment, a shared session, a start-up credential or a system prompt. If it is not on a grant the agent holds, it cannot be done.
2. Every delegation produces a strictly narrower credential that names its parent. A child grant identical to its parent is the same grant and carries no information. Attenuation is monotone by construction, checked at mint time rather than asserted in documentation.
3. The chain is verifiable without replaying the run. A verifier at the resource evaluates the grant presented against the action attempted. Reconstructing authority from traces after the fact is the thing this design exists to avoid.
4. A grant is minted unexercisable, and a review decision is what makes it exercisable. This is the sector-specific move. Review is a gate, not a log. The consequence is that the decision record is produced by the control rather than composed about it, which is the difference between evidence and narrative.
5. The written supervisory procedure compiles into the review policy. Not describes it, not accompanies it. The mapping from action class to reviewer category and review mode is an artefact under change control, and the prose in the procedures manual is generated from it or checked against it — never the other way around.

The fourth premise is where most of the argument lives, so it is worth being precise about what it is not. It is not a claim that every agent action needs a human. It is a claim that the classes of action a firm's own procedures route to principal review must be structurally incapable of executing before that review happens — and that the classes which are not so routed must be recorded as having been classified, by whom, and under which version of the policy. A design in which everything is gated is unbuildable at production volume. A design in which the gating decision is invisible is worse than no design, because it looks like a control.

The data model

The types below are the core of the reference implementation. They are written to be read, and they are deliberately small: everything that is not load-bearing for the argument has been left out, including transport, serialisation, key management and the cryptographic construction that makes attenuation verifiable offline, all of which are treated in the general primitive rather than here.

Three things to watch for while reading. The principal categories are a closed union, so a service identity can never be the root of a chain — the type system refuses it rather than a policy document forbidding it. The mint function takes a parent and returns a strictly narrower child or fails, so monotonicity is not something a caller can opt out of. And the exercise function requires a review decision for any grant whose class the policy routes to review, which means the gate is a property of the credential rather than a check somebody remembered to write.

/** The identity layer's sense of the word. Can hold grants; can never be a chain root. */
export interface ServiceIdentity {
  readonly kind: "service";
  readonly id: string;
}

/** An associated person conducting the business. */
export interface RegisteredRepresentative {
  readonly kind: "registered-representative";
  readonly crdId: string;
  readonly displayName: string;
}

/** An associated person registered in a principal capacity, designated for a type of
 *  business. The rulebook's sense of the word. */
export interface RegisteredPrincipal {
  readonly kind: "registered-principal";
  readonly crdId: string;
  readonly displayName: string;
  readonly designatedFor: readonly string[];   // types of business, as the firm names them
}

export type Person = RegisteredRepresentative | RegisteredPrincipal;
export type Holder = Person | ServiceIdentity;

/** What a grant permits. Bounds are compared structurally, never by string equality. */
export interface Bounds {
  readonly actionClass: string;                // keys into the review policy
  readonly accountIds: readonly string[];      // empty means "none", never "all"
  readonly operations: readonly string[];
  readonly fieldScope?: readonly string[];     // narrows a write to named fields
  readonly notAfterIso: string;
  readonly maxUses: number;                    // 1 for the gated classes
}

export type GrantState =
  | { readonly status: "proposed" }
  | { readonly status: "exercisable"; readonly review: ReviewDecision }
  | { readonly status: "exhausted"; readonly review: ReviewDecision }
  | { readonly status: "revoked"; readonly revokedIso: string; readonly reason: string };

/** The review decision. This object IS the writing the rule asks for: it names a
 *  reviewer of a category, the item, the basis considered, and the disposition. */
export interface ReviewDecision {
  readonly reviewer: Person;
  readonly reviewedGrantId: string;
  readonly basis: string;
  readonly disposition: "approved" | "approved-with-conditions" | "rejected";
  readonly conditions?: readonly string[];
  readonly decidedIso: string;
  /** Which version of the compiled policy routed this item here. */
  readonly policyVersion: string;
}

export interface Grant {
  readonly id: string;
  /** null only at the root. A root grant's authority comes from rootAuthority. */
  readonly parentId: string | null;
  /** Present only at the root, and only ever a person. */
  readonly rootAuthority: Person | null;
  readonly holder: Holder;
  readonly bounds: Bounds;
  readonly state: GrantState;
  readonly mintedIso: string;
}

Mapping the observations onto controls that can be tested

The five risk areas FINRA named in January 2026 are not requirements and I am not going to present them as such. They are, however, the closest thing available to a published statement of what a regulator is looking at, and a design that cannot say what it does about each of them is not finished. Below is that mapping, with the coverage marked honestly — including the two rows where the design reaches only part of the way.

The middle column of that figure deserves defending rather than mocking. An entitlement review is a real control. An approval click is a real control. A written procedure describing a workflow is a real artefact and firms are examined on it. None of them is negligent; all of them are the best available answer given the objects a firm currently has. The claim is only that the objects changed, and the controls have not.

The objections, at full strength

Four, and the second is the one that has actually stopped this design in rooms I have been in.

This is maker-checker with extra steps. Largely, yes — and that is a point in its favour rather than against it, because maker-checker is a control the sector already knows how to operate, audit and staff. What is new is not the pattern but where it sits: today the check happens against a draft in an application, and the authority to submit exists independently of it, held standing by a service account. Here the check is the thing that brings the authority into existence. The difference shows up exactly when it matters — when someone asks what the agent could have done had nobody looked. Under maker-checker as usually built, the answer is everything the service account could do. Under this design, the answer is nothing.

The gate destroys the economics. The point of the agent was to remove the human. This is the serious objection and it deserves a serious answer rather than a reframe. If every action is gated, the design converts an autonomous workflow into a queue with extra latency and the business case evaporates. My answer is that the design does not gate everything and refuses to pretend the classification is free: the review policy is where the economics are decided, explicitly, by a named person, under version control. The honest formulation is that this design does not make the human cheaper. It makes the decision about how much human to spend into an artefact rather than an emergent property of what the platform team found convenient. A firm that runs the numbers and gates almost nothing has still gained something — the classification is now written down and someone owns it.

Nobody has asked for this, and building it is speculative compliance. Correct on the first half. FINRA has published a notice, a report and a blog post, none of which requires anything specific about agents. But Rule 3110 is not speculative, it is in force, and it asks for three things of which an agentic account-opening record currently supplies one. The speculative position is the other one: that a supervision requirement written for work done by people will be satisfied, without adaptation, by a record in which the reviewer field holds a service account. I would rather build the object early and be told it was unnecessary than argue that one in an examination.

You have made the reviewer a single point of failure. Also correct, and I am not going to argue it away. A design that routes work to a named person concentrates risk on that person's availability, judgement and willingness to say no. It is failure mode three below. The defence is not that the concentration disappears but that it becomes visible: a queue has a length, a reviewer has a throughput, and a class that keeps getting reclassified downward leaves a trail of policy versions with names attached. The alternative arrangement diffuses the same risk across an architecture where nobody can see it at all.

The bill

Seven ways this design fails or degrades. They are not caveats. Four of them are things I would expect to see within a year of a real deployment, and one of them is unavoidable rather than merely likely.

One — the rubber stamp. A reviewer clearing two hundred items a day produces two hundred writings and considers none of them, and the record is indistinguishable from a reviewer who considered all two hundred. The design can force a basis field to be populated; it cannot force it to be thought about. Partial mitigations exist and none of them is a fix: require the basis to be specific enough to fail a duplicate-string check, sample the reviews themselves rather than only the items, measure dwell time and treat implausibly short reviews as a supervisory finding rather than a metric. All of that is second-order, and a firm that builds this and does not staff the review has bought a more convincing record of a control that is not happening — which is worse than the paragraph it replaced.

Two — sampling becomes theatre. A risk-based sample is a control only where the sample frame and the rate are set by someone other than the team whose work is being sampled. The design makes the frame computable, which is necessary and not sufficient. If the same function that builds the workflow also owns the policy version that sets the rate, the rate will drift down and every individual decision will be defensible.

Three — the reviewer is a bottleneck, and bottlenecks get reclassified. Every class routed to full review is a queue. Queues create pressure, pressure creates reclassification requests, and reclassification requests are made by the people the queue inconveniences and granted by people who want the workflow to ship. This is the failure mode I would bet on seeing first. The only structural defence I know is to make the reclassification itself a supervised act with a named approver and a retained history, so that the drift is legible afterwards even though nothing prevents it.

Four — a monotone chain cannot make a wrong root safe. Attenuation guarantees that no descendant exceeds its parent. If the root grant was approved on a misunderstanding, every strictly narrower grant beneath it inherits the error and the design registers nothing unusual, because nothing unusual has happened structurally. Monotonicity is a containment property, not a correctness property, and a piece that lets a reader confuse the two has oversold.

Five — the boundary. Where part of the chain runs on a custodian's or a vendor's platform, the grant stops at the edge. What happens on the other side is governed by contract and by whatever the platform chooses to record, and the firm's own responsibility does not attenuate at that boundary even though its visibility does. This is not a defect I can engineer away from inside one firm; it is the reason the interesting version of this design eventually needs the counterparty to accept a presented grant rather than only a bearer credential, which is a market-structure problem rather than a software one.

Six — revocation and offline verification pull in opposite directions. A grant that can be verified without contacting the issuer cannot be withdrawn instantly, because a verifier that never asks anyone will never learn that it was withdrawn. A grant that can be withdrawn instantly requires the issuer to be reachable on every call, which reintroduces the availability dependency the offline construction existed to remove. Short expiries narrow the window and do not close it. Every real system picks a point on that trade, and the only unacceptable answer is not knowing which point you picked.

Seven — a well-formed grant tree is not a good decision. The design evidences who authorised what, within which bounds, reviewed by whom, on what basis. It is entirely silent on whether the authorisation was correct. A firm can produce an immaculate authority record for a systematically bad practice, and this design will not notice. Anyone selling it as a risk-reduction measure rather than an evidence measure is selling something I did not build.

What it costs, with the unmeasured parts marked

I am not going to give benchmark numbers, because I do not have any I would defend and this sector will check. What follows is the shape of the cost with each unmeasured quantity named as unmeasured.

• Latency, per gated action: the wall-clock time from the grant entering the queue to a decision. This is a staffing and queue-discipline number, not an engineering one, and it is unmeasured here. The engineering component — minting, structural narrowing checks, verification at the resource — is small relative to a model call, but I have not benchmarked it and will not assert a figure.
• Latency, per ungated action: one additional verification at the resource, plus the mint. Also unmeasured, and also expected to be small against the surrounding calls. Anyone quoting a percentage here should be asked for the harness.
• Reviewer time: the dominant cost, entirely determined by the policy. Gating a class at full review buys evidence at the price of a person's attention, and there is no version of this where that price falls.
• Migration: the expensive part is not the credential layer, it is the classification. Enumerating what your agents actually do, grouping it into action classes, mapping each class to a type of business and a reviewer category, and reconciling that against a procedures manual written before any of it existed. In every comparable exercise I have seen described, that inventory takes longer than the code.
• Ongoing: the policy is now an artefact with a version, an approver and a reconciliation obligation against the written procedures. That is a real recurring cost and it is also, awkwardly, most of the value.

A build order that omits most of this

If I had two weeks and a firm that wanted to know whether this is real, I would not build the architecture. I would build the smallest thing that produces the artefact and refuses to produce it falsely.

1. Days one to three — the inventory. Enumerate the actions the agents in one workflow actually take against systems of record. Not the components; the actions. Group them into classes. This is the part firms want to skip and it is the part that determines whether anything downstream is meaningful.
2. Days four to five — the classification, with names on it. For each class: type of business, reviewer category, review mode. Where the answer is not gated, write the rationale and the owner. Get it approved by whoever would answer for it in an examination. This document is the deliverable even if no code is written.
3. Week two, days one to three — the gate on exactly one class. Pick the class with the highest supervisory salience and the lowest volume. Mint proposed grants, block exercise, build the queue, emit the review decision. One class, one queue, one reviewer.
4. Week two, days four and five — the walk. Implement the parent walk from an action to the root and confirm it terminates in a person. Do not build attenuation across the whole chain yet; a two-level chain is enough to prove the property and to find out whether the resource-side verifier is where you thought it was.

Deliberately omitted from those two weeks: offline verification, revocation distribution, cross-boundary presentation, key management, sampling machinery, and the reconciliation build step between the compiled policy and the procedures manual. All of those are necessary eventually and none of them tells you within a fortnight whether the design fits the firm.

What would falsify this

Four things, and the first two are the ones I would look for hardest if I were arguing against this piece.

A firm that gates nothing and passes examination anyway. If a firm running agentic workflows at volume is examined on its supervisory system, produces the current artefacts — an approval event, a written procedure, an entitlement review — and draws no finding, then the object I am building is not the object the regime is asking for, and this design is a preference about evidence quality rather than a response to a requirement. I have no visibility into examination outcomes and cannot close this. It is the strongest available counter and it is behavioural rather than textual.

A platform that already carries per-action authority to a named human. If a custodian, an agent framework or a vendor product mints authority per action, bounds it, and terminates the chain in a person of a specified category, then the construction here is redundant and the interesting work moves to interoperating with it. I have not found such a thing described in a primary source. I have also not surveyed the market, and absence of publication is not absence.

A measurement showing the gate does not change what reviewers catch. The design's implicit claim is that a reviewer looking at a proposed grant before execution catches things a reviewer looking at a completed action afterwards does not. That is testable — run both arms over the same population and compare the findings — and I have not seen it tested. If pre-execution review catches nothing post-hoc review misses, then the gate is buying evidence and not judgement, and a cheaper design would buy the same evidence.

A specification that contradicts the shape. FINRA may publish agent-specific guidance that describes a reasonably designed supervisory system in terms incompatible with this design — for instance, one that treats post-hoc review of a complete population as sufficient and pre-execution gating as unnecessary. In that world this is over-engineered, and the firms that built it will have absorbed a cost early rather than a penalty late. That is the cheapest way to be wrong, and it is the asymmetry the whole argument rests on.

One closing limit. Nothing here shows that a firm without this design will be sanctioned, and I have not found a published enforcement action turning on agentic attribution in this sector. The claim is about what a firm can hand across the table when asked, and about the interval — open now — in which what the industry builds is what the eventual specification will be written against.