OWASP’s agentic top 10 reframes AI agents as active attack surfaces

At a glance

What this is: This is an analysis of the first OWASP Top 10 for Agentic Applications and the claim that agent security must be treated as a lifecycle problem, not a prompt-safety problem.

Why it matters: It matters because IAM, PAM, and security teams now need to govern agents as active principals that can invoke tools, inherit authority, and create blast radius at runtime.

Context

Agentic applications create a governance gap because they do not behave like passive LLMs. Once an agent can choose tools, act on data, write code, and trigger downstream systems, the control model shifts from output review to authority management.

That is the right place to start for identity teams because the primary risk is no longer only what the model says. It is what an agent can do with delegated access, inherited permissions, and persistent context.

The article argues that the OWASP GenAI Security Project’s new list is really a lifecycle map for agentic risk, from pre-execution trust to runtime misuse to post-incident containment.

Key questions

Q: What breaks when AI agents inherit loose human authority?

A: Loose human authority turns agent security into an amplification problem. When an agent inherits broad approvals, standing privilege or unclear delegated access, it can perform actions that no single human intended to authorise. The result is not just overreach, but loss of control over which identities can combine privileges at runtime.

Q: Why do agentic applications need more than prompt filtering?

A: Prompt filtering only addresses one attack path, but agentic risk also includes supply-chain tampering, over-privileged tools, memory poisoning, and rogue runtime behaviour. A filter cannot verify whether the agent’s model, MCP server, or attached identity is trustworthy, and it cannot contain a bad decision once the agent starts executing. That is why runtime authority and provenance both matter.

Q: How should teams handle approvals for high-risk agent actions?

A: Treat approval as part of the authorisation decision for one specific action, not as a reusable privilege. The approval should be time-bound, tied to the current user and resource, and automatically expire once the request completes to avoid residual access.

Q: What is the difference between platform control and runtime control for AI agents?

A: Platform control decides where the AI lifecycle runs and how infrastructure is operated. Runtime control decides what an agent may do after it starts, including which tools, data and destinations it can reach. Both are necessary, but they answer different governance questions and fail in different ways.

Technical breakdown

Why agentic applications create a new identity surface

An agentic application is not just a model that answers questions. It is a software actor that can choose tools, sequence actions, and persist state across sessions. That makes identity and authorization dynamic rather than static: the same agent may request different tools, different data, and different execution paths depending on context. The article’s central point is that traditional IAM can confirm that an identity is allowed to act, but it cannot reliably attest to how that actor will behave once it has runtime discretion. That is why agentic risk includes goal hijack, tool misuse, privilege abuse, and memory poisoning as separate failure modes. The governance task is to treat the agent as an active principal with changing operational intent, not a simple consumer of preapproved access. See the Agentic AI Identity Guide.

Practical implication: Model every agent as a runtime identity with bounded authority, not as a static application integration.

How tool misuse and privilege abuse happen in practice

Tool misuse emerges when an agent is connected to APIs, admin consoles, data stores, or execution environments that exceed the task’s real scope. The article separates ASI02 and ASI03 for a reason: an agent can misuse a legitimate tool without the tool itself being malicious, and it can inherit excessive authority simply by being wired to too many secrets or service accounts. In practice, this is a privilege aggregation problem. The agent becomes a concentrator of access, and compromise of the agent becomes compromise of everything attached to it. That is why the real control boundary is not the model prompt alone. It is the combination of tool-level authorization, per-action policy, and the identities the agent can reach through delegation. See the AI Agent Authorisation Guide.

Practical implication: Constrain each tool call and each attached credential separately rather than granting broad agent-wide access.

Why lifecycle controls matter before, during, and after execution

The article’s strongest architectural insight is that agentic security spans the full lifecycle. Before execution, compromised tools, models, or MCP servers can corrupt the environment before an agent even runs. During execution, goal hijack, prompt injection, memory poisoning, and human trust exploitation alter what the agent does in the moment. After execution, detection and containment determine whether the system can explain what happened and stop repetition. This is why the OWASP list is more useful than a single control category: it aligns with trust, runtime enforcement, and forensic proof as separate layers. A lifecycle view also prevents teams from over-focusing on input filtering while missing supply chain trust, or from focusing on logs while ignoring that the wrong tool was already approved. See the AI Agent Observability, Audit and Incident Response Guide.

Practical implication: Build verification, runtime enforcement, and auditability as one control chain rather than isolated controls.

Threat narrative

Attacker objective: The attacker wants to redirect an agent’s authority so it performs actions that expose data, execute code, or propagate compromise without obvious human intervention.

1. Entry begins when a malicious prompt, poisoned tool output, compromised MCP server, or tampered agent artefact reaches the environment and shapes agent behaviour before execution.
2. Escalation occurs when the agent accepts manipulated instructions, misuses legitimate tools, or inherits more privilege than the task requires, expanding the attacker’s effective authority.
3. Impact follows when the compromised agent exfiltrates data, runs unapproved code, propagates bad instructions to other agents, or creates a cascading failure across connected systems.

