OWASP Agentic AI Risks Security Architects Should Review

TL;DR: The OWASP Top 10 for Agentic Applications works best as a design-review checklist for agentic AI security. Turn each of the ten AI agent security risks into a question to ask, controls to look for, and evidence to request, and review in three passes: authority and inventory, then inputs, state, and execution, then coordination and oversight. The review should leave an evidence pack that a second reviewer could use to reach the same conclusions, since no single control covers all ten entries.

The OWASP Top 10 for Agentic Applications is most useful as a design-review checklist, not a reading list. Security architects get the most from it by turning each entry into a question a team must answer, an artifact it must produce, and an owner who signs off. That is where agentic AI security stops being a taxonomy and becomes operational control of agents: a set of controls and evidence that an application security review can verify.

This guide is for security architects and governance teams at regulated enterprises. It walks through all ten AI agent security risks as review cards, each with the question to ask, the controls to look for, and the evidence to request, and it ends with the evidence pack a review should leave behind.

The OWASP GenAI Security Project's official list was published in December 2025, developed with input from more than 100 experts and practitioners. Because most agentic systems are built on LLM applications, security teams should also consider the relevant risks covered by the OWASP Top 10 for LLM Applications. Each OWASP entry carries a description, common examples, attack scenarios, and prevention guidance, and that document remains the reference. The cards below are this guide's own review synthesis, not verbatim OWASP recommendations. For a mapping of each risk to detection and impact-limiting controls, Prediction Guard's published overview, "Key OWASP Agentic AI Risks Enterprise Teams Must Know," is the companion piece, and this guide focuses on running the review itself.

How to Run the Review: The OWASP Security Framework in Three Passes

OWASP's list is voluntary, community-developed guidance, not a compliance mandate, and it does not rank its entries by likelihood. It fits into an application security program the way any threat taxonomy does: it feeds threat modeling, scopes testing, and tells reviewers what evidence to expect. A practical order for a design review, which is editorial and not OWASP's, is three passes:

1. Authority and inventory first (ASI03, ASI04, ASI02). What can each agent reach, under whose identity, through which tools? Everything else depends on these answers, because they bound the damage of every other risk.
2. Inputs, state, and execution (ASI01, ASI06, ASI05). What untrusted content and stored context can steer the agent, and where does any code it produces run?
3. Coordination and oversight (ASI07, ASI08, ASI09, ASI10). How do agents talk to each other, what contains a failure, can humans see what they are approving, and can you detect and stop an agent that leaves its scope?

The OWASP Top 10 for Agentic Applications as Ten Review Cards

ASI01: Agent Goal Hijack

An attacker redirects what the agent is trying to accomplish, usually through content it reads. EchoLeak (CVE-2025-32711, MSRC advisory) is the best-known case: a crafted email could make Microsoft 365 Copilot exfiltrate data with no user click. It carried a CVSS score of 9.3, Microsoft patched it server-side, and no in-the-wild exploitation was reported.

• Ask: Which untrusted content can reach the agent's context, and what actions become possible once it has read it?
• Look for: Agent Behavior Controls (what an agent may do, in what sequence, against which systems) that authorize each action independently of the model's judgment, narrow tool scope, and approval gates for goal-changing or high-impact actions. Component Input/Output Controls (what passes into and out of a model or tool) can screen content entering the model for injected instructions, but treat that as a signal and not a guarantee. Prediction Guard's guide to prompt injection in production covers the underlying techniques.
• Evidence: A data-flow map of every content source the agent reads, injection test results, and the list of actions that require approval.

ASI02: Tool Misuse and Exploitation

A legitimate tool is used in an unsafe or unintended way, such as chaining a harmless tool with a sensitive API or passing unvalidated output into a powerful command. OWASP's launch materials cite the Amazon Q Developer extension compromise (CVE-2025-8217) as a reference case. In July 2025, a threat actor used an inappropriately scoped GitHub token to commit malicious code that shipped in version 1.84.0. BleepingComputer's report documents the injected prompt, which told the assistant to return a system to a near-factory state and delete file-system and cloud resources, with instructions that other outlets reported extended to bash and AWS CLI commands. AWS's security bulletin says the code was distributed but did not execute because of a syntax error, and that no customer environment was changed. The incident demonstrates how an agent's existing tool access can become dangerous when malicious instructions enter a trusted extension, even though the payload did not execute in this case. The same event is also a supply-chain case (ASI04), a reminder that the categories overlap.

