Three teams built three agents and nobody owns what happens when they talk

Consider a programme of a shape a delivery organisation will recognise. A retail bank is eleven months into an agent build. Three workstreams run in parallel against one architecture. Two belong to the systems integrator that holds the master services agreement; the third belongs to a second vendor the client engaged directly, because the correspondence layer sits on a communications platform the incumbent does not own. Each workstream has its own statement of work, its own delivery lead, its own acceptance test pack and its own handover date.

Workstream A delivers a document intake agent. It classifies inbound customer documents, calls an optical character recognition service, and looks up the customer master. Workstream B delivers a reconciliation agent, which compares a nightly ledger extract against a counterparty file and holds write authority on an adjustments table under a service account provisioned by the client's platform team. Workstream C delivers a correspondence agent, which drafts and dispatches customer letters from an approved template set.

All three passed. The acceptance packs are not thin: each contains an interface schema, a runbook, a security review of that agent's own service account, a data-flow map and a signed test report. Three delivery leads, three sets of sign-offs, three invoices raised against milestones that were genuinely met.

The integration story, which everyone agreed to in the second month, was that intake would call reconciliation when a document changed a balance, and reconciliation would call correspondence when an adjustment crossed a materiality threshold. Nobody wrote a fourth statement of work for those two calls. They were not a deliverable. They were the reason the three deliverables were worth having.

At 02:14 on a Tuesday in the fourth week after go-live, the nightly run does what it was built to do. Intake processes a scanned instruction. Reconciliation finds a variance and posts an adjustment. Correspondence dispatches a letter to the customer explaining it. The trace is complete: four spans, each one after the root recording its parent, latency broken out per hop, tool arguments and results attached. If the correspondence agent had timed out, an engineer would have found it in ninety seconds.

Three weeks later, at the first post-implementation review, the client's operational risk lead asks a question that sounds administrative:

Under whose authority did the correspondence agent send that letter?

The trace answers a different question, and answers it perfectly. The letter was dispatched by the correspondence agent, which was invoked by the reconciliation agent, which was invoked by the intake agent, which was invoked by a scheduled job that started under a service principal the platform team provisioned at deployment. Four nodes, three edges, no gaps. It is a complete and accurate account of who called whom.

It contains nothing at all about who permitted what. The dispatch happened under authority that was established once, at the outer boundary, when the job started. Every hop after that inherited it — not by being handed it, not by asking for a narrower version of it, but by running inside a context in which it was already present. No span records that reconciliation was permitted to cause a customer letter, because reconciliation was never permitted to cause a customer letter in any sense that produced a record. It was simply somewhere that a customer letter was possible.

The programme above is a constructed illustration, assembled from patterns documented in public specifications and vendor documentation. It is not a report of any real client, engagement, deployment or incident, and no part of this piece describes client work.

Three packs, each complete, jointly silent

Take the handover artefacts seriously for a moment, because the argument is worthless if it depends on them being bad. They are not bad. An interface schema states what one agent will accept and return; it is checkable, and it was checked. A runbook states how to restart the thing at three in the morning; it was rehearsed. A security review of the agent's own service account enumerates the permissions that account holds against the systems it touches; it was signed by someone competent. A data-flow map states which categories of personal data pass through; it fed a privacy assessment. A test report demonstrates that the acceptance criteria hold.

Each of those artefacts is scoped to one agent. That is not a defect in the artefact. It is the definition of the deliverable: a workstream is accountable for what it built, and asking it to attest to something it did not build would be worse governance, not better.

The boundary, though, is the joint product of two workstreams and belongs to neither. When workstream B's security review says the reconciliation agent's account may write to the adjustments table, it is silent on what happens when reconciliation, mid-run, causes an outbound letter through an agent built by a different vendor under a different statement of work. Workstream C's review says the correspondence agent may dispatch from an approved template set — which is true, and which does not tell you what may cause the dispatch.

