OWASP Agentic AI Top 10: Security Risks for Autonomous Agents

The OWASP Agentic AI Top 10 is the 2026 OWASP list of security risks for applications in which AI agents plan, use tools, communicate, retain memory, and act across several steps. The official title is the OWASP Top 10 for Agentic Applications for 2026, and its entries run from agent goal hijack through rogue agents.

The list extends application and LLM security into systems where one manipulated input can change a plan and trigger actions in other systems. An agent may read email, call an MCP server, query a private database, delegate work to another agent, and send a result. Each action creates a separate authorization and failure decision.

OWASP’s document introduces “least agency” beside least privilege. The practical meaning is simple: do not give an agent autonomy that its task does not need, and do not let the model decide its own permission boundary.

Key Takeaways

• Bind every agent run to a declared goal, authenticated principal, permitted tools, target resources, time limit, and approval policy.
• Treat model output, retrieved content, memory, tool results, and messages from other agents as untrusted data.
• Enforce authorization at the tool and resource boundary because an agent’s plan is not an access-control decision.
• Test multi-step failure, revocation, retries, delegation, and recovery instead of judging security from one model response.

What Makes an Agentic Application Different

An LLM application can generate text without taking an external action. An agentic application adds planning, state, tool selection, repeated execution, or delegation. Autonomy may be narrow, such as choosing which read-only search tool to call, or broad enough to change infrastructure and communicate with people.

This difference changes the impact of model error and hostile input. A misleading answer is harmful, but a misleading plan paired with credentials can create an account, transfer data, push code, or alter access. Security therefore depends on the surrounding control system as much as the model.

The OWASP document connects agentic risks to the LLM Top 10, Non-Human Identities Top 10, CycloneDX, and OWASP AI Vulnerability Scoring System. Those mappings make sense because agent behavior sits on top of software dependencies, identities, models, data, APIs, and operational policy.

OWASP Agentic AI Top 10 Risks Explained

ASI01: Agent goal hijack

Agent goal hijack occurs when attacker-controlled content changes the objective, plan, or action selection of an agent. The content can arrive directly in a prompt or indirectly through email, documents, web pages, retrieved records, tool output, or agent messages.

Keep the authorized goal in structured state outside the model context. Compare proposed actions with the original request, permitted resources, and current approvals. If a new objective appears during execution, pause the run and require a fresh decision.

ASI02: Tool misuse and exploitation

An agent can choose a legitimate tool for an unsafe purpose, supply dangerous arguments, or chain several harmless functions into a harmful outcome. Tool misuse also includes exploiting a vulnerable handler through injection, path traversal, unsafe URLs, or malformed data.

Define small tools with typed inputs and narrow effects. Apply deterministic validation, resource authorization, quotas, and transaction limits at execution time. Do not infer permission from the fact that a tool was made visible to the model.

ASI03: Identity and privilege abuse

Identity abuse appears when agents share service accounts, inherit a user’s entire session, keep authority after a task ends, or act without a traceable delegation chain. An attacker who redirects the agent can then use valid credentials for an unauthorized purpose.

Give the agent or workload its own identity and represent delegated authority separately. Bind access to the initiating principal, agent, action, target, and lifetime. The AI identity infrastructure guide explains this separation across users, agents, models, tools, and data services.

ASI04: Agentic supply chain vulnerabilities

Agentic systems depend on models, agent frameworks, prompts, tools, MCP servers, packages, retrieval sources, skills, and hosted services. A malicious update can change behavior even when application code remains untouched.

Inventory each component and record its source, version, owner, permissions, and update path. Review changes to tool schemas, prompts, policies, models, and remote services. Isolate third-party components so one compromise does not inherit every credential available to the agent host.

ASI05: Unexpected code execution

Unexpected code execution occurs when generated text or untrusted data reaches a shell, interpreter, notebook, template engine, browser, database, or automation platform without a safe boundary. The model may generate the dangerous value, but the vulnerable design is the component that executes it.

Use fixed operations, parameterized libraries, constrained sandboxes, read-only filesystems, restricted networks, and disposable environments. Require approval for actions that modify systems or execute user-visible code, and log the exact resolved operation rather than a summary of the model’s intent.

ASI06: Memory and context poisoning

Memory poisoning stores false facts, malicious instructions, or altered preferences that affect later runs. Unlike a one-time prompt injection, poisoned state can survive the original interaction and influence other users or tasks.

Separate memory by tenant and purpose, record provenance, limit which content may become durable, and provide review and deletion. Retrieval should apply access checks before content enters the model, while high-impact decisions should verify claims against authoritative systems instead of trusting memory.

ASI07: Insecure inter-agent communication

Agents may exchange tasks, results, identities, and authority through messages that look trustworthy but lack authenticated provenance. One compromised agent can forge a request, change another agent’s plan, or pass data into a context where it does not belong.

Authenticate agent workloads and protect message integrity. Define allowed senders, recipients, schemas, task types, and delegation depth. The receiving agent should authorize the requested operation under its own policy rather than treating a peer’s message as approval.

ASI08: Cascading failures

