The pattern
Agent chains create authorization, liability, standards, security, and supervision questions at the same time.
OPERATIONAL FRAMEWORKS
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.
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
Use as a working artifact

Primary object
Connect each agent, delegated action, boundary, and consequence owner into one record before the chain goes live.
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 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
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.
ISACA
December 19, 2025
The Looming Authorization Crisis
Traditional IAM does not answer what autonomous agents are authorized to do.
FINRA
2026
Observations on AI Agents
Financial firms are already moving from single agents into coordinated agent workflows.
NIST
February 17, 2026
AI Agent Standards Initiative
Federal standards work has begun, but chain authorization is not yet defined.
OCC
April 17, 2026
Bulletin 2026-13
Bank supervisors point firms back to existing governance when agentic AI falls outside model risk scope.
CISA and Five Eyes
May 1, 2026
Careful Adoption of Agentic AI Services
Cyber agencies identify multi-agent accountability as an unresolved operational risk.
Berkeley Technology Law Journal
June 2, 2026
Multi-Agent AI Liability Frameworks
Liability analysis is moving from single-agent systems to multi-agent chains.
NSA
June 22, 2026
Five Eyes Cyber Security Agencies Statement
The same agencies continue to treat agentic AI as a cross-border security governance issue.
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

Chain gap
The chain can produce a consequential external effect even when no single agent was authorized for what the chain collectively did.
WHY IT COMPOUNDS
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.

Platform and enterprise layers
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
WHAT THE ENTERPRISE MUST BUILD ABOVE IT
THE FRAMEWORK
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.

Four-question model
A governed chain can answer who asked, who authorized, which agents acted, and what external effects the chain is permitted to produce.
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.
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.
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.
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
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.

Scenario map
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
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
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
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
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 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
CISA, NSA, FBI, ASD's ACSC, CCCS, NCSC-UK, and NCSC-NZ
May 1, 2026
View sourceNIST
February 17, 2026
View sourceMicrosoft Learn
Last updated May 1, 2026
View sourceMicrosoft Learn
Published April 9, 2026
View sourceFINRA
June 27, 2024
View sourceFINRA
2026
View sourceEU AI Act Service Desk
Articles 12, 18, 19, 26(6), and Annex IV reference
View sourceISACA
December 19, 2025
View sourceOCC
April 17, 2026
View sourceBerkeley Technology Law Journal
June 2, 2026
View sourceNSA
June 22, 2026
View sourceConnected frameworks
Multi-agent accountability depends on intent design, authorization evidence, readiness measurement, and deployment accountability.
Use these cards when the chain question points to missing authorization records, readiness gaps, or accountability ownership.
Connected framework
Defines the context, intent, and governance layers that must exist before any agent or chain is authorized to operate.
Connected framework
Measures agent count against authorization coverage so chain-level gaps become part of the readiness picture.
Connected framework
Turns individual and chain authorization decisions into an artifact that can survive audit and examination.
Connected framework
Separates provider, platform, and deploying-organization accountability so the chain gap lands with a named owner.
Connected framework
The runtime counterpart to the chain authorization record. Names the Suspension Authority who can halt a running chain when the outcome is authorized and wrong at the same time.
THE TARGET STATE
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.

Target state
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.
APPLY THIS FRAMEWORK NOW
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.
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.
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.
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.
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
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.