This is not negligence, and calling it negligence gets the diagnosis wrong. Each delivery lead made the same reasonable assumption, and the assumption was symmetric: the boundary is the other side's responsibility. Workstream B assumed the correspondence agent authorises its own callers, because that is what a well-behaved service does. Workstream C assumed the caller arrives holding authority that someone upstream established, because that is what a well-behaved caller does. Both assumptions are correct descriptions of good practice. Together they describe a boundary that nobody checks, and they do so without either party being wrong about their own half.

There is a commercial fact sitting underneath the technical one, and for a services firm it is the more consequential of the two. The boundary was never in a statement of work. Because it was never in a statement of work, it was never estimated. Because it was never estimated, it was never staffed. And because it was never staffed, the first person who will ever look at it in earnest is a client auditor, eighteen months later, when the programme has closed, the team has rolled off, and the only budget line available is a warranty argument.

The objection, stated properly

The strongest response to all of this is that it is a familiar complaint dressed up as a new one, and it deserves to be put at full strength before it is answered. There are four versions of it and each has real force.

First: integration assurance is a mature discipline and this is what it exists for. Large programmes have run multi-vendor integration for decades. There is an integration workstream, an architecture review board, a design authority, an interface control document, a non-functional requirements catalogue, and a set of integration tests that run across vendor boundaries before anything goes near production. The suggestion that a serious integrator simply forgot about the seams between three systems is, on its face, insulting and usually wrong.

Second: liability is already allocated, in writing. The master services agreement names a prime. The prime's contract flows obligations down. The client's third-party risk function ran a vendor assessment on both the integrator and the second vendor before either was engaged. If something goes wrong at the boundary, the question of who answers for it is not open; it was closed in procurement.

Third: the technical fix is a configuration change, not an architecture. Give each agent its own service account with least privilege against the systems it actually needs. Log the account on every call. Now the trace tells you which principal acted at every hop, the reconstruction becomes a lookup, and the whole essay collapses into a ticket somebody closes in a sprint.

Fourth: the audit does not want the authority graph. What an auditor actually asks for is the change record, the approval that authorised the release, the evidence that the control was designed and operating, and a sample of transactions traced to source. Estates that predate agents have been audited successfully on exactly that basis for decades, without anyone reconstructing a runtime authority chain.

I want to grant all four, and then be precise about what each one does not reach.

Integration assurance verifies behaviour. It answers whether the call works, whether the schema holds under malformed input, whether the timeout is right, whether the retry is idempotent. It is very good at this. But an integration test executes inside a context where the ambient credential is present, which means a passing integration test is evidence that the call succeeds under whatever authority happened to be in scope — it is not evidence about what that authority was, and it cannot be, because the test asserts on outputs. The test passes for the same reason the production run works, and the reason is the thing nobody wrote down.

Liability allocation and recoverability are different properties, and only one of them is under contract. The interagency third-party guidance is unambiguous that the obligation does not move: whether activities are performed internally or via a third party, the guidance states, banking organisations are required to operate in a safe and sound manner and in compliance with applicable laws and regulations, and a banking organisation's use of third parties does not diminish its responsibility to meet those requirements to the same extent as if the activities were performed in-house. Knowing who is answerable does not produce a record of what happened. An indemnity is a mechanism for allocating a loss after it has been quantified. It is not a mechanism for quantifying one.

Per-agent service accounts are worth doing and they do not create the missing object. Suppose all three agents run under distinct accounts. You now have three principals instead of one, which is a genuine improvement to blast radius and a genuine improvement to the security review of each agent in isolation. What you do not have is a single edge. A distinct identity tells you which account acted. It says nothing about whether that account acted because another principal delegated something to it, what was delegated, how far the delegation was narrowed, or whether the caller was itself entitled to cause the call. Three identities and zero edges is still zero edges. The authority graph has nodes and no arcs.

