Segregation of duties survived thirty years and did not survive the toolbelt

What follows is constructed. No institution, no incident, no client — an approval path assembled out of parts that are each entirely ordinary, because the argument is about the shape of the path rather than about anyone's failure to follow it.

In March, a payments platform team approves a connector for an agent that will help treasury operations work through the previous day's payment exceptions. The control objective on the approval record is instruction integrity. The review is competent and asks the questions that objective implies: are the calls authenticated, is every call logged with a correlation identifier, is instruction creation idempotent under retry, does the connector fail closed when the gateway is unavailable. The connector is approved. The record says `payments-api`.

In June, treasury operations approve a second connector for the same agent, this one against the workflow system that holds the approval queue. The control objective on this approval record is queue throughput — the exceptions queue has a tail of items that sit unresolved because nobody notices them, and the agent is meant to work the tail. This review is also competent, and asks the questions its objective implies: what happens on timeout, does a retry double-decide an item, can the connector be rate-limited. The connector is approved. The record says `workflow-queue`.

The credential behind the first connector can create a payment instruction. The credential behind the second can post a decision on a queue item, and one of the queue item types is an instruction awaiting approval. Neither reviewer was wrong about anything they were asked to consider. Neither reviewer saw the other's grant, because the two approvals live in two different systems, under two different control objectives, four months apart. The agent now holds both, and there is no document anywhere in the bank on which both connectors appear.

To say it once more, plainly: this scenario is invented for the purpose of the argument. It is not a report of anything that happened, at any institution, and I make no claim that any bank currently has an agent holding both capabilities. The claim is narrower and, I think, harder to dismiss — that nothing in the approval path would detect it if one did.

The control passes, and the test is correct

The bank has a segregation control over this exact pair. In its usual form — and this is the form the argument is about, not a claim about every institution — it is written as a predicate over entitlement holders: for every user in the entitlement report, not both the initiator entitlement and the approver entitlement in the payments application. It is tested by pulling the entitlement report, joining it to the staff roster, and looking for rows that satisfy both conjuncts. It is one of the oldest controls in the building. The OCC was publishing examination guidance on credit scoring models in 1997; segregation of duties was already furniture then, and it is furniture now.

Run the test against the estate that contains our agent. It returns no exceptions. It returns no exceptions correctly — not because the entitlement data is stale, not because someone scoped the population badly, but because every row it examined genuinely fails to hold both entitlements. The agent is not a row. Its credentials are service accounts attached to two applications, and a service account is not a member of the domain the predicate quantifies over.

Now do the obvious remediation, which any competent second line will propose within a minute of hearing this: extend the population. Put the service accounts into the entitlement report, certify them on the same cycle as human identities, and re-run. The test still returns no exceptions, and it still returns them correctly, because the two credentials are two distinct principals. One holds initiation. The other holds approval. Neither holds both. The predicate is satisfied by every element of its enlarged domain, and the thing that holds both — the agent — is not an element of any domain the control knows how to enumerate.

The strongest version of the objection

Before the argument goes any further it should meet the objection that a good head of technology risk will raise, and it should meet it at full strength rather than in a version convenient to answer.

This is not new and it is not about agents. Non-human identities have been composing incompatible entitlements since the first overnight batch job. Every large bank already has a toxic-combination ruleset, a privileged access management platform, a joiner-mover-leaver process and a certification cycle, and the reason those exist is precisely that service accounts accrete permissions nobody reviewed as a set. You have described a stale access review with a new vocabulary. The fix is unglamorous and known: get the non-human identities into the certification scope, express the toxic combinations at the entitlement level rather than the role level, and run the recertification. Nothing about a language model changes that.

Most of that is right, and the parts of it that are right are the parts that matter operationally. Banks with a mature privileged access management programme and a genuine toxic-combination ruleset over non-human identities are much closer to handling this than the illustration above implies, and any bank that has not done that work should do it before reading another word of this piece. I am not going to pretend otherwise in order to make the argument look larger.

What I do not accept is the conclusion. There are three differences here that are differences of kind rather than of degree, and each of them survives a mature certification programme.

The first is authorship and rate. A batch job's entitlement set is authored once, by a named person, and changes at the rate of a change ticket. Its composition is a document, and the document has an owner. A toolbelt's entitlement set is authored incrementally by whoever adds the next connector, and the composition is not a document at all — it is an emergent property of a configuration file plus a catalogue, computed at process start. Certification can review what is there today; it cannot review a thing nobody wrote down, and the pair in the illustration is exactly such a thing.

