Enforcing segregation of duties on composed agent capability

A bank can tell you, today, which of its employees may raise a payment and which may release it, and it can produce the matrix that says those two duties must never sit with one person. That control is decades old, it is examined, and it works. It stopped applying the moment the acting principal became an agent carrying six tools at once — not because anyone disabled it, but because the matrix is expressed over people and roles, and nothing in it has an opinion about a process that holds a payments client and a treasury queue client in the same event loop. The companion teardown to this piece — Segregation of duties survived thirty years and did not survive the toolbelt — walks the evidence for that lapse and for why the usual remedies do not close it. I am going to take it as established and design against it.

What follows is the design I would build, written in the form an implementer needs rather than the form a conference talk needs. The reference implementation is set out below in full rather than described, and the second half of the piece is about what it fails to do. I should say at the outset that the single number this design would most like to quote — how much larger the actually reachable resource set is than the intended one, for a typical tool grant — does not exist in any primary publication I could reach. I will come back to that, because proposing the measurement is a stronger position than importing a figure from an adjacent problem.

A capability is a triple, not a tool name

Start with the smallest possible question: what is it, exactly, that an agent has been given? The answer almost every system gives today is a tool name. The agent has the payments tool, the ledger tool, the counterparty directory. Ask what the payments tool permits and you get a second answer, usually a list of operations, and ask what resources those operations reach and you generally get a shrug and a service account.

A tool name is not a grant. It is a label on a bundle of grants, and the bundle's contents are decided by whoever wrote the integration, at a time when nobody was thinking about duty conflicts. The unit that can actually carry a control has three parts, and it is worth being pedantic about them because the whole design falls out of the pedantry.

1. A verb. The action, in the resource server's own namespace — payments:initiate, payments:approve, ledger:amend-beneficiary. Not a tool name, not an HTTP method, not a job title. The verb is the thing the institution's control framework already has an opinion about.
2. A resource set. Which instances the verb may be applied to, expressed as patterns in the institution's own grammar — the operating accounts of one legal entity, one treasury queue, one book. A verb without a resource set is not a permission; it is a category.
3. A set of constraints. The conditions under which the verb-and-resource pair holds at all: an expiry, an audience, a value ceiling, a proof-of-possession requirement, a requirement that a second and different principal has already acted in a named duty class. Constraints are where everything the institution knows about how the duty is supposed to work goes.

This is not an invention. IETF RFC 9396, OAuth 2.0 Rich Authorization Requests, standardised the same triple in May 2023: its authorization_details parameter carries a required type together with the common fields actions, locations and datatypes — the verb, the resource set as URIs, and the data classes in play. Its own worked examples are drawn from precisely this sector: payment initiation, with the actions initiate, status and cancel, and account information, with list_accounts, read_balances and read_transactions. A specification that reached Standards Track three years ago already says a permission is a structured object rather than a string.

What makes the RFC worth reading rather than merely citing is that it publishes the failure mode too. A single authorization_details object requests, in the RFC's words, all of its actions values at all of its locations values for all of its datatypes values. It then works the example through: for a request naming actions read and write over datatypes contacts and photos, the client would assume it could use any combination the API defines — including write access to the contacts, which is not what anyone meant. And it names the remedy in the same breath: if the client wants finer control it sends multiple objects, after which the client would not be able to write to the contacts.

That is the entire argument of this piece, stated by a standards body in a worked example about photographs. One object is a union and produces authority nobody intended. Several precise objects are a set of intersections and produce exactly what was asked for. The banking case is the same shape with initiate, approve and a ledger behind it, and the consequence of getting it wrong is not a leaked contact list.

Two consequences follow immediately, and they constrain everything downstream. First, the verb and the resource pattern belong to the institution, not to the broker: a control that has to parse a bank's account grammar in order to function is a control the bank cannot change without a vendor release. Resource containment therefore has to be an injected predicate rather than a parser in the library. Second, because constraints are the only place conditional logic lives, the constraint vocabulary has to be closed and small. An open-ended policy expression language here would be a second policy engine, owned by nobody, that the second line would have to learn in order to attest to anything.

