You integrated nine systems for a client and granted an agent all nine at once

The statement of work names five integrations and a delivery date. The client is a regional bank; the firm has held its systems integration account for eleven years; the engagement is to put an agent behind the servicing desk so that four analysts stop reconciling exception queues by hand every morning. Five workstreams, five technical leads, five sets of acceptance criteria, one programme manager holding the plan on a wall.

Workstream one wires the CRM. The agent needs to know which relationship manager owns an account, so it reads accounts, contacts and opportunities through the vendor's API with a service principal the client's platform team provisions. The lead pushes back on an early draft that asked for write access and gets it removed. Reviewed, tested, accepted.

Workstream two wires the data warehouse. The agent needs balances, transaction history and the exception queue itself, which live in three schemas. The client's data team, sensibly, refuses the analytics admin role and provisions a purpose-built reporting role instead. The lead documents the connection, the connection pooler and the query timeout. Reviewed, tested, accepted.

Workstream three wires ticketing, because exceptions that cannot be auto-resolved have to become work for a human. Create and update, no delete, no administrative scope. Workstream four wires the file store, because the daily summary has to land somewhere the operations lead can open it: write access to one exports folder on the shared drive. Workstream five wires outbound mail, because the summary has to reach a distribution list, and the client's messaging team configures the sender so that it authenticates against the bank's own domain and does not land in spam.

Every one of those five was delivered correctly. I want to be unusually clear about that, because the argument does not depend anywhere on someone having been careless. Each workstream had a specification, and the thing built matched it. Each had an acceptance test, and it passed. Each had a lead who pushed back on at least one over-broad request and won. The client's own security architect attended three of the five design reviews and signed the fourth by email. If you audited each workstream individually you would find five defensible pieces of engineering.

This engagement is a constructed illustration — the bank, the five workstreams, the pushback, the architect, all of it. It is not a client engagement of mine, not a disclosed incident, and not a description of any named firm's delivery. I have built it out of mechanisms documented in vendor and protocol primary sources, cited below, because the argument needs a concrete trace and I will not manufacture one out of somebody's outage.

Now stop asking what each integration was for, and ask what the agent can reach.

Start with the warehouse, because it is the one everybody thinks is bounded. The reporting role attaches to three schemas. Three schemas is not the exception queue — it is every row in every table in those schemas, for every customer, for the whole of the retained history, plus every view built over them, plus whatever functions the role is permitted to execute. If the client assumed row-level filtering was doing work here, the assumption is worth checking against the database's own documentation rather than against the mental model: PostgreSQL states that by default tables have no policies at all, so that a user with table privileges under the SQL privilege system finds all rows equally available for querying or updating. Policies are opt-in. And even where they exist, table owners normally bypass row security unless the table has been altered to force it, and roles carrying the bypass attribute always do. A connector wired with an owning role reads straight through the filters that were written to hide things from exactly this kind of query.

Now the file store. Write access to one exports folder is what was specified and what was built. But a folder on a shared drive is a node in an inheritance graph, and the interesting question is not what the folder is called, it is who reads what that folder is inside of, and which synchronisation service mirrors it somewhere with a different access model. Nobody asked, because the workstream's acceptance criterion was that a file appears in the folder.

Then mail. The messaging team did good work: the sender authenticates against the bank's domain, which is why the summary reaches the distribution list instead of a junk folder. The same property means a message the agent composes is, to every recipient inside and outside the bank, a message from the bank. The workstream delivered deliverability. Deliverability and authority to speak as the organisation are the same technical fact viewed from two directions, and only one of them was in scope.

Each of those three is fine. Held together in one process, they are a path. The agent can read a customer record it was never asked about, write it into a location whose readership nobody enumerated, and send it to an address nobody vetted, under the bank's own name. Nobody granted that. Nobody reviewed it, because no review step in the programme had the set as its input. Five leads granted five reasonable things, and a sixth person — the one who wrote the agent's tool configuration file, probably in the last fortnight before go-live — put them in the same process.