A small error can spread through retries, delegated tasks, shared memory, event queues, or automated remediation. Several agents may respond to each other’s outputs, consume resources, duplicate transactions, or amplify an incorrect decision.

Set budgets for steps, time, tokens, cost, retries, fan-out, and external actions. Use idempotency keys for transactions, circuit breakers for repeated failure, and a clear stop state that propagates to child tasks. Recovery tests should prove that operators can contain one run without shutting down unrelated work.

ASI09: Human-agent trust exploitation

People can give agent messages more authority than they deserve, especially when the output uses a trusted name, corporate channel, or confident tone. Attackers may exploit that trust to obtain approval, credentials, money, or sensitive information.

Interfaces should identify the agent, the source of material claims, and whether a message or action was generated automatically. High-impact approvals should show primary evidence and the real transaction details. A person should never have to approve a vague request such as “continue” when the next action changes access or sends data.

ASI10: Rogue agents

A rogue agent acts outside intended goals or control, whether through compromise, misalignment, unsafe adaptation, or loss of governance. The risk is broader than one injected prompt because the agent may continue pursuing harmful behavior across steps and systems.

Constrain runtime permissions, monitor behavior against invariants, and give operators an independent kill and revocation path. An agent must not be able to disable its own audit, expand its own role, approve its own exception, or create an unrestricted replacement.

Agent Authorization Must Stay Outside the Model

Models can propose actions, but policy enforcement needs deterministic inputs and outcomes. A tool gateway should receive the authenticated user, agent identity, delegation record, action, resource, environment, and relevant risk signals. It can then allow, deny, narrow, or require approval under policy that the model cannot rewrite.

This separation also improves investigation. The audit record can show what the model proposed and what the policy engine permitted. Without that distinction, a successful tool call may look authorized simply because it happened.

Delegation should attenuate authority rather than copy it. A child agent needs no more permission than the parent task requires, and its grant should expire with that task. The agent authorization article covers tool access, delegation chains, least privilege, and revocation in more detail.

How to Threat Model an Agentic Application

Begin with entities and data flows rather than the agent prompt. List the user, agent runtime, model provider, memory store, retrieval system, tools, APIs, other agents, approval interface, identity provider, and audit pipeline. Mark where content, identity, and authority cross a boundary.

For each tool, write the maximum effect of a successful call. Reading a calendar and sending an invitation are different effects even if one connector exposes both. Record whether the action can change money, access, production, customer data, code, or communication with another person.

Then trace one normal task and one hostile task. Include indirect instructions in retrieved data, a poisoned tool response, a delegated subtask, a timeout, a repeated call, a revoked credential, and a partial downstream failure. The exercise should reveal where the application assumes the model will notice danger that code should stop.

Testing Should Measure Actions and Containment

Response-quality tests cannot show whether an agent is secure. A test needs to observe selected tools, resolved arguments, authorization decisions, side effects, messages, memory writes, retries, and audit events. The pass condition is often that an unsafe action did not occur, even if the model produced persuasive text.

Build an adversarial corpus across every input channel. Include hidden instructions, conflicting goals, malicious files, forged peer messages, untrusted URLs, altered tool schemas, poisoned memory, and requests from the wrong tenant. Repeat tests after model, prompt, policy, tool, or dependency changes.

Containment deserves its own test set. Disable a tool during execution, revoke the agent credential, break a downstream service, exceed a budget, and interrupt a child agent. Verify that the system stops safely, avoids duplicate effects, preserves evidence, and reports what remains unfinished.

How the Agentic, LLM, and MCP Lists Work Together

The OWASP LLM Top 10 focuses on model-enabled application risks, including prompt injection, information disclosure, unsafe output handling, and excessive agency. The agentic list focuses on planning and action across multiple components. The MCP list focuses on one common protocol layer used to expose context and tools.

Their categories overlap by design. ASI01 agent goal hijack may begin with LLM01 prompt injection, then use an MCP tool affected by weak authorization. Teams should map each category to controls and tests rather than run three separate checkbox reviews.

Frequently Asked Questions

What is the OWASP Agentic AI Top 10?

It is OWASP’s 2026 awareness framework for security risks in applications where AI agents plan and act across tools, data, memory, and other agents. The official document names ten risks from agent goal hijack to rogue agents. It provides descriptions, scenarios, mitigations, and mappings to related OWASP work.

How is agent goal hijack different from prompt injection?

Prompt injection describes input that changes model behavior or output. Agent goal hijack describes the wider effect on an agent’s objective, plan, and multi-step actions. A prompt injection can cause goal hijack, but hostile tool output or a forged agent message can also redirect the goal.

What does least agency mean?

Least agency means giving an application no more autonomy than the task requires. A workflow should use fixed code or a narrow tool when open-ended planning adds no useful capability. Reducing autonomy lowers the number of decisions that depend on uncertain model behavior.

Can a human approval step make an AI agent safe?

Approval can reduce risk when it shows the exact action, target, identity, and consequence. It cannot compensate for hidden side effects, vague prompts, unsafe code execution, or a credential with excessive reach. Agent security also needs identity, authorization, isolation, validation, monitoring, and revocation.