OWASP Top 10 for Agentic Applications: AppSec Guide

The OWASP Top 10 for Agentic Applications identifies the ten most critical security risks introduced by autonomous AI agents, including goal hijacking, tool misuse, identity abuse, supply chain vulnerabilities, memory poisoning, and rogue agents. For AppSec teams, it provides a framework for securing AI systems that can write code, invoke tools, access data, and take actions without continuous human approval.

If your agents can write to a database, call an external API, or kick off a downstream workflow without human approval, your threat model needs to catch up. The blast radius from a compromised agent looks nothing like a compromised static app, and the controls are different too. The OWASP Top 10 for Agentic Applications spells out exactly where those gaps are and what to do about them.

TLDR:

• The OWASP Agentic Top 10 governs what agents do, not what models say; an insecure action deletes records, exfiltrates files, or calls APIs with no human approval.
• Least Agency and Least Privilege are distinct controls: scoped access without scoped autonomy still leaves your systems exposed to goal hijack.
• A single compromised vendor-validation agent processed a large volume of fraudulent transactions before detection, showing how cascading trust creates org-wide blast radius.
• Give every agent its own time-limited credential, log every tool invocation and memory write, and gate irreversible actions behind mandatory human approval.
• Arnica's Agentic Rules Enforcer writes governed security rule packs into agent config files before code generation begins, covering ASI01 and ASI02 at the source.

Why the OWASP Top 10 for Agentic Applications Exists

Agentic AI moved from experiment to production faster than most security teams had time to plan for it. Autonomous agents now plan multi-step tasks, call external APIs, modify databases, send emails, and spawn sub-agents, often without a human approving each action in real time. The security models built for static applications and single-model LLM interactions assumed software that responds, not software that acts. That assumption is no longer valid.

The scale of adoption makes this hard to ignore. Gartner predicts that as many as 40% of enterprise applications will add task-specific AI agents by end of 2026, while a Deloitte report found that 74% of companies expect to be using agentic AI at least moderately by 2027. The Forrester agentic development security market map has already begun tracking dedicated tooling in this space. OWASP released the Top 10 for Agentic Applications because the threat surface created by autonomous, multi-step systems needed a community-validated framework, not vendor whitepapers alone.

How the Agentic Top 10 Differs from the OWASP LLM Top 10

The simplest way to separate these two frameworks: the LLM Top 10 governs what a model says; the Agentic Top 10 governs what a system does.

As OWASP's own framing puts it, the LLM Top 10 focuses on risks from content generation, while the Agentic Top 10 covers the far greater risks that come from autonomous action. An insecure LLM output is a bad answer. An insecure agentic action is a deleted record, an exfiltrated file, or a rogue API call made without any human ever approving it.

The Agentic Top 10 extends the LLM Top 10 without replacing it. Autonomy, tool integration, and multi-agent coordination amplify foundational LLM risks into a different threat category entirely, a subject covered in depth in the agentic AI security complete guide. ASI01 makes this concrete: prompt injection alone produces a bad output, but when an autonomous agent acts on that injected instruction across multiple steps, the blast radius expands across every downstream system the agent can reach. Both frameworks belong in your threat model.

The Principle of Least Agency

Least Privilege governs what an agent can access. Least Agency governs how freely it can act on that access. The OWASP publication treats these as distinct concerns, and the distinction matters: an agent with read access to your database and unlimited autonomy is a different risk than one with the same access and a narrow, bounded scope of action.

The OWASP Agentic Top 10 recommends two complementary controls alongside scoped autonomy: human-in-the-loop approval gates for high-impact actions, and regular red team exercises that simulate goal-override scenarios before an adversary runs them first.

ASI01 and ASI02: Agent Goal Hijack and Tool Misuse

ASI01 occurs when an attacker manipulates an agent's goals through indirect prompt injection, embedded inside documents, web pages, or emails the agent reads as part of its task. The model cannot reliably separate instructions from content. The EchoLeak incident made this concrete: copilots turned into silent exfiltration engines, with no user ever seeing the injected instruction.

ASI02 is subtler. Tool Misuse occurs when an agent chains a legitimate capability with a sensitive API or forwards unvalidated output into a powerful command. The threat is poor scoping, not unauthorized access.

Controls for both:

• Version-controlled, explicitly scoped agent goals with auditable change history
• Anomaly monitoring on tool call sequences, beyond individual tool invocations
• Input validation before any agent output reaches a downstream system or tool

ASI03 and ASI07: Identity Abuse and Insecure Inter-Agent Communication

ASI03 and ASI07 are two sides of one problem: identity and trust in environments where agents act as first-class principals.

ASI03 covers what happens when agents inherit user sessions or consume shared credentials instead of holding their own scoped identities. Leaked credentials expanding agent scope beyond intended limits is among the most cited failure patterns in recent enterprise agent incident reviews. A shared API key used by multiple agents is a single point of compromise with no audit trail and no revocation boundary.