Intersection, not union

Given the triple, the next question is how a running agent comes to hold one. The default answer — hand it everything it might need at start-up, and let the model choose — is the toolbelt, and the reason it is wrong is not that it is careless. It is wrong because of an arithmetic property that a Standards Track RFC stated in January 2020, six years before any supervisor deferred on agents.

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 thing a segregation matrix exists to prevent. The matrix says two duties must not meet in one principal; the product says every scope meets every target. And RFC 8693 does not merely observe the problem — it advises against it in the same section, telling clients to exercise discretion in the breadth of the access requested, particularly the number of target services, and defining an invalid_target error code so that an authorisation server can tell a client it requested access to too many target services simultaneously. There is a standardised way for a server to say that is too many tools at once, and it has been sitting there for six years.

So the primitive is an intersection. The agent does not receive a toolbelt; it receives, per task, a capability set computed as the meet of two things: what the principal on whose behalf it acts already holds, and what this specific task has declared it will do. Anything in the declaration that the holder did not already have simply falls out of the result. Anything the holder has that the task did not declare never enters it.

The immediate objection is that this requires the task to declare itself in advance, and the defining characteristic of an agent is that it decides what to do at runtime. That objection is real and I will answer it properly in the failure analysis. The short form: a declared intent does not have to be a plan. It has to be a bound — a statement of the verbs and resource sets the task may touch, wide enough that a competent agent will not hit the wall doing the legitimate thing, and narrow enough that it does not span two duty classes. Producing that bound is a design activity a bank is already good at, because it is the same activity as writing a role.

The sector's own security profile has already ruled on the rest of the mechanics, which saves a great deal of argument. The FAPI 2.0 Security Profile, published Final by the OpenID Foundation on 22 February 2025, requires that authorisation servers shall only issue sender-constrained access tokens — using mutual TLS or DPoP — shall only support confidential clients, shall reject the resource owner password credentials grant, and shall issue authorisation codes with a maximum lifetime of sixty seconds. It also states that servers should restrict the privileges associated with an access token to the minimum required for the particular application or use case. And its fifth note recommends rich authorisation requests when the scope parameter is not expressive enough to convey the authorization that a client may want to obtain.

A tool name is precisely a scope parameter that is not expressive enough. The profile a bank's open-banking estate is already being built to says, in as many words, to reach for the structured triple in that situation. This design does not ask the sector to adopt an unfamiliar control; it asks it to apply a recommendation it has already published to a caller it did not have in mind when it published it.

The closure is what you are actually granting

Now the part that is genuinely new, and the reason a broker is not enough on its own.

A grant is not the same as what a grant reaches. If an agent may initiate a payment on an operating account, and an initiated payment lands in a treasury queue, and the queue exposes an approve action on anything it holds, then a principal granted only initiate has, through composition, arrived at approve. Nothing was escalated. No control was bypassed. Every individual step was permitted, and the segregation matrix was violated by the path rather than by any of its edges.

This is why checking each capability against the matrix is insufficient, and why a broker that mints correctly and analyses nothing will pass its own tests and fail the control. What has to be evaluated is the transitive closure of the proposed capability set over the graph of what tools do to each other — computed before execution, because after execution the only remaining question is how bad it was.

Three properties of that closure are load-bearing.

• It is computed over a graph the institution supplies. An edge says: holding this verb on this resource pattern makes that verb on that resource pattern reachable. The edges are facts about the bank's own systems — a queue that accepts anything from an upstream, a batch job that runs under whoever queued it, a reporting view that materialises from a book the caller cannot otherwise read. Nobody can derive these from a token.
• It is bounded, and the bound is a decision. A closure over a real estate will not terminate usefully at unlimited depth, and a depth limit is a statement about how much composition the institution is willing to be blind to. That limit belongs in the evidence record, because it is the honest boundary of the control.
• It is judged against the matrix, and the grant is not. The finding a supervisor cares about is the pair of duty classes the closure spans, together with the edge that joined them. A finding that names only the two capabilities is a finding nobody can act on.

