Skip to main content

OPERATIONAL FRAMEWORKS

Chain Authorization Gap

When the chain causes harm, no single agent's authorization record covers it.Four questions. One record. Most enterprises cannot answer any of them on the day the examiner arrives.

v1.0 - May 2026Sougata Roy, sougataroy.com

Free to read and cite with attribution to Sougata Roy and sougataroy.com. Do not republish, rebrand, or claim authorship of any framework, term, or model as your own.

Type

Chain accountability test

Version

v1.0

Published

August 2026

Time to use

30 min review / 90 min workshop

Audience

Architecture, risk, security, and compliance leaders

Output

A chain-level authorization record

Use this first

Test whether one original approval can travel through a multi-agent chain without review.

Primary object

Chain authorization gap

Use as a working artifact

Diagram showing a multi-agent chain where individual approvals fail to cover the aggregate outcome.

Primary object

Connect each agent, delegated action, boundary, and consequence owner into one record before the chain goes live.

View completed example

Limitation

This object can expose missing chain-level authorization and ownership. It cannot prove that every downstream action was technically prevented or that the aggregate outcome is safe.

Revision history

Version 1.0, August 2026: Page structure reordered to place the chain authorization test before explanatory content; added a constructed completed example. Framework definition and version unchanged.

Copyable citation

Sougata Roy, "Chain Authorization Gap," Version 1.0, August 2026, https://sougataroy.com/frameworks/multi-agent-accountability

When one agent calls another

Single-agent governance does not survive orchestration.

Single-agent governance asks who authorized one agent to take one action. Multi-agent orchestration breaks that simplicity when the chain collectively does something no single agent was authorized to do.

Use this section to identify what breaks first: scope, attribution, and the named human accountable for the aggregate outcome.

Evidence behind the pattern

One evidence trail, one missing record.

The links below are the trail. Together, they explain why a chain needs an authorization record before it reaches production.

The pattern

Agent chains create authorization, liability, standards, security, and supervision questions at the same time.

The warning

CISA, NSA, and Five Eyes partners specifically identify multi-agent accountability as an unresolved operational risk.

The gap

No published standard defines the chain-level authorization record or the accountable human named on it.

A customer request comes in. One agent receives it, hands it to a second agent that pulls the policy documents, and a third agent drafts the recommendation that shapes a credit decision. Each agent was approved to do its own step. The question this framework answers is who approved the three of them acting together.

Every framework built for single-agent AI governance asks the same question: who authorized this agent, what is it permitted to do, and who is accountable if it acts outside that scope? That question has a clean answer when one agent takes one action. It stops having a clean answer the moment orchestration begins.

When Agent A decomposes a task and delegates subtasks to Agent B and Agent C, three things happen simultaneously. The scope of permitted action expands beyond what any single agent's authorization record defines. The attribution chain fragments across multiple identities, multiple logs, and multiple system boundaries. The named human accountable for the outcome becomes ambiguous, because no single agent was individually authorized for what the chain collectively did.

The joint guidance published by CISA, NSA, and Five Eyes partner agencies in April 2026 named this scenario directly: multiple autonomous agents collaborate on a task, an erroneous outcome occurs, and fragmented logs plus opaque reasoning make it difficult to explain the result, assign responsibility, or demonstrate compliance. That description is not a future warning. It describes what is already happening in enterprise Copilot Studio deployments running orchestrated agent pipelines today.

Source: ASD's ACSC, CISA, NSA, and Five Eyes partners, "Careful Adoption of Agentic AI Services," May 1, 2026. URL: https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-ai-services

Editorial governance illustration showing a multi-agent chain with individual agent records and no chain-level authorization record covering the aggregate outcome.

Chain gap

Individual records do not cover the aggregate outcome

The chain can produce a consequential external effect even when no single agent was authorized for what the chain collectively did.

WHY IT COMPOUNDS

The Chain Authorization Gap

Multi-agent accountability failures compound because delegated decisions, attenuated audit trails, and missing principals can all exist at once.

Use this section to distinguish the Chain Authorization Gap from single-agent drift, agent sprawl, or ordinary logging failure.

Editorial governance illustration comparing platform identity controls with the enterprise authorization layer required for chain accountability.

Platform and enterprise layers

Identity is not authorization

Platform records can show agent identity, linked child identities, tokens, and logs. The enterprise still must produce the chain-level authorization record.

The Chain Authorization Gap is the absence of any authorization record for the outcome of a multi-agent chain, where no single agent in the chain was individually authorized for what the chain collectively did.