The fourth objection is the one with the most force, and I concede more of it than the other three. For a large class of questions the change record genuinely suffices, and an estate where agents make suggestions that humans approve can be audited on the traditional basis indefinitely. The distinction is whether an action reached a customer or a ledger without a human in the path. Once it did, the question of what authorised it is no longer answerable by pointing at the release that deployed the code, because the release authorised the capability and the run exercised it, and the interesting cases are exactly those where the two diverge.

Why the boundary produced no artefact

The structural claim is narrow and it is worth stating in one sentence: delegation between agents is implicit, so the authority graph has no edges to record — not unrecorded edges, no edges.

Set the two graphs side by side. A call graph is a graph of invocations: its nodes are executions and its edges are calls, and every edge has a moment at which it began, a moment at which it ended, and a caller nameable at the moment it began. That is the whole reason tracing works. The edge is an event, and an event can be observed by the code that is causing it, at the instant it is caused. Distributed tracing is the practice of writing down edges while they are live.

An authority graph is a graph of grants: its nodes are principals and its edges are permissions one principal extended to another, bounded to a resource, an action, or a window. This is the graph the risk lead was asking about. For an edge in it to exist, the correspondence agent would have to hold a credential distinct from the reconciliation agent's, naming reconciliation as its issuer, and bounded more tightly than reconciliation's — because a grant identical to its parent is not a grant, it is the same grant.

None of that happens. What happens instead is one of three things, and all three are non-events.

1. A shared session. The run executes inside one session object authenticated once at the boundary. Each agent reads from it. Nothing is passed, so there is no moment at which one agent gives another anything, and therefore no moment at which an edge could have been observed.
2. An inherited credential. A token, key or client object was constructed at startup and is in scope for everything in the process. The correspondence agent does not obtain it. It has been in possession of it since the process began, alongside every other agent.
3. A carried-forward prompt. The system instruction, the tool definitions and the accumulated conversation move forward across the handoff. The context grows at every hop. The authority attached to it does not narrow at any hop, because nothing in the handoff is a place where narrowing could be expressed.

There is a second piece of evidence for this, and it is empirical rather than argumentative. The OpenTelemetry semantic conventions for generative AI describe the call graph in considerable detail: the operation name, the provider, the request model, input and output messages, system instructions, tool definitions, the conversation identifier, token usage. They define no attribute recording the authorising principal, the credential in use, the permission relied upon, or the delegation under which a tool call was made. The people who wrote the telemetry standard were not careless; they modelled what the runtime produces, and the runtime does not produce this. The GenAI-specific attributes carry Development stability, which is worth saying because it means the absence is a snapshot rather than a settled fact.

The specifications closest to the problem confirm the shape from a different direction. RFC 8693 draws the distinction the whole argument turns on. Under impersonation, the RFC says, one principal is given all the rights another has within some defined rights context and is indistinguishable from it in that context; under delegation, the acting principal still has its own identity, and it is explicitly understood that while some rights may have been delegated, any actions taken are being taken by one party representing another. An agent acting under a credential it inherited because the credential was in scope is doing the first thing, in the RFC's own vocabulary. Nothing at the resource can tell it apart from its parent.

The RFC also defines the only widely standardised delegation-chain object, and then declares it non-actionable. Its actor claim can be nested — the outermost act claim is the current actor, nested act claims are prior actors, the least recent actor is the most deeply nested — which is a delegation chain, written down. The same section then states that for the purpose of applying access-control policy the consumer of a token must consider only the token's top-level claims and the party identified as the current actor, and that prior actors identified by nested act claims are informational only and are not to be considered in access-control decisions. The chain is standardised as an audit artefact and explicitly disclaimed as a constraint.