Here I have to be straight about an absence, because the temptation to fill it is strong. The obvious quantity to publish alongside this design is the ratio between what a tool grant actually reaches and what it was intended to reach. I could not find it in any primary publication I could reach: I could find no regulator, standards body or vendor publishing a measured reachability-to-intent ratio for tool or connector grants. The over-permissioning statistics in circulation from the cloud identity world are not a substitute — they measure granted-versus-used permissions on a single platform, which is a different quantity from reachable-versus-intended closure across composed tools, and the ones that get repeated are marketing rather than published methodology.

So the honest position is that this is unmeasured, and that the analyser described here is the instrument that would measure it: a bank running the closure over its own tool graph produces the ratio for its own estate as a by-product of the control. That measurement is planned rather than performed. I have not run it, and I am not going to imply a number by describing one.

The matrix already exists — do not write a second one

Everything above could be built as a self-contained agent permission system with its own rules, its own conflict definitions and its own owner. That version fails, and it fails in a specific and predictable way: at the first examination that asks who approved the rules, the answer is a platform team, and the control is immediately a shadow control operating in parallel to the real one.

The composition policy therefore has to be expressed in the institution's existing segregation matrix, as data. The broker is handed the duty classes, the incompatible pairs, and — this is the part most implementations skip — the control reference each pair traces to. A refusal that says these two capabilities conflict is a technical event. A refusal that says the closure of this grant spans payment initiation and payment approval, which your matrix marks incompatible under the four-eyes control, because of this edge is a control event, in the institution's own vocabulary, owned by whoever owns that control.

Three practical consequences. The matrix must be versioned, and the version must appear in every receipt, so that a decision can be re-derived against the rules that were in force when it was taken rather than the rules in force when someone asks. Duty classes must map to verbs, not to tools, because the tool inventory turns over and the duty classes do not. And some pairs are incompatible only within a scope — initiate and approve on the same book, rather than in the abstract — which means the matrix needs resource scoping and the analyser needs to respect it, or the control will produce so many false conflicts that it is switched off inside a quarter.

One note on reach, briefly, because the shape travels. Nothing in the design is specific to a United States supervisor: it requires only that the institution already operates a documented segregation matrix and can express its resource grammar. Institutions in the Gulf and in India instantiate the same primitive by loading a different matrix. The regulatory argument below binds in North America; the technical argument is portable.

What the supervisor will ask for, and what the April guidance actually says

This design has to survive an examination that asks for evidence rather than architecture diagrams, and it must not depend on a control framework the current guidance declines to specify. Both halves of that constraint are sharper than they look, and getting the citation right matters more here than anywhere else in the piece.

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 Supervisory Guidance on Model Risk Management, attached to Federal Reserve SR 26-2 and to OCC Bulletin 2026-13. SR 26-2, signed by Randall D. Guynn, Director of the Division of Supervision and Regulation, 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 systems supporting Bank Secrecy Act and anti-money-laundering compliance, issued 9 April 2021. The OCC bulletin separately rescinds four of its own issuances: the Model Risk Management booklet of the Comptroller's Handbook, OCC Bulletin 1997-24 on credit scoring models, OCC Bulletin 2011-12, and OCC Bulletin 2021-19. The Federal Reserve supersedes SR letters; the OCC rescinds OCC bulletins. SR 11-7 is superseded by the Federal Reserve's own instrument, and anyone still citing it as current guidance is citing a document that was replaced.

Footnote 3 of the joint guidance is the sentence everyone quotes, and almost everyone quotes a quarter of it. In full it is four sentences.

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.

