OWASP agentic applications top 10 puts identity risk in focus

At a glance

What this is: This is an analysis of the OWASP Top 10 for Agentic Applications 2026 and its central finding that identity, tools, and delegated trust are the core agentic AI risk surface.

Why it matters: It matters because IAM and NHI teams now need controls that account for autonomous software acting with inherited credentials, delegated sessions, and tool access.

By the numbers:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so.

👉 Read Astrix Security's analysis of the OWASP Agentic Applications Top 10

Context

The agentic AI problem is not simply that autonomous systems can make mistakes. The security issue is that agents are now being given tool access, data access, and delegated permissions that were designed for human-operated workflows, not software that can chain decisions and act continuously. That creates an NHI governance gap because the control plane for service accounts, tokens, and tool credentials was never built for autonomous execution.

OWASP’s framework gives practitioners a useful vocabulary for that gap by separating goal hijacking, tool misuse, identity and privilege abuse, supply chain risk, and memory corruption. Astrix Security uses the release as a lens for identity-centric risk, but the broader point is independent of any single vendor: once agents can act across corporate systems, the boundary between application security and identity governance starts to collapse.

For security teams, this is a familiar pattern in a new form. The starting position is not unusual in cloud and SaaS environments, where over-scoped credentials and weak delegation have already been common; what changes is the speed and scale at which those weaknesses can now be exercised by agents.

Key questions

Q: How should security teams govern AI agents that use multiple credentials?

A: Security teams should treat each agent as an aggregated identity and map every credential it can present, including API keys, OAuth tokens, service accounts, and delegated sessions. Then apply ownership, approval, logging, and revocation at the agent level, not just the underlying account level. That approach reduces hidden privilege stacking and makes incident response practical.

Q: When does agentic AI create more risk than it reduces?

A: Agentic AI becomes net risk when the system can act across tools faster than the organisation can verify identity, constrain privilege, and monitor output. If the agent can access sensitive systems without tight task scoping, the likelihood of unsafe delegation, privilege abuse, or tool misuse rises sharply.

Q: What is the difference between IAM controls for humans and for AI agents?

A: Human IAM assumes a person makes decisions within a session and can be challenged, trained, or stopped in real time. Agent IAM must assume autonomous execution, inherited credentials, and machine-speed chaining of actions. That means stronger credential scoping, more explicit trust boundaries, and faster revocation are required.

Q: Should organisations prioritise secrets rotation or agent governance first?

A: Organisations should do both, but agent governance comes first when autonomous systems already hold live access. Rotating secrets helps only if you also know which agents possess them, what those agents can reach, and how to shut them down quickly when behaviour changes.

Technical breakdown

Identity and privilege abuse in agentic systems

Agentic systems do not create entirely new identity primitives so much as they concentrate existing ones. An agent may present a persona, but the real risk sits in the credentials behind that persona: API keys, OAuth tokens, delegated sessions, service accounts, and cached authorisations. When those artifacts are combined with tool access, the agent becomes an execution point for multiple NHI entitlements at once. That is why privilege boundaries matter more than model capability. If a prompt, tool output, or external input can shift the agent’s behaviour, the attacker may inherit whatever authority the agent already holds.

Practical implication: Treat every agent as a privileged NHI and map the full credential chain behind its execution authority.

Tool misuse and model context poisoning

Tool misuse occurs when an agent uses a legitimate connector, API, or workflow in an unsafe way. The control failure is often not the tool itself, but the absence of guardrails around what the agent may ask it to do, when it may do it, and under what conditions it may act. Memory and context poisoning makes this worse by persistently shaping future decisions through tainted retrieval content, poisoned prompts, or corrupted state. In practice, the agent’s next action can be influenced long after the original input has disappeared.

Practical implication: Constrain tool scopes, validate tool outputs, and separate persistent memory from untrusted operational context.

MCP and agentic supply chain exposure

Model Context Protocol makes it easier to connect agents to tools and data sources, but connectivity is not the same as trust. Every new tool definition, server, or integration extends the supply chain and introduces an identity question: who is operating the endpoint, and what credentials will the agent hand over? In agentic environments, supply chain compromise is not only about code tampering. It also includes malicious tool descriptors, impersonated endpoints, and trust decisions made too early in the session lifecycle.

Practical implication: Verify tool identity before enabling data exchange and apply zero standing privilege to every external connector.

Threat narrative

Attacker objective: The attacker wants to turn a trusted agent into a privileged execution path for data theft, unauthorized action, or downstream system compromise.

1. Entry begins when a malicious prompt, unsafe tool output, or impersonated MCP endpoint influences the agent’s next action.
2. Escalation occurs when the agent reuses inherited tokens, delegated sessions, or cached credentials to reach systems beyond its intended scope.
3. Impact follows when the compromised agent misuses legitimate tools to exfiltrate data, alter records, or trigger unauthorized operations.

Breaches seen in the wild

• Moltbook AI agent keys breach — Moltbook breach exposed 1.5M AI agent keys.
• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Identity is now the control plane for agentic AI, not a supporting control. Once autonomous software can inherit credentials, call tools, and act across systems, identity stops being a back-office concern and becomes the primary security boundary. The OWASP framework is useful because it makes that shift explicit. Practitioners should stop asking whether an agent is “trusted” and start asking what it can do, with whose credentials, and under which revocation model.