The Model Context Protocol, at revision 2025-06-18, closes the worst version of the problem and does not open the record. Its authorization section is normative that servers must not accept or transit tokens other than those issued to them, that servers must validate that access tokens were issued specifically for them as the intended audience, and that where a server calls an upstream API the token used upstream is a separate token issued by the upstream authorization server, which the server must not satisfy by passing through the token it received from its client. The specification names the failure mode it is preventing: passthrough can cause the confused deputy problem, where the downstream API incorrectly trusts the token as if it came from the server. That is the right rule. Note what it produces: a fresh token at every hop, and no claim linking that token to the token it replaced.

The Agent2Agent protocol at version 1.0.0 takes the same position by omission. It defines no in-protocol identity and no on-behalf-of chain: credentials are obtained and transmitted out of band through standard transport mechanisms against the schemes an agent declares in its agent card, each agent independently authenticates its caller, and servers must return an authorization error where the authenticated client lacks the required permissions. That is a coherent design. It also means that cross-vendor agent interoperability, as specified today, transmits the request and not the grant behind it — which is precisely the boundary in the illustration, the one between the integrator's workstreams and the second vendor's.

The convergence is the finding. Three independent specification families arrived at the same discipline — do not pass the parent's credential onward — and none of them supplies the complement, which is a way of recording that a narrower credential was derived from a wider one and having the resource enforce the derivation. The industry has agreed on what not to do. It has not agreed on what the resulting object is called, who mints it, who carries it, or who gets handed a copy at the end of an engagement.

What the client's instrument requires, and what it cannot reach

A services firm has no supervisory instrument of its own here, and it is worth being exact about that because the sector is regularly sold governance products premised on the opposite. A systems integrator building inside a bank is not supervised as a bank. What it has is a contract, and what governs the work is whatever instrument governs the client. So read the client's.

For a US bank, the operative text is the June 2023 interagency guidance on third-party relationships, issued jointly by the Federal Reserve, the FDIC and the OCC. Its overview holds that a banking organisation's use of third parties does not diminish its responsibility, and its contract-negotiation section on responsibility for compliance with applicable laws and regulations states that the use of third parties does not abrogate the organisation's responsibilities and that it is therefore important for a contract to specify the obligations of both the third party and the banking organisation to comply. Read that as a services firm rather than as a bank: the obligation cannot be moved to you, and the mechanism the guidance reaches for is contract text. Whatever the statement of work specifies is what will exist.

The nearest thing that guidance offers to a delegation clause is its subcontracting provision, and it is written entirely about legal entities. It opens by naming the defect precisely — subcontracting can result in risk due to the absence of a direct relationship between the banking organisation and the subcontractor, further lessening the organisation's direct control of activities — and then suggests the contract address when and how the third party notifies the organisation of its use or intended use of a subcontractor, whether specific subcontractors are prohibited, whether assignment, transfer or subcontracting of the third party's obligations to another entity requires consent, the third party's liability for the activities or actions of its subcontractors, and a right to terminate without penalty where subcontracting arrangements do not comply. The audit provision reaches the same way: contracts generally include provisions for periodic independent audits of the third party and its relevant subcontractors, and may reserve the organisation's right to conduct its own audits or engage an independent party to do so.

An audit right that reaches the subcontractor but cannot recover which subagent acted under whose grant is a right that cannot be exercised. The client has bargained for visibility into the delegation chain, and the chain it can see is the one made of companies. Underneath the last company on that chain sits a runtime that creates and destroys delegates thousands of times a night, and the audit right does not fail at that layer so much as arrive to find nothing addressed to it.

In India the shape is the same and the source is a statute rather than guidance. The Digital Personal Data Protection Act, 2023 makes the client's liability non-waivable and simultaneously mandates a contract. Section 8(1) provides that a Data Fiduciary shall, irrespective of any agreement to the contrary or any failure of a Data Principal to carry out their duties, be responsible for complying with the Act in respect of any processing undertaken by it or on its behalf by a Data Processor. Section 8(2) permits engaging a Data Processor to process personal data on its behalf only under a valid contract, and section 2(k) defines a Data Processor as any person who processes personal data on behalf of a Data Fiduciary. Section 8(5) extends the same posture to security: the Fiduciary shall protect personal data in its possession or under its control, including in respect of processing undertaken by it or on its behalf by a Processor, by taking reasonable security safeguards to prevent a personal data breach.

