The OWASP GenAI Security Project published the OWASP Top 10 for Agentic Applications on December 9, 2025, the first OWASP flagship list built specifically for autonomous AI agents. It runs from ASI01 (Agent Goal Hijack) to ASI10 (Rogue Agents), and it is already the reference every security buyer points a vendor at. The list does one job well: it names the risks. It does not answer the question a team actually has before shipping an agent.
That question is simple. What does the OWASP Agentic AI Top 10 mean for a security test, and what should I require from a vendor? Here is the short answer. Roughly half of the ten items are direct exploit targets that a penetration test can prove by reproducing the attack. The other half are architecture and governance controls that a test can validate but cannot manufacture. A vendor who quotes a flat "we cover the OWASP Agentic Top 10" is either testing things that are not testable or governing things they never touched. You need the crosswalk below: which item is pentest-testable, which is a governance control, and whether a human red teamer or an autonomous agent should lead each check.
This is becoming procurement language, not just a research artifact. NIST's Center for AI Standards and Innovation (CAISI) announced the AI Agent Standards Initiative on February 17, 2026, organized around industry-led standards, open-source protocols, and research into AI agent security and identity. Buyers who can articulate coverage precisely will get better tests. This post is the buyer checklist for that conversation.
TL;DR
The list, in one line. OWASP's Agentic Top 10 (ASI01 to ASI10) names the risks of autonomous agents. It does not tell a buyer what a test can prove versus what only architecture and governance can control.
Pentest-testable, roughly half. Agent goal hijack (ASI01), tool misuse (ASI02), identity and privilege abuse (ASI03), unexpected code execution (ASI05), and memory poisoning (ASI06) are exploit paths a test can reproduce and prove.
Governance-heavy, roughly half. Agentic supply chain (ASI04), insecure inter-agent communication (ASI07), cascading failures (ASI08), human-agent trust exploitation (ASI09), and rogue agents (ASI10) are dominated by architecture and monitoring that a test validates rather than creates.
Human versus autonomous split. An autonomous web-application agent is strongest on the authorization flaws around tool-calling endpoints (parts of ASI02, ASI03, and ASI05). Human red teamers own planning, prompt-injection scenarios, memory poisoning, inter-agent orchestration, and rogue-agent simulation.
What to demand. An ASI-mapped scope, an explicit pentest-testable-versus-governance label per item, a human-plus-autonomous coverage statement, and a retest cadence that matches how often your agent changes.
Key takeaways
A single "we cover OWASP Agentic Top 10" line is a warning sign, not a reassurance. A credible scope tells you which items it proves by exploitation and which it only assesses against your architecture and monitoring.
The testable core sits around tool-calling endpoints. When an agent calls tools and APIs, the classic web failures reappear: broken object-level authorization, business-logic abuse, and command execution. This part behaves like a modern application pentest, and it is where an autonomous agent adds the most leverage.
The governance-heavy items still need a human red teamer, not a scanner. Inter-agent spoofing, cascading failure, and rogue-agent behavior are scenario work that needs someone to design the abuse case.
Coverage should be labeled honestly per item. The most useful deliverable is not a pass or fail grid. It is a per-item statement of what was tested, what was assessed, and what the buyer still owns as a gap.
Agents change weekly, so cadence is part of scope. A one-time test of a prompt, tool list, and memory policy that all shifted last sprint is already stale. Recurring testing is the honest match for how agentic systems evolve.
How to read this checklist: pentest-testable versus governance control
Two labels do the heavy lifting in the crosswalk.
Pentest-testable means a tester can attempt the attack against your running system and prove the outcome. The evidence is a reproduction: an injected instruction that changed the agent's goal, a tool call that reached data it should not, a request under the agent's identity that crossed a tenant boundary, a payload that executed code. Success is a finding with a proof of concept; a serious failed effort is earned assurance.
Governance control means the risk is reduced primarily by how the system is designed, operated, and monitored, not by whether a single exploit lands. Supply-chain provenance for third-party tools and Model Context Protocol (MCP) servers, mutual authentication between agents, blast-radius limits, and behavioral monitoring are architecture and process. A test can validate that these controls exist and probe their edges, but it cannot substitute for building them.
Most real items are a blend, and the crosswalk says so. The labels stop a test from overclaiming. "ASI10 Rogue Agents: passed" after a two-week engagement describes monitoring the vendor did not build. "ASI10: validated your kill-switch and scope enforcement against three deviation scenarios, and flagged two monitoring gaps you own" is the honest version.
The human-versus-autonomous column is the second axis. An autonomous web-application testing agent is purpose-built for the exploit paths that look like application and API testing, especially broken authorization and business-logic flaws around the endpoints an agent's tools call. Human red teamers own the parts that need adversary planning: goal-hijack scenarios, memory poisoning, spoofed inter-agent messages, and rogue-agent simulation. The strongest coverage uses both, with senior humans validating and extending what the autonomous agent surfaces.
The OWASP Agentic AI Top 10 test-coverage crosswalk
The table below is the core of this post. For each ASI item it gives the plain-language meaning, the coverage label, and who should lead the test. Titles follow OWASP's canonical wording for the 2026 list.
Risk | What it means for a buyer | Coverage type | Who leads the test |
|---|---|---|---|
ASI01 Agent Goal Hijack | Injected input redirects the agent from its real objective to an attacker's instructions. | Pentest-testable | Human red team, autonomous assist |
ASI02 Tool Misuse | The agent uses a legitimate tool or API in an unsafe way to exfiltrate data or hijack a workflow. | Pentest-testable | Autonomous plus human |
ASI03 Identity and Privilege Abuse | The agent acts beyond its scope, reuses stale credentials, or inherits too much access. | Both: exploit path plus identity governance | Autonomous plus human |
ASI04 Agentic Supply Chain Vulnerabilities | Third-party agents, tools, MCP servers, or prompt templates are malicious or tampered with. | Mostly governance; test validates specific components | Human, component assessment |
ASI05 Unexpected Code Execution | The agent generates and runs code or commands that let an attacker take over the host. | Pentest-testable | Autonomous plus human |
ASI06 Memory and Context Poisoning | Planted data in memory or retrieval steers the agent's later decisions. | Pentest-testable | Human red team |
ASI07 Insecure Inter-Agent Communication | Agent-to-agent messages lack authentication or integrity, enabling spoofing or interception. | Both: protocol governance plus validation | Human red team |
ASI08 Cascading Failures | One fault propagates and amplifies across a network of agents. | Mostly architecture and governance; red team simulates | Human red team |
ASI09 Human-Agent Trust Exploitation | The agent's persuasive, human-like output manipulates a person into an unsafe action. | Both: social-engineering test plus UX governance | Human red team |
ASI10 Rogue Agents | A compromised or misaligned agent operates outside its scope or pursues hidden goals. | Mostly governance and monitoring; red team validates | Human red team |
The autonomous-led core: ASI02, ASI03, ASI05
When an agent calls a tool, it makes a request to an API, a database, a shell, or another service, and that request has an identity, a scope, and parameters an attacker can influence. This is where agentic risk collapses back into familiar application and API security, the most directly testable part of the list.
Tool misuse (ASI02) and the exploit side of identity and privilege abuse (ASI03) are, in practice, broken object-level authorization and business-logic abuse against tool-calling endpoints. Can the agent be steered to fetch another tenant's record through a tool? Does a tool run with a broader token than the user's session justifies? Unexpected code execution (ASI05) is the agent version of remote code execution: a tool or code-interpreter path that turns generated output into commands. These are exactly the high-impact classes an autonomous web-application testing agent is built to hunt, and they reward automated probing followed by human validation. This is where AI-driven application penetration testing earns its keep.
The human-led core: ASI01, ASI06, ASI07, ASI08, ASI09, ASI10
The rest of the list needs an adversary's plan more than a scanner's signature. Goal hijack (ASI01) is scenario design: what untrusted content reaches the agent, and does it change behavior. Memory and context poisoning (ASI06) means understanding your memory or retrieval architecture, planting data, and proving it persists into a later decision. Insecure inter-agent communication (ASI07) and cascading failures (ASI08) are multi-agent orchestration problems, tested by spoofing messages and by forcing a fault to see how far it spreads. Human-agent trust exploitation (ASI09) is social engineering routed through the agent's interface. Rogue agents (ASI10) is validated by simulating deviation and checking whether monitoring, scope enforcement, and a kill switch catch it. These are the domains where experienced red teaming does the work automation cannot.
Where each risk lives: the agent test-surface map
A useful way to scope an agent test is to map each risk to the layer of the stack where it lives, because that is where the test has to reach.
Goal and prompt layer: ASI01 goal hijack. Untrusted input meets the agent's instructions here.
Tool and MCP layer: ASI02 tool misuse, ASI04 supply chain, and the execution surface of ASI05. Every tool and MCP server is an authorization boundary and a dependency.
Identity layer: ASI03 identity and privilege abuse. The credentials and scopes the agent carries into every action.
Memory layer: ASI06 memory and context poisoning. Persistent state that outlives a single request.
Inter-agent layer: ASI07 insecure communication and ASI08 cascading failures. The messages and dependencies between agents.
Human interface layer: ASI09 trust exploitation, with ASI10 rogue behavior spanning every layer at once.
Scoping by layer forces the honest questions. If your agent has no memory store, ASI06 is not in scope and no one should bill you for it. If it orchestrates five sub-agents over a message bus, ASI07 and ASI08 are central and a single-agent test misses them entirely. A vendor who cannot map their proposed tests to your actual architecture is selling a template.
What to demand from a vendor before you ship
Use this as the checklist when you evaluate an agentic AI security test. A strong provider says yes to all six without hedging.
An ASI-mapped scope with honest labels. The proposal should list ASI01 to ASI10 and mark each as tested by exploitation, assessed against architecture, or out of scope for your system. Reject any scope that claims to "cover" all ten as testable findings.
A human-plus-autonomous coverage statement. The vendor should name which items an autonomous agent probes (the tool-calling authorization and execution surface) and which senior humans lead (goal hijack, memory, inter-agent, rogue behavior). One without the other leaves gaps.
Real tool-calling authorization testing. Ask specifically how they test broken object-level authorization and business-logic abuse across the agent's tools and MCP servers. This is the highest-impact testable surface and the one generic scanners miss.
Memory and inter-agent testing when they apply. If your agent has persistent memory or orchestrates other agents, the vendor must be able to poison a memory store and prove persistence, and to spoof or intercept inter-agent messages.
A retest cadence matched to change. Agents change weekly as prompts, tools, and policies evolve. A one-time report is a snapshot of a system that no longer exists. Continuous or recurring testing is the honest model for production agents.
A governance-gap section, not just findings. The report should tell you plainly which risks remain your architecture and monitoring responsibility, so ASI04, ASI08, and ASI10 are handed back to you as owned controls rather than quietly marked green.
What this means for teams shipping agents
The OWASP list is a strong shared vocabulary, and the NIST initiative signals it is becoming procurement language. The gap it leaves is coverage clarity, and that gap is a buyer's job to close before signing a test.
Stingrai's approach reflects the split in the crosswalk. Snipe, Stingrai's autonomous agent for web-application penetration testing, is purpose-built to hunt the complex classes that show up around tool-calling endpoints: broken object-level authorization, broken access control, and business-logic flaws, the exploit core of ASI02, ASI03, and ASI05. It runs black-box dynamic testing and white-box code review, and it can act as a pull-request gating check on the code that builds your agent. Senior red teamers own the scenario work the list demands, from goal-hijack design and memory poisoning to inter-agent orchestration and rogue-agent simulation, validating and extending what the autonomous agent surfaces. For agents that change every sprint, continuous red teaming keeps the test current instead of freezing it at one release. That same testing produces the evidence your SOC 2, ISO 27001, and PCI DSS compliance program needs to show an auditor the agent was assessed against a named standard. The Stingrai pricing page lays out the PTaaS tiers.
Frequently Asked Questions
What is the OWASP Agentic AI Top 10 and what should I require from a security vendor?
The OWASP Top 10 for Agentic Applications (ASI01 to ASI10) is a list of the most critical security risks for autonomous AI agents, published by the OWASP GenAI Security Project on December 9, 2025. From a vendor, require a scope that maps each of the ten items to your architecture and labels it as tested by exploitation, assessed as a governance control, or out of scope, rather than a blanket claim to "cover" all ten.
Which OWASP Agentic Top 10 items can a penetration test actually prove?
The directly pentest-testable items are agent goal hijack (ASI01), tool misuse (ASI02), the exploit path of identity and privilege abuse (ASI03), unexpected code execution (ASI05), and memory and context poisoning (ASI06). These are attacks a tester can reproduce and demonstrate with a proof of concept against your running agent.
Which items are governance or architecture controls rather than test findings?
Agentic supply chain vulnerabilities (ASI04), insecure inter-agent communication (ASI07), cascading failures (ASI08), and rogue agents (ASI10) are dominated by design, monitoring, and process. A test can validate that the controls exist and probe their edges, but it cannot create them, so these should be reported as owned controls and gaps, not as simple pass or fail results.
Can an autonomous AI agent test all ten OWASP agentic risks on its own?
No. An autonomous web-application testing agent is strongest on the authorization and execution flaws around tool-calling endpoints, which covers the exploit core of ASI02, ASI03, and ASI05. Goal-hijack scenarios, memory poisoning, inter-agent orchestration, and rogue-agent simulation need human red teamers to design and drive, which is why the strongest coverage is a hybrid.
How do I test an AI agent for broken authorization?
Broken authorization in an agent shows up around the tools and APIs it calls. A tester checks whether the agent can be steered to access another tenant's or user's data through a tool, whether tools run with a broader token than the session justifies, and whether business logic can be abused across multiple tool calls. It is broken object-level authorization and access-control testing applied to the agent's tool-calling surface.
What is ASI05 Unexpected Code Execution and how is it tested?
ASI05 is the risk that an agent generates and runs code or commands that let an attacker take over the host, the agentic form of remote code execution. It is tested by probing code-interpreter and command-running tools, and any path where generated output becomes an executed instruction, then attempting to escalate into control of the underlying system.
How often should an agentic AI system be tested?
Match the cadence to how fast the agent changes. Because prompts, tool lists, memory policies, and connected agents often shift every sprint, a one-time test quickly goes stale. Recurring or continuous testing keeps coverage aligned with the version that is actually in production.
Does the NIST AI Agent Standards Initiative change what I need to test?
Not the mechanics, but the expectation. NIST's CAISI announced the AI Agent Standards Initiative on February 17, 2026, focused on agent standards, open-source protocols, and security and identity research. It signals that stating ASI coverage precisely will increasingly be expected in vendor and audit conversations.
What is the difference between agentic red teaming and an agentic AI pentest?
An agentic AI pentest is scoped to prove specific exploit paths, especially the authorization and execution flaws around tool-calling endpoints, and to produce reproducible findings. Agentic red teaming is broader scenario work: goal hijack, memory poisoning, inter-agent spoofing, trust exploitation, and rogue-agent simulation. Most programs need both, with the pentest anchoring the testable core and the red team covering the human-led scenarios.
Where can I get the OWASP Agentic AI Top 10 and related guidance?
The list is published by the OWASP GenAI Security Project and was released on December 9, 2025, with the NIST AI Agent Standards Initiative adding federal direction from February 2026. Both are linked in the references below, alongside Stingrai guidance on autonomous-versus-human agent testing and on assessing MCP servers.
References
OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications (2026). Released December 9, 2025. https://genai.owasp.org/resource/owasp-top-10-for-agentic-applications-for-2026/. The first OWASP flagship list built specifically for autonomous AI agents, enumerating ASI01 through ASI10 with definitions and mitigations.
OWASP GenAI Security Project. OWASP Top 10 for Agentic Applications: The Benchmark for Agentic Security in the Age of Autonomous AI. December 9, 2025. https://genai.owasp.org/2025/12/09/owasp-top-10-for-agentic-applications-the-benchmark-for-agentic-security-in-the-age-of-autonomous-ai/. Announcement post summarizing the ten categories and the peer-review process behind the list.
NIST (Center for AI Standards and Innovation). Announcing the AI Agent Standards Initiative for Interoperable and Secure Innovation. February 17, 2026. https://www.nist.gov/news-events/news/2026/02/announcing-ai-agent-standards-initiative-interoperable-and-secure. Launch of the federal initiative organized around industry-led standards, open-source protocols, and AI agent security and identity research.
Stingrai. AI Red Teaming for LLM and Agentic Apps (2026). https://www.stingrai.io/blog/ai-red-teaming-llm-agentic-apps-2026. Companion guide on scoping red-team scenarios for language-model and agentic systems.
Stingrai. Agentic AI Pentesting (2026). https://www.stingrai.io/blog/agentic-ai-pentesting-2026. Deeper walkthrough of the autonomous-versus-human division in testing agentic applications.
Stingrai. MCP Server Security Assessment. https://www.stingrai.io/blog/mcp-server-security-assessment. How to assess the Model Context Protocol servers and tools an agent depends on, relevant to ASI02 and ASI04.
