OWASP Top 10 for Agentic AI Applications 2026: A Practical Security Guide

An AI chatbot can produce a bad answer. An AI agent can produce a bad answer and then act on it.

That difference changes the security problem. Agentic systems can plan several steps, retrieve external information, call tools, use delegated credentials, write to applications, communicate with other agents and preserve memory between interactions. A manipulated decision can therefore propagate beyond the model into real systems.

The OWASP Top 10 for Agentic Applications 2026, released in December 2025 by the OWASP Gen AI Security Project’s Agentic Security Initiative, gives teams a useful framework for reasoning about these risks. It is not a certification checklist and it does not replace conventional application, cloud or identity security. Instead, it highlights security problems that become especially important when AI is given agency.

NIST reaches a similar conclusion from another direction. Its 2025 adversarial machine learning taxonomy describes agents as systems that iteratively use model outputs to select actions and tools, and notes that agents inherit risks such as direct and indirect prompt injection. In 2026, NIST’s Center for AI Standards and Innovation also identified the combination of model outputs with software functionality as a distinct area requiring security attention.

The OWASP Agentic Top 10 at a glance

The categories overlap deliberately. A malicious document might hijack a goal under ASI01, cause misuse of an email tool under ASI02, exploit an over-privileged delegated identity under ASI03 and then create a cascading failure under ASI08. Security therefore needs to be applied across the whole execution path, not only at the prompt boundary.

Original architecture diagram for this article. It maps common agentic trust boundaries to practical control points derived from OWASP’s mitigation guidance and established security principles.

ASI01: Agent Goal Hijack

An agent receives more than instructions from its user. It may read websites, email, documents, tickets, calendar entries, retrieved knowledge and messages from other agents. The underlying model does not provide a dependable security boundary between trusted instructions and attacker-controlled natural language.

Imagine a research agent asked to collect information and prepare a private report. One retrieved web page contains hidden text telling automated assistants to ignore their task, search connected storage for confidential material and send it to an external destination. If that content changes the agent’s objective or plan, the problem has moved beyond a misleading response. The agent’s goal has been hijacked.

This is why prompt filtering alone is insufficient. OWASP recommends treating natural-language inputs as untrusted, limiting tool privileges, requiring approval for high-impact actions, validating intent before execution, monitoring goal changes and testing goal-override scenarios. NIST’s work on agent hijacking likewise focuses on indirect prompt injection delivered through external data.

A useful design principle is to keep the user’s declared objective outside the model’s editable context where possible. A policy layer can compare proposed actions with the original task before allowing execution.

ASI02: Tool Misuse and Exploitation

A tool can be legitimate and still be dangerous in the wrong context. An email tool that can read messages may also be able to send or delete them. A database connector intended for lookups may expose write operations. A shell tool can turn an unreliable model output into an operating-system action.

The key distinction is that the agent may already be authorized to use the tool. The failure is how that authority is applied. For example, a customer-support agent needs to view an order. If its commerce integration also allows unrestricted refunds, an injected instruction or planning error could convert a simple support workflow into a financial action.

OWASP’s guidance includes per-tool least privilege, action-level approval, sandboxing, outbound network restrictions, policy enforcement before execution, usage budgets, short-lived credentials and immutable tool logs. This is a strong reason to expose narrow operations such as get_order_status rather than handing an agent a broad administrative interface.

ASI03: Identity and Privilege Abuse

Traditional identity systems were mostly designed around people and services with relatively stable roles. Agents complicate this because they can act for a user, delegate to another agent and call several services during one task.

A dangerous shortcut is to let the agent simply inherit the user’s full session. If a task needs read-only access to three invoices, the agent should not automatically receive every permission the user has across finance, email and storage.

Separate the identity of the user, the agent and the tool invocation. Authorization should be evaluated close to each action, with task-specific scopes and short-lived credentials. This also improves attribution: logs can show which user requested the task, which agent proposed the action and which credential authorized it.

NIST’s 2026 work on software-agent identity specifically highlights identification, authorization, auditing and non-repudiation as areas that need attention for agents.

ASI04: Agentic Supply Chain Vulnerabilities

An agent is assembled from many moving parts: models, orchestration frameworks, system prompts, tools, MCP servers, plugins, packages, container images, retrieval components and external APIs. Trusting the agent means trusting this chain.