Breaches seen in the wild

• OmniGPT breach claim 2025: A hacker claims to have leaked 34 million OmniGPT AI chat messages holding users' API keys and credentials; OmniGPT has not confirmed it.
• Moltbook AI agent keys breach: Moltbook breach exposed 1.5M AI agent keys.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Agentic applications invalidate the assumption that authorization and behaviour are the same thing. The article shows that traditional IAM can prove an identity is entitled to act, but not that the actor will remain aligned with the approved task once runtime context changes. That is a structural governance break, not just a tooling gap. The implication is that agent identity must be governed as an active execution model, not a static access record.

Tool sprawl becomes privilege sprawl the moment an agent can bind multiple credentials to one task. When an agent aggregates keys, tokens, service accounts, and execution paths, compromise of the agent becomes compromise of every attached control plane. That is why ASI03 is not just a technical risk category but a governance signal that delegated authority has become overconcentrated. Practitioners should read this as a warning that boundary control now starts with the agent’s reachable authority, not with the app that calls it.

Before-execution trust is the named concept that most teams still under-model. The article makes clear that a tampered model, tool, or MCP server can poison the outcome before runtime policy has a chance to act. Once the artifact enters production unverified, the downstream control stack is already compromised. The practitioner lesson is to treat provenance as part of identity governance, because approval without verification is not governance.

Lifecycle containment is now as important as prevention for agentic systems. The article’s ASI08 and ASI10 categories reflect a reality that teams often miss: a bad decision inside one agent can cascade across dependent agents and systems faster than human review cycles can react. That makes traceability, blast-radius control, and fail-closed behaviour governance requirements, not just incident-response enhancements. The field needs to stop assuming that one filter or one policy layer can absorb that complexity.

Human approval remains relevant, but only when it is detached from the agent’s conversational channel. The article’s approval model matters because a persuasive agent can otherwise talk a human into authorising harmful action. That is a governance problem across human and machine identity, not a UI problem. The implication is that approvals need cryptographic separation from the agent path if they are to mean anything under adversarial pressure.

From our research library:

• Only 23% of IT leaders were very confident in their organisation's ability to manage security and governance for GenAI deployments, according to a 2025 Gartner survey of 360 IT leaders.
• Read next: Agentic AI Identity Guide

What this signals

Policy must move from prompts to execution boundaries. Teams that only harden prompts will miss the larger problem: agentic systems fail when authorization, tool access, and delegation are not bounded at runtime. Governance needs to follow the action path, not just the input path, because that is where the real control break lives.

Identity review processes will need a new trigger model. Access review assumes a stable entitlement that can be recertified later, but agentic systems can create and consume authority inside a short execution window. That makes issuance-time control more important than periodic review for many deployments.

AI agent security is becoming a lifecycle discipline, not a point control. The most useful operating model is to verify what enters the environment, enforce what the agent can do while it runs, and prove what happened after the fact. That sequence is where programme design will separate mature teams from those still treating agents like chatbots.

For practitioners

• Map each agent to a named authority boundary Document which tools, data sets, execution environments, and delegated identities each agent can reach, then remove anything that is not required for the task.
• Separate tool approval from model permission Treat tool invocation as its own control point, with per-tool and per-action authorization instead of broad access inherited from the host application.
• Verify every agentic artifact before it reaches runtime Require signature, provenance, and security checks for models, MCP servers, agent definitions, and skills before they are allowed into production.
• Design approvals that the agent cannot simulate Move high-risk approvals outside the agent conversation and log them as separate attestations so a compromised agent cannot impersonate consent.

Key takeaways

• Agentic applications create a governance problem that starts with delegated authority and ends with blast-radius control, not with prompt quality alone.
• The article’s main warning is that runtime behaviour, tool access, and provenance all need separate controls because one layer does not cover the others.
• Teams should treat verification, enforcement, and forensic proof as one lifecycle for AI agents rather than as disconnected security tasks.

Related NHI Mgmt Group resources: Agentic AI Security Guide · AI Agent Authorisation Guide · AI Agent Observability, Audit and Incident Response Guide · OmniGPT breach claim 2025

Key terms

• Agentic Application: An agentic application is software in which an AI system can choose actions, call tools, and complete tasks with limited human intervention. In security terms, it behaves like an active workload that needs scoped identity, logging, and control boundaries, not just prompt filtering.
• Goal hijack: A failure mode where an agent is steered away from its approved objective and begins pursuing a different one, often through manipulated inputs or chained context. For autonomous or semi-autonomous systems, the risk is not only misuse of a tool but the redefinition of the mission itself.
• 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.
• Lifecycle Containment: The ability to verify an agentic artifact before use, control it during execution, and explain or stop it after failure. This is the operational answer to agentic risk because prevention, runtime control, and evidence are all part of the same governance chain.

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 identity security in your organisation, it is worth exploring.