It is distinct from three related concepts. The Intent Gap describes behavioral drift in a single agent: the distance between what the agent was authorized to do and what it did in production. Agent Sprawl describes a deployment volume problem: more agents running than the organization knows about. The Chain Authorization Gap describes something different from both. It is a structural gap in the authorization architecture itself. The chain acted. No authorization record covers what the chain did.

Microsoft Entra Agent ID provides agent identities as special service principals and supports agent identity blueprints with linked child agent identities created from them. Copilot Studio separately supports connected-agent orchestration in which a primary agent delegates work to another agent. User tokens can carry the agent identity as the actor on behalf of the user as the subject. The A2A protocol supports shared identity, managed identity, and OAuth passthrough for agent-to-agent calls. Microsoft Purview audit and eDiscovery cover agent activity logs. These controls are real and they matter. They do not produce a single immutable record linking every delegation hop, approval, token scope, and final external effect to the human who authorized the chain to operate. That organizational governance layer sits above the platform. No platform currently builds it automatically. NIST opened a standards initiative in February 2026 specifically to address this gap. No finalized standard has been published.

What first-party Microsoft documentation does not specify, confirmed from primary sources reviewed in May 2026: a single immutable record linking every delegation hop, approval, token scope, and final external effect in a multi-agent chain. Purview captures activity. Entra Agent ID captures identity. Neither produces the chain-level authorization record that answers the four examiner questions: who asked, who authorized, which agent acted at each delegation hop, and what external effects the chain is authorized to produce.

The backbone of that record can be assembled from platform telemetry, joining Purview audit events, the Entra agent object with its linked child identities, and A2A call traces against the case identifier.

What telemetry cannot supply is the Authorization Root: the approving human, the approved scope, and the consent artifact exist only if the organization wrote them down first.

That gap is not a criticism of Microsoft's architecture. It reflects where the organizational accountability layer sits. Microsoft provides the substrate. The enterprise builds the authorization record above it. No enterprise should deploy a multi-agent orchestration and assume the platform has produced that record automatically.

Source: Microsoft Learn, "Agent identities in Microsoft Entra Agent ID," last updated May 1, 2026. URL: https://learn.microsoft.com/en-us/entra/agent-id/agent-identities

Source: NIST, "Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation," February 17, 2026. URL: https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure

Source: Microsoft Learn, "What is Microsoft Entra Agent ID?," URL: https://learn.microsoft.com/en-us/entra/agent-id/what-is-microsoft-entra-agent-id

Source: Microsoft Learn, "Connect an agent available over the A2A protocol," published April 9, 2026. URL: https://learn.microsoft.com/en-us/microsoft-copilot-studio/add-agent-agent-to-agent

THE GOVERNANCE SIGNAL

The orchestrator may delegate the task. The enterprise cannot delegate the burden of proof. When the examiner asks for the authorization record covering this chain's actions, the Entra Agent ID record is not that document.

WHAT ENTRA AGENT ID PROVIDES

  • Agent identity as a service principal
  • Parent-child relationship documentation
  • Actor-subject token semantics for on-behalf-of actions
  • Authentication for A2A agent-to-agent calls
  • Activity logs surfaced in Microsoft Purview

WHAT THE ENTERPRISE MUST BUILD ABOVE IT

  • The authorization record naming who approved the chain
  • The aggregate scope definition covering all agents in the chain
  • The named human accountable for the chain's output
  • The re-authorization trigger and review cadence
  • The chain-level evidence record satisfying an examiner's request

THE FRAMEWORK

Four questions. One record. Every chain must answer all four.

A chain-level authorization record is not a policy document. It is not a platform configuration. It is a governance artifact that answers four specific questions, produced before the chain goes live, and maintained for the life of the chain. If any one of the four questions cannot be answered from the record, the chain is ungoverned regardless of what the platform logs show.

Use these four cards as the chain-level accountability model. If the record cannot answer all four, the chain is not governed.

Editorial chain authorization dossier organized around who asked, who authorized, which agent acted, and what external effects are permitted.

Four-question model

Four questions become one record

A governed chain can answer who asked, who authorized, which agents acted, and what external effects the chain is permitted to produce.

Q1WHO ASKED

The Chain Root

Every multi-agent chain originates with a human or system trigger. The chain root identifies the initiating subject, the business purpose, the matter or case context, and the timestamp of the request. It is the legal and business anchor for everything that follows in the chain. Without a documented chain root, the chain has no traceable origin and no business justification that survives examination.

Named artifact or role

Initiating subject, business purpose, matter or case ID, source channel, tenant, request timestamp.

Q2WHO AUTHORIZED

The Authorization Root