That distinction carries the whole essay, so it is worth putting in the flattest possible terms. The authority an agent holds is not the union of the delivered scopes. The union is what the programme plan implies, and it is computable by reading five acceptance documents. The closure is what runs, and it is computable only by someone holding all five credentials at once — which, in the shape of every integration engagement I have seen described publicly, is nobody, because the five credentials belong to five workstreams that closed on five different dates.

The objection that has to be answered before anything else

The strongest response is that this is the client's estate and the client governs it, and that a large bank's identity governance is not a napkin sketch. This deserves full strength rather than a wave, because in my experience the people making it are usually right about their own controls.

A regulated institution of that size runs privileged access management with credentials vaulted and checked out, joiner-mover-leaver automation, and quarterly entitlement recertification in which named owners attest, line by line, that a principal should continue to hold an entitlement. It has a control catalogue mapped to its examiners' expectations, an internal audit function that tests the mapping, and a third-party risk process that put this very firm through diligence before the contract was signed. Its data team refused the analytics admin role in workstream two — the narrowing there came from the client, not the firm. Telling that organisation its access governance is immature is both rude and, as a description of its access governance, wrong.

So the concessions, and there are three real ones. The service principals in the illustration would appear in the client's identity inventory. They would be picked up by recertification and shown to an owner. And in some institutions a data loss control on the mail gateway would flag the constructed exfiltration path before anybody reconstructed it. None of that is imaginary.

The argument is not that the client's governance is weak. It is that recertification answers a different question, and the difference has three parts.

Recertification is per-principal; the finding is per-set. The artefact an attesting owner receives is a row: this principal holds this entitlement on this system, approve or revoke. Every row in the constructed engagement is approvable, because every row was justified by a workstream that a competent person signed off. The owner of the warehouse role has no visibility of the mail integration; the owner of the mail sender has never heard of the exports folder. Nothing in the recertification pack has the shape of a set, and an attestation cannot find a property that its unit of review cannot express.

Entitlement inventories are actual; reachability is counterfactual. An inventory records what was granted. The authority question is what could be reached, which is a statement about possibilities rather than records — and the overwhelming majority of an agent's reachable set is never exercised in any given run. The paths that matter for a review are precisely the ones nothing has taken yet. The industry accepted this distinction for cloud identity years ago, which is why static reachability analysis over policy graphs exists at all. The tool layer above those policies simply never got the equivalent object.

The gateway control is a tail control, not a design. Grant that a data loss control fires. What it is then catching, repeatedly, across engagements, is the ordinary behaviour of correctly delivered integration work. A control that works is not the same as an architecture that is right, and the difference shows up as a permanent operational tax on the client that scales with how much integration they buy.

There is a fourth version of this objection specific to banks, and it is the most sophisticated one: that model risk management covers it. That reading is now out of date in a way worth stating precisely. On 17 April 2026 the federal banking agencies issued revised interagency model risk management guidance — OCC Bulletin 2026-13, with the Federal Reserve's parallel issuance designated SR 26-2 — which supersedes SR 11-7 and SR 21-8. Anyone still citing SR 11-7 as the live instrument is citing a rescinded one. More importantly, the OCC's bulletin states in its own text that generative and agentic AI models are novel and rapidly evolving and, as such, are not within the scope of that guidance, and that the guidance does not set forth enforceable standards or prescriptive requirements. That wording is the OCC's bulletin speaking for itself; do not read it as a joint statement of what every agency's issuance says.

The correct reading of that is a deferral, not an exemption. Every obligation attached to the underlying activity — safety and soundness, consumer protection, the client's third-party risk duties — is entirely untouched. What was withdrawn is the framework that would have specified the controls. So the practical position for a services firm is the inverse of comfortable: nobody is going to hand your client a control specification for agent authority in the near term, and whatever separate guidance arrives will be written against whatever the industry has already built by then. The gap in the delivery model is not waiting for a regulator to close it.