Ephemeral access does not eliminate ephemeral credential trust debt. Short-lived sessions reduce exposure time, but they do not solve the deeper problem that an agent can still accumulate privilege across tools, contexts, and workflows. The named concept matters because the issue is not just standing access. It is the unreviewed trust chain that forms when every delegation hop is assumed to be safe. Security teams need to govern those hops explicitly.

Tool governance and identity governance are converging. In agentic systems, a tool is effectively a remote action surface, so its trustworthiness now belongs in the same policy conversation as service accounts and API keys. That convergence will push security teams toward stronger attestation, tighter connector approval, and more granular revocation. The practical conclusion is simple: if you cannot govern the tool, you cannot safely govern the agent.

OWASP’s taxonomy will accelerate control selection, but it will also expose program gaps. Many organisations already have some combination of secrets management, PAM, and application controls, yet those controls are usually deployed in separate silos. Agentic AI forces those silos to coordinate around a single runtime identity problem. Teams that cannot connect identity, data, and tool governance will struggle to operationalize the framework.

The market is moving from detection language to governance language. That matters because agentic AI risk is no longer framed only as prompt abuse or adversarial ML. It is increasingly framed as entitlements, trust boundaries, and delegated authority. For practitioners, the implication is that agent security reviews should be built into IAM design, not added after deployment.

From our research:

• 92% agree governing AI agents is critical to enterprise security, yet only 44% have implemented any policies to do so, according to AI Agents: The New Attack Surface report.
• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
• For a broader control framework, see OWASP Agentic AI Top 10 for how these risks map to agentic application governance.

What this signals

Identity blast radius: as agentic systems spread, the practical question is no longer whether a bot can act, but how far its credentials can reach before a human notices. That makes access review, connector approval, and revocation speed central programme metrics, especially when AI systems are already operating with delegated authority across cloud and SaaS.

The next phase of agent governance will look less like model safety and more like entitlement control. Security teams should expect more scrutiny of service accounts, OAuth grants, and privileged connectors because those controls determine whether an agent can be contained or can move laterally through business systems.

For readers building control roadmaps, the best indicator of maturity is whether identity, data, and tool governance are reviewed together. If those functions remain split, the organisation will keep finding the same blind spots under a new label.

For practitioners

• Inventory every agent as a non-human identity Record the persona, service account, OAuth grants, API keys, and delegated sessions behind each agent before it reaches production. Use that inventory to define revocation paths and ownership.
• Scope tool permissions to the minimum task window Assign only the tool actions an agent needs for a specific workflow, then remove access when the task ends. This reduces the blast radius if a prompt or endpoint is compromised.
• Gate MCP and external connectors by trust review Approve every tool server, descriptor, and integration through the same review path you would use for a privileged service account. Require explicit ownership, logging, and rollback before enabling data exchange.
• Separate memory, context, and operational state Keep persistent memory, retrieval content, and live task context distinct so poisoned inputs do not survive across sessions or silently influence future actions.

Key takeaways

• Agentic AI turns identity into the main control surface because autonomous software can accumulate and reuse privileges across tools.
• The data suggests governance is lagging adoption, with most organisations already seeing problematic agent behaviour and far fewer enforcing policy.
• Practitioners should focus on trust boundaries, revocation speed, and tool scoping before they scale autonomous agents further.

Key terms

• Agent Identity: The identity an autonomous software agent uses to act across tools, services, and data sources. It includes the agent’s persona and the authentication material behind it, such as keys, OAuth tokens, delegated sessions, and service accounts. In practice, it is the security boundary that determines what the agent can reach and do.
• Identity Blast Radius: The maximum scope of damage that can occur when an identity is misused, overprivileged, or compromised. For agents, blast radius expands when one autonomous workflow inherits several credentials or spans multiple systems. Security teams reduce it by shrinking permissions, narrowing trust boundaries, and enforcing fast revocation.
• Tool Misuse: A failure mode where an agent uses a legitimate connector, API, or workflow in an unsafe way. The tool may be functioning correctly, but the policy around when and how the agent may invoke it is too weak. This is a central NHI concern because tool access often carries real operational authority.
• Memory Poisoning: The corruption of an agent’s persistent memory, retrieval store, or contextual knowledge so future decisions are influenced by tainted data. It is dangerous because the harmful input can survive beyond the original session and shape later actions. For security teams, it means context integrity must be governed like other sensitive runtime assets.

What's in the full article

Astrix Security's full blog covers the operational detail this post intentionally leaves for the source:

• The full OWASP risk list with Astrix’s commentary on why each agentic category matters in real environments
• Identity-centric examples of tool misuse, privilege abuse, and MCP-related trust failures
• The vendor’s mapping of agentic risks to NHI-centric controls and deployment assumptions
• FAQ content on how Astrix says enterprises should think about securing agents and their connected identities

👉 Astrix Security's full post covers the risk taxonomy, identity focus, and FAQ detail behind the framework

Deepen your knowledge

Agentic AI identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls for autonomous agents, it is a practical place to start.