Authorization for the chain must be documented before the chain executes. The authorization root names the approving authority, the approval mode (human review, automated policy, or delegated authority), the lawful basis for the chain's actions, the requested and approved scopes, the expiration of the authorization, and the specific environment the authorization covers. An authorization that cannot be traced to a named human decision is not an authorization. It is an assumption.

Named artifact or role

Approving authority, approval mode, consent artifact ID, lawful basis, requested scopes, approved scopes, expiration, environment.

Q3WHICH AGENT ACTED

Each Delegation Hop

Every point in the chain where one agent delegates a subtask to another agent is a delegation hop. Each hop must be recorded: the parent agent's identity, the child agent's identity, the delegated task, the delegated scopes, the endpoint receiving the delegation, the protocol used, the token type, the actor-subject relationship, and the start and end timestamps. This is the section of the record most current platforms do not produce automatically. It is also the section an examiner will ask for first.

Named artifact or role

Parent step ID, child step ID, child agent ID, delegated task summary, delegated scopes, endpoint URL, protocol, token type, actor-subject relationship, start and end timestamps.

Q4WHAT IS THE CHAIN AUTHORIZED TO CHANGE

The Permitted External Effect Boundary

Before the chain goes live, the authorization record must define the boundary of permitted external effects. Which tools the chain may call. Which data sources each agent may read or write. Which records may be created, modified, or deleted. Which actions require human review before execution. Which outputs may reach an external party without human review. The examiner does not only ask what the chain did. The examiner asks whether what the chain did was within what the chain was permitted to do. That second question requires a pre-defined boundary, not a post-execution log.

Named artifact or role

Permitted tool list, permitted data sources, permitted record modifications, human review requirements, external output permissions, prohibited actions.

THE EXAMINER TEST

Can you produce a single authorization record that names who approved this chain, defines the aggregate scope of permitted actions across all agents, identifies the human accountable if the chain acts outside that scope, and defines the boundary of what the chain is permitted to do outside the model? If any one of those four questions cannot be answered from the record, the Chain Authorization Gap exists in your environment.

THREE INDUSTRIES, ONE GAP

Three industries. Three orchestrations. Three examinations with no answer.

Each scenario below describes a real deployment pattern in a regulated environment. The examination question at the end of each scenario is the question a regulator would ask. The governance gap is the same in each case: an authorization record exists for individual agents but not for the chain's aggregate actions.

Use the scenarios to trace accountability back through the chain before the chain executes a consequential action.

Editorial triptych showing financial services, healthcare, and security operations multi-agent chains where individual records exist but the chain record is missing.

Scenario map

Different industries, same chain-level gap

The examination question changes by industry, but the gap is the same: individual agent records do not authorize the aggregate chain action.

Scenario construction

The three scenarios below are constructed examination scenarios, built to match documented regulatory patterns rather than drawn from any specific real examination.

FINANCIAL SERVICES - OCC EXAMINATION SCENARIO

Three-agent loan modification pipeline

A financial institution deploys a three-agent Copilot Studio orchestration: an orchestrator that receives customer requests, a retrieval agent that queries SharePoint for policy documents, and a drafting agent that produces loan modification recommendations. Each agent has an Entra Agent ID. Parent-child relationships are documented in the platform. The orchestrator is authorized to receive customer requests. The retrieval agent is authorized to query policy documents. The drafting agent is authorized to produce recommendations. No single agent's authorization record covers the combined action: receiving a customer request, retrieving policy data, and producing a recommendation that influences a credit decision.

OCC EXAMINATION QUESTION

Produce the authorization record for this orchestration chain. Name who approved the combined scope of all three agents acting together, define what that combined scope permits, and identify the human accountable for the chain's output on any given transaction.

Gap

The Entra Agent ID records exist. The chain authorization record does not. The OCC examination question cannot be answered from the documentation available.

Pattern documented in FINRA, "Emerging Trend in GenAI: Observations on AI Agents," January 2026. URL: https://www.finra.org/media-center/blog/observations-on-ai-agents

HEALTHCARE - CMS AUDIT SCENARIO

Clinical documentation and billing code orchestration

A healthcare system deploys a two-agent orchestration: a summarization agent that processes clinical notes and a coding agent that produces billing codes from the summary. The summarization agent is authorized to process physician documentation. The coding agent is authorized to suggest billing codes from structured input. Together, the chain produces billing codes that are submitted to CMS without physician review of the coding agent's output. No individual agent's authorization record covers the aggregate action: processing physician notes and producing billable codes in a single automated chain without documented human review of the combined output.

CMS AUDIT QUESTION

Identify the human who reviewed the coding agent's output before submission. Produce the authorization record showing that automated billing code production without physician review was an approved workflow for this orchestration.

