OWASP agentic AI top 10 shows why identity controls are failing

At a glance

What this is: OWASP's first Top 10 for Agentic Applications maps ten agentic AI failure modes, with identity and privilege abuse, tool misuse, and cascading failures standing out as core governance risks.

Why it matters: Identity and IAM teams need to govern agents as active runtime actors, because delegated access, inherited privilege, and trust in machine decisions create failure modes that prompt security never covered.

Context

Agentic AI changes the security problem from protecting model output to governing software that can plan, act, and use tools on its own. That creates a new trust boundary around identity, privilege, memory, and inter-agent communication, especially where agents inherit human permissions or operate through service credentials.

The article's central point is that the old assumption of a passive system no longer holds. Once an AI system can choose actions and execute them, identity governance has to cover the agent's runtime authority, not just the model behind it.

Key questions

Q: What breaks when an agent identity role can affect non-agent service principals?

A: The boundary between agent governance and application governance breaks, and ownership becomes a takeover primitive. When a role intended for one object class can modify another, the organisation loses assurance that scope statements match real enforcement. That turns a delegated admin role into a privilege escalation path rather than a constrained control plane.

Q: Why do agentic AI systems increase initial access and privilege abuse risk?

A: Because they can chain valid access into multiple tool calls without needing a human to approve each step. If a secret is exposed or a role is overbroad, the agent can turn that access into data movement, service interaction or recursive task execution. The risk rises when access outlives the task that created it.

Q: What are the signs that an agentic development workflow is failing?

A: Common signs include slow sessions, rising context usage, unclear tool-call sequences, repeated regressions, and changes that improve one example but fail on the next representative dataset. Those signals mean the team has implementation speed without enough behavioural evidence to trust release decisions.

Q: How should teams respond when a high-impact agent action depends on another agent's output?

A: Require a verification step before the downstream action executes, especially when the action can change data, trigger payments, or access privileged systems. Chained agent decisions should not inherit trust automatically. Each handoff needs policy enforcement, logging, and a clear rollback path if the upstream output was wrong or manipulated.

Technical breakdown

Why agent identity now matters more than prompt security

Agentic systems do not just generate responses. They convert model reasoning into actions through APIs, databases, tools, and delegated permissions. That means the security boundary shifts from content moderation to runtime authorisation, where an agent's identity, scope, and context determine what it can do. If an agent inherits human privileges, accepts spoofed instructions, or keeps state across tasks, the risk is no longer only model manipulation. It is unauthorised execution through a trusted identity path.

Practical implication: Treat agent identities as governed principals with explicit scopes, not as passive extensions of an LLM.

How tool misuse becomes real-world damage

Tool misuse happens when an agent is allowed to call functions that were technically available but not operationally safe. The article shows how APIs, file systems, and database access can be turned into destructive outputs if an attacker shapes the instruction stream. In practice, the failure is not that the tool exists. The failure is that the agent can cross from interpretation to action without sufficient constraints, policy checks, or output validation. This is the same control problem seen in privileged automation, but with dynamic decision-making layered on top.

Practical implication: Constrain tool execution with approval boundaries, scoped credentials, and action-level logging.

Why cascading failures are a governance problem, not just a bug

Cascading failures occur when one agent's false belief or bad action propagates through dependent agents and automations. In multi-agent designs, trust is often implicit, so one poisoned task can alter downstream decisions, overwrite context, or trigger chains of incorrect execution. The technical issue is compounded by memory and inter-agent messaging, because bad state persists longer than a single prompt. This is why agentic systems need integrity controls around messages, context, and handoffs, not only content filters at the edge.

Practical implication: Add verification points at every agent handoff and do not assume downstream agents can safely inherit upstream context.

Threat narrative

Attacker objective: The attacker aims to turn a trusted agentic workflow into an execution path for unauthorised data access, destructive actions, or systemic control failure.

1. Entry occurs when hidden instructions, spoofed identities, or poisoned dependencies reach an agent through content, tools, or external packages.
2. Credential and privilege abuse follows when the agent acts with inherited permissions or accepts a false trusted source as authoritative.
3. Escalation happens as tool misuse, memory poisoning, or inter-agent message tampering spreads the compromised state across the workflow.
4. Impact appears when the agent exfiltrates data, executes harmful actions, or triggers cascading failure across connected systems.

