Imagine a procurement agent receives a request to evaluate a new supplier. It delegates financial checks to one agent, compliance screening to another and document verification to a third. Each agent completes its task and returns a result. The procurement agent combines those results and recommends approving the supplier.
But what happens if the financial agent retrieves the wrong company's records, the compliance agent misses a relevant finding, and the procurement agent approves the supplier?
Which agent made the mistake? Who authorized the delegation? Which system had access to the incorrect records? And who in the organization is responsible for reviewing the outcome?
This is not just a theoretical concern. The Canadian Centre for Cyber Security and its international partners explicitly describe an accountability scenario in which multiple agents collaborate on tasks such as approving payments or updating records. Because the outcome emerges from several connected decisions, identifying the component or design choice responsible can become difficult.
As enterprises move from individual AI agents to systems in which agents delegate work to other agents, accountability needs to follow the entire task, not stop at the first agent.
1. Why does delegation make accountability difficult?
In a conventional workflow, a person assigns a task to another employee. The receiving employee has an identifiable role, an accountable manager and defined authority.Agent-to-agent delegation is less straightforward. An orchestrating agent may assign a task to a specialist agent, which may call an external service or initiate another agent. The original user may never see these intermediate steps. Consider a simple banking workflow:
- A customer requests a change to their payment instructions.
- A customer-service agent retrieves the account information.
- A verification agent checks the submitted details.
- A risk agent assesses whether additional review is required.
- A payment agent initiates the requested change.
The verification agent may have received incorrect information. The risk agent may have been given incomplete context. The payment agent may have executed an instruction that appeared valid within its own task. The problem is that each agent can complete its individual assignment while the overall workflow still produces an incorrect outcome.
The joint guidance from CISA, NSA, ASD's ACSC and other cybersecurity agencies identifies this as an accountability risk. Extended delegation chains, secondary tasks and interconnected decisions can make it difficult to reconstruct how an outcome was produced.
An agent completing its assigned task does not prove that the overall delegated workflow was properly authorized or controlled.
2. Does accountability transfer when one agent delegates to another?
No, not automatically.An AI agent is software, not an independent legal person that assumes responsibility simply because another agent delegated work to it.
However, saying that the original human or organization always carries every form of legal liability would also be too simplistic. Legal responsibility depends on the applicable law, the roles of the parties involved, contractual arrangements and the circumstances of the incident.
For enterprise governance, the more useful principle is that delegation must not create a gap in organizational oversight.
Singapore's Infocomm Media Development Authority (IMDA) makes human accountability a central part of its Model AI Governance Framework for Agentic AI. Its guidance calls for organizations to define meaningful human approval checkpoints, limit agent autonomy and maintain controls throughout the agent lifecycle.
NIST's October 2026 guidance takes this further at the identity and authorization level. Its Design Tenets for Agent Identity Management Systems proposes that agents and their task originators remain linked throughout execution. It also states that delegated authority should become narrower as work passes to downstream agents.
This introduces an important distinction:
- Task delegation: Agent A asks Agent B to complete a particular activity.
- Authority delegation: Agent A passes a defined set of permissions or authority to Agent B.
- Accountability: The organization must retain the ability to establish who initiated the task, who authorized the activity and who is responsible for overseeing the outcome.
3. What happens when authority expands across agents?
Consider a procurement agent that is authorized to evaluate suppliers but cannot approve purchases.It delegates financial verification to another agent. That agent retrieves financial records and identifies a potential concern. It then asks a third-party verification agent to obtain additional information. There are three separate boundaries to consider:
- The original authority: The procurement agent was authorized to evaluate a supplier, not approve a purchase.
- The delegated authority: The financial agent was authorized to retrieve and assess financial information, not modify supplier records.
- The downstream authority: The verification agent was authorized to obtain specific information, not access unrelated financial or employee records.
This is the problem NIST addresses through authority attenuation:
A downstream agent should never acquire more authority through delegation than the agent passing the task was permitted to exercise.The guidance also proposes signed mandates that define the intended outcome and constraints of a task. These can help downstream systems verify what an agent was actually authorized to do.
For enterprises, this means a permission check should not simply ask whether an agent has access to a system. It should also establish whether the requested action falls within the authority delegated for that particular task.
4. A practical governance model: the Delegation Accountability Chain
Enterprises need a way to connect every handoff to the original task and its accountable owner.A useful approach is to maintain a Delegation Accountability Chain: a record that connects the initiating request, delegated authority, participating agents, consequential actions and final outcome.
Consider what should happen in the procurement example. What to record and practical example:
- Original task: Evaluate supplier ABC for a proposed procurement contract.
- Initiating authority: Procurement Head requested and authorized the evaluation.
- Primary agent: Procurement Evaluation Agent.
- Delegated task: Financial verification assigned to Finance Review Agent.
- Downstream delegation: Finance Review Agent requests a company-registration check from an approved external verification service.
- Authority limits: Financial agent can retrieve and assess records but cannot approve suppliers or modify payment details.
- Decision and approval: Procurement Head reviews the consolidated findings before supplier approval.
- Execution evidence: Records of the data retrieved, agents involved, tool calls, returned results and approvals.
- Final outcome: Supplier evaluation completed, with the decision and accountable owner recorded.
NIST's proposed agent identity principles reinforce this approach through distinct agent identification, linked delegation, defined mandates and independent, tamper-evident evidence.
This is a particularly important distinction between ordinary activity logging and accountability. A log may show that three agents interacted. A delegation record should help establish why they interacted, what each was permitted to do and how their actions contributed to the final outcome.
5. What should enterprises control across the delegation chain?
Four controls deserve particular attention.- Give every agent a distinct identity: An agent should not disappear behind a shared employee account or generic service credential. Organizations should be able to identify which agent performed an action and distinguish it from the person or service that initiated the task. NIST recommends distinct agent identities linked to the workload, environment and approved configuration.
- Restrict delegated authority: If an agent can only retrieve financial records, it should not be able to pass payment-approval authority to another agent. Delegated permissions should be limited to the task and should not expand as the chain grows.
- Establish human approval at consequential boundaries: Not every handoff requires a human. Requiring approval for every low-risk operation can create approval fatigue and encourage people to accept requests without reviewing them. However, actions such as approving payments, modifying access rights or changing important customer records may require a defined human checkpoint. Singapore's IMDA framework recommends identifying these significant approval points and ensuring that people have enough information to make an informed decision.
- Preserve evidence independently of the agents: If an agent can modify or delete the records used to reconstruct its own actions, the evidence becomes less trustworthy. Organizations should preserve relevant execution records independently, including agent identities, task origin, delegated permissions, tool interactions, approvals, timestamps and outcomes. The Canadian cybersecurity guidance also recommends clear delegation boundaries, defined agent roles, expiry of delegated authority and controls against unapproved delegation.
6. What happens when accountability is defined but cannot be demonstrated?
A survey by SecurityHQ and Datadog illustrates the gap between governance policies and operational readiness.Their October 2026 report, The Accountability Gap: The State of AI Agent Security and Governance 2026, surveyed 204 cybersecurity leaders at midsize and large organizations. The findings are revealing:
- 76% said their organizations had formally defined accountability for AI-driven operational or security decisions.
- 45% had experienced an AI or automation-related incident where accountability was unclear.
- Only 49% said they could fully reconstruct every action an agent performed over the previous 30 days.
- Just 17% believed they could reconstruct every action in a critical agent-driven incident within minutes.
For example, knowing that the Head of Procurement owns a supplier-evaluation workflow is not enough. The organization must also be able to establish which agents participated, what authority they received, what information they used and which decision led to the final approval.
Accountability that cannot be demonstrated through evidence becomes difficult to defend during an investigation, audit or dispute.
7. What enterprise leaders should ask before deploying multi-agent workflows
Before allowing agents to delegate work across business systems, leaders should be able to answer:- Who authorized the original task?
- Can every participating agent be individually identified?
- Does each downstream agent receive only the authority required for its assigned task?
- Can an agent initiate further delegation without approval?
- Which actions require human review?
- Can delegated permissions expire or be revoked?
- Can the organization reconstruct the complete sequence of handoffs and consequential actions?
- Is there a named business owner responsible for overseeing the workflow?
8. From agent delegation to continuous assurance
As enterprises connect more agents to business processes, the governance challenge moves beyond individual permissions. Organizations need to preserve the relationship between the original authorization, every subsequent delegation, the decisions made and the evidence supporting the final outcome.KlaritiQ approaches this as a continuous assurance problem: connecting system changes, ownership, evidence, approvals and decisions so that organizations can establish what was authorized, what changed and whether the original assurance still holds.
The goal is not to make every agent explain its private reasoning. It is to ensure that an organization can answer a much more practical question:
When one agent delegates to another, can the enterprise still prove who authorized the task, what authority was passed, what each agent did and who remains accountable for the outcome?