Gap

The individual agent logs exist. The chain authorization record covering the automated billing workflow does not. The audit question cannot be answered.

Pattern consistent with HHS OIG guidance on AI in healthcare billing and documentation, 2025-2026.

SECURITY OPERATIONS - INTERNAL AUDIT SCENARIO

Alert triage and remediation orchestration

A security operations team deploys a two-agent orchestration: a triage agent that classifies security alerts and an action agent that executes predefined remediation playbooks based on the classification. The triage agent is authorized to classify alerts. The action agent is authorized to execute playbooks. An alert is misclassified. The action agent executes a remediation playbook that blocks legitimate network traffic for four hours. No authorization record documents who approved the triage-to-remediation chain as an automated workflow, what the aggregate scope of the combined chain permitted, or which human was accountable for automated remediation decisions taken without real-time human review.

INTERNAL AUDIT QUESTION

Which human approved this chain to execute remediation actions automatically based on triage classifications? What was the approved scope of automated remediation? Where is the re-authorization event that should have occurred when the playbook set was expanded last quarter?

Gap

No chain authorization record was produced before the orchestration went live. The audit question cannot be answered.

Pattern consistent with Oso Agents Gone Rogue incident register, 2025-2026.

Primary sources

This framework is built from primary sources.

The framework is grounded in current primary sources for agentic AI guidance, identity, recordkeeping, and regulatory expectations.

Use these references when chain accountability needs to be defended in architecture review, audit preparation, or examiner response.

HOW LONG AND HOW DEFENSIBLE

The record that does not survive counsel is not a record.

The EU AI Act separates provider and deployer record duties. Articles 12 and 19 and Annex IV define provider obligations for logging, compliance, and technical documentation. Article 18 places the ten-year technical documentation retention duty with providers. Article 26(6) gives deployers a log retention duty of at least six months, unless other law requires longer. That floor is a starting point, not an endpoint. An enterprise operating across jurisdictions must retain chain records for the longest applicable period across business, supervision, litigation-hold, and incident-response requirements.

Use this section to separate authorization records, audit logs, retention duties, and evidence integrity.

The chain authorization record defines the boundary of permitted external effects before the chain runs. The audit log records what the chain actually did outside the model: tool calls, server identities, request and response hashes, effect type, target resource, changed records, and any monetary or operational impact captured at the point of execution. The audit log is the evidence that the chain stayed within its authorized boundary. The authorization record and the audit log are two artifacts. Both must exist. Neither replaces the other.

Tamper evidence is not optional. A chain authorization record that can be altered after the fact is not a governance artifact. It is a liability. Signed events, hash chaining, and append-only or object-locked storage convert the record from a convenient narrative into defensible evidence. The measure of the record is whether it survives contact with counsel, not whether it satisfies an internal audit checklist.

Version control applies to the chain's configuration and its logs. Prompts, policies, tool schemas, and agent manifests must be versioned so that any event in the chain's history can be replayed against the exact configuration that existed at the time. If the system prompt changed between deployment and incident, the record must show both versions and the date the change occurred.

Source: EU AI Act, Articles 12, 18, 19, 26(6), and Annex IV. URL: https://ai-act-service-desk.ec.europa.eu/en/ai-act/article-12

Source: ASD's ACSC, CISA, NSA, and Five Eyes partners, "Careful Adoption of Agentic AI Services," May 1, 2026. URL: https://www.cisa.gov/resources-tools/resources/careful-adoption-agentic-ai-services

THE TARGET STATE

Every orchestration has a chain authorization record before it goes live. Every record survives the examiner's first four questions.

The target state is a chain authorization record that exists before production, survives the examiner's first four questions, and stays current when the chain changes.

Use this section as the operating standard for production multi-agent chains.

Editorial governance illustration showing a complete chain authorization record with aggregate scope, accountable human, delegation ledger, external effect record, material change triggers, review cadence, and evidence retained.

Target state

The chain is governed before it goes live

A production chain has approval, aggregate scope, delegated actions, external effects, re-authorization triggers, review cadence, and evidence retained on demand.

A governed multi-agent orchestration has a chain authorization record produced before the chain executes in production. That record names who approved the chain, defines the aggregate scope of permitted actions across all agents, identifies the human accountable for the chain's output, and documents the re-authorization triggers and review cadence. The record is maintained for the life of the chain and updated when the chain is materially modified.

Every agent in the chain has a distinct workload identity. Every delegation hop is logged with the parent agent ID, child agent ID, delegated scope, endpoint, protocol, token type, and timestamps. Every tool call that produces an external effect is recorded with the effect type, target resource, and changed records. The complete record can be produced on demand, not in response to an incident, but as a routine operational capability.