The third sentence is the one that matters for a design like this, and it is routinely dropped. The agencies did not say agent controls are somebody else's problem. They said the determination of appropriate governance and controls for out-of-scope tools is guided by the banking organisation's own risk management and governance practices. That is a duty placed on the institution, in the same footnote that declines to specify how to discharge it.

The scope exclusion is in fact doubled, which is worth understanding precisely because it is the strongest version of the counter-argument to this whole programme. The guidance defines a model as a complex quantitative method, system, or approach that applies statistical, economic, or financial theories to process input data into quantitative estimates, and expressly excludes simple arithmetic calculations, deterministic rule-based processes and software with no statistical, economic or financial theories underpinning their design or use. Footnote 3 hangs off the end of that very sentence. So a tool-calling agent falls through two exclusions at once: the generative or agentic model is out of scope by the footnote, and the deterministic dispatch and permission code around it was never inside the definition of a model in the first place.

And the guidance disclaims enforceability in its introduction, in terms the programme's shorthand usually truncates.

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.

Put those three together and the strongest form of the objection to everything above is: nothing here is required, the guidance says so, and a bank that builds a capability broker is gold-plating. I want to state that at full strength before answering it, because it is the argument that will actually be made in the room.

The answer is in footnote 1, which is attached directly to the non-enforceability sentence. After citing the agencies' respective rules on the status of supervisory guidance, it adds: supervisory action may result for any violations of law or unsafe or unsound practices stemming from insufficient management of model risk. The agencies wrote the survival of supervisory action into the same footnote that disclaims enforceable standards. That makes the deferral-not-exemption reading textual rather than interpretive.

The stronger answer is that this is not a model risk problem at all. It is an access control problem, and access control adequacy over customer information systems is governed by a rule rather than by guidance. The Interagency Guidelines Establishing Information Security Standards — 12 CFR Part 30, Appendix B for national banks and Federal savings associations, with parallel appendices at 12 CFR 208 Appendix D-2 and 12 CFR 225 Appendix F for the Federal Reserve, 12 CFR 364 Appendix B for the FDIC, and 12 CFR 748 Appendix A for the NCUA — are issued under section 39 of the Federal Deposit Insurance Act and sections 501 and 505(b) of Gramm-Leach-Bliley. Paragraph III.C provides that an institution shall design its information security programme to control identified risks, and must consider whether enumerated security measures are appropriate and, if so, adopt them. First on that enumerated list: access controls on customer information systems, including controls to authenticate and permit access only to authorized individuals.

Two further instruments close the loop. The FFIEC guidance Authentication and Access to Financial Institution Services and Systems, dated 11 August 2021 — which replaced the 2005 internet banking authentication guidance and its 2011 supplement — defines the users whose access must be authenticated to include employees, board members, third parties, service accounts, applications, and devices. It directs institutions to identify all users, including service accounts and users at third parties, and states that layered security controls can include assigning access rights based on the principle of least privilege provisioning. Its footnote 14 adopts the CIS Controls definition of a service account: 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 by that definition, which means banking supervisors classified the non-human caller as a user requiring authentication and least-privilege provisioning in 2021.

And where the tool is a vendor's — a hosted connector, a third-party API, a vendor-operated server the agent calls — OCC Bulletin 2023-17, Third-Party Relationships: Interagency Guidance on Risk Management, dated 6 June 2023 and issued jointly by the OCC, the Federal Reserve Board and the FDIC, outlines the third-party risk management life cycle and applies, in its own note for community banks, to all banks with third-party relationships. Nothing in the 2026 deferral touches it. The 2026 guidance's own vendor section transfers cleanly too: customised vendor and third-party products present unique validation challenges because the bank may not receive the underlying code, data or methodology, and nevertheless the principles remain applicable.

One thing I will not claim. Several versions of this argument in circulation say that separate AI guidance is promised. No primary text supports that. The only forward-looking statement in either document is a sentence unique to the OCC bulletin body — not the joint attachment — recording that the agencies will continue to consider additional measures and that 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 and agentic AI and AI-based models. A request for information is a consultation step. The agencies have said they intend to begin asking what should be in the specification, not that they are writing it. Whether that request for information has been issued in the four months since is a thing to check in the Federal Register before quoting any of this in front of a supervisor; I have not verified it, and the absence of a specification is the argument either way.