A second objection is quieter and I will take it up at the end, because it has the most institutional weight and the least architectural support: that the composed authority is the client's configuration and therefore the client's problem.

A name is not a bound

The physical fact underneath all of this is small enough to state in one line and load-bearing enough to spend a section on. A tool grant is written as a name and exercised as a transitive closure.

Take the wire format at its word. In the Model Context Protocol specification at revision 2025-11-25, a tool definition consists of a name, a title, a description, icons, an input schema for the arguments, an optional output schema, annotations and execution hints. Read that list looking for the field that constrains which rows, folders, mailboxes, accounts or objects the tool may reach when invoked, and there is not one. The input schema types the arguments. It does not type the reachable set, and no other field does either. The blast radius of a grant is simply not part of the protocol.

The same specification is explicit that even the descriptive fields are not to be trusted on their own account: clients must consider tool annotations untrusted unless they come from trusted servers. So the one part of the definition that gestures at behaviour is the part the protocol tells you to discount.

This is not sloppiness in the protocol so much as an accurate reflection of where the information actually lives. The reachable set is a property of the credential the connector holds, and that credential was issued by a flow that knew nothing about the task. The name says the warehouse tool. The credential says the reporting role. The role says three schemas. The schemas say every row. Four hops, each individually reasonable, and the distance between the first and the fourth is recorded nowhere.

It matters that this is not a limitation of computers. Intersection — the operation that would let a grant be narrowed to a task — is a shipped production primitive with documentation you can read this afternoon. AWS states the rule for session policies directly: the permissions for a session are the intersection of the identity-based policies for the entity used to create the session and the session policies. It adds the sentence that makes the primitive safe to hand to a caller, which is that session policies limit permissions for a created session but do not grant permissions. The same page describes permissions boundaries in the same conjunctive terms — an entity with a boundary can perform only the actions allowed by both its identity-based policies and its boundary — and, where a session policy, a boundary and an identity policy all apply, the resulting permissions are the intersection of all three.

That dissolves the excuse. A capability is expressible as an intersection of caveats rather than as a name, and somebody already built it, documented it and shipped it as a parameter on an existing API call. What has not happened is anyone making it the unit in which integration work is delivered.

And the counter-example, from the other dominant substrate, shows what happens when a model cannot express narrowing at all. Kubernetes documents its authorization model as purely additive: a role or cluster role contains rules representing a set of permissions, and permissions are purely additive, with no deny rules. A cluster role is not namespaced, so a grant written once can apply everywhere. In an estate whose authorization primitive can only accumulate, every integration is a monotonic increase in what the composed principal can do, and there is no operation available to anyone — the client, the firm, the agent runtime — that subtracts.

Why the gap is structural rather than an oversight

The reflex on reading the above is that someone should just add a composition review to the delivery method. That reflex is worth arguing with, because it underestimates why the review is absent, and the reasons it is absent are the reasons it will not appear on its own.

The composition is not a deliverable, and delivery organisations act on deliverables. Follow the artefacts an engagement actually produces. Each workstream produces a design document, a build, a test result and an acceptance sign-off, and the workstream terminates at acceptance. The programme produces a plan and a go-live checklist. The client produces a change record. At no point does an object exist whose content is the composed authority, and organisations do not review things that are not objects — not out of carelessness, but because a review needs something to be handed. There is no line in the plan called compose the five grants and describe what results, so there is no meeting at which that gets described.

Review cost is linear in workstreams; composed authority is combinatorial in the set. This is arithmetic rather than opinion, and it is the sharpest form of the structural claim. Five integrations give ten pairs and ten triples. Nine give thirty-six pairs and eighty-four triples. The programme's review effort grows with the number of workstreams, because reviews attach to deliverables and deliverables are per-workstream. The authority grows with the number of subsets. Those are not merely different quantities, they are different orders, and no amount of additional diligence per workstream changes an exponent. Any fix has to change the object being granted, not the rigour with which each integration is examined. Those counts are the combinatorics of the illustration and not a measurement of any real estate.

