OWASP Top 10 for agentic applications 2026: identity risks

At a glance

What this is: OWASP’s 2026 agentic Top 10 defines ten risk categories for AI systems that can plan, use tools, and act with production permissions.

Why it matters: IAM, NHI, and PAM teams need this framing because agent identity, delegation, and privilege now behave like a live access control problem, not just an application security concern.

👉 Read Teleport's summary of the OWASP Top 10 for agentic applications

Context

Agentic AI creates a governance gap because existing identity models were built around predictable request and approval flows. When an AI agent can choose actions, invoke tools, and carry forward context across sessions, the security question shifts from application hardening to identity, privilege, and accountability.

The primary issue is not that agents are sophisticated. It is that they behave like runtime identities with permissions, delegated authority, and access paths that can cross application, data, and infrastructure boundaries. That puts agent governance in the same control family as NHI management and privileged access, while adding decision volatility that classic IAM does not assume.

Key questions

Q: How should security teams govern AI agents that can use tools and make decisions?

A: Treat each agent as a scoped identity with explicit tool permissions, short-lived credentials, and strong auditability. Separate planning from execution, require approvals for high-impact actions, and isolate sessions so context does not bleed across tasks. The goal is to bound runtime authority, not just authenticate access.

Q: Why do AI agents create more access risk than ordinary automation?

A: Ordinary automation follows predetermined paths, but agents can alter task selection, tool usage, and timing while holding live permissions. That creates room for goal hijack, misuse of legitimate tools, and delegated authority abuse. The risk comes from runtime discretion inside a trust boundary that was not designed for it.

Q: What do security teams get wrong about least privilege for agentic systems?

A: They often scope access as if the agent’s purpose is fixed at provisioning time. In practice, agent intent can shift during execution, especially when tools, memory, or external content influence behaviour. Least privilege has to be task-bounded, not role-bounded, and must be reassessed when the agent’s context changes.

Q: How can organisations reduce the blast radius of compromised agent memory or messages?

A: Use segmented memory, signed inter-agent messages, replay protection, and containment boundaries between workflows. When one memory store or communication channel is compromised, the aim is to stop that corruption from propagating into other agents or tasks. Blast-radius control matters as much as detection.

Technical breakdown

Agent goal hijack and tool misuse in production workflows

Agent goal hijack occurs when an attacker alters what the agent is trying to achieve, usually by influencing instructions hidden in documents, emails, retrieved content, or API responses. Tool misuse happens when an agent uses a legitimate capability in an unsafe way, such as chaining tools into an action the defender did not intend. These are not the same as traditional application exploits. The failure mode is runtime intent manipulation combined with overbroad tool scope, where the agent still appears to be operating normally while pursuing the wrong objective.

Practical implication: separate high-impact actions from ambient agent execution and limit each tool to the smallest possible permission set.

Identity and privilege abuse across delegated agent sessions

Identity and privilege abuse in agentic systems comes from delegated credentials, shared context, cached sessions, and unclear ownership of an action chain. An agent may inherit authority from a human, another service, or a previous task, but that inheritance can become ambiguous once context is reused across sessions. This is fundamentally an identity problem, not just a logging problem. The challenge is that the runtime identity is often shaped by what the agent was given earlier, not by what it should be allowed to do now.

Practical implication: give agents unique short-lived identities and isolate sessions so privilege does not persist across unrelated tasks.

Memory poisoning, inter-agent trust, and cascading failures

Memory and context poisoning corrupt the inputs that guide later reasoning, while insecure inter-agent communication lets one compromised agent influence another through weak authentication or replayable messages. Once those failures exist in a multi-agent chain, a small compromise can cascade through planning, delegation, and execution. The architecture problem is compound trust. Each agent may appear bounded on its own, but the combined system can amplify a single bad instruction, corrupted memory entry, or spoofed message into wider operational impact.

Practical implication: protect agent memory, sign inter-agent messages, and add blast-radius controls before deploying multi-agent workflows.

Threat narrative

Attacker objective: The attacker aims to redirect agent behaviour so trusted credentials, tools, and delegated actions produce unintended access, data movement, or destructive execution.

1. Entry begins when an attacker places malicious instructions into content, prompts, retrieved data, or a trusted-looking agent interaction that the system treats as valid runtime input.
2. Credential access or abuse follows when the agent reuses delegated authority, cached context, or overbroad tool permissions to execute actions outside the defender’s intent.
3. Escalation and impact occur when the agent propagates the bad instruction through memory, delegation, or inter-agent communication, causing chained actions across systems.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• AI LLM hijack breach — attackers used stolen AWS access keys to hijack Anthropic LLM models on Bedrock.

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 AI turns identity into a decisioning layer, not just an authentication layer. Once an agent can choose tools, sequence actions, and act on live permissions, the old boundary between identity governance and application behaviour disappears. That means the relevant control question is no longer only who authenticated, but what runtime authority was exercised and how far it could propagate. Practitioners should treat agent identity as an operational control plane, not a static account record.