What all of this means for the design is concrete rather than rhetorical. The artefact the control has to produce is not a diagram. It is a record, per task, that names the intent, the matrix version in force, the closure that was computed, the decision that was taken, and the control reference behind any refusal — retrievable by task identifier without a reconstruction exercise. Every layer in the architecture below is obliged to emit its piece of that record, and a layer that cannot is a layer that will not survive its first examination.

The data model

The reference implementation is small on purpose. Three ideas carry it: the triple, the meet, and the closure. Everything else is injected, because a package that decides a bank's key management, parses its resource grammar or authors its duty classes is a package the bank cannot own.

Four properties of the model are easy to miss and do all the work:

1. There is no widen operation. The only public path to a capability set is the intersection of held authority with declared intent. Over-grant is not an error the code checks for; it is a result the code cannot produce.
2. Resource containment is a predicate, not a parser. The package compares patterns using a function the caller supplies and never interprets one. That is what lets a bank change its account grammar without a broker release, and what keeps the broker out of the institution's namespace.
3. The matrix is data with provenance. Every incompatible pair carries the institution's own control reference. A finding cites that reference, so the refusal is traceable to a control someone owns rather than to a rule the package invented.
4. The analyser judges the closure, and the mint depends on the analyser. The broker does not evaluate the capability set it computed. It evaluates what that set reaches, and refuses on the closure. A design that checks the grant will pass its own tests and miss the composition, which is the only interesting case.

/** A verb in the resource server's own namespace, e.g. "payments:initiate".
 *  Compared, never parsed by this package. */
export type Verb = string;

/** A resource pattern in the institution's own grammar, e.g. "acct:corp/operating/*".
 *  Compared via an injected predicate — see Covers. */
export type ResourcePattern = string;

export type PrincipalId = string;
export type DutyClassId = string;

/** The closed constraint vocabulary. Deliberately small: an open-ended policy language here
 *  would be a second policy engine that the second line would have to learn to attest to. */
export type Constraint =
  | { readonly kind: "expires-at"; readonly epochMillis: number }
  | { readonly kind: "audience"; readonly resourceServer: string }
  | { readonly kind: "max-invocations"; readonly count: number }
  | { readonly kind: "value-ceiling"; readonly currency: string; readonly minorUnits: number }
  | { readonly kind: "requires-possession"; readonly keyThumbprint: string }
  /** Four-eyes, expressed as a constraint rather than as an out-of-band convention. */
  | { readonly kind: "second-principal"; readonly inDutyClass: DutyClassId; readonly notPrincipal: PrincipalId };

/** The unit that can carry a control. A tool name is none of these; it is a label on a
 *  bundle of them, decided by whoever wrote the integration. */
export interface Capability {
  readonly verb: Verb;
  readonly resources: readonly ResourcePattern[];
  readonly constraints: readonly Constraint[];
}

/** One declared step of what the task is about to do. A bound, not a plan. */
export interface IntentStep {
  readonly verb: Verb;
  readonly resource: ResourcePattern;
}

export interface TaskIntent {
  readonly taskId: string;
  /** The principal whose authority is being drawn on. Never the agent itself. */
  readonly onBehalfOf: PrincipalId;
  /** The agent workload identity. SPIFFE-shaped by convention; opaque here. */
  readonly agent: PrincipalId;
  readonly steps: readonly IntentStep[];
  readonly notAfterEpochMillis: number;
}

/** Resource containment. Injected because the grammar belongs to the institution, and a
 *  control that parses a bank's namespace cannot be changed without a vendor release. */
export type Covers = (held: ResourcePattern, requested: ResourcePattern) => boolean;

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