• Ask: What is the worst thing each tool can do with the credentials the agent holds, and what prevents it?
• Look for: Agent Behavior Controls that scope each tool per task, validate parameters, and deny destructive operations by default, plus environment separation. The principle behind these is least agency: the minimum delegated authority over models, tools, APIs, and budgets that a task needs.
• Evidence: A tool inventory with scopes, a list of destructive operations with the control on each, and a test showing a blocked destructive call.

ASI03: Identity and Privilege Abuse

Agents often act with borrowed, over-scoped, or long-lived credentials, so a manipulated agent inherits far more access than its task needs. Cached credentials and delegation chains can be reused or escalated, creating confused-deputy situations.

• Ask: Whose authority does each action run under, and can we prove it afterward?
• Look for: A unique, revocable identity per agent, short-lived scoped credentials, delegated authority traceable to an accountable human where the agent acts for a person, and no shared service credentials.
• Evidence: A credential inventory, the delegation model, and the latest review of each agent's delegated authority.

ASI04: Agentic Supply Chain Vulnerabilities

A tool, server, plugin, model, or dependency the agent loads is compromised. In September 2025, researchers at Koi Security reported the first malicious MCP server in the wild: an npm package impersonating Postmark built trust over fifteen versions, then version 1.0.16 added one line that blind-copied every email to the attacker. The real vendor said it had nothing to do with the package.

• Ask: Which third-party tools, servers, and dependencies can the agent load, and who approved each one?
• Look for: A registry of approved components with a named owner for each, pinned versions, review of tool descriptions and of changes to them, and isolation of third-party servers.
• Evidence: An inventory or AI bill of materials, approval records, and a change log for tool definitions.

ASI05: Unexpected Code Execution (RCE)

Code the agent generates or runs becomes remote or local code execution. CVE-2025-53773, patched in August 2025 by Microsoft, showed the chain: prompt injection in files, web pages, or issues could lead GitHub Copilot to write an auto-approve setting into the workspace configuration, after which commands ran without confirmation.

• Ask: Where does generated code run, with what filesystem, network, and credential access?
• Look for: Containment through isolation such as microVMs, default-deny egress, no ambient credentials, and approval for any change to execution settings. Prediction Guard's guide to agent code execution security pairs runtime controls with isolated execution for this reason.
• Evidence: Sandbox and egress configuration, plus a test showing that generated code cannot reach internal networks or credentials.

ASI06: Memory and Context Poisoning

Corrupted memory or retrieved context skews later decisions, and because it persists, one bad write can affect many sessions. Researcher Johann Rehberger showed the pattern in September 2024 with ChatGPT's memory feature: a prompt injection hidden in a document or web page could write instructions into long-term memory, after which every later conversation, in any new session, quietly sent the user's messages and replies to an attacker-controlled server. OpenAI closed that exfiltration route in a macOS app update, but the underlying risk of untrusted content writing to persistent memory remains. OWASP also identifies the Gemini memory attack, a related persistent-memory injection by the same researcher, as an example of this risk, and the ChatGPT incident illustrates a related persistence and exfiltration pattern. It is a consumer app, and the pattern applies to any agent whose memory is written from content a model reads.

• Ask: What can write to the agent's memory or retrieval stores, and how long does that content persist?
• Look for: Component Input/Output Controls on what is written to memory, memory scoped to a task or tenant, expiry, provenance tags, and a purge procedure that is tested separately from deleting the source conversation. Removing a conversation and purging the persistent memory it created are different operations, and only testing shows whether the second happens.
• Evidence: The memory architecture, retention settings, a test showing what survives when a source conversation is deleted, and a purge test that confirms the entry is gone.

ASI07: Insecure Inter-Agent Communication

Messages between agents are spoofed, replayed, or altered because authentication, integrity, or authorization between agents is weak.

• Ask: How does one agent authenticate another, and what protects messages in transit?
• Look for: Authenticated, integrity-protected channels, network allowlists between agents, and per-agent credentials. Component Input/Output Controls act on what passes into and out of a model or tool, so they do not by themselves secure agent-to-agent transport that never crosses that path.
• Evidence: A communication map of agent-to-agent paths and a test in which a spoofed message is rejected.

ASI08: Cascading Failures

One agent's error or compromise spreads across agents and systems, often at machine speed.

• Ask: If one agent fails or is compromised, what contains the damage?
• Look for: Token and spend enforcement with step limits, circuit breakers, validation at boundaries, isolation between workflows, and containment that can pause or scope down a runaway chain in one action. Scoring blast radius before deployment bounds the damage in advance.
• Evidence: Limit and circuit-breaker settings, results of a failure-injection test, and a blast-radius assessment for each workflow.

ASI09: Human-Agent Trust Exploitation

An agent's apparent authority or confident tone is used to manipulate the person who approves its actions.