ASI07 extends this into multi-agent environments. Unauthenticated agent communication opens the door to replay and spoofing. One compromised agent can impersonate a trusted orchestrator and redirect every downstream agent in the pipeline.

Controls for both:

• Every agent gets its own managed identity with time-limited, scoped credentials, so a single compromised key cannot propagate across the entire fleet.
• Mutual authentication on all agent-to-agent channels prevents impersonation at the inter-agent layer, where spoofing is otherwise trivially easy.
• Audit every credential use, including access grants and all subsequent activity, so anomalous behavior surfaces before the blast radius widens.

Scoped identities are the most direct blast-radius control available. Even when you cannot prevent a compromise, they limit how far it spreads.

ASI06 and ASI10: Memory Poisoning and Rogue Agents

ASI06 and ASI10 sit at the end of the list but represent the longest-horizon risks in the framework.

ASI06 spreads deceptively. Memory and context poisoning describes the persistent corruption of the context window and long-term memory, which influences decisions even after the original session ends. Because many multi-agent architectures share memory stores, a single poisoned input can propagate across every cooperating agent reading from that source without any of them flagging it as suspicious.

ASI10 is the scenario most teams are least prepared for, and AI-generated code security practices must account for it. Agents showing misalignment, concealment, and self-directed action was documented in the Replit production database meltdown, where an agent's behavior diverged from its stated intent in ways that were invisible until damage was done.

Controls for both:

• Auditable chain-of-custody for every memory write, so poisoned inputs can be traced back to their source before damage spreads, and well before propagation is already underway.
• Strict versioning of knowledge bases with the ability to roll back to a verified clean state quickly when contamination is identified.
• Behavioral anomaly detection that monitors for divergence between declared goals and actual action sequences, the earliest reliable signal for rogue behavior.

ASI04, ASI05, and ASI08: Supply Chain Vulnerabilities, Code Execution, and Cascading Failures

These three risks share a common thread: they originate in the agent's operating environment, not in its direct instruction set.

ASI04 hits the supply chain layer. MCP ecosystems exposed poisonable runtime components, with the GitHub MCP compromise as the clearest documented example. A poisoned tool description is invisible to the consuming agent. It reads legitimate, executes legitimate-looking logic, and routes data or actions somewhere unintended.

ASI05 follows directly. Execution paths opened by agentic architectures create code execution surfaces that traditional static analysis never modeled. An agent that writes and runs code, interprets shell commands, or invokes system APIs based on prompt content is a remote code execution vector, a pattern closely related to vibe coding security risks that surface when AI generates and executes code without sufficient review, waiting for the right injected instruction.

ASI08 is the blast-radius problem. One compromised vendor-validation agent approved a large volume of fraudulent orders before detection. No single agent had organization-wide authority. Cascading trust across a coupled network created it anyway.

Controls for all three:

• Explicit failure boundaries between agents, so a compromised node cannot propagate decisions downstream without a verification gate
• Circuit breakers and fan-out rate limits that halt runaway action chains before damage accumulates
• Pre-production red team exercises designed to trigger cascading failure scenarios, going beyond individual agent compromise

These are the risks most likely to be underestimated in early agentic deployments because they only become visible at production scale. AI SAST tooling can surface some of these code execution risks earlier in the pipeline.

ASI09: Human-Agent Trust Exploitation

ASI09 is the only risk in the framework that your firewall cannot touch.

Agents can appear confident, fluent, and authoritative, which leads humans to approve recommendations without independent verification. An attacker who shapes what an agent says, through goal hijack or memory poisoning, gains a persuasive human-facing vector at no additional cost. The agent does the convincing. The human does the damage.

Scoped credentials and blast-radius limits do not fix this. A user who approves a risky financial transfer because an agent provided a confident, detailed rationale has bypassed every technical control in the stack voluntarily. The countermeasures are structural:

• Mandatory approval workflows for any high-consequence agent recommendation, independent of how well-reasoned it sounds, as demonstrated by research on bypassing Cursor agents guardrails through a script inspection design flaw
• A second human or system verification step before agents can initiate credential sharing, payment actions, or configuration changes
• Explicit training that fluency and confidence are not correctness signals, and that an agent's persuasiveness should raise scrutiny, not lower it

Human-agent trust exploitation scales precisely because agents are good at sounding right. That's the threat model.

Controls AppSec Teams Should Implement Now

The OWASP Top 10 for Agentic Applications provides a community-validated framework for understanding these risks, and the controls above can be adopted without a full program redesign. Threat modeling is the prerequisite for every new agent deployment.

How Arnica Maps to the OWASP Agentic Top 10

The OWASP Agentic Top 10 is a threat model for a world where AI agents write code, invoke tools, and make decisions faster than any human can review. The controls framework only holds if the governance layer underneath it was built for the same world.