The composition comes into existence after the last gate has closed. The ordering is the part that makes this genuinely hard rather than merely neglected. Workstream one is accepted in month two. Workstream five is accepted in month seven. The agent first holds all five in one process at go-live, in month eight. Every review forum the engagement possesses has already adjourned by the time the thing worth reviewing exists. There is no gate left open, and the natural moment to build one is exactly the moment when the programme is under the most schedule pressure it will ever be under.

The friction gradient points the wrong way, and it points at your delivery team. Narrowing a grant costs the firm days: more provisioning requests through the client's change process, more mid-run failures in user acceptance testing, more support tickets after go-live, worse demonstrations to the steering committee. Widening one costs nothing measurable until something goes wrong, and when it does the cost lands on the client's incident channel rather than on the engagement's margin. At the moment of decision, in the week before go-live, bundling is the locally rational move for every individual in the room. Anything that claims to fix this has to beat that argument on its own terms.

The field's own guidance has already named this, in a document aimed precisely at firms like yours. The current revision of NIST's supply-chain publication carries a least-privilege enhancement written for exactly this population.

When enterprise users include independent consultants, suppliers, developers, system integrators, external system service providers, and other ICT/OT-related service providers, relevant access requirements may need to use least privilege mechanisms to precisely define what information and/or components are accessible, for what duration, at what frequency, using what access methods, and by whom.

Count the fields in that sentence: the resource set, the duration, the frequency, the method, and the principal. Five properties. A connector name carries none of them. The guidance is not asking for anything exotic; it is describing the record that ought to exist for every grant a system integrator leaves behind, and the delivery artefacts an engagement produces have no field where any of the five could go.

What actually fails, and by what mechanism

Abstractions are cheap. Here is the mechanism level, in the terms an integration lead would use.

The read that is not a read. Somewhere in a five-system estate there is a configuration store, a secrets file, an environment dump or a build artefact that a connector can read. What comes back is not information in the sense the design review had in mind when it approved a read-only tool. A connection string is authority, serialised. The moment it lands in the agent's context, every carefully scoped credential elsewhere stops being the boundary, because the agent now holds material addressing a system nobody integrated, that appears on no architecture diagram for this engagement, and whose access logs will attribute the query to a service account rather than to your agent. The composition did not add two reachable sets together; it turned the output of one tool into the input authority of the next, which is a different and worse operation.

The pair nobody could have reviewed. A configuration-reading tool is unremarkable. A network-calling tool is unremarkable. The pair is an egress path. Neither workstream could have found it, because the property belongs to the pair and each workstream's input was one member of it. This is what makes per-workstream review not merely incomplete but ill-posed: the reviewer of the config tool cannot be right or wrong about its risk, because its risk is not determined until the other tool exists.

The credential you forwarded because it was easiest. When wiring an agent into an inherited estate, the path of least resistance is to take the token the client's system already issues and pass it downstream. The protocol names this and forbids it. Token passthrough is defined as an anti-pattern in which a server accepts tokens from a client without validating that they were issued to that server, and passes them through to the downstream API; the normative rule is that servers must not accept tokens that were not explicitly issued for them. The stated risks are precisely the two that bite a services firm: an actor holding a stolen token can use the server as a proxy for data exfiltration, and where a token is accepted by multiple services without validation, compromising one service yields access to the others. If you have built the pattern the specification forbids, you have built the mechanism by which one compromised integration becomes five.

The identity that is a service account rather than a person. Because the connector authenticates as itself, every downstream access log records the service principal. The client's forensic reconstruction of who read that customer record therefore terminates at a name your firm chose during workstream two. Attribution to the agent, to the run, to the ticket that prompted it, or to the analyst on whose behalf it acted, exists only if somebody built it, and nobody scoped it, because logging was not the deliverable either.