NHI Mgmt Group analysis

Agentic AI identity is now a control plane, not a side effect: once agents can plan and act, identity governance must cover runtime authority, delegated access, and tool scope. The article's examples show that the real risk is not just what the model says, but what the system is allowed to do. Practitioners should treat agent identity as a first-class governance object.

Identity and privilege abuse is the named concept this category has been missing: ASI03 makes clear that spoofed authority and inherited permissions are the pivot point for many agent failures. That is an identity problem, not a model-quality problem. Organisations should reframe agent access decisions around authentication, authorisation, and trust boundaries rather than prompt safety alone.

OWASP's list validates the shift from prompt security to runtime control: goal hijacking, tool misuse, and cascading failures are linked failure modes, not isolated defects. That means one control cannot solve the category, because compromise can start in content, move through privilege, and end in workflow corruption. Teams need layered governance across identity, tools, memory, and inter-agent trust.

Agentic supply chain risk widens the governance perimeter: poisoned MCP servers, malicious plugins, and compromised dependencies show that agent security extends beyond the model provider. The security team must govern the sources an agent trusts, the code it loads, and the data paths it inherits. In practice, that pushes agent security into supplier review and runtime attestation.

Confidence is now an attack surface: ASI09 shows that humans may approve harmful actions because the agent presents them with false certainty. That creates a trust exploitation problem that looks like workflow efficiency until it becomes loss. Practitioners should design review points that challenge agent output before approval, especially where the action has real-world consequences.

From our research library:

• Gartner predicts that by the end of 2026, 40% of enterprise apps will feature task-specific AI agents.
• Read next: Agentic AI Identity Maturity Model

What this signals

Agentic AI governance will shift from model oversight to identity control: teams that keep treating agents as chat interfaces will miss the real risk, which is delegated action under mutable context. The practical response is to govern issuance, scope, and approval of agent authority the way IAM teams govern any other high-trust principal.

Only 13% of organisations feel extremely prepared for the reality of agentic AI despite the majority racing toward autonomous adoption, according to the 2026 Infrastructure Identity Survey. That gap suggests many programmes are adopting agent behaviour faster than they can define identity boundaries, which will surface first in access control, workflow review, and supplier governance.

For practitioners

• Define agent identities explicitly Assign each agent a unique identity, scope, and ownership model so runtime actions can be traced back to a controlled principal rather than a generic application account.
• Restrict tool permissions by task Limit APIs, file access, and database actions to the smallest task-scoped permission set needed for the agent's current job.
• Validate every inter-agent handoff Insert policy checks and message integrity controls between agents so one compromised step cannot silently rewrite the next agent's decisions.
• Separate memory from authority Do not let long-lived memory or prior context expand what the agent is authorised to do in the current session.
• Review human approval points Add explicit challenge steps for high-impact agent actions so confident output does not become automatic approval.

Key takeaways

• Agentic AI failures are no longer confined to bad text, because the risk now sits in the authority to act, not only the quality of the output.
• The OWASP list shows that identity, tools, memory, and inter-agent trust are linked attack surfaces that can compound into wider workflow compromise.
• Security teams need runtime controls for agent identity, scoped access, and handoff validation before autonomous behaviour becomes normalised.

Key terms

• Agentic AI: Autonomous AI systems capable of planning, deciding, and taking actions, including calling APIs, writing code, and orchestrating other agents, with minimal human oversight. Agentic AI introduces new NHI risks as agents must authenticate to external services.
• Identity And Privilege Abuse: Identity and privilege abuse happens when delegated authority, cached credentials, or inherited access lets an agent act beyond the intent of the original owner. In agentic systems, the problem is often ambiguity in who owns the action and whether the granted authority still matches the task.
• Inter-Agent Context: Inter-agent context is the data, prompts, memory, or task state passed from one AI agent to another. It can improve delegation, but it also creates exposure if too much sensitive information is forwarded across different permissions, clouds, applications, or trust boundaries. Minimizing context reduces unnecessary spread.
• Tool Misuse: Tool misuse occurs when an agent uses an allowed integration in a way that exceeds its intended task, scope, or risk tolerance. The problem is often not access alone but the combination of valid credentials, broad permissions, and unbounded action sequencing.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and agentic AI identity. It is designed for practitioners who need to govern delegated access as a first-class security problem.