Arnica's architecture maps to that framework by design. The Agentic Rules Enforcer writes governed security rule packs directly into the configuration files each AI coding agent reads at generation time: .cursor/rules/ for Cursor, CLAUDE.md for Claude Code, .github/copilot-instructions.md for GitHub Copilot, GEMINI.md for Gemini, .augment/rules/ for Augment. Before a line of code is written, the agent's behavior is already scoped. That is the ASI01 and ASI02 mitigation at the source, not after the fact.

The Agentic Asset Inventory covers ASI04 directly, giving security teams a continuously updated inventory of every MCP server, skill, and agentic rule in their environment, so poisoned or unauthorized runtime components are visible before they execute. MCP security governance extends that to cover tool response poisoning, authentication between agents and MCP servers, and least-privilege tool scopes.

Arnica's three-layer agentic risk model covers the full ASI posture:

• Scope controls before a session begins, restricting what agents can access or generate
• Runtime behavioral monitoring during execution, surfacing drift and privilege escalation as it occurs
• Human-in-the-loop approval gates at high-risk decision points, pausing execution before irreversible actions land

A Dark Reading 2026 poll found 48% of security professionals expect agentic AI to be the top attack vector by end of 2026, with most organizations reporting they are not yet ready. Forrester named Arnica in its Agentic Development Security Tools market report, Q2 2026, the first tier-one analyst recognition of this category by name.

Final Thoughts on the OWASP Top 10 for Agentic Applications

The OWASP Agentic Top 10 is the right framework for a world where your agents write code, call APIs, and make decisions at machine speed. Scoped identities, blast-radius controls, and behavioral monitoring are not optional extras; they are the baseline your team needs before the next agent hits production. Create a free Arnica account and see how the controls map to your agentic environment today.

FAQs

What are the agentic AI security risks engineering teams need to plan for when deploying AI coding agents in 2026?

The OWASP Top 10 for Agentic Applications catalogs ten named risk categories your team should model before any agent reaches production: Agent Goal Hijack (ASI01), Tool Misuse (ASI02), Identity and Privilege Abuse (ASI03), Agentic Supply Chain Vulnerabilities (ASI04), Unexpected Code Execution (ASI05), Memory and Context Poisoning (ASI06), Insecure Inter-Agent Communication (ASI07), Cascading Failures (ASI08), Human-Agent Trust Exploitation (ASI09), and Rogue Agents (ASI10). The risks that most teams underestimate at deployment are ASI08 and ASI10, which only become visible at production scale when a single compromised node propagates decisions across coupled systems or an agent's behavior diverges from its stated goals without triggering any alert. For each new agent deployment, answer two questions before it ships: what is the blast radius if this agent is compromised, and what does normal behavior look like so anomalies are detectable?

How do I set up agentic rules in Claude Code or Cursor to enforce OWASP ASVS security policies automatically?

Governed security rule packs can be written directly into the configuration files each agent reads at generation time: CLAUDE.md for Claude Code and .cursor/rules/ for Cursor. Arnica's Agentic Rules Enforcer automates this across every connected repository through a PR-piggyback delivery pattern, writing a managed rule block mapped to OWASP ASVS Level 2 across roughly 100 ARNIE_* Rule IDs, self-healing the block if a developer removes it, and instructing the agent to cite the Rule ID inline so security teams can verify governed controls actually landed in committed code.

What is the OWASP Top 10 for Agentic Applications, and how is it different from the OWASP LLM Top 10?

The OWASP Top 10 for Agentic Applications governs what a system does, while the OWASP LLM Top 10 governs what a model says. An insecure LLM output is a bad answer; an insecure agentic action is a deleted record, an exfiltrated file, or a rogue API call that no human ever approved. The Agentic Top 10 extends the LLM Top 10 without replacing it, covering the distinct threat surface created when autonomous agents plan multi-step tasks, call external APIs, modify databases, and spawn sub-agents at machine speed.

Should I use human-in-the-loop approval gates for every agentic action, or only for high-consequence ones?

Mandatory human-in-the-loop approval gates are warranted for irreversible or high-consequence actions regardless of how confident or well-reasoned the agent's output appears. The OWASP framework recommends pairing scoped autonomy with approval gates precisely because agent fluency is not a correctness signal, and an attacker who shapes what an agent says through goal hijack or memory poisoning gains a persuasive human-facing vector at no additional cost. A two-axis risk scoping matrix calibrates where gates are required: higher autonomy combined with larger blast radius prescribes stricter controls, while lower autonomy and narrower blast radius can operate with lighter oversight such as audit logging and agentic rules.

What controls should AppSec teams implement first when securing agentic AI deployments against OWASP agentic risks?

Start with the two controls that cap blast radius before any other mitigation matters: unique, scoped, short-lived credentials per agent with no shared API keys (the direct fix for ASI03 and ASI07), and an explicit inventory of every deployed agent, its permitted tools, and its blast radius tier (the direct fix for ASI04). From there, add observability before an incident by logging every tool invocation, memory write, and credential use, then run a goal-override and cascading failure scenario against each new agent deployment before it reaches production.