const constraintKey = (c: Constraint): string =>
  Object.entries(c)
    .sort(([a], [b]) => (a < b ? -1 : 1))
    .map(([k, v]) => k + "=" + String(v))
    .join("|");

const dedupe = (constraints: readonly Constraint[]): readonly Constraint[] => {
  const seen = new Map<string, Constraint>();
  for (const c of constraints) seen.set(constraintKey(c), c);
  return [...seen.values()];
};

/**
 * The meet. The ONLY constructor for a task capability set.
 *
 * A step survives if and only if (a) the intent declared it and (b) something the principal
 * already holds covers it. Anything the intent named that the principal lacks falls out
 * silently — it is not refused, because it was never in the set being computed. Anything the
 * principal holds that the intent did not name never enters.
 *
 * There is no counterpart to this function that widens. That is the whole monotonicity
 * argument, and it is an argument about which functions were written rather than about which
 * rules are remembered.
 */
export const intersect = (
  held: readonly Capability[],
  intent: TaskIntent,
  covers: Covers,
  additionalConstraints: readonly Constraint[] = [],
): readonly Capability[] => {
  const accumulated = new Map<Verb, { resources: ResourcePattern[]; constraints: Constraint[] }>();

  for (const step of intent.steps) {
    const source = held.find(
      (cap) => cap.verb === step.verb && cap.resources.some((pattern) => covers(pattern, step.resource)),
    );
    if (source === undefined) continue;

    const entry = accumulated.get(step.verb) ?? { resources: [], constraints: [] };
    if (!entry.resources.includes(step.resource)) entry.resources.push(step.resource);
    entry.constraints.push(...source.constraints);
    accumulated.set(step.verb, entry);
  }

  const deadline: Constraint = { kind: "expires-at", epochMillis: intent.notAfterEpochMillis };

  return [...accumulated].map(([verb, entry]) => ({
    verb,
    resources: [...entry.resources],
    constraints: dedupe([...entry.constraints, deadline, ...additionalConstraints]),
  }));
};

The control path

Six layers, and the discipline is that each one is obliged to emit its part of the record. A layer that computes something correctly and writes nothing down has produced an architecture rather than a control.

Read top to bottom, the path is this. The caller declares an intent — verbs, resource sets, the principal on whose behalf the task runs, and a deadline — and that declaration is signed and written before anything executes, which is the only way it can serve as evidence later. The broker loads the institution's matrix at its current version. It computes the intersection of held authority with the declared intent. It hands the resulting set to the analyser, which walks the tool graph and returns the closure together with the depth applied and whether the frontier was still growing when it stopped. The findings are computed against the closure. If there are none, the broker mints one expiring, sender-constrained capability set and writes a mint receipt; if there are any, it refuses and writes a refusal record naming the pair, the control reference and the edge that joined them. The resource servers then do what they already do — audience validation, caveat enforcement, proof of possession — and each records the capability identifier alongside its decision. Everything lands in an append-only register keyed to the task identifier.

Two details in that path are worth defending because they will both be argued with.

The intent is written before execution, not derived from it. It is tempting to reconstruct intent from the trace afterwards, and it is much less work, because the agent has already told you what it did. The problem is that a record fitted to an outcome cannot evidence a control: it will always show that what happened was what was intended, because that is how it was built. An intent written first can be wrong, can be too narrow, and can be shown to have been exceeded. Those are exactly the properties that make it evidence.

A refusal produces an artefact. Most permission systems record grants and treat denials as noise, or as a log line at debug level. In this design a refusal is a first-class receipt carrying the same fields as a mint, plus the finding. That is partly because it is the more interesting event, and partly because a supervisor asking how the control behaves is asking, specifically, to see the times it said no. A control with no recorded refusals is either never binding or never triggered, and you cannot tell which from the outside.

What breaks it

Eight things. The first three are the ones that would stop me deploying this without a plan for them.