• Ask: Does the approver see the real action and its parameters, or only the agent's description of them?
• Look for: Approval screens that show actual parameters and context, independent confirmation for high-impact actions, and attention to approval fatigue.
• Evidence: Screenshots of the approval flow, a sample of approval records, and rejection and override rates.

ASI10: Rogue Agents

An agent deviates from its intended purpose or authorized scope because of compromise, misalignment, or emergent behavior, and keeps acting. OWASP's launch materials associate the reported Replit incident from July 2025 with this entry: during a declared code freeze, an agent reportedly deleted a database in production, and Replit's CEO called the outcome "unacceptable and should never be possible." The freeze was an instruction, not an enforced control, and the company's response included automatic separation of development and production databases. The case also shows how closely rogue behavior and unconstrained tool access are related.

• Ask: Can we detect when an agent leaves its scope, and can we stop it?
• Look for: Agent Behavior Controls that enforce scope while the agent runs, containment (pause, scope down, or revoke) that has been tested, and Immutable Audit Logs tied to each agent's identity. Observability alone only explains what happened, so the stop path matters as much. For what a defensible record contains, see this guide to audit log implementation.
• Evidence: Scope definitions per agent, an Evidence bundle documenting what was attempted, which control acted, and what was contained during a tested intervention such as an automated pause or revoke, and a sample of Immutable Audit Logs.

AI Agent Security Risks: Who Answers What

Reviews stall when nobody owns an answer. These are typical owners, to be adjusted to your organization:

What the Review Should Leave Behind: An Evidence Pack for AI Threat Mitigation

A review that produces only opinions cannot be repeated or audited. Aim for an evidence pack that a second reviewer could use to reach the same conclusions:

The quality of the pack depends on how much of it is generated by systems and not assembled by hand. Records produced at the moment a control acts are more credible than screenshots collected before a review.

What This List Does Not Do for Agentic AI Security

The list is a map, not a guarantee. A few limits are worth keeping in view:

• It is voluntary guidance. Regulatory duties apply by their own scope and are not created by the OWASP list.
• It does not rank risk for your environment. Exposure depends on how your agents are built, which is why the review starts with inventory and authority.
• No single control covers all ten. Coverage comes from stacking controls so that each category has more than one, and some categories, such as inter-agent transport, rely on layers outside a model-path policy.
• Detection is not prevention. Most controls that hold under attack limit what an agent can do, and detection only reports what it did.
• The list will evolve. It is the first edition, so treat the cards as a starting point and revisit them as OWASP and your agents change.

From Application Security Review to Control

For every agent, a review should establish three things: who holds authority, which controls constrain that authority, and what evidence shows those controls work. When each entry on the list has an owner, a control, and evidence you could hand to someone who was not in the room, you have operational control of agents in practice, and not just a catalog of the ways it can fail.

Delivering those controls consistently across a fleet of agents is the role of a sovereign AI control plane: an architecture that identifies, authorizes, enforces, meters, records, and contains agent actions, running inside your boundary. No single layer covers all ten entries, so the review's last question is always where a given architecture stops, and which other layer picks up from there. Ask it of every vendor, Prediction Guard included.

Frequently Asked Questions About the OWASP Top 10 for Agentic Applications

1. What is the OWASP Top 10 for Agentic Applications?

It is a voluntary, community-developed list from the OWASP GenAI Security Project, published in December 2025, that names ten risks specific to agentic systems, from ASI01 Agent Goal Hijack to ASI10 Rogue Agents. Each entry carries a description, common examples, attack scenarios, and prevention guidance.

2. How should security architects use the OWASP Top 10 for Agentic Applications in a design review?

Turn each entry into a question a team must answer, an artifact it must produce, and an owner who signs off. A practical order is three passes: authority and inventory first, then inputs, state, and execution, then coordination and oversight.

3. Which AI agent security risks should a review cover first?

Start with authority and inventory (ASI03, ASI04, ASI02), because what each agent can reach, under whose identity, and through which tools bounds the damage of every other risk. The OWASP list does not rank its entries by likelihood, so exposure depends on how your own agents are built.

4. What evidence should an agentic AI security review leave behind?

A registry of agents, tools, servers, and dependencies with owners, a credential and delegation map, data-flow diagrams for untrusted content and memory, test results, exported control configuration, approval records, samples of Immutable Audit Logs, an Evidence bundle for each tested intervention, and a register of open risks.

5. Is the OWASP list a compliance requirement?

No. It is voluntary guidance, and regulatory duties apply by their own scope. It is best used to feed threat modeling, scope testing, and show reviewers what evidence to expect.