The write that triggers something. Ticketing was scoped as create and update, no delete, which sounds narrow and is not, because tickets are inputs to workflow. A created ticket routes, notifies, escalates, and in a mature operations estate sometimes triggers automation. The effect class of the grant is not write, it is initiate a process in a system that was never part of this engagement. Effect classes travel further than resource classes and are much less often enumerated.

The field's own risk taxonomy already contains this. The OWASP Top 10 for Large Language Model Applications, in its 2025 entry on excessive agency, describes an extension holding permissions on downstream systems that are not needed for the intended operation, and gives as its example an extension intended to read data that connects to a database with a role holding not only select but also update, insert and delete. It separates the causes into excessive functionality, excessive permissions and excessive autonomy, and recommends that extensions execute in the user's context and that authorization be enforced in the downstream systems rather than in the tool layer. That last recommendation is the one integration firms are structurally worst placed to follow, because the downstream systems belong to the client and predate the engagement.

The instrument is the client's, and it already says this

Here is where services firms usually go looking for a rule of their own and do not find one. In the jurisdictions this piece surveys, there is no supervisory instrument that governs a systems integrator as such. What governs is whatever governs the client, and it reaches the firm through the contract. So the honest way to read the following is: this is the bank's obligation, and it lands on you because the bank signed a piece of paper with you.

For a US bank, the operative text is the Interagency Guidance on Third-Party Relationships, published at 88 Federal Register 37920 on 9 June 2023 and issued by the agencies as OCC Bulletin 2023-17, Federal Reserve SR 23-4 and FDIC FIL-29-2023. It rescinded and replaced the Board's 2013 guidance, the FDIC's 2008 guidance, and the OCC's 2013 guidance and 2020 FAQs, and it opens the argument by removing the escape route.

The use of third parties does not diminish or remove banking organizations' responsibilities to ensure that activities are performed in a safe and sound manner and in compliance with applicable laws and regulations.

The part that speaks directly to composed authority is in the contract-negotiation section on confidentiality and integrity, which says that effective contracts typically prohibit the use and disclosure of banking organisation and customer information by a third party and its subcontractors, except as necessary to provide the contracted activities or comply with legal requirements. Read that clause against the illustration. The contracted activity was reconciling an exception queue. The grant reaches every row in three schemas. The instrument already requires that access be bounded by the contracted purpose. What is missing is any mechanism that enforces the boundary at the authority layer rather than in prose — the sentence exists, and nothing in the estate makes it true.

The same guidance's subcontracting section is the closest published analogue to what a tool grant actually is. It observes that subcontracting can create risk through the absence of a direct relationship between the banking organisation and the subcontractor, lessening the organisation's direct control of activities. It suggests contracts address when and how the third party notifies the organisation of its intent to use a subcontractor and whether particular subcontractors are prohibited; whether assignment, transfer or subcontracting without consent should be barred; and the third party's liability for the actions of its subcontractors. Now consider what a connector is. It is a capability, obtained by your firm, exercised inside the client's estate, that the client has no direct relationship with and limited direct control over. A tool your firm connects is functionally an undeclared subcontractor of capability — and the clause the client would use to control it was written about companies, not connectors.

The audit provision closes the loop, and closes it on an absence. The guidance contemplates contracts including provisions for periodic independent audits of the third party and its relevant subcontractors, consistent with the risk and complexity of the relationship; it names service organisation control reports and payment card compliance reports among the artefacts, and it contemplates reserving the organisation's right to conduct its own audits or engage an independent party to do so. So the client has the right. Now ask what document that right would read to establish how far a granted connector could reach. There is not one. None of the standard assurance artefacts reports a reachability closure for a tool grant. The audit right exists and the evidence object does not, and that is a gap a firm can be paid to fill.

