Who Is Responsible When AI Agents Work Across Multiple Systems?
An AI agent handling a customer refund may interact with several applications. It retrieves the support case, verifies the order, initiates a payment and updates the customer record. Each application accepts the request, and every action appears to be properly authorized.
But suppose the refund succeeds while the order-management system fails to register the transaction. The customer receives their money, yet the complaint remains unresolved. A subsequent attempt to process the request could result in a duplicate refund.
The agent has performed authorized actions, but the overall business process has failed.
This illustrates an accountability challenge as organizations deploy AI agents across multiple enterprise systems. Who is responsible for the final outcome when an agent operates across applications with different permissions, controls and records?
The issue is attracting greater attention from standards bodies. On 29 September 2026, the US National Institute of Standards and Technology (NIST) published a summary of feedback on its Software and Agentic AI Identity and Authorization concept paper.
The accompanying summary of public comments highlights concerns about preserving delegated authority across systems, maintaining traceability and avoiding accountability gaps when agents act through multiple services.
These concerns point to a broader governance problem. Identity and authorization establish whether an agent is permitted to perform an action. Organizations must also establish who oversees the complete workflow, particularly when individual actions succeed but the intended business outcome does not.
Delegated Authority Must Remain Identifiable
Before determining who is accountable for an AI agent's actions, organizations need to establish whose authority the agent is exercising.
An employee may have permission to investigate customer complaints and approve refunds within a defined financial limit. However, assigning an agent to investigate a particular complaint should not automatically transfer every permission available to that employee.
The distinction between identity and delegated authority already exists in established technical standards.
OAuth 2.0 Token Exchange, RFC 8693, distinguishes delegation from impersonation. Under delegation, the acting party retains its own identity while exercising authority on behalf of another party.
The standard also provides a mechanism for representing a history of delegated actors. This helps preserve information about how authority passed between participants. However, earlier actors recorded in a delegation chain are informational and do not independently determine access rights.
Microsoft's delegated-permissions model for Microsoft Graph provides another relevant example. In delegated access, an application's effective permissions are constrained by both the application's granted permissions and those of the signed-in user.
Microsoft separately documents application permissions for systems operating without a signed-in user. These arrangements require organizations to establish who approved the application's authority and what it is permitted to do.
The operational implication is important.
An employee authorized to issue refunds may delegate only the investigation of a complaint. The agent should not acquire payment authority simply because the employee possesses it.
Organizations therefore need to distinguish the identity of the agent, the person or function authorizing its work, and the specific authority granted for the task.
Authorization Must Be Enforced at Every System Boundary
Enterprise applications do not necessarily operate under a common authorization framework.
A customer support platform may permit an agent to read complaints. An order-management system may allow access to delivery information. A payment service may apply separate permissions to financial transactions.
Successfully accessing one application does not establish authority to perform actions in another.
NIST's Zero Trust Architecture, SP 800-207, provides a useful foundation. It establishes that authentication and authorization to one resource do not automatically grant access to another.
The architecture also distinguishes between the component making an access decision and the mechanism enforcing that decision at the resource boundary.
Applied to AI agent workflows, this suggests that authorization should be evaluated when the agent attempts an action within each connected application.
Permission to inspect an order should not silently become permission to release funds.
Organizations should define the scope of delegated authority according to the task, including permitted operations, relevant resources, transaction limits and duration.
Where a receiving application cannot enforce these restrictions, an additional enforcement mechanism or approval step may be necessary.
This helps prevent agents from accumulating broader permissions as they move between systems.
However, even properly enforced permissions cannot guarantee that the overall business process will be completed correctly.
When Every Action Is Authorized but the Workflow Still Fails
Consider a hypothetical retailer using an AI agent to manage customer refunds.
A support manager authorizes the agent to investigate a complaint and initiate a refund within a defined spending limit. The authorization applies only to the customer and order under review and expires when the task ends or after a specified period.
The agent retrieves the complaint, verifies the order and checks delivery information. These activities require read permissions.
It then prepares a refund request.
At the payment service, a separate authorization check evaluates the transaction against the approved scope. If the amount exceeds the permitted limit, the request is held for review by an authorized person.
Any approval should identify the particular order, amount and payment destination. A material change to those details should require renewed authorization.
At this stage, the individual controls are operating as intended.
Now suppose the payment succeeds, but the subsequent update to the order-management system fails.
The customer's refund has been processed, yet the business process remains incomplete.
The support system may continue to display an unresolved complaint. An automated retry could attempt the same payment again. The payments team may see a completed transaction that has not been reconciled with the original order.
The failure cannot be explained or resolved solely by demonstrating that each application correctly enforced its permissions.
Someone must determine whether the payment succeeded, reconcile the affected records and ensure that corrective action does not create another error.
This requires accountability for the workflow as a whole, extending beyond authorization of its individual steps.
Who Is Accountable for the Complete AI Agent Workflow?
When AI agents act across multiple systems, organizations should clearly assign responsibility for three distinct functions.
1. Delegating authority
The person or function authorizing the agent must ensure that the task remains within their own authority and the organization's applicable policies.
For example, a support manager should not authorize a refund beyond their permitted financial limit.
2. Enforcing permissions
The owners of connected applications must ensure that the applicable authorization restrictions are enforced within their systems.
The payment service, for example, should reject or hold transactions that exceed the agent's delegated authority.
3. Owning the business outcome
A designated workflow owner should oversee completion, identify unresolved transactions and coordinate recovery when the process fails.
In the retailer's case, the support manager might own the customer-resolution process, while the payments team remains responsible for enforcing transaction controls and supporting financial reconciliation.
These responsibilities may be distributed across teams, but they need to be explicitly assigned and coordinated.
Otherwise, each participating application may successfully perform its assigned function while no one takes responsibility for the incomplete business process.
The owner must also have the operational ability to intervene. Assigning responsibility without access to relevant records, escalation procedures or authority to initiate corrective action creates accountability on paper without the means to exercise it.
AI Agent Audit Trails Must Connect Decisions to Outcomes
When an AI agent operates across applications, each system may maintain its own records.
The support platform records the customer complaint. The order system records changes to the order. The payment service records the financial transaction.
These records may be individually accurate without providing a complete account of the workflow.
A stronger approach is to associate participating actions with a shared workflow identifier and retain information about:
- The original request and the person or function initiating it.
- The agent's identity and delegated authority.
- The authorization decisions and approvals applied at each relevant step.
- The actions executed and their results.
- Any failures, retries, interventions and corrective actions.
A reviewer should be able to reconstruct how the original request led to the final outcome.
In the refund example, this means establishing whether the payment was authorized, whether it was executed, why the order update failed and what happened during recovery.
Such evidence helps distinguish an authorization failure from an execution or reconciliation failure.
Recovery also needs technical safeguards. For example, Stripe's documentation on idempotent requests explains how supported API operations can use idempotency keys to allow retries without accidentally repeating the same operation. This is one example of a control that can help prevent duplicate transactions.
Nevertheless, a complete audit trail does not establish that the original business decision was justified.
An agent may misunderstand a complaint. A manager may approve an incorrect amount. An authorized transaction may still produce an inappropriate outcome.
As discussed in our earlier article, When AI Checks AI: Where Does Human Oversight Begin?, automated verification, AI evaluation and accountable human judgment establish different things.
The same principle applies to agent execution. Records may establish what happened and which authority applied, while determining whether the outcome was correct can require additional evidence and judgment.
Operational Accountability and Legal Liability Are Different Questions
Assigning a workflow owner is an important organizational control, but it does not automatically determine legal responsibility for an AI agent's actions.
An organization may designate a business manager as accountable for completing a workflow, while contractual obligations, statutory duties and legal liability are allocated differently.
The legal consequences of an agent's mistake depend on the applicable jurisdiction, the nature of the activity, the parties' contractual relationships and the circumstances surrounding the failure.
For example, a failure involving an internal customer-service process may raise different legal questions from an unauthorized financial transaction or an automated decision affecting regulated customer rights.
Technical standards must also be interpreted within their proper scope.
RFC 8693 defines mechanisms for security token exchange and delegation. NIST's Zero Trust Architecture provides cybersecurity guidance. Neither establishes a universal legal framework assigning liability for actions performed by AI agents.
Similarly, NIST's ongoing work on agent identity and authorization should not be treated as an already adopted set of binding requirements.
Organizations should therefore distinguish their internal accountability arrangements from any legal or regulatory obligations applicable to the relevant workflow.
Where ZeroH Fits
At Blade Labs, ZeroH addresses important parts of this challenge through a governed AI runtime.
As described in ZeroH's Policy & Control framework, the platform applies policies to govern permitted actions, access to connected tools and activities requiring human approval.
Its governance and evidence capabilities also support retained records of agent activity, authorization-related controls and approvals.
These mechanisms help organizations establish what an agent is permitted to do, where additional authorization is required and what evidence is available to review its actions.
When agents work across applications, such controls are particularly important because individual systems may otherwise provide only a fragmented view of the authority under which an action occurred.
However, enforcing authorization and retaining evidence do not automatically guarantee successful completion of the broader business process.
An organization still needs arrangements for detecting incomplete workflows, reconciling records between applications and recovering from partial failures.
This distinction also separates the present discussion from our earlier article, Keeping AI Agents Within Authorized Boundaries, which examines how independently enforced permissions prevent agents from taking unauthorized actions.
Authorization controls establish boundaries around execution. Workflow ownership establishes how the organization manages the resulting business process, including failures and corrective action.
Both are necessary for meaningful operational accountability.
Responsibility Must Follow the Complete Workflow
As AI agents take on business processes spanning multiple applications, organizations need to establish accountability beyond individual access decisions.
Before deploying an agent into a consequential workflow, the organization should be able to identify who authorized the task, what authority the agent received, how permissions are enforced and who is responsible when the process fails.
It should also be possible to reconstruct the original request, authorization decisions, actions performed and final outcome.
An agent may be properly authorized to perform every action and still fail to complete the intended task. The organization deploying it must be prepared to recognize and resolve that failure.
Effective AI agent accountability requires enforceable authority at each system boundary, traceable decisions and identifiable responsibility for the complete business outcome.
Explore how ZeroH supports governed AI agent execution through policy enforcement, approval controls and verifiable records.
Frequently Asked Questions
1. Who is responsible when an AI agent performs actions across multiple systems?
Organizations should designate a workflow owner responsible for overseeing the complete business process. The person delegating authority should ensure that the task remains within permitted limits, while individual system owners should enforce the relevant permissions. Legal liability, however, depends on applicable law, contracts and the circumstances of the agent's actions.
2. What is delegated authority in AI agent workflows?
Delegated authority allows an AI agent to perform specified activities on behalf of a person or organization. The scope of that authority should identify the permitted actions, relevant resources and applicable restrictions. RFC 8693 provides technical mechanisms for representing delegation, although enforcing task-specific business limits may require additional controls.
3. Why are individual authorization checks insufficient for AI agent accountability?
Authorization checks establish whether an agent is permitted to perform particular actions. They do not necessarily determine whether a complete business process succeeds. For example, an authorized refund may be processed successfully while the corresponding order update fails. Organizations therefore need monitoring, reconciliation and recovery procedures alongside authorization controls.
4. How can organizations maintain accountability for AI agents across different applications?
Organizations can establish task-specific permissions, enforce authorization at system boundaries, retain linked records of agent activity and assign responsibility for workflow completion. A shared workflow identifier can help reviewers reconstruct actions across participating applications, while defined escalation and recovery procedures support the resolution of failed or incomplete tasks.
5. How does ZeroH support AI agent accountability?
ZeroH provides governance controls around AI agent execution, including policy enforcement, managed tool access, approval mechanisms and retained records of actions. These capabilities support authorization and traceability. Organizations must additionally establish the operational responsibilities and recovery procedures needed to manage complete business workflows.
References
- National Institute of Standards and Technology (NIST). (29 September 2026). Comments on Software and Agentic AI Identity Concept Paper. Announcement of feedback received by the National Cybersecurity Center of Excellence on agent identity and authorization. https://www.nist.gov/news-events/news/2026/09/comments-software-and-agentic-ai-identity-concept-paper
- NIST National Cybersecurity Center of Excellence. Summary of Comments on the Concept Paper: Software and Agentic AI Identity and Authorization. Public feedback addressing delegation chains, authorization, trust boundaries, accountability and auditability. https://pages.nist.gov/nccoe-ai-identity/summary-of-comments.html
- Internet Engineering Task Force (IETF). (January 2020). RFC 8693: OAuth 2.0 Token Exchange. Technical specification covering security token exchange, delegation, impersonation and actor claims. https://www.rfc-editor.org/rfc/rfc8693.html
- Microsoft Learn. Overview of Microsoft Graph Permissions. Technical documentation explaining delegated access, application permissions and the constraints applicable to each model. https://learn.microsoft.com/en-us/graph/permissions-overview
- NIST. (August 2020). Zero Trust Architecture, Special Publication 800-207. Cybersecurity guidance describing resource-specific authorization, policy decision mechanisms and enforcement points. https://csrc.nist.gov/pubs/sp/800/207/final
- Stripe. Idempotent Requests. API documentation explaining how idempotency keys can prevent duplicate operations when supported requests are retried. https://docs.stripe.com/api/idempotent_requests
- Blade Labs / ZeroH. Policy & Control. Product documentation describing ZeroH's policy enforcement, permissions and human approval mechanisms. https://zeroh.io/policy
- Blade Labs / ZeroH. The Governed AI Workforce. Product information describing the ZeroH platform, governance controls and evidence capabilities. https://zeroh.io/proof-security
- ZeroH Blog. (20 October 2026). When AI Checks AI: Where Does Human Oversight Begin? Related analysis distinguishing automated verification, AI evaluation and accountable human judgment. https://blog.zeroh.io/when-ai-checks-ai-where-does-human-oversight-begin/
- ZeroH Blog. (28 October 2026). Keeping AI Agents Within Authorized Boundaries. Related article examining independently enforced permissions, agent authorization and governance at the point of action. https://blog.zeroh.io/keeping-ai-agents-within-authorized-boundaries/