The recurring statutory phrase is on its behalf, and it is exactly the relation an ambient shared session fails to record. When the correspondence agent dispatches a letter containing personal data, the question of whose behalf it acted on is a statutory question in India before it is an architectural one, and the runtime has no field that answers it.

For an Indian regulated entity the outsourcing instrument adds the contractual layer. The RBI Master Direction on outsourcing of information technology services holds that outsourcing does not diminish the regulated entity's obligations, and that its board and senior management remain ultimately responsible for the outsourced activity; its contractual-clauses section requires prior consent for the service provider's use of sub-contractors, a right to seek information about third parties in the supply chain, clauses making the provider contractually liable for the performance and risk-management practices of its sub-contractors, and audit rights extending to the sub-contractor.

In the Gulf the gate is higher. SAMA's Rules on Outsourcing require that a contract prohibit sub-contracting of material outsourcing without the prior approval of the bank and a no-objection from the regulator, require the contract to address the provider's obligations where all or part of the outsourcing is sub-contracted, and hold that the bank's board retains ultimate responsibility for the outsourcing policy and all outsourcing arrangements. An unrecorded sub-delegation in a Saudi engagement is therefore not merely an audit gap in the abstract; it sits in the same conceptual place as a step that would have required a supervisor's no-objection.

That unresolved question matters more than it looks, because it is the point where two governance systems fail to mesh rather than the point where one of them is weak. If a subagent is a sub-contractor, then a great deal of runtime behaviour is happening without the notification, consent or no-objection the contract stack requires. If it is not, then the runtime has a delegation mechanism that no clause in the contract stack governs at all. Both readings are uncomfortable, and the primary text supports neither.

One more instrument belongs here, and it is the one a services firm should read most carefully. The current US model-risk instrument is OCC Bulletin 2026-13, "Model Risk Management: Revised Guidance," issued 17 April 2026, with the parallel Federal Reserve issuance SR 26-2 of the same date. The bulletin rescinds the earlier OCC issuances — 1997-24, 2011-12 and 2021-19 — and the model-risk booklet of the Comptroller's Handbook; the Federal Reserve letter is the one that supersedes SR 11-7 and SR 21-8. Either way, SR 11-7 should no longer be cited as current by anyone. The bulletin states that generative AI and agentic AI models are novel and rapidly evolving and, as such, are not within the scope of the guidance, and that the guidance does not set forth enforceable standards or prescriptive requirements. Separate AI guidance has been promised; I could not locate it as published.

Read that as a deferral, not an exemption. Every obligation attached to the underlying action is untouched: safety and soundness, consumer protection, sectoral duties, third-party risk. What was withdrawn is the framework that would have specified the controls. For a bank that is a question about supervisory expectations. For the firm building inside the bank it is more immediate and more concrete: there is no external specification arriving in time to tell you what to hand over, so the handover will contain exactly what the statement of work said it would contain, and nothing else.

What fails, mechanism by mechanism

Abstractions about missing objects are easy to nod along to. Here is what the absence does in delivery terms, at the level a delivery lead would recognise.

Revocation degrades from surgical to blunt. A credential can be revoked in seconds. What cannot be done is enumerate what was performed under authority derived from it, because nothing was derived — the credential was inherited whole, repeatedly, by everything in scope. The recovery action available is therefore to revoke and then reason backwards from the call graph about what might have been reachable, which is a superset of what actually happened and usually a large one. In a multi-vendor programme that superset spans three vendors' systems, and the reasoning has to be done by people from all three.