Least privilege for agents is harder than least privilege for people because intent is not stable at provisioning time. Human access can often be scoped against a known role, but agent behaviour is task-shaped and changes during execution. The result is a moving target for privilege design, especially where agents delegate, remember, and self-direct across multiple tools. Practitioners should stop assuming that predeclared roles are enough to describe autonomous runtime authority.

Identity and privilege abuse is the clearest named failure mode in agentic systems. The same delegated access patterns that create convenience also create ambiguity, because cached credentials, reused context, and inherited authority blur accountability. OWASP’s framing is useful because it shows that the breach condition is not simply overpermission, but identity that outlives its intended task boundary. Practitioners should map every agent session to a bounded ownership model.

Memory poisoning and inter-agent communication failures create a compound trust problem. A single compromised memory store or spoofed agent channel can pollute multiple downstream decisions, which is why agentic systems need trust segmentation, not just better prompts. This is where traditional IAM thinking underestimates the problem, because the blast radius is created by propagation as much as by privilege. Practitioners should design for containment between agents, not just control of individual agents.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, which shows the behaviour gap that agentic systems can inherit and amplify.
• If your programme already struggles with secret governance, the 52 NHI Breaches Analysis is the right next step for understanding how identity failures compound in practice.

What this signals

Agentic governance should be treated as an extension of NHI control design, not a separate security silo. As agents become persistent runtime identities, programmes will need tighter linkage between PAM, NHI lifecycle control, and application policy enforcement. The practical shift is toward bounded authority, tamper-evident logging, and session-level containment across both AI and non-AI machine identities.

The OWASP Non-Human Identity Top 10 remains relevant because the same problems that affect service accounts now reappear in agents with more decision power. The difference is that the agent can also change how those permissions are used mid-session, which makes inventory alone insufficient.

Identity blast radius: when agentic systems propagate context, messages, and delegated authority across workflows, the security programme has to control how far a single compromise can travel. That means designing for containment between agents, not just authentication at the edge, and pairing policy gates with rollback-ready audit trails.

For practitioners

• Define unique identities for each agent session Assign short-lived credentials to each agent session and prevent reuse across unrelated tasks. This makes it easier to isolate delegated authority and identify which execution path produced a specific action.
• Separate planning from execution Keep task planning, tool selection, and destructive execution under different policy checks so a single poisoned instruction cannot flow directly into high-impact action. Use approval gates for scope changes.
• Constrain tool scope and data reach Limit every API, shell, database, and retrieval tool to the minimum data scope required for the task. Add allowlists, rate limits, and semantic validation before execution.
• Protect memory and inter-agent channels Segment persistent memory by task and trust level, sign messages between agents, and block replayable or unauthenticated communications. Treat memory stores and routing paths as security boundaries.

Key takeaways

• Agentic AI changes the identity problem from access granting to runtime authority control, which makes old IAM assumptions incomplete.
• The OWASP 2026 model highlights ten distinct failure modes, but identity and privilege abuse, memory poisoning, and rogue agent behaviour are the most governance-relevant for practitioners.
• Teams should respond by bounding agent sessions, segmenting memory and communications, and enforcing privilege containment before multi-agent systems scale further.

Key terms

• Agentic Application: An agentic application is software that can plan, select tools, and take actions with real permissions in a live environment. Unlike a simple chatbot or scripted workflow, it can change what it does at runtime, which makes identity, privilege, and accountability central governance concerns.
• 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.
• Memory Poisoning: Memory poisoning is the corruption of an agent’s stored context, conversation history, or retrieval data so future decisions are skewed or unsafe. The risk is not only bad output, but persistence, because poisoned memory can influence later sessions and spread through connected workflows.
• Blast Radius: Blast radius is the amount of damage or spread that a compromised identity, message, or tool invocation can cause before containment stops it. For agents, it depends on permissions, memory reuse, inter-agent trust, and whether execution boundaries are isolated enough to prevent propagation.

What's in the full article

Teleport's full post covers the operational detail this post intentionally leaves for the source:

• The category-by-category OWASP summary with the vendor's own mitigation examples for each risk
• Teleport's implementation-oriented guidance for identity-based guardrails, session isolation, and audit logging
• The article's embedded links to agentic AI security resources and related product guidance
• The full conclusion on how Teleport positions access guardrails for AI agents in production

👉 Teleport's full post breaks down each agentic risk category and the associated mitigation guidance.

Deepen your knowledge

OWASP Top 10 for Agentic Applications 2026 is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building governance for AI agents alongside service accounts and workload identities, it is worth exploring.