Change the sector and the flow-down gets stricter rather than looser. For a healthcare client, the business associate contract requirements at 45 CFR 164.504(e)(2)(ii) require that the business associate ensure that any subcontractors that create, receive, maintain or transmit protected health information on its behalf agree to the same restrictions and conditions that apply to the business associate — read alongside the requirement not to use or further disclose the information other than as permitted by the contract, an over-reaching tool grant is a contract breach before it is ever a security incident. Again: that is the covered entity's and the business associate's instrument, and it reaches your firm through the agreement you signed.

For an Indian regulated entity, the Reserve Bank of India's Outsourcing of Information Technology Services Directions of 10 April 2023 make the same two moves. They state that outsourcing of any activity shall not diminish the regulated entity's obligations, nor those of its board and senior management, who remain ultimately responsible for the outsourced activity. They contemplate contractual clauses making the service provider liable for the performance and risk management practices of its sub-contractors and requiring the regulated entity's prior consent for their use. And on access they are blunt in a way the American text is not: access to data at the entity's location or data centre by service providers is to be on a need-to-know basis. Need-to-know is a statement about the task. The reporting role is a statement about three schemas. Nothing in the delivery converts one into the other.

Notice what is common across all three jurisdictions. Every instrument binds access to the contracted purpose. Not one specifies an artefact in which the binding could be evidenced, and the firm's own obligation — the one genuinely its own rather than inherited — is contractual, sitting in a statement of work that in every template I have read specifies deliverables, service levels, intellectual property and personnel, and says nothing about the authority layer at handback. I looked for a published standard for that: something from a standards body, a professional association or a procurement authority specifying what an engagement must hand over regarding capability scope, expiry and reachability. I did not find one, so I am arguing that gap from its absence rather than citing a source that does not exist. If someone can point me at the instrument I missed I would like to read it.

The closure is computable, which is rather the point

One reason to be blunt about the missing artefact is that producing it is not hard. The code below is not a remedy: it grants nothing, narrows nothing and brokers nothing, and computes only what the engagement already implies. It supports one narrow claim — that the absence of this object is a delivery-model decision rather than a technical limit.

The first tab models an integration as delivered, because the absence is easier to see in a type than in prose. The second computes the closure and enumerates the source-to-sink pairs — the object nobody currently holds. The third checks the handback record against the five properties the supply-chain guidance asks for, and reports which are missing.

export type EffectClass = "read" | "write" | "egress" | "initiate";

/** A resource class, not a resource. Globs are the honest granularity: a role
 *  attaches to "warehouse:servicing.*", and the star is doing far more work
 *  than anyone reviewing that workstream realised. */
export type ResourceClass = string;

export type Sensitivity = "public" | "internal" | "restricted";

/**
 * One integration workstream, as an engagement actually delivers it.
 *
 * Fields one to four come straight off the acceptance pack. Fields five and six
 * do not exist anywhere in the delivery artefacts and have to be authored by
 * hand, which is the whole finding: the reachable set is a property of the
 * credential, and no document produced by the engagement records it.
 */
export type DeliveredIntegration = {
  readonly id: string;
  readonly system: string;
  /** The name the design review approved. A word, nothing more. */
  readonly grantName: string;
  readonly effects: readonly EffectClass[];
  /** Everything the credential can touch — not what the task needs. */
  readonly reaches: readonly ResourceClass[];
  readonly sensitivity: Sensitivity;
  /** True where a read can return credential material: config stores, secret
   *  managers, environment dumps, some build artefacts. Data that is authority. */
  readonly yieldsCredentials: boolean;
};

/** What the statement of work said the agent was for, as resource classes.
 *  Usually reconstructible from the requirements document in an afternoon. */
export type DeclaredTask = {
  readonly id: string;
  readonly summary: string;
  readonly needs: readonly ResourceClass[];
};

What the field already knows

None of this argument is novel, which should be encouraging rather than deflating. The pieces are published, and most of them are old.