Attribution becomes correlation. Asked which principal authorised the letter, the honest answer is a reconstruction assembled from timestamps, the call graph, the release record and somebody's memory of the design intent. Reconstructions of that kind are defensible when they are complete and cheap when the estate is small. They are neither at scale, and their quality is invisible from inside — the reconstruction looks the same whether it is right or wrong.

The contracted audit right cannot be exercised in the direction that matters. The client bargained for audit reaching the third party and its relevant subcontractors. An auditor exercising that right against the boundary in the illustration is asking for evidence about a relation that no system recorded. What the auditor will be given is the same three handover packs, which is what an integrator has, and which does not respond to the question.

Blast radius is computed on the wrong set. The question after any prompt-injection-shaped event is what the affected agent could reach. Where authority is ambient, the answer is the union of everything in scope of the shared credential, which in a three-workstream programme is the union of three workstreams' scopes — including the second vendor's, whose scope the integrator did not design and may not fully enumerate. The security review of each agent, individually accurate, understates this by construction, because each was scoped to one agent.

The breach clock runs on a fact nobody holds. Under DPDP the Fiduciary's duty attaches to processing undertaken on its behalf. Establishing what was processed on whose behalf, across a boundary where behalf was never recorded, is work that has to happen inside a notification window rather than before it. That work is not hard because the systems are complex. It is hard because the field does not exist.

Change control has a gate on the wrong event. Adding a new subagent, or letting an existing one call one more tool, is a code change inside one workstream. It is gated by that workstream's review. Whether it is also a change to the delegation surface the client contracted around is a question the change process does not ask, because the delegation surface is not a named object in any document the change process consults.

And then the commercial mechanism, which is the one that decides whether any of this gets fixed. Every failure above surfaces after handover. At that point the funded workstream has closed, the delivery leads have rolled off, the client is looking at three signed acceptance packs, and the conversation about who pays to close a gap that nobody scoped is a conversation between a client and a prime with a signed contract between them. The technical defect is a governance gap. The commercial defect is that the gap is discovered at exactly the moment when nobody has a budget line for it.

/** A span in the OpenTelemetry GenAI shape, reduced to what this probe reads. */
export interface GenAiSpan {
  readonly spanId: string;
  readonly parentSpanId: string | null;
  readonly name: string;
  /** Flat attribute bag as exported. Values are compared, never parsed. */
  readonly attributes: Readonly<Record<string, string | number | boolean>>;
}

export interface CallEdge {
  readonly fromSpanId: string;
  readonly toSpanId: string;
  readonly operation: string;
}

/** An edge in the authority graph: a grant, with the principal that issued it. */
export interface AuthorityEdge {
  readonly issuer: string;
  readonly subject: string;
  readonly scope: readonly string[];
}

export interface ProbeResult {
  readonly callEdges: readonly CallEdge[];
  readonly authorityEdges: readonly AuthorityEdge[];
  readonly answerable: readonly string[];
  readonly unanswerable: readonly string[];
}

/**
 * Attribute keys defined by the GenAI semantic conventions that this probe relies on.
 * Enumerated explicitly so that the absence below is a claim about the standard, not an
 * accident of what one vendor happened to emit.
 */
const OPERATION_KEY = "gen_ai.operation.name";

/**
 * There is no constant here for an authorising principal, a credential, a permission or a
 * delegation, because the conventions define none. Adding a vendor-specific key would make the
 * probe report a fuller graph on one vendor's data and would stop measuring what it is for.
 */
