Who is accountable when a multi-agent workflow exceeds its authority?

Why This Matters for Security Teams

When a multi-agent workflow exceeds its authority, the failure is rarely just one bad request. It is usually a design gap in delegation, token scoping, and runtime enforcement that let the workflow accumulate more power than intended. For autonomous systems, static RBAC alone is not enough because the path an agent takes is shaped by tool outputs, intermediate states, and changing objectives. Current guidance from the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework treats that as a governance problem, not just an access-control problem.

NHI Management Group has also shown how often the underlying identity layer is already weak: only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs. In practice, that means a workflow can exceed authority without triggering a clear owner, because the organisation never designed accountability around agent behaviour, only around individual credentials. In practice, many security teams encounter misuse only after tool chaining or lateral action has already occurred, rather than through intentional workflow-level governance.

How It Works in Practice

Accountability should be assigned at three layers: the business owner of the workflow, the team that operates the control plane, and the approver who defined the delegation model. For agentic systems, best practice is evolving toward intent-based authorisation, where the decision is made at runtime against the agent’s current task, risk context, and available tools. That is the operational difference between a human user signing in and an agent assembling a chain of actions over time.

To make that workable, security teams should treat the agent’s workload identity as the primary identity primitive. Standards such as SPIFFE and OIDC can prove what the agent is, while just-in-time credentials and short-lived secrets limit how far authority can spread if the workflow goes wrong. The relevant question is not only “Did the token validate?” but “Was this token issued for this task, this context, and this duration?” That aligns with the control direction described in the CSA MAESTRO agentic AI threat modeling framework and the NHIMG analysis in OWASP NHI Top 10.

• Use policy-as-code so approvals are evaluated at request time, not pre-baked into static role tables.
• Issue per-task credentials with narrow TTL and automatic revocation on task completion.
• Log delegated actions back to the business owner, not just the platform operator.
• Separate tool authorization from data authorization so a valid token does not imply broad downstream access.

These controls tend to break down in long-running, multi-hop workflows because the system’s effective privilege can drift faster than review and revocation processes can keep up.

Common Variations and Edge Cases

Tighter workflow control often increases operational overhead, requiring organisations to balance rapid agent execution against stronger review and containment. That tradeoff becomes most visible in environments where agents coordinate across SaaS tools, CI/CD systems, and internal APIs, because each hop can introduce a new trust boundary. There is no universal standard for this yet, so current guidance suggests treating high-impact workflows more conservatively than low-risk retrieval tasks.

Edge cases matter. In a supervised pipeline, the approver may be accountable for authorising an overly broad workflow, while the platform team remains accountable for enforcing the guardrails. In a self-directed multi-agent system, accountability can also extend to the product or engineering owner if the system was deployed without meaningful runtime limits. The lesson from NHIMG case research, including the CoPhish OAuth Token Theft via Copilot Studio and Amazon Q AI Coding Agent Compromised reports, is that valid authentication does not equal valid authority. When agents can chain tools, call sub-agents, or inherit stale tokens across orchestration layers, accountability shifts from the request itself to the governance model that allowed the chain to exist.

That is why NIST AI RMF and OWASP agentic guidance both point toward continuous monitoring, explicit human ownership, and runtime policy checks rather than one-time role assignment.

Related resources from NHI Mgmt Group

• Who is accountable when a multi-agent workflow leaks data or opens access?
• Who is accountable when an agent reopens the same PR or repeats a side effect after recovery?
• Who is accountable when an AI coding agent sends traffic to the wrong system?
• Who is accountable when a self-modifying agent causes a bad outcome?