One: the tool graph is the weakest input, and nobody maintains one. The closure is only as good as the edges. If the graph is missing the edge that joins initiate to approve, the analyser returns a clean closure and the broker mints a conflicting capability with full confidence and a receipt to prove it — which makes the wrong answer look authoritative. Building the graph is an integration-archaeology exercise across queues, batch schedulers, materialised views and anything that runs under the identity of whoever queued the work, and it decays every time a system changes. My honest assessment is that the graph, not the broker, is where the real project cost sits, and that a graph maintained by a platform team rather than by the owners of each system will drift within two release cycles. The mitigations I would rely on: fail closed on unclassified verbs, so an unmodelled path shows up as a refusal rather than a silence; require every edge to name a system owner; and treat closureTruncated as a reportable condition rather than a flag.

Two: refusal at mint time relocates the widening incentive; it does not remove it. When the broker refuses, someone has to do something, and at three in the morning the something is to widen the intent or edit the matrix. This design does not prevent that and I have no clean answer to it. What it changes is the shape of the artefact: in a toolbelt system the widening is a config change with no owner and no record, whereas here it is either a broader signed intent or a new matrix version, both of which are timestamped, attributed and sitting in front of every decision taken afterwards. That is a real improvement and it is smaller than it sounds. It converts an absence into a thing; it does not convert a bad decision into a good one.

Three: a correct refusal and a broken integration look identical from the outside. The operator sees the agent stop. Whether it stopped because the control worked or because the entitlement feed was stale is not visible from the failure, and the incentive under pressure is to assume the second. This is the failure mode most likely to get the control disabled in its first quarter, and the only defence I know is to make the refusal legible at the point of failure: the message the operator sees must name the pair, the control reference and the edge, in the institution's own vocabulary, so that the person deciding whether to override is reading a control statement rather than an error code.

Four: an intent that is a bound is not an intent that is minimal. To avoid failing on the legitimate path, teams will declare wide intents — every verb the task might plausibly need, over generous resource patterns. A wide intent still cannot exceed the principal's held authority, so the intersection remains a real constraint, but the marginal narrowing over a role-based grant can approach zero. The control then degrades into ordinary least privilege: not nothing, and much less than advertised. The degradation is measurable — declared versus exercised triples, per task, from the register — and I have not measured it.

Five: the matrix does not classify everything, and unclassified is not safe. Real matrices cover the duties that mattered when they were written. An agent estate will reach verbs nobody classified — an internal reporting call, a reference-data write, a workflow transition. Failing closed on those is correct and generates a queue of classification work somebody has to own; if nobody owns it, the setting gets flipped. Failing open is a control that only catches conflicts you already knew about.

Six: scoping is where false conflicts come from. Initiate and approve on different books is usually fine; on the same book it is the control. Express the pair unscoped and the analyser flags every dual-role agent in the estate, the second line drowns, and the pair gets relaxed. Express it too tightly and a genuine conflict slips through a scope boundary. There is no way to get this right from outside the institution, which is the strongest argument for the matrix being the bank's data rather than the vendor's.

Seven: the design says nothing about what the model was persuaded to declare. If an agent's intent is composed by a model that has read attacker-controlled content, the intent may be adversarial. Everything downstream still holds — the intersection cannot exceed held authority, the closure is still computed, the matrix still refuses — so the blast radius is bounded by the principal's own entitlements and by the duty classes. But within those bounds, a malicious intent produces a legitimate-looking capability and a clean receipt. This design bounds the damage; it does not detect the manipulation, and pairing it with a control over what may enter the model's context is not optional.

Eight: revocation and short expiry pull in opposite directions. The design leans on short-lived capabilities rather than on revocation, which is the right trade for latency and availability and the wrong one for the case where you need everything an agent holds to stop now. A ninety-second expiry means a compromised capability is useful for up to ninety seconds, and closing that window costs a check against a revocation surface on the hot path — reintroducing the central dependency the short expiry was chosen to avoid. Institutions with a genuine kill-switch requirement should expect to pay for it at the resource server, not at the broker.

What it costs