export function probe(spans: readonly GenAiSpan[]): ProbeResult {
  const byId = new Map<string, GenAiSpan>(spans.map((s) => [s.spanId, s]));

  const callEdges: CallEdge[] = [];
  for (const span of spans) {
    if (span.parentSpanId === null) continue;
    if (!byId.has(span.parentSpanId)) continue;
    const operation = span.attributes[OPERATION_KEY];
    callEdges.push({
      fromSpanId: span.parentSpanId,
      toSpanId: span.spanId,
      operation: typeof operation === "string" ? operation : "unknown",
    });
  }

  // Every edge of the authority graph would have to be read from a grant. No attribute in the
  // conventions carries one, so the set is empty by construction rather than by sampling.
  const authorityEdges: readonly AuthorityEdge[] = [];

  return {
    callEdges,
    authorityEdges,
    answerable: [
      "which agent invoked which",
      "how long each hop took",
      "which tool was called with which arguments",
      "where the run failed",
    ],
    unanswerable: [
      "which principal authorised the deepest action",
      "what the authority at hop N was narrowed to, relative to hop N minus 1",
      "whether the caller was entitled to cause the call",
      "what else was reachable under the same authority",
    ],
  };
}

What the field already knows, and how long it has known it

None of this is a new observation about agents. It is an old observation about ambient authority that agents have made cheap to reproduce at machine rate.

NIST's zero-trust architecture publication, from August 2020, forbids the pattern in its tenets: access to individual enterprise resources is granted on a per-session basis, access is granted with the least privileges needed to complete the task, and authentication and authorization to one resource does not automatically grant access to a different resource. A subagent that can reach a second system because a credential for the first was in scope violates the third of those by construction, not by misconfiguration.

The same publication anticipated the agent case specifically, five years before the frameworks existed. In its section on non-person entities it observes that artificial intelligence and other software-based agents are being deployed to manage security issues on enterprise networks, and that how these components authenticate themselves in an enterprise implementing a zero-trust architecture is an open issue. It states the risk exactly: an attacker may be able to induce or coerce such an entity to perform a task the attacker is not privileged to perform, and the software agent may face a lower bar for authentication — an API key rather than multi-factor authentication — to perform administrative or security-related tasks than a human user would. NIST called it an open issue in 2020. No instrument reviewed in this piece has closed it.

The constructions exist and are published. The macaroon paper, presented at NDSS in 2014, describes bearer credentials that embed caveats attenuating and contextually confining when, where, by whom and for what purpose a service authorises a request, built from nested chained message authentication codes and supporting decentralised delegation between principals. Its important property for this argument is that attenuation is offline: a holder can narrow a credential without a round trip to the issuer, which is what makes per-hop narrowing viable inside an agent run where hops are measured in milliseconds.

Biscuit takes the same idea further into structure. Its specification describes a token as an authority block containing the rights given to the holder, followed by blocks containing checks that reduce the token's scope; the holder can at any time create a new token by adding a block with more checks, thereby restricting the rights of the new token, blocks cannot be removed without invalidating the signature, and an operation must comply with all checks in order to be allowed. Each block carries the serialised policy, the next public key, and the signature by the previous key — a verifiable chain in which every link names its parent. That is the concrete form of the principle that a child can never hold more than its parent, expressed as a property of the credential rather than as a rule somebody has to remember to apply.

So the inventory reads: the cryptography was published more than a decade ago, the standardised chain vocabulary exists and is disclaimed for enforcement, the transport specifications have converged on not passing the parent's token, the telemetry convention models the call and not the grant, and the supervisory instruments require a chain of legal persons to be visible and consented. Every ingredient is on the table. No layer owns the assembly, and no document in a delivery programme names the result as a deliverable.

The limits of the argument

An argument this structural should be honest about where it thins out, and there are five places.