The organization has defined which orchestration changes constitute material modifications requiring re-authorization. Adding an agent to the chain, changing an agent's system prompt, extending the chain's data access, or changing the orchestration topology are each evaluated against the materiality definition. Where a change is material, re-authorization occurs before the modified chain goes back into production. Where orchestration composes chains dynamically at runtime, the Authorization Root covers a defined delegation envelope, the class of permissible agents, scopes, and effect types, and any chain outside that envelope requires new authorization before execution.

Authorization written before the chain runs is consent, not live judgment. The record proves the chain was permitted to act. The Disposition Protocol names the human standing by with the authority to stop it mid-run when the scope was right and the result is not. A governed orchestration has both.

THE PORTFOLIO DIAGNOSTIC

The Chain Authorization Test

One page. Two columns. Fifteen minutes to see your chain authorization coverage.

Use this worksheet to compare individual-agent review coverage against unit-level chain approval across the portfolio.

Take one piece of paper. Name every multi-agent orchestration running in your environment. Next to each one, fill the review column: the date its individual agents last cleared identity and sponsor review. Then fill the approval column: the date each orchestration was approved as a unit, by name, by a person, in writing.

The review column fills itself. Platform controls like Microsoft Entra Agent ID keep individual agent identities sponsored, reviewed, and current, and sponsor lifecycle workflows now automate what happens when a sponsor leaves.

The approval column has no platform behind it. It only fills when a person writes something down. That asymmetry is why review meetings end with a full review column, an empty approval column, and a clean audit result that proves nothing about the chain.

The Examiner Test above checks one chain in depth: whether a single record answers the four questions. The Chain Authorization Test checks breadth: how many of your chains carry any unit-level approval at all, and how stale those approvals are against material changes. Run the breadth test first. It tells you which chain deserves the depth test next.

Source: Microsoft Learn, "What's new in Microsoft Entra Agent ID," last updated May 1, 2026. URL: https://learn.microsoft.com/en-us/entra/agent-id/whats-new-agent-id

APPLY THIS FRAMEWORK NOW

Apply this framework in one working session.

Leave this session with four named answers or four documented gaps. Either outcome is a governance finding that moves the organization forward.

Use this working session to leave with named answers or documented gaps.

01

15 minutes: Inventory your orchestrations

How many multi-agent orchestrations are currently running in your environment? Include Copilot Studio agent chains, any workflow where one AI system calls another, and any automation pipeline that uses an LLM at more than one stage. Write the number down. If you cannot produce a number, that inability is the finding.

Output

A count of running orchestrations, or a documented gap in your inventory capability.

02

15 minutes: Check for chain authorization records

For each orchestration in your inventory, does a chain authorization record exist? Not an individual agent's authorization record. A chain-level record that names who approved the combined scope of all agents acting together, defines that combined scope, and identifies the human accountable for the chain's output. Count how many orchestrations have this record. The ratio of governed to total is your current chain authorization coverage. The Chain Authorization Test worksheet above is the artifact for this step.

Output

A count of governed orchestrations, or confirmation that no chain authorization records exist.

03

15 minutes: Run the four questions on your highest-risk chain

Take the orchestration with access to the most sensitive data or the most consequential output. Ask all four questions: who asked, who authorized, which agent acted at each delegation hop, and what external effects the chain is authorized to produce. Write down which questions the current documentation can answer and which it cannot. The questions that cannot be answered are the Chain Authorization Gaps in that specific orchestration.

Output

Four answers or four documented gaps for your highest-risk chain.

04

15 minutes: Name the next owner

Producing a chain authorization record requires a named human to own the process. Who is responsible for producing and maintaining chain authorization records for orchestrations in your environment? If the answer is unclear, that ambiguity is itself a Chain Authorization Gap at the organizational level. Name the owner before you leave this session.

Output

A named human owner for chain authorization records, or a documented escalation path to establish one.

Revision History

What changed in this framework

v1.4, July 2026: Added The Chain Authorization Test portfolio diagnostic with downloadable worksheet. Merged duplicated platform-coverage text, split long-form paragraphs, and cleaned section labels for readability.

v1.3, July 2026: fact corrections verified against primary sources; corrected Entra Agent ID blueprint wording and linked child identity telemetry language.

v1.2, July 2026: Added telemetry assembly guidance, dynamic delegation envelope language, and date-specific standards wording.

v1.1, July 2026: Added constructed-scenario disclosure, corrected the joint advisory agency list, and clarified EU AI Act record-keeping attribution.

v1.0, May 2026: Original publication.