The second is that the unit reviewed is not the unit exercised. A certification cycle reviews grants. The grant is a name. What actually gets exercised is the transitive closure of what the credential behind that name can reach. This is the physical fact the whole piece rests on, and it is developed at length in the next section. The short form: a reviewer who approves every grant in the estate, correctly, has still not reviewed the estate, because approving a name is not the same operation as bounding a set.

The third is that the action sequence is selected at runtime. A batch job's sequence of calls is fixed when it is written; a reviewer can read the code and enumerate what it will do. An agent's sequence is selected at runtime by a model conditioned on inputs that did not exist when the review happened — the contents of the exceptions queue, a counterparty name, a free-text note somebody typed into a case. The reachable sequences are therefore not statically enumerable from the connector list, and a reviewer who reads the connector list has not read the program. That is a structural statement about what the artifacts contain, not a claim about how often the model will do something surprising.

Take the objection seriously enough and it becomes a stronger version of my own argument rather than a rebuttal of it. Certification works on the entitlement layer. The problem is one layer down, where the grant becomes a reachable set, and one layer sideways, where two grants become a capability neither of them was.

A name is not a set

Here is the fact the rest of the piece is built on, stated as plainly as I can manage: a tool grant is written as a name and exercised as a transitive closure.

The name is what appears in every artifact a control function will ever see. A connector identifier in a catalogue. A line in an agent's configuration. A row in an approval record with a requesting team, a control objective and a date. The name is atomic — it has no internal structure, and in particular it has no size.

The closure is what the running system actually has. It is everything the credential behind that name can reach: every endpoint the gateway routes for that client identity, every table and view and stored procedure the database role can touch, every downstream service that trusts the calling service because it always has, and then everything those reach in turn, because a service that accepts a call on your behalf does not stop being a service. Granting the database tool grants every row, schema and stored procedure the tool credential can reach. The grant did not say that. The grant said a word.

Between the two sits the thing everybody actually meant, which is neither of them: the task. Somebody wanted an agent to reconcile yesterday's payment exceptions. That is the unit of intent. The unit of grant is a connector. The unit of exercise is a closure. Three different sizes, and the approval path records exactly one of them — the middle one, which is the only one of the three that is not a set.

The reason this is structural rather than an oversight somebody will patch comes down to three things, and I want them separated so that a reader who disagrees can say which one they reject.

*The closure is not computable from the artifacts an approver holds.* To compute it you need the credential's server-side grants, the gateway's routing table for that client, the bodies of the stored procedures the database role can execute, and the trust configuration of every downstream service that will accept a call from the first hop. In a bank those four facts live with four different teams, on four different change cycles, and no single approval forum has all four in the room. This is not laziness. It is the ordinary consequence of a system large enough to need an approval forum in the first place.

*The naming layer is the product, not an accident of it.* Connector catalogues, tool registries and integration marketplaces are sold on precisely the promise that a capability is a name you select rather than a set you specify. That is what makes them fast, and speed is why anyone buys them. The abstraction is not hiding the closure by mistake; hiding the closure is the feature. Any proposal that requires the approver to see the set is proposing to remove the thing the layer was bought for, which is why it will lose that argument on the first Tuesday it is raised.

*And the difference is silent.* There is no error, no warning, no field in the record that reads 'this grant is four hundred times larger than the task that justified it'. Silence is the operative property. A control function does not fail to act on a signal it received; it never received one. Everything downstream of that — the certification that passes, the examiner who is satisfied, the risk acceptance nobody wrote because nobody perceived a risk to accept — follows from an absence rather than from a decision.

Grants compose, and the composition has no owner

The second half of the physical fact is that grants compose, and that the composition is invisible from inside either half of it.

A configuration-reading tool is unremarkable. A network-calling tool is unremarkable. Together they are an exfiltration path, and no approval step saw an exfiltration path, because neither approval step was looking at a path. In our illustration the composition is sharper still, because both halves are not merely unremarkable but positively good: initiating payment instructions is what the payments connector is for, and deciding queue items is what the workflow connector is for. Neither grant is over-broad relative to its own control objective. The pair is the problem, and the pair is not a thing that exists in any system of record.

This is the part I would push hardest with a bank's second line. Every governance mechanism in the estate attaches to an artifact with an owner: a model has an owner, an application has an owner, a third-party relationship has an owner, a change has a requester and an approver. The composition of two connectors held by one agent has no artifact and therefore no owner, which means there is no forum whose agenda it can appear on, no register it can be entered in, and no person who can be asked why it was accepted. It is not that the wrong person accepted the risk. It is that acceptance never happened, in either direction.