1. Nobody has measured this, including me. No primary publication I could locate measures how attribution accuracy degrades as agent-to-agent handoffs increase. Not NIST, not the banking agencies, not RBI or SAMA, not the IETF, not OpenTelemetry, not the MCP or A2A projects. There is no decay curve, no hop-count threshold, no quantified attribution metric. I have not run the experiment either, and I am not going to imply a number by writing around the absence of one. The claim here is structural — the object does not exist — and it is not a claim about how much accuracy is lost per hop, because that is unpublished.
2. There is no prevalence figure either. I found no primary-published measurement of how common multi-agent architectures are in services engagements, or what share of statements of work specify anything at the authority layer. Percentages on either point circulate in market commentary; treat them as unsourced until somebody publishes the original.
3. The negative claims rest on targeted reads of moving specifications. The A2A observation is against version 1.0.0 and the OpenTelemetry observation against the current GenAI conventions, whose attributes carry Development stability. Both are actively evolving. A reader relying on the absence should re-verify it rather than trusting this piece's snapshot date.
4. The legal question is genuinely open. Whether spawning a subagent under an inherited credential is a sub-contracting event for the purposes of the clauses quoted here is not answered in the primary text of any of them. I have deliberately not picked a reading, and an argument that needed one would be weaker than this one.
5. Two relevant standards are behind a paywall. The ISO management-system and supplier-security standards nearest this problem could not be read at the source, so their control text is excluded rather than paraphrased from commentary. If they address the authority layer, this piece has not accounted for it.

What would falsify the argument is easier to state, and I would rather state it than be argued into it.

• A telemetry convention adds an authorising-principal attribute and frameworks emit it by default. Then the record becomes a byproduct of running the system, and the handover gap collapses into a documentation task — a real task, but a much smaller one than this piece claims.
• An agent framework mints a fresh, attenuated credential per hop that names its issuer, and does it by default rather than as an opt-in. Then the object exists, and the argument is obsolete rather than wrong.
• A supervisory instrument names the authority record as a required artefact in an outsourcing handover. The promised AI guidance following OCC Bulletin 2026-13 could do this; it is not published, and I am not going to assume its contents.
• Someone demonstrates that reconstruction from timestamps, change records and the call graph is sufficient in practice for the questions actually asked at review — with a published method and an error rate. This is the objection I would find hardest to answer, and it is answerable with evidence rather than argument.

The fourth of those deserves more than a bullet. For a small estate with two agents and a human approval in the path, reconstruction is fine, the cost of building anything else is not justified, and a firm that sold the client an authority-layer programme on the strength of this essay would be selling something the client does not need. The argument bites where actions reach customers or ledgers without a human between, where the number of boundaries is more than a person can hold in their head, and where more than one vendor's code is inside the loop. That is a real and growing set. It is not every engagement.

Where this leaves the statement of work

This is a teardown, and it stops before the construction on purpose. But the shape of what would close the gap is constrained enough by the foregoing to state without building, and stating it is the fairest way to end.

Three properties, which have to hold together, because any two without the third reproduce something that already exists and already fails. The grant has to be an object rather than an ambient condition — something minted, held and passed, so that there is a thing to record. The child has to be weaker than its parent by construction rather than by policy, and it has to name its parent verifiably, so that the record cannot be forged by the party it would incriminate. And the constraint has to be evaluated where the call lands, not only at issuance, because a check performed at an authorisation server is a check performed before the interesting decisions were made.

For a services firm there is a fourth, and it is the one that belongs in the contract rather than in the architecture: the resulting record has to leave the runtime and arrive in the client's hands as a named artefact with an owner. An authority record that exists inside a vendor's platform and is never handed over solves the security problem and leaves the client's post-implementation review exactly where it started — which, from the client's side, is indistinguishable from not having solved it.

How to build that — what the object is, where it sits relative to the orchestration loop, what it costs per hop, how it degrades when a downstream service has never heard of it, and what the clause looks like that makes it a deliverable — is a separate piece and a longer one. It is the companion to this one, "Delegation contracts across workstream and vendor boundaries."

What I would leave a delivery organisation with is smaller and available immediately. Before the third statement of work is signed, list the calls that will cross a workstream or a vendor boundary in production. For each one, name the document that will state what authority passes across it and the person who signs that document. On most programmes the list of calls is short and the list of documents is empty, and the gap between those two lists is legible in an afternoon. It is also, at that moment, still a scoping conversation rather than a warranty conversation — and that difference is the entire commercial content of this argument.