TL;DR: More than half of large organisations already have an AI agent project in motion, and Gartner tracked a 750% surge in AI-agent inquiries between Q2 and Q4 of 2024, according to LEVO, while nearly a third of pilots stall before production because enterprises cannot enforce behavioural guardrails. The operational problem is not agent capability but runtime governance, because access review, policy enforcement, and identity tracking assumptions break once agents chain decisions across tools and systems.
At a glance
What this is: This is a governance analysis of AI agents and multi-agent workflows, showing that runtime autonomy amplifies privilege, data, and policy risks across chained actions.
Why it matters: IAM, PAM, IGA, and security architecture teams need a control model that tracks agent identity, permissions, and data flow in real time across every hop.
By the numbers:
- Gartner tracked a 750% surge in AI-agent inquiries between Q2 and Q4 of 2024.
👉 Read LEVO's analysis of governance risks in multi-agent AI workflows
Context
AI agent governance is now an identity problem as much as an application problem. These systems do not just automate tasks, they choose tools, move data, and trigger actions across APIs, MCP servers, and internal systems, which makes their runtime identity and permission boundaries central to security.
The gap is that conventional governance often assumes stable actors, predictable execution paths, and reviewable access states. Multi-agent workflows break those assumptions by chaining decisions, passing context between agents, and compounding access in ways that are difficult to see with static policy or point-in-time approvals.
Key questions
Q: What breaks when AI agents are not governed at runtime?
A: Without runtime governance, an agent can shift behaviour after provisioning and still execute actions that were never reviewed in context. That is where tool chaining, MCP connections, and rapid decision-making become dangerous. Static approval cannot stop a live change in intent, so teams lose control at the point of action.
Q: Why do multi-agent AI workflows increase information leakage risk?
A: Because each handoff can widen or drop the original user’s permissions. If identity and entitlement do not follow the task through retrieval, tool calls, and response generation, downstream agents may expose data that the initiating user should never see. That is why permission context must persist across the whole execution chain.
Q: What are the signs that AI agent governance is too weak for production use?
A: Weak governance usually shows up as poor visibility into what agents can access, incomplete audit trails, and inconsistent oversight across security, legal, compliance, and operations teams. Another warning sign is when organizations cannot explain which datasets an agent used or why it took a specific action. Those gaps make investigation, containment, and compliance far harder.
Q: How should security teams govern agentic AI that can execute IAM tasks?
A: Start by treating the agent as an NHI with bounded authority, explicit ownership, and revocation procedures. Require human approval for high-risk actions, log every decision path, and enforce least privilege at the workflow level. If the agent cannot be audited or rolled back, it is not yet ready for autonomous IAM execution.
Technical breakdown
How multi-agent workflows create privilege aggregation
Multi-agent workflows split a task across multiple agents, each with a bounded permission set. The security problem appears when outputs from one agent become inputs for another and the combined effect exceeds the original intent. A read-only agent can seed data for a write-capable agent, or a specialist agent can trigger actions that another agent would never have been allowed to initiate alone. This is privilege aggregation at runtime, and it is structurally different from a single application role. Traditional IAM sees separate permissions; the workflow creates emergent capability across the chain.
Practical implication: model the chain, not the individual agent, when defining authorization and audit boundaries.
Why transitive trust turns context into exposure
Transitive trust means one agent assumes that another agent’s output is both accurate and safe to reuse. In practice, that creates a hidden data propagation layer where sensitive context can travel far beyond the original business need. If an HR agent summarizes private employee data and a finance agent later consumes that summary, the finance workflow now contains HR information without ever requesting it directly. The problem is not only leakage. It is also authority reuse, because downstream agents often treat inherited context as validated input and act on it with broader privileges.
Practical implication: classify agent-to-agent data exchange as a governed trust boundary, not as an internal implementation detail.
How confused deputy behaviour scales across agent chains
A confused deputy appears when a less-privileged agent persuades a more-privileged agent to carry out an action on its behalf. In multi-agent workflows, this can happen through prompt injection, logic manipulation, or simply by exploiting the trust relationship between steps in the chain. The higher-privileged agent then acts as the execution surface for the attacker’s intent. When chains get longer, the origin of the request becomes harder to reconstruct, and the policy that should have blocked the action is often applied too late or too locally. That is why identity propagation and policy enforcement must follow the workflow, not the individual node.
Practical implication: enforce policy at the point where agent identity and delegated authority intersect, not only at tool ingress.
Threat narrative
Attacker objective: The attacker wants to convert a single compromised interaction into systemic workflow abuse, data exposure, or unauthorised business actions across the agent chain.
- Entry begins when a malicious prompt, poisoned dataset, or compromised intermediate agent enters the workflow through a valid agent interaction channel.
- Escalation occurs when one agent passes untrusted context or privileged instructions to another agent with broader tool access or write capability.
- Impact follows when the chain executes unsafe actions at scale, such as leaking sensitive data, approving fraudulent transactions, or triggering runaway compute and cost growth.
Breaches seen in the wild
- Meta AI Instagram Account Takeover — 20,225 Instagram accounts hijacked via compromised Meta AI support chatbot with overprivileged access.
- Replit AI Tool Database Deletion — Replit vibe coding AI assistant deletes live production database and creates 4,000 fake user records.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Agentic governance fails when enterprises treat each agent as an isolated identity. The real control problem is the chain, not the component. Privilege aggregation, transitive trust, and confused deputy behaviour emerge only when agents exchange context and authority across steps, which is why static per-agent policies miss the actual risk surface. The practitioner takeaway is that governance must be designed around workflow-level identity behaviour, not single-agent permissions.
Runtime visibility is the named concept that separates agent oversight from agent governance. Discovery of agents, MCP servers, APIs, and sensitive data flows is necessary, but not sufficient unless it is tied to execution-time identity mapping and policy enforcement. Without that runtime view, shadow agents and untracked integrations remain invisible until a breach, cost spike, or compliance failure forces discovery. Practitioners should treat visibility as the prerequisite for every other control, not as an optional monitoring layer.
Identity and access assumptions built for human-paced review collapse under autonomous agent timing. The assumption that access persists long enough to be certified was designed for human or service-account governance cycles. That assumption fails when agents make tool choices and execute within a single workflow pass, because the state can change faster than any review cadence. The implication is that governance programmes must stop relying on post hoc review as the primary control for agent behaviour.
Policy fragmentation is the hidden failure mode in multi-agent systems. Enterprises often configure safe local rules for each agent and assume the composition will remain safe. In reality, a collection of individually acceptable actions can still violate enterprise policy when chained together, especially where sensitive data crosses business domains. The practitioner conclusion is that global policy semantics must override local agent convenience, or the chain will define the control boundary for you.
Accountability in agentic systems depends on tracing authorisation across delegation hops. When tokens swap mid-session and actions are delegated across agents, the question is no longer who clicked a button but which identity authorised the action and which identity executed it. That distinction matters for audit, incident response, and compliance evidence. Security teams should require identity lineage across the workflow if they expect to defend the result of an agentic action.
From our research:
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems (39%), inappropriately sharing sensitive data (31%), and revealing access credentials (23%), according to AI Agents: The New Attack Surface report.
- 39% of organisations say their AI agents have accessed unauthorised systems, which means the boundary problem is already operational rather than theoretical.
- OWASP Agentic AI Top 10 is the next step for teams that need a control framework for prompt injection, tool misuse, and agent identity abuse.
What this signals
Runtime visibility: the practical shift is from reviewing agent outputs to controlling agent behaviour at execution time. With 80% of organisations already reporting out-of-scope actions, teams cannot rely on periodic review cycles or static allowlists alone. The operating model now needs continuous identity tracking, policy enforcement, and workflow-level telemetry that can be aligned with NIST AI Risk Management Framework.
Agentic AI also changes how security leaders should think about trust boundaries. A workflow that looks safe at the single-agent level can still fail once outputs are reused downstream, so the control boundary moves from the agent to the chain. That makes governance closer to OWASP Top 10 for Agentic Applications 2026 than to traditional app configuration management.
The named concept here is runtime governance gap, which is the distance between what teams think their policies cover and what the agent chain actually does. Closing that gap requires evidence of who authorised, who executed, and what data moved between them. For identity teams, that means agent programmes must be treated as a first-class IAM and PAM workload, not as an adjacent automation project.
For practitioners
- Map agent identity lineage across every workflow Inventory agents, MCP servers, APIs, and memory stores together so you can see where identity, privilege, and data flow intersect across the chain.
- Enforce policy at the workflow level Replace per-agent rules with global controls that define what data may move between agent classes and which actions may not be chained together.
- Trace delegated authority in session logs Record which identity authorised an action, which identity executed it, and how tokens or privileges changed during the session.
- Block unsafe context reuse between domains Prevent HR, finance, customer, and operational agents from reusing one another’s outputs unless the business need and policy allow it explicitly.
Key takeaways
- AI agent risk is no longer about isolated misuse cases, but about workflow composition that turns safe local actions into unsafe global outcomes.
- The strongest evidence in the article is that out-of-scope agent behaviour is already common, which makes governance a production control, not a future requirement.
- Teams need runtime identity lineage, workflow-level policy, and continuous telemetry to keep multi-agent systems inside enforceable boundaries.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Agentic AI Top 10 address the attack and risk surface, while NIST AI RMF, NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Agentic AI Top 10 | NHI-03 | The article focuses on agent identity, tool misuse, and runtime guardrails. |
| NIST AI RMF | GOVERN | AI governance and accountability are the article's central themes. |
| NIST CSF 2.0 | PR.AC-4 | The post centres on access governance and least-privilege enforcement for agents. |
| NIST Zero Trust (SP 800-207) | Zero Trust principles support continuous verification of agent actions and context. | |
| NIST SP 800-53 Rev 5 | AC-6 | Least privilege is directly relevant to multi-agent privilege aggregation. |
Map workflow controls to agent identity, tool access, and policy enforcement across chained actions.
Key terms
- Multi-Agent Workflow: A multi-agent workflow is a system where several AI agents or models pass outputs to one another to complete a task. Each step can introduce new assumptions, errors, or policy drift, which makes accountability and failure analysis more difficult than in a single-model design.
- Transitive trust: The hidden risk created when one trusted app inherits confidence from another trusted relationship. In SaaS environments, approving a third-party tool means trusting its hosting, storage, developers, and connected services, which widens the attack surface beyond the original login event.
- Confused Deputy: A confused deputy is a privileged system that is tricked into performing an action on behalf of an untrusted requester. In agentic AI, the agent may misread malicious input as legitimate intent and then use its own authority to act, which turns a logic problem into a security incident.
- Runtime Visibility: The ability to observe what an AI client actually accessed, which tools it used, and how it behaved during a session. It is more useful than entitlement snapshots for agent governance because it captures executed reality, not just approved access.
What's in the full article
LEVO's full blog post covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how agent-to-agent trust breaks down across coordinator-worker and peer-to-peer workflows.
- Detailed descriptions of runtime visibility, identity mapping, and policy-as-code enforcement across agent chains.
- Operational guidance on risk scoring, audit trails, and monitoring packs for production AI agent environments.
- The article's examples of how multi-agent failures can lead to fraud, data leakage, and runaway cost growth.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an identity security programme, it is worth exploring.
Published by the NHIMG editorial team on September 3, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org