OWASP agentic applications top 10 puts identity risk in focus

At a glance

What this is: This is a breakdown of the OWASP Top 10 for Agentic Applications 2026, which centres identity, tools, and delegated trust as the main risks in AI agent adoption.

Why it matters: It matters because IAM, PAM, and NHI programmes now have to govern agent behaviour where credentials, permissions, and tool access can be combined dynamically at runtime.

Context

The core governance gap is simple: many identity and access models assume the subject being controlled is a human user or a static non-human workload, while agentic systems can decide how to sequence actions, which tools to use, and when to act. That makes the control problem different from traditional automation, especially when an agent can inherit credentials and then move across multiple systems in a single task.

OWASP’s new framework gives the industry a shared language for risks that were previously described inconsistently, including goal hijack, tool misuse, privilege abuse, supply chain compromise, context poisoning, and rogue behaviour. For IAM and NHI teams, the significance is not the label on the framework but the fact that identity boundaries are now the primary place where agentic security must be enforced.

Astrix Security uses the release to argue that agentic adoption is already outpacing security governance. Whether or not teams adopt the same taxonomy, the underlying point stands: once agents can act with delegated authority across enterprise tools, the identity model itself becomes part of the attack surface.

Key questions

Q: What breaks when AI agents are given broad inherited permissions?

A: Broad inherited permissions break the assumption that access is tied to a narrow business need. The result is larger blast radius, weaker accountability, and faster propagation of mistakes or abuse across connected systems. A single compromised or misconfigured agent can then touch far more data and workflows than the original task required.

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

A: AI agents create more risk because they can interpret context, choose actions, and invoke tools autonomously. Traditional automation follows fixed rules, but an agent can be manipulated into using its own authority in unintended ways. That makes permission scope, tool boundaries, and monitoring more important than model accuracy alone.

Q: What are the signs that agentic access controls are failing?

A: The main signs are invisible tool use, delayed discovery of actions, and audit logs that explain an outcome only after it has already occurred. If a security team cannot see which agent attempted which action on which target at the moment of execution, the control is monitoring, not governing.

Q: How should teams govern agentic identity across OWASP and NHI controls?

A: Treat the agent as a first-class identity subject and apply lifecycle, privilege, and trust controls to the credentials it inherits. Then separate tool provenance, delegated access, and runtime monitoring so one control failure does not cascade across the agent stack. That approach aligns governance with how agents actually operate.

Technical breakdown

Why agentic identity is different from workload identity

Agentic identity is not just a service account with a new label. A workload identity typically runs a bounded task under a known execution pattern, while an agent can choose between tools, alter its action sequence, and operate with a mix of persona, credentials, and delegated sessions. That creates a compound identity surface: the agent’s logical identity, the secrets it can reach, and the trust relationships inherited from upstream systems. In practical terms, the security question is no longer only whether the credential is valid, but whether the credential should still be usable in that runtime context.

Practical implication: Model agent identity as a governed execution principal, not as an ordinary service credential.

How tool misuse turns legitimate access into a security problem

Tool misuse happens when an agent is authorised to call a valid tool but uses it in a harmful or unintended way. The issue is not necessarily a broken API or a missing permission check in the tool itself. The issue is that the agent’s reasoning layer can be manipulated by prompt injection, bad context, or misleading instructions into choosing a destructive action that still fits within its technical privileges. This is why the article links identity, tools, and trust boundaries so tightly: if the agent is the decision-maker, then authorization must account for how decisions are made, not just what is technically allowed.

Practical implication: Constrain agent tools by task, context, and execution policy, not only by raw API permission.

Why delegated privilege becomes an identity concentration point

The framework’s identity and privilege abuse category reflects a structural change: the agent becomes a concentration point for keys, OAuth tokens, delegated sessions, and service credentials. That means one runtime subject can aggregate multiple non-human identities and then exercise them together, which is very different from a human user with a single interactive session. In identity terms, the problem is privilege inheritance without clear separation of duties. Once that happens, a compromise in one agent can expose the authority of several underlying systems at once.

Practical implication: Inventory which credentials an agent can inherit and treat privilege aggregation as a control failure, not a convenience feature.

Threat narrative

Attacker objective: The attacker wants to turn a trusted agent into a high-authority execution point that can misuse enterprise tools and expose the credentials and data behind them.

1. Entry begins when an attacker manipulates agent instructions, external content, or a tool interaction so the agent accepts an unintended objective or unsafe context.
2. Privilege expansion follows when the agent uses inherited credentials, delegated sessions, or over-scoped tool access to reach enterprise systems beyond the original intent.
3. Impact occurs when the agent misuses legitimate tools, propagates bad context, or triggers destructive actions across connected data and operational services.