The non-transitivity principle is stated plainly in NIST's zero trust architecture publication of August 2020. Its third tenet holds that access to individual enterprise resources is granted on a per-session basis, that trust in the requester is evaluated before access is granted, and that access should be granted with the least privileges needed to complete the task. Then the sentence that is the published counter-statement to the ambient toolbelt: authentication and authorisation to one resource will not automatically grant access to a different resource. An agent holding five connectors is a machine for violating that sentence, and the violation is not in any one connector.

The protocol's own security guidance names the failure mode in its own vocabulary, which is useful when you need language a client's security team will recognise. Its scope minimisation section lists, as risks, an expanded blast radius in which a stolen broad token enables unrelated tool and resource access, and privilege chaining in which an attacker can immediately invoke high-risk tools without further elevation prompts. Its list of common mistakes includes publishing all possible scopes as supported, using wildcard or omnibus scopes, and bundling unrelated privileges to preempt future prompts. That last one is on the list because it is common, and it is common because it is what a delivery team under schedule pressure rationally does.

The mitigation it prescribes is not a better toolbelt. It is a progressive model: begin from a minimal initial scope set, elevate incrementally through targeted authentication challenges naming the specific scope when a privileged operation is first attempted, and — the requirement most integrations quietly fail — tolerate down-scoping, meaning the server should accept reduced-scope tokens. Read as an architecture rather than a checklist, that is a negotiation in which authority is requested at the moment of use for the operation actually attempted. It is the correct shape. It is not the shape of any integration delivery method I have seen documented.

The vocabulary for what a broker would have to record already exists too. RFC 8693, the IETF's token exchange standard of January 2020, distinguishes impersonation — where, insofar as any entity receiving the token is concerned, they are dealing with the impersonated principal — from delegation, where the acting party retains its own identity and it is explicitly understood that actions are taken by one party representing another. The specification defines an act claim recording that delegation occurred and identifying the acting party, and a may act claim stating that a party is authorised to act on behalf of another. For a services firm that is the missing half of the audit story: not just what was reached, but on whose behalf, in a form a machine can check.

One honest limit, because this claim is widely misstated. RFC 8693 does not require an exchanged token to be narrower than the token presented. Narrowing by scope, audience or resource is requested by the client and granted at the authorisation server's discretion. Saying that token exchange enforces least privilege is a misreading of the primary text. It supplies the vocabulary; it does not supply the guarantee.

Where this argument runs out

Architectural claims are cheap unless the person making them says what would show them wrong. Five things.

The headline number does not exist, and I will not invent one. The obvious way to end an essay like this is with a multiplier — a granted connector reaches so many times more than its task needs. No such figure is published anywhere I could reach. I found no standards body, cloud vendor or supervisor publishing a measured grant-versus-closure ratio, and no vendor shipping a reachability analyser for tool grants that would report one. That absence is itself the strongest finding available: the industry carries a contractual duty to bound access to the contracted purpose, and has no published instrument for measuring whether it did. If you are quoted such a ratio, the two questions are what was measured and how the sample was drawn.

There is no incident behind this, and there should not need to be. I am not aware of, and did not verify, any public advisory attributing a named breach to composed tool authority created during an integration engagement. The argument is built from vendor documentation, protocol text, a published risk taxonomy and supervisory guidance, plus the structure of the delivery model. If it only lands once there is a named victim, it has not landed — and waiting for one is a poor engineering strategy in any case.

The strongest genuine counter is that closures may be small in practice. Suppose most engagements provision genuinely narrow per-task roles because the client's data team insists; suppose most agents are single-integration in practice and chain across systems rarely; suppose the file store really is isolated and the mail sender really is restricted to one distribution list at the gateway. Under those conditions the combinatorics never bite and this essay describes a problem nobody has. I believe that is false, but I cannot demonstrate it is false from public data, and I would rather say so than dress an intuition as a finding.