It is worth noticing how the standards community described this, because it described it precisely and it described it years ago. RFC 8693, the OAuth 2.0 token exchange specification — Standards Track, January 2020 — is discussing what happens when a client asks for one token usable at several target services, and states the semantics without euphemism.

The semantics of such a request are that the client is asking for a token with the requested scope that is usable at all the requested target services. Effectively, the requested access rights of the token are the Cartesian product of all the scopes at all the target services.

A Cartesian product is exactly the right description and it is a description of growth. The same section tells clients they should exercise discretion in the breadth of the access requested, particularly in the number of target services, and the specification goes as far as defining an `invalid_target` error code so that an authorization server can tell a client it has asked for access to too many target services at once. The protocol has a way to say no to this. That mechanism was published six years before the supervisory guidance deferred on agents, in a Standards Track document co-authored at Visa.

RFC 9396, Rich Authorization Requests — Standards Track, May 2023 — makes the composition arithmetic even more explicit, in a specification whose own worked examples are payment initiation and account information. Its `authorization_details` parameter carries a required type together with `actions`, `locations` and `datatypes`, and it spells out the union semantics: a single object requests all of the listed actions, at all of the listed locations, for all of the listed datatypes. It then works the failure through in the plainest possible terms — for a request naming the actions read and write over the datatypes contacts and photos, the client would assume it could use any combination of rights the API defines, including read access to the photos and write access to the contacts. And it names the remedy immediately: if the client wants finer control, it sends multiple objects, after which it would not be able to write to the contacts.

What specifically fails, in a bank

Take the general fact and put it back into this sector's vocabulary, because the failure is more specific than 'agents have too much access'.

*The predicate quantifies over the wrong domain.* Segregation of duties, as implemented, is a statement about entitlement holders. It needs to be a statement about actors — the things that decide and act — with credentials as one of an actor's attributes rather than as the actor itself. In a human estate those two coincide closely enough that nobody has ever had to notice the difference: a person is an actor, a person holds entitlements, and one identity carries both facts. An agent breaks the coincidence. One actor, several credentials, each credential issued by a different authority under a different objective, none of them individually in violation. The control is not weak here. It is well-formed over a domain that no longer contains the thing you care about.

*Maker-checker loses the property it was purchased for.* The value of a second pair of eyes is not that a second credential was used; it is that a second, independent judgement was applied. Independence is a property of the judging process. When the initiating decision and the approving decision resolve to the same inference process, conditioned on the same context window, reading the same case notes, the second judgement is correlated with the first however many credentials sit between them. So the control can be satisfied credential-wise and void substantively — which is a worse position than failing, because a failure is visible and this is not.

*And the evidence is about the wrong thing.* This is where the exposure actually lands, and it is an evidentiary exposure rather than a control exposure. When an examiner asks a bank to demonstrate that no actor could both initiate and approve, the bank produces the entitlement report and the certification attestations. Those documents are accurate. They answer a question about entitlement holders. The question asked was about actors. A control function that cannot see the difference between those two questions will be confident in exactly the wrong proportion to its evidence, and confidence of that kind does not survive contact with a determined examiner or a real loss.

/** The verbs a payments control cares about. Deliberately small — a real catalogue
 *  has hundreds, and nothing in the argument depends on the size. */
export type Verb = "read" | "initiate" | "amend" | "approve" | "release";

/** A resource class, not a resource. Globs are the honest granularity: a connector
 *  credential attaches to "payments:instructions.*", and the star is doing far more
 *  work than the approval record ever acknowledged. */
export type ResourceClass = string;

/** What the credential behind a connector can reach.
 *  `declared` is what the approval artifact said.
 *  `observed` is what somebody actually enumerated against the resource server.
 *  `observed: null` means nobody ever did — which is the usual state of the world. */
export type Reach = {
  readonly declared: readonly ResourceClass[];
  readonly observed: readonly ResourceClass[] | null;
};

export type ToolGrant = {
  readonly connectorId: string;
  readonly approvedBy: string;
  readonly controlObjective: string;
  readonly approvedOn: string;
  readonly verbs: readonly Verb[];
  readonly reach: Reach;
};

/** The thing the segregation predicate needs to quantify over and currently does not:
 *  one running agent, holding several credentials issued by several authorities. */
export type Actor = {
  readonly actorId: string;
  readonly grants: readonly ToolGrant[];
};