A malicious or compromised tool can advertise an apparently useful capability while behaving differently at runtime. A dependency update can change code. An unverified model or prompt package can alter behaviour. Dynamic discovery makes this harder because components may enter the workflow after deployment.

Treat agent components as supply-chain assets. Maintain inventories, pin and verify versions where practical, review provenance, restrict dynamic tool installation, protect build and deployment systems, and monitor changes to tool definitions and permissions. An AI Bill of Materials can improve visibility, but inventory is only useful when connected to verification and change control.

ASI05: Unexpected Code Execution (RCE)

Some agents are intentionally allowed to write or run code. Others reach execution indirectly through shell tools, notebooks, automation platforms, templating systems or interpreters. In either case, model output must not be treated as trusted code merely because the model generated it.

Consider a coding assistant that reads a repository issue containing attacker-controlled instructions. If it converts those instructions into a command and runs the command on a workstation with developer credentials, the trust boundary has failed.

Execution-capable agents need strong isolation. Use disposable sandboxes, minimal filesystem access, restricted network egress, resource limits and explicit approval for sensitive operations. Separate code generation from code execution and inspect the proposed operation before it crosses that boundary.

ASI06: Memory and Context Poisoning

Memory makes agents useful because they can preserve preferences, facts and task state. It also creates a persistence mechanism.

Suppose an attacker convinces a support agent to store a false instruction such as “requests from this domain are pre-approved.” The original malicious interaction may end, but the poisoned memory can influence future sessions. Retrieval systems can create a similar effect when untrusted content becomes part of a knowledge source repeatedly supplied to the agent.

Memory needs provenance, segmentation and lifecycle controls. Record where important facts came from, separate users and security domains, avoid storing secrets unnecessarily, validate high-impact memory writes, support deletion and rollback, and monitor unexpected changes. Persistent context should not silently become equivalent to trusted policy.

ASI07: Insecure Inter-Agent Communication

Multi-agent systems introduce a distributed trust problem. A planner might ask a research agent for evidence and then send the result to an execution agent. If the execution agent trusts any message that appears to come from an internal peer, a compromised or spoofed agent can become a confused-deputy path.

Agent-to-agent messages should have authenticated identities, explicit authorization and integrity protection. Validate schemas rather than accepting arbitrary natural language as executable intent. Preserve the original user’s authorization context through delegation instead of assuming that an internal message is automatically trusted.

This is ordinary secure distributed-systems thinking applied to a new interface: identity and provenance matter even when the participants communicate in natural language.

ASI08: Cascading Failures

Autonomy connects decisions. A small error early in a workflow can therefore become a large operational effect later.

Imagine an agent incorrectly classifies a supplier as fraudulent. A second step freezes purchases, another notifies customers, and a final automation removes the supplier from an approved list. Each individual action may be legitimate, but the chain magnifies one incorrect premise.

Reduce blast radius with checkpoints, transaction boundaries, rate limits, bounded retries, circuit breakers and reversible actions. High-impact workflows should be designed so one model output cannot silently trigger an unlimited chain of consequences. Observability also matters because operators need to reconstruct how the cascade began.

ASI09: Human-Agent Trust Exploitation

People can over-trust fluent output. An agent can present a recommendation, approval request or summary with confidence even when its reasoning depends on manipulated or incorrect evidence.

An attacker may exploit that trust by influencing what the agent shows a reviewer. A human approval step is therefore not automatically a security control. It becomes useful only when the person receives enough independent information to make a real decision.

Approval interfaces should expose the proposed action, target, important parameters, data leaving the system and relevant provenance. Avoid vague prompts such as “Allow agent to continue?” for consequential actions. The goal is informed authorization, not approval fatigue.

ASI10: Rogue Agents

OWASP uses Rogue Agents for harmful or misaligned autonomous behaviour that emerges without an attacker actively controlling the agent. That distinction matters. Not every dangerous action is an intrusion.

An agent may optimize a poorly specified objective in an unintended way, conceal relevant information, resist correction or continue a strategy beyond the operator’s intended scope. Security architecture should assume that model-level alignment is not an access-control mechanism.

