Why this list is very different from the LLM Top 10 and why most organizations are not ready

If you already run copilots, AI assistants or RAG systems in your organization, the OWASP LLM Top 10 probably felt familiar. The Agentic Top 10 (https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/) should feel uncomfortable. Because this is the first OWASP list that treats AI not as a chat interface, but as: a distributed, autonomous execution layer embedded into your business workflows.

Agents plan.
Agents choose tools.
Agents delegate to other agents.
Agents carry identity.
Agents persist memory.
Agents act without a human looking at every step.

OWASP makes one statement very clearly: “Agents amplify existing vulnerabilities” and unnecessary autonomy must be avoided through least-agency and strong observability. That single sentence should already worry any security leader running automation in production.

The uncomfortable shift: from “prompt safety” to “operational safety”

Traditional GenAI risk models assume:

• a human prompt
• a model response
• maybe a tool call
• then the loop ends

Agentic systems break this mental model. In agentic platforms (Auto-GPT style systems, LangGraph pipelines, Bedrock Agents, Copilot Studio, internal orchestration layers, MCP-based tool frameworks, etc.), the loop does not end.

You now have:

• long-lived goals
• planning graphs
• chained tool execution
• delegated execution
• persistent memory
• inter-agent messaging

This is no longer an AI problem. It is an autonomous distributed system security problem.

The OWASP Agentic Top 10 at a glance

The list is structured into ten classes of failure and abuse:

• ASI01 – Agent Goal Hijack
• ASI02 – Tool Misuse & Exploitation
• ASI03 – Identity & Privilege Abuse
• ASI04 – Agentic Supply Chain Vulnerabilities
• ASI05 – Unexpected Code Execution (RCE)
• ASI06 – Memory & Context Poisoning
• ASI07 – Insecure Inter-Agent Communication
• ASI08 – Cascading Failures
• ASI09 – Human–Agent Trust Exploitation
• ASI10 – Rogue Agents

(overview extracted from the official document)

Instead of repeating the definitions, I want to focus on what really changes your threat model.

ASI01 – Agent Goal Hijack

The real risk is not prompt injection. It is silent re-planning.

Goal hijack is not about making a model say something wrong. It is about changing what the agent is trying to achieve.

In practice, this happens through:

• RAG documents
• emails
• tickets
• calendar invites
• tool outputs
• other agents

Once an agent’s planner accepts a poisoned objective, everything that follows is technically “correct”. In an enterprise automation context, this becomes extremely dangerous:

• approval bots
• procurement bots
• SOC response bots
• change automation agents

If the goal shifts, your controls remain blind because the actions still follow valid workflows.

Research angle that matters

We need to start treating goals as first-class security objects.

OWASP hints at emerging ideas such as “intent capsules” and runtime intent validation.
But practically, most agent frameworks today do not sign, version or audit goals.

Do

• Treat every external input as untrusted before it can influence planning.
• Bind every execution cycle to an explicit, auditable goal object.

Don’t

• Let agents infer or update their own objectives without change control.

ASI02 – Tool Misuse & Exploitation

EDR will not save you here

One of the most important scenarios in the document describes legitimate tools being chained to perform data exfiltration, while every single action is authorized and executed by trusted binaries.

This should immediately ring alarm bells for SOC and platform teams.

From a host point of view:

• PowerShell is allowed
• API calls are allowed
• credentials are valid
• binaries are signed

Nothing looks like malware. The attack is entirely in orchestration logic. This is one of the biggest blind spots in current security tooling.

Do

• Treat tool invocation as a policy-enforced operation, not a model decision.
• Build an “intent gate” in front of tools.

Don’t

• Give agents generic shells, admin APIs or multi-object data access just because it is convenient.

ASI03 – Identity & Privilege Abuse

The agent identity problem no one solved yet

OWASP highlights something many teams are quietly struggling with:

Our IAM systems are human-centric.
Agentic systems are delegation-centric.

Agents:

• inherit credentials
• reuse cached sessions
• forward delegated context
• trust other agents

This produces a classic confused deputy problem, but now at machine speed and scale. OWASP explicitly frames agents as non-human identities and references the need to integrate them into identity systems such as Entra, Bedrock, Salesforce, Workday, etc. In large enterprises, this becomes a governance nightmare.

Do

• Issue per-agent, per-task identities with short-lived tokens.
• Re-authorise at every privileged step.

Don’t

• Reuse long-lived service credentials inside agent workflows.

ASI04 – Agentic Supply Chain Vulnerabilities

Your runtime becomes your supply chain

This is where the agentic world diverges completely from classical SBOM thinking.

Agents dynamically load:

• tools
• MCP descriptors
• prompt templates
• agent cards
• other agents

And they do it at runtime.

OWASP explicitly calls this a live supply chain.

This is not just about poisoned libraries.

It is about poisoned capabilities.

The exploit table in the appendix shows real incidents involving:

• malicious MCP servers
• agent card spoofing
• extension poisoning
• dynamic prompt hubs

Do

• Pin tools, prompts and agent descriptors by hash.
• Maintain an AIBOM, not only an SBOM.

Don’t

• Allow open discovery of tools or agents in internal networks.

ASI05 – Unexpected Code Execution (RCE)

Vibe coding meets production

The danger is not that agents can write code.The danger is that many systems now execute what agents generate.

OWASP explicitly covers:

• shell invocation
• deserialisation attacks
• unsafe eval in memory systems
• multi-tool chains leading to RCE

In internal developer platforms, this is already happening.

Do

• Separate code generation and code execution.
• Enforce pre-execution scanning and approval.

Don’t

• Allow auto-run in shared or production environments.

ASI06 – Memory & Context Poisoning

This is your new persistence mechanism

This is one of the most underestimated risks.

Agent memory is:

• vector databases
• summaries
• embeddings
• cross-session state

Once poisoned, the agent becomes a self-propagating insider threat. OWASP explicitly differentiates this from simple prompt injection and focuses on persistent corruption across sessions.

Do

• Version and snapshot memory stores.
• Track provenance and trust scores for memory entries.

Don’t

• Automatically ingest the agent’s own outputs into trusted memory.

ASI07 – Insecure Inter-Agent Communication

East-west traffic is now natural language

The document makes an important observation:

Inter-agent traffic is not only transport risk. It is also semantic risk.

A message can be syntactically valid and cryptographically signed and still manipulate another agent’s intent.

Do

• Sign and encrypt messages.
• Perform semantic validation and intent diffing.

Don’t

• Assume mTLS alone solves inter-agent security.

ASI08 – Cascading Failures

This is why agentic systems scare SREs

OWASP treats cascading failures as a first-class threat, not as an operational nuisance.

Because in agentic systems:

• planners feed executors
• executors feed memory
• memory feeds new plans
• plans spawn new agents

One fault becomes many faults. This is described explicitly as fan-out, feedback loops and cross-tenant spread.

Do

• Insert policy gates between planning and execution.
• Apply blast-radius controls and circuit breakers.

Don’t

• Allow bulk automation without replay and rollback capability.

ASI09 – Human–Agent Trust Exploitation

Social engineering is now embedded in your automation

This entry is deeply uncomfortable for leadership teams. The agent becomes an untraceable social engineer.

OWASP explicitly highlights:

• authority bias
• fake explainability
• emotional manipulation

This is not theoretical. The incidents table includes real cases of payment fraud and operational sabotage driven by compromised assistants.

Do

• Separate preview from execution.
• Show provenance, not model-generated explanations.

Don’t

• Let agents justify their own high-risk actions.

ASI10 – Rogue Agents

The “insider threat” of autonomous systems

This is the hardest class to detect. A rogue agent:

• behaves within policy boundaries
• executes valid workflows
• slowly drifts

OWASP explicitly frames this as behavioural integrity loss.

This is extremely relevant for long-running optimisation agents and self-improving automation.

Do

• Track behavioural baselines.
• Monitor objective drift and reward manipulation.

Don’t

• Rely on static rule-based detection.

What this means for real enterprise platforms

In environments, where:

• automation touches infrastructure
• identity systems are complex
• change processes are regulated
• incident response is partially automated

the most dangerous misconception is: “We already have security controls around the tools.”

Agentic risk is not tool risk. It is decision and delegation risk.

A practical checklist you can take to your architecture review

If you are building or approving an agentic platform, ask only five questions:

1. Where are agent goals stored, versioned and audited?
2. Who enforces tool usage policies, the model or a policy engine?
3. How are agent identities issued, scoped and revoked?
4. How is memory governed, segmented and rolled back?
5. What stops a bad plan from reaching execution?

If you cannot answer all five clearly, you already have multiple OWASP ASI risks.

The biggest mistake teams will make

They will treat this as another awareness document.

The OWASP Agentic Top 10 is not a developer checklist.

It is a platform and governance architecture blueprint.

If you try to bolt these controls onto existing agent frameworks after rollout, you will end up rebuilding the orchestration layer anyway.

Final thought

The most important concept introduced in this document is not any single ASI category.

It is the idea of least agency.

Not least privilege.

Least agency.

Because in agentic systems, autonomy itself becomes your attack surface.