The measurement that would settle it has not been taken. The prediction under test is that if a firm ran the diagnostic above across its delivered engagements — reachable resource classes against those the declared tasks name — the gap would be large enough that the delivered union and the exercised closure could not sensibly be called the same object. I have not measured that, and no number in this piece is such a measurement. Two distributions would settle it and only large integrators hold the data: the distribution of integration-set sizes per agent, and the per-connector relationship between reachable resources and those a median task uses.

Three things would falsify the argument as stated. First, an engagement whose acceptance packs already carry the five properties the supply-chain guidance names, with grants minted per task, would make the central claim locally wrong and I would want to study it rather than defend the claim. Second, evidence that agent runs are effectively single-integration in practice would remove the composition premise entirely. Third, evidence that connectors in these engagements faithfully carry the calling user's own authority rather than a service identity would collapse the amplification argument — though note that the protocol forbids passing a client's token through to downstream APIs, which closes that particular escape route and is informative about the difficulty rather than reassuring.

Two scope limits on the sourcing, stated so nobody mistakes silence for coverage. I have not quoted the payment card standard or the ISO information security controls anywhere above: both are licence-gated at the publisher and I could not read them at the primary source within this pass, and services-firm content quotes them constantly from secondary summaries. And Gulf supervisory outsourcing provisions — the Saudi and UAE instruments a GCC client would be governed by — are not covered here. They need their own verified pass rather than a citation from memory, and a firm working a Gulf engagement should treat that as an open item rather than assume the American text transfers.

The half nobody scoped

Which returns to the objection I held back: that the composed authority is the client's configuration and therefore the client's problem.

As a statement about contracts that is frequently true and it helps nobody. Consider what the client actually has to work with when their examiner, their internal audit function or their own board asks the authority question — who authorised this agent to touch that, and how far could it have gone. The answer has to be assembled from the primitives the engagement left behind. If the only primitive is an integration, the answer is a list of five system names, which is not an answer to the question asked; it is the union restated, and the union was never the issue. Every client building an authority story today is reconstructing one from parts that were not designed to carry it, and they are all reconstructing it differently, which is why no two of their answers can be compared.

Your firm is the only party positioned to change that, and at the moment it is the only party not being asked to. The supervisor asks the client. The auditor asks the client. The security questionnaire asks the client. The party that chose which units of authority would exist in the estate is downstream of all of it, and the choice was made five times, in five design reviews, by five people who were each looking at exactly one system.

That is the reframe worth leaving with, and it is commercial rather than merely architectural. An integration engagement is not a set of connections. It is a claim about what units of authority exist in a client's estate, imposed on every audit, every incident review and every subsequent engagement for as long as the estate stands. Right now that claim is made by default, one workstream at a time, by a firm that is neither paid for it nor accountable for it. Both halves change together: the moment the composition becomes a deliverable with a name, an owner and an acceptance test, it becomes something to scope, price and hand over.

The shape of the alternative is visible from here without being built here. The grant stops being an integration and becomes something minted at the moment of use: narrow by construction, bounded to the task rather than to the system, carrying its expiry and its on-behalf-of with it, and verifiable at the resource rather than trusted at the perimeter. Every ingredient exists in shipped software and published standards — the intersection semantics documented for session policies and permissions boundaries, the delegation vocabulary of RFC 8693, and the challenge-driven elevation the protocol's own guidance prescribes. Assembling them into something a firm can deliver inside somebody else's estate, without a nine-month platform programme, is a separate piece of work with its own arguments and its own costs.

That construction is the companion to this one, forthcoming: Task-scoped capability brokering in a client integration. This is the teardown, and a teardown that hands you the answer in its last section has not made you sit with the problem long enough to want a good one.

For now the cheapest useful action is also the smallest. Take one engagement that has already gone live. Put the five or nine credentials behind it on a single page — not the five approved scopes, the five credentials — and write down what each one reaches. Nobody in that programme has ever done it, and the page will tell you within an hour whether the rest of this argument is worth your quarter.