/** A pair of verbs no single actor may hold. Banks already have this list. It is
 *  written down for people, and it is applied to people. */
export type ToxicPair = readonly [Verb, Verb];

export const PAYMENT_DUTY_PAIRS: readonly ToxicPair[] = [
  ["initiate", "approve"],
  ["amend", "approve"],
  ["approve", "release"],
];

Two exclusions in one document

Now the supervisory position, read carefully, because a great deal of loose commentary has attached to it and the precise text is sharper than any of the paraphrases.

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 joint document titled Supervisory Guidance on Model Risk Management. The Federal Reserve's designation is SR 26-2, signed by Randall D. Guynn, Director of the Division of Supervision and Regulation; it states that the attached guidance supersedes and replaces SR letter 11-7, Guidance on Model Risk Management (issued 4 April 2011), and SR letter 21-8, the interagency statement on model risk management for bank systems supporting Bank Secrecy Act and anti-money-laundering compliance (issued 9 April 2021). The OCC's designation is Bulletin 2026-13, and it does a different thing with different instruments: it rescinds four OCC issuances — the Model Risk Management booklet of the Comptroller's Handbook, OCC Bulletin 1997-24 on credit scoring models, OCC Bulletin 2011-12 on sound practices for model risk management, and OCC Bulletin 2021-19 on BSA/AML model risk management. The Fed supersedes SR letters; the OCC rescinds OCC bulletins. SR 11-7 is superseded, and it is superseded by the Federal Reserve's own instrument. Anyone still citing it as current guidance is citing a document that was withdrawn four months ago.

The guidance defines its own subject matter, and the definition is where the first exclusion sits.

For the purposes of this guidance, 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. The term “model” in this guidance 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 system in the illustration. The tool router that maps a chosen tool name to a connector, the credential store that holds the tokens, the permission check that decides whether this agent may call this connector, and the catalogue that lists what exists — all of that is deterministic rule-based software with no statistical, economic or financial theory underpinning it. It is precisely, textually, excluded from the definition of a model. And it is exactly the layer where the closure is computed and exercised.

The second exclusion is footnote 3, which hangs off the end of that very sentence. It is four sentences long, and the last three are almost always dropped.

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.

So a tool-calling agent leaves the scope of this document twice, by two different routes, on the same page. The part that chooses is out of scope by footnote 3. The part that dispatches and holds the credentials is outside the definition of a model in the first place. There is nothing left inside.

And then there is the third sentence, which is the strongest line in the document for anyone building this layer and which is almost never quoted. The agencies do not say the controls are unnecessary. They say the determination of appropriate governance and controls for tools, processes or systems not covered by the document is to be guided by the banking organization's own risk management and governance practices. That is a duty being placed, textually, on the bank — and it is placed on precisely the systems that just fell out of scope.

What the deferral did not touch

The document is careful about its own force, and the sentence people quote is only half of the relevant text.

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.

The second clause is stronger than the first and is usually omitted. But footnote 1 attaches directly to that sentence, and it is what makes the deferral-not-exemption reading textual rather than interpretive: after citing the agencies' respective statements of policy on the use of supervisory guidance, it adds that supervisory action may result for any violations of law or unsafe or unsound practices stemming from insufficient management of model risk. The agencies themselves state that supervisory action survives their own non-enforceability disclaimer. There is no savings clause in either document of the form 'all other obligations are untouched' — I looked, and I am not going to invent one — but footnote 1 plus the separate binding instruments do the same work more honestly.

Those separate instruments are where the argument gets its edge, and it is worth being exact about which of them is guidance and which is a rule.

*The access-control duty is in a regulation and it uses the word shall.* The Interagency Guidelines Establishing Information Security Standards sit at 12 CFR Part 30, Appendix B for national banks and Federal savings associations, issued under section 39 of the Federal Deposit Insurance Act and sections 501 and 505(b) of the Gramm-Leach-Bliley Act, with parallel appendices at 12 CFR 208 Appendix D-2 and 12 CFR 225 Appendix F for the Board, 12 CFR 364 Appendix B for the FDIC and 12 CFR 748 Appendix A for the NCUA. Paragraph III.C provides that each institution shall design its information security programme to control the identified risks, and that it must consider whether the enumerated security measures are appropriate and, if so, adopt them. First on that enumerated list is access controls on customer information systems, including controls to authenticate and permit access only to authorized individuals. This is the pivot of the whole piece: the blast-radius problem is an access-control problem, and access-control adequacy over customer information systems is governed by a regulation rather than by guidance that disclaims enforceability.