Three costs: latency, operations, migration. I am going to be careful to distinguish the ones I can reason about from the ones that need measuring.

On latency: the broker adds one round trip before the first tool call of a task, plus the closure computation. The closure is a bounded breadth-first walk over a graph whose size is the number of modelled edges — hundreds to low thousands in a realistic estate, not millions — with a depth limit in single digits, so the asymptotics are unthreatening. What I have not done is measure it, on real hardware, against a real graph, under concurrency, with the entitlement lookup in front of it. I am not going to publish a millisecond figure I have not observed. The measurement is planned; the honest statement today is that the cost is paid once per task rather than once per tool call, which is the property that makes it affordable, and that the entitlement lookup is more likely to dominate than the graph walk.

On operational burden, three standing obligations, and these are the real bill. The tool graph needs an owner and a change process tied to system releases. The matrix needs classification of new verbs as the estate grows, with an owner in the second line rather than in platform engineering. And the register needs retention aligned to the institution's examination cycle, which for a bank is longer than most engineering teams assume when they choose a log store.

On migration, the sequencing matters more than the effort. The order that works is to run the analyser in observation mode against existing service accounts before any broker exists — computing closures and findings for what is already deployed, refusing nothing. That produces two things at once: a defensible baseline for what the estate currently reaches, and the first honest measurement of how far the closure exceeds the intent, which is the number this piece could not source from anyone else. Only then does minting go live, per workflow, starting with the ones that already have a documented four-eyes control, because those are the ones where the matrix entry exists and the finding will be legible.

The migration risk nobody costs is the estate that has no verb vocabulary at all — where permissions are expressed as application roles, and the mapping from role to verb is folklore. That mapping has to be written down before any of this functions, and it is a discovery exercise on the institution's own systems rather than a broker feature.

If you have one week

Most of the architecture above should not be built in the first week. What follows is what I would do, in order, and what I would deliberately skip.

1. Days one and two: the verb vocabulary for one workflow. Pick a single workflow that already has a documented four-eyes control — an outbound payment path is the obvious candidate. Write down its verbs and its resource patterns. This is the artefact everything else depends on and the one most likely to be missing.
2. Day three: the matrix slice, as data. Take the existing segregation matrix entries covering that workflow — usually two or three incompatible pairs — and encode them with their control references. Do not write new rules. If a needed rule does not exist in the matrix, that is a finding for the control owner, not a gap for engineering to fill.
3. Day four: the tool graph for that workflow only. Sit with the owners of each system in the path and enumerate the edges. Expect this to take longer than it sounds and to surface at least one edge nobody had written down anywhere. Record a system owner against every edge.
4. Day five: the analyser, in observation mode. Run the closure over the capabilities the existing service accounts already hold. Refuse nothing. Publish the findings to the control owner as a report. This is the deliverable that makes the case for the rest, and it is the first real measurement of how far reach exceeds intent in your estate.

Skip, for now: minting, sender-constrained tokens, the constraint vocabulary beyond expiry, the register, and every integration with the agent framework. All of it is necessary and none of it decides whether this gets built. That turns on whether the observation-mode report shows conflicts the institution did not know it had. If it does, the rest follows without further argument. If it does not, you have learned something worth more than a broker — that your service accounts are already narrow — and the correct response is to say so.

One closing note on where this sits relative to the supervisory position. The agencies have said, in a footnote, that agentic systems are outside the scope of the guidance and that determining appropriate controls for them is guided by the institution's own risk management and governance practices. They have said, in another footnote, that supervisory action survives their non-enforceability disclaimer. And separately, in a regulation rather than in guidance, they require access controls on customer information systems. A bank reading those three together does not have a compliance obligation to build a capability broker. It has something more awkward: an obligation to determine the controls itself, for a class of system whose authority is composed at runtime, with no specification arriving to say what determining looks like. Building the enforcement point now, against the matrix the institution already owns, is how that determination becomes a thing you can show someone rather than a position you have to argue.