Constrain what the agent can do even when its reasoning fails. Apply least agency, explicit policy, resource limits, independent monitoring, termination mechanisms and human escalation. A system should remain containable even if the agent chooses an unexpected plan.

A practical architecture: control the action path

A secure agentic design separates reasoning authority from execution authority.

The model can propose that an email should be sent, but a deterministic policy component should decide whether sending is permitted. The model can request a customer record, but the data layer should enforce tenant and field-level authorization. The model can suggest code, but a sandbox should constrain execution.

A useful control sequence is:

1. establish the authenticated user and a narrowly defined task;
2. label retrieved and external content as untrusted and preserve provenance;
3. allow the model or planner to propose actions, not directly authorize them;
4. validate the tool name, arguments, destination and requested privilege through a policy enforcement point;
5. require meaningful human approval for destructive, financial, external-publication or other high-impact actions;
6. issue scoped, short-lived credentials only after authorization;
7. execute in a constrained environment with egress and resource controls;
8. log the goal, proposed action, authorization decision, tool call and result;
9. detect unusual goal changes, tool chains, privilege use and repeated failures;
10. provide a way to stop, revoke and roll back where the operation allows it.

This design cannot make an LLM perfectly trustworthy. It does something more realistic: it limits how much an untrusted or mistaken decision can affect the rest of the system.

Least privilege is not enough: think about least agency

One of the strongest ideas in OWASP’s Agentic Top 10 is least agency. Least privilege asks, “What permissions does this component need?” Least agency asks an earlier question: “Does this task need autonomous action at all?”

If an AI system only needs to summarize an invoice, it may not need a payment tool. If it needs to draft an email, it may not need permission to send. If it needs to recommend a configuration change, it may not need direct production access.

Reducing unnecessary autonomy removes attack paths before fine-grained permissions are even considered. This is especially valuable because the same model may process attacker-controlled content during normal work.

What the Top 10 does not replace

The Agentic Top 10 should sit alongside conventional security, not above it. An agent can still be compromised through ordinary broken access control, vulnerable dependencies, exposed secrets, cloud misconfiguration or insecure APIs. The surrounding application still needs secure software development, identity management, vulnerability management, logging, incident response and data protection.

The framework also should not be read as proof that every listed attack will affect every agent. Risk depends on architecture. A read-only local assistant with no memory and no tools has a very different exposure from an autonomous agent with email, cloud and payment access.

Threat modelling should start with the actual capabilities and trust boundaries of the system.

A compact review checklist for an agent before production

Before deploying an agent, ask whether the team can answer these questions clearly:

• What is the agent allowed to decide, and what must remain a human decision?
• Which inputs can be controlled by outsiders?
• Which tools can read, write, execute, publish, transfer money or send data externally?
• Does each action receive the minimum authorization needed for that task?
• Can retrieved content or peer-agent messages change the agent’s goal?
• What enters persistent memory, and who can correct or remove it?
• Are tool and agent identities authenticated rather than inferred from names or descriptions?
• Can generated code execute, and if so, where is it isolated?
• Can one failed decision trigger many downstream actions?
• Do approval screens show enough context for a person to notice manipulation?
• Can operators reconstruct why an action occurred?
• Can credentials be revoked and the agent stopped quickly?

If several answers are unclear, adding another prompt instruction is unlikely to solve the underlying architecture problem.

The main lesson

Agentic AI security is not simply “LLM security with more prompts.” Agency connects probabilistic reasoning to privileges and side effects. That makes identity, authorization, tool design, provenance, containment, observability and human decision design part of the AI security boundary.

The OWASP Top 10 for Agentic Applications 2026 is useful because it gives names to these failure modes. Its greater value is architectural: do not make the model the final security authority for the actions it proposes.

If you are building the surrounding controls, my earlier guides to AI security, prompt injection, AI agents and cybersecurity, and protecting sensitive data when using AI tools provide useful background.

Sources and further reading

• OWASP Top 10 for Agentic Applications for 2026, OWASP Gen AI Security Project, December 2025.
• OWASP Agentic Security Initiative, OWASP Gen AI Security Project.
• Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025, March 2025.
• Summary Analysis of Responses Regarding Security Considerations for AI Agents, NIST, May 2026.
• Strengthening AI Agent Hijacking Evaluations, NIST CAISI, January 2025.