*Supervisors already treat non-human callers as users. The FFIEC guidance Authentication and Access to Financial Institution Services and Systems*, dated 11 August 2021 — which itself replaced the 2005 internet-banking authentication guidance and its 2011 supplement — sets out principles for authenticating users of financial institution information systems, and defines that population expressly to include employees, board members, third parties, service accounts, applications and devices, collectively users. It directs institutions to identify all users, including service accounts and users at third parties, that access institution systems and data, and states that layered security controls can include assigning users' access rights on the principle of least privilege provisioning. Its footnote 14 adopts the CIS Controls definition of a service account as a dedicated account with escalated privileges used for running applications and other processes, not intended to be used by people except for administrative operations. An agent's tool credential is a service account under that definition, which means it is a user under that guidance, which means least-privilege provisioning is already the stated expectation for it. Four years and eight months before the model risk deferral.

*And the third-party duties are recent and live. OCC Bulletin 2023-17, dated 6 June 2023, carries the interagency third-party risk management guidance issued jointly by the OCC, the Board and the FDIC; it rescinds OCC Bulletin 2013-29 and OCC Bulletin 2020-10, sets out the third-party risk management life cycle, and its note for community banks states that the guidance applies to all banks with third-party relationships. An agent calling a vendor's tool or a vendor-hosted tool server is a third-party relationship, and none of that duty moved in April 2026. The 2026 guidance's own vendor section points the same way for the components that are* in scope: because certain components may be proprietary, a banking organization may not receive the underlying code, data or methodology it would have for an internally developed model — and nevertheless, in the guidance's words, the principles of model risk management remain applicable.

One more sentence from the OCC bulletin deserves accurate handling, because it is the one most often stretched. The bulletin — and this sentence is the OCC's alone; a sweep of the Federal Reserve's fourteen-page package returns no occurrence of the phrase — says the agencies will continue to consider additional measures, and that for example they plan to issue in the near future a request for information addressing model risk management generally and considering, in particular, banks' use of AI, including generative AI, agentic AI and AI-based models.

A request for information is a consultation step. It is not a rule and it is not draft guidance. What that sentence records is that the agencies have not begun writing the specification; they have begun asking what should be in it. Whether such a request has actually issued in the four months between 17 April and the date on this piece, I have not verified, and I am not going to assert it either way — anyone relying on this should check the Federal Register and the agencies' newsrooms before quoting me. Either answer supports the same conclusion. If a request has issued, its comment period is a live opportunity to put the composed-capability problem on the record. If it has not, the four-month silence is itself the argument.

Both readings push the same way: the eventual specification is further off than the commentary assumes, and it will be written against whatever the industry has already built. That makes building the evidence layer now a stronger move rather than a weaker one, because the alternative is to have the specification written against an estate in which nobody could produce the evidence.

For completeness on who this reaches: the joint guidance states it is expected to be most relevant to banking organizations with over $30 billion in total assets, adding that it may also be relevant to smaller organizations with significant model risk exposure because of the prevalence and complexity of their models, or because of activities outside the scope of traditional community banking. SR 26-2's applicability line names organizations over $30 billion regulated by the Federal Reserve. The OCC bulletin's note for community banks reads that the guidance is applicable to all community banks, subject to the limitations discussed in the guidance. None of that threshold language touches the access-control regulation, the third-party guidance or the authentication guidance, which have their own scopes.

Nothing in the argument depends on the American instruments. They are simply the ones I can quote at this level of precision, and a bank in the Gulf or in India reading this will find its own supervisor's wording differs while the structure of the gap does not: a segregation control expressed over human principals, an agent that does not instantiate one, and an approval path in which a grant is a name.

The limits of this argument

Four limits, and the first is the one I would attack if I were reading this rather than writing it.

*I cannot tell you how big the gap is.* The central quantity — for a given tool grant, how much larger the actually-reachable set is than the intended set — is unmeasured. I could find no regulator, standards body or vendor publishing a measured reachability-to-intent ratio for tool or connector grants. I am specifically not going to borrow an over-permissioning statistic from the cloud identity world as a proxy: those figures measure granted-versus-used permissions, which is a different quantity from reachable-versus-intended closure, and the ones in circulation are vendor material without published methodology. So the honest position is that I have argued the gap exists and is structural, and I have not argued that it is large. The measurement I would run — enumerate, for a sample of connector grants, the credential's server-side reachable set and the set the approval artifact intended, and publish the ratio with the method — is planned, not performed, and nothing above should be read as though it had been.