Breaches seen in the wild

• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
• Amazon Q Developer extension compromise 2025: An over-scoped CI token let an attacker ship a prompt telling Amazon Q's AI coding agent to wipe files and AWS resources (CVE-2025-8217).

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 security is now an identity governance problem, not a prompt-engineering problem. The OWASP Top 10 makes it harder to treat AI agents as just another application layer because the risks cluster around identity, privilege, tool access, and trust delegation. That means the programme question shifts from how to make agents smarter to how to bind their authority, scope, and lifecycle. Practitioners should read this as a signal that governance now starts at the identity layer.

Identity & privilege abuse is the category that best explains why existing NHI controls only partially apply. The same core governance questions from NHI still matter, but agents can combine credentials, sessions, and tools in ways static workloads do not. Delegated authority concentration: this is the specific failure mode where a single agent becomes a merge point for multiple entitlements. The implication is that least privilege must be reasoned about at runtime context, not only at provisioning time.

The OWASP Top 10 validates that identity boundaries are the enforcement point for agentic adoption. When agents can reach databases, SaaS tools, and cloud services, the issue is not whether access exists but whether the access path is governable under real operating conditions. That makes identity inventory, delegated trust review, and tool attestation part of the core control set. The practical conclusion is that teams cannot govern agentic systems without treating them as first-class identity subjects.

Agentic supply chain risk expands the trust problem beyond code and into runtime authority. A third-party tool, MCP server, or external agent can change what the local agent believes it is authorised to do. This is where supply chain and identity governance meet: the question becomes who, or what, is allowed to influence an execution path. Practitioners should treat provenance, trust, and privilege as one combined control surface.

Access review assumptions break down when the actor can recompose authority dynamically. Access review processes were designed for permissions that persist long enough to be observed, certified, and revoked on a schedule. That assumption weakens when an agent can inherit, exercise, and discard access within a single session. The implication is that governance has to move closer to issuance and execution, because periodic certification alone cannot describe what happened.

What this signals

Delegated authority concentration: agentic systems force IAM teams to govern not just access, but the way multiple credentials can be merged into one execution path. That changes the control objective from certification of entitlements to containment of runtime authority.

The most important programme question is whether current NHI and PAM controls still make sense when the actor can choose tools and actions at runtime. If the answer depends on a human-paced review cycle, the control model is already behind the risk.

Identity teams should expect agentic governance to converge with workload identity, secrets management, and access boundary design. The practical outcome is a tighter link between who can influence execution and what that execution is allowed to touch.

For practitioners

• Inventory agentic trust chains Map every identity, token, OAuth grant, service account, and MCP connection an agent can inherit or call. Record which systems receive delegated authority through each path.
• Separate tools by task scope Assign only the minimum tool set needed for each agent workflow and block broad reusable access where a narrower execution boundary will do. Remove the assumption that one agent persona should operate across all tools.
• Attest third-party tool provenance Require explicit verification of external tools, descriptors, and agent integrations before allowing them to influence production actions or data flows.
• Treat agent privileges as runtime state Review whether access can be issued, used, and discarded within the same task. If so, shift governance from periodic review to issuance controls, execution logging, and revocation triggers.
• Segment agent-to-agent communication Apply separate trust boundaries to messages between agents so one compromised agent cannot automatically extend its authority into another workflow or sub-agent chain.

Key takeaways

• AI agents change the identity problem by combining tool choice, delegated authority, and runtime execution in one subject.
• The OWASP Top 10 for Agentic Applications formalizes risks that are already appearing in production environments, including privilege abuse and unsafe tool use.
• IAM and NHI teams need governance that starts at issuance and follows the agent through execution, not just periodic access review.

Key terms

• Agentic Identity: An agentic identity is a non-human identity used by an autonomous system that can act, call tools, and access data with execution authority. It needs the same governance discipline as other privileged identities, plus runtime context, ownership mapping, and revocation paths.
• Delegated Privilege: Delegated privilege is access granted to a tool or system so it can perform actions without direct human intervention. The risk rises when delegation is broad, hidden, or hard to revoke, because the delegated actor can continue operating after trust has changed.
• 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.
• Identity Boundary: The point in an application where authentication and authorisation decisions are enforced. In Node.js systems, this often sits in APIs, middleware, and session handling code, making it the place where governance, runtime behaviour, and security evidence intersect.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.