*The illustration is constructed, and it establishes possibility rather than incidence.* I have no evidence that any bank currently has an agent holding both initiation and approval over the same instruction, and I make no such claim. What I claim is that the approval path as described would not detect it. Those are different assertions and only the second one is mine.

*A mature programme is closer to this than the piece implies.* An institution running genuine toxic-combination analysis over non-human identities, with connector credentials scoped per application rather than per platform, and with an agent runtime that binds each tool call to a distinct downstream identity, has already removed most of the illustration's oxygen. My argument is about the shape of the predicate, not about anyone's maturity, and the shape matters most in the estates that are otherwise well run — because those are the estates where the control passes and the passing is believed.

*And here is what would falsify it.* First, a connector-grant artifact whose approval record carries the closure — computed at approval time against the resource server, re-verified when the underlying grants drift, and shown to the approver in the same view as the name. If that artifact exists in a shipping product, the difference between panel two and panel three stops being silent and my central claim fails. Second, a segregation control whose predicate quantifies over actors, with credentials as attributes, and which is tested by joining entitlement data across applications by actor identity rather than by principal. If a bank can run that test today, the agent is inside the domain and the gap closes without anything new being built. Third, an empirical result showing that composed capability risk concentrates in a small number of high-value connectors that are already hand-audited — in which case the structural argument would remain true and stop being important, which is a fate I would accept. I cannot settle the third one from a desk, and I am not going to pretend the argument is stronger than the evidence for it.

What follows

This piece stops at the diagnosis deliberately. But the diagnosis constrains the answer tightly enough that the shape of it is already visible, and it is worth naming the constraints so that a reader can evaluate any proposal — mine or anyone else's — against them.

• The grant has to stop being a name. Whatever replaces it must carry at least the triple the field already standardised — the verb, the resource set, and the data classes — because a name cannot express a set and an approver cannot bound one they cannot see. RFC 9396 has had the encoding since 2023.
• The predicate has to quantify over actors. Segregation of duties expressed over credential holders will keep returning correct answers to the wrong question for as long as one actor can hold several credentials issued by several authorities.
• The composition has to have an owner and an artifact. Until the pair of connectors is a thing that exists in a system of record, no forum can consider it, no register can hold it, and nobody can accept the risk it carries.
• The broker has to be able to say no to breadth. RFC 8693 already defines an error for a client asking to reach too many target services at once; a tool-grant path with no equivalent has no way to express refusal, only approval or absence.

It is worth noting that this sector's own API security profile is already most of the way there for human-facing flows. The OpenID Foundation's FAPI 2.0 Security Profile, published Final on 22 February 2025, requires authorization servers to issue only sender-constrained access tokens, to support only confidential clients, to reject the resource owner password credentials grant, and to issue authorization codes with a maximum lifetime of sixty seconds; it says privileges associated with an access token should be restricted to the minimum required for the particular use case; and its NOTE 5 recommends Rich Authorization Requests where the scope parameter is not expressive enough to convey the authorization a client wants. A tool name is precisely a scope parameter that is not expressive enough. The sector wrote down the recommendation. The agent layer sits beside it, using names.

One further thing the design will have to face, and I want it on the record here rather than discovered later: the 2026 guidance defines effective challenge as the critical analysis conducted by objective experts who evaluate model risk and effect appropriate changes throughout the model lifecycle, performed by individuals with sufficient independence to maintain objectivity and the organizational standing and influence to effect change. Effective challenge over a closure that nobody has computed is not possible, however independent or senior the challenger. The evidence has to exist before the challenge can be meaningful, which is why the first deliverable is measurement rather than governance.

The companion to this piece — Enforcing segregation of duties on composed agent capability — takes those four constraints and builds against them: what the grant record has to contain, where the predicate has to run, what the broker refuses, and what it costs to run in front of a payments estate. It is forthcoming. Nothing in it will make the control in the illustration fail; the point of the design is to make the control ask a question whose answer is worth having.

Until then, there is one thing worth doing this quarter that requires nobody's architecture. Take every agent in the estate, list its connectors, and for each connector enumerate what the credential behind it can actually reach — not what the approval record says it is for. Then compare the two lists. That comparison is the measurement nobody has published, and it is the one exercise here that needs no new architecture — though it does need the four teams named earlier in the same room, which is the part that takes the scheduling rather than the work. Whatever the ratio turns out to be, it will be a number the institution owns, which is more than anyone currently has.