OWASP LLM Top 10 vs OWASP Agentic Top 10

OWASP LLM Top 10 vs OWASP Agentic Top 10: which list should set your test scope

Your team has a chat, retrieval or agent system on the roadmap and needs to decide which list defines the test. The LLM Top 10 (2026 edition, published August 2026) fits applications that mainly return text to a user, such as a support chatbot or a document question-answering tool that reads from a vector store but cannot act on anything. The *OWASP Top 10 for Agentic Applications for 2026*, released on 9 December 2025, fits systems that plan multi-step work, call tools, hold identities and pass messages to other agents. Most production systems with tools need both lists, because an agent is still an LLM application with a larger attack surface.

The two lists overlap but do not map cleanly. Prompt injection appears in the LLM list as LLM01, while the agentic list adds Agent Goal Hijack (ASI01) and Tool Misuse (ASI02), which describe what happens after injected input reaches a tool. Excessive Agency is LLM03 in the 2026 LLM edition, and the agentic list splits that concern into Identity and Privilege Abuse (ASI03) and Rogue Agents (ASI10). Ask your team to write down every tool, credential and downstream agent the system can reach, then check each item against both lists. Confirm the exact mappings in each list's own documents before you cite them in a report.

Decide who owns the choice. The security architect who owns the threat model should set the scope, with the product owner and the team that holds the agent's credentials signing off. If the system uses the Model Context Protocol, confirm with the tester whether the MCP authorization issues are in scope, since they sit between the two lists. Put the chosen lists, the tool inventory and the identity model into the written scope before a quote is requested, so the tester prices the agent's actions, not just its prompts.

How the two lists differ on scope, risk focus and test inputs

This table compares the OWASP LLM Top 10 and the OWASP Top 10 for Agentic Applications factor by factor, from the system each describes to the environment a test needs. Read each row as a question about your own system: if it calls tools, holds identities or delegates to other agents, the agentic list asks questions the LLM list does not. Confirm every mapping against the source documents before you cite it.

Factor	OWASP LLM Top 10 (2026)	OWASP Agentic Top 10 (2026)
System described	LLM-based applications that take prompts and return output, including retrieval and plugin features	Autonomous agents that plan, call tools, hold identities and act across systems
Release date	Published August 2026	Released 9 December 2025
Number and naming of entries	Ten entries, LLM01 to LLM10, such as LLM01 Prompt Injection and LLM10 Improper Output Handling	Ten entries, ASI01 to ASI10, such as ASI01 Agent Goal Hijack and ASI10 Rogue Agents
Unit of risk	The model-backed application and the data and outputs it produces	The agent as an actor, including its goals, tools, memory and permissions
Action risk	Excessive Agency sits at LLM03, a risk that grows once the model can act	Tool Misuse (ASI02) and Unexpected Code Execution (ASI05) are first-class entries
Identity assumptions	Identity appears mainly through data access and output handling	Identity and Privilege Abuse (ASI03) treats delegated and inherited credentials as the central concern
Multi-agent coverage	Largely out of scope as a separate concern	Insecure Inter-Agent Communication (ASI07) and Cascading Failures (ASI08) cover agent-to-agent chains
Memory and context	Hidden Context Exposure (LLM08) and Vector and Embedding Weaknesses (LLM09)	Memory and Context Poisoning (ASI06) covers persistent state that agents reuse across tasks
Test environment needed	A model endpoint, the application and its data stores, with prompts and retrieval sources under your control	A sandboxed agent runtime with test identities, tool stubs or sandboxed tools, and logging of every action
Mapping to other references	Mappings to NIST, MITRE ATLAS and CWE are expanded in the 2026 edition	Confirm mappings to ATLAS and NIST in the agentic document before you cite them
Scope driver for a test	Start here if your system answers users without calling tools on their behalf	Start here if your system takes actions, holds credentials or talks to other agents

What a scope built from either list leaves out

A scope built only from the OWASP Top 10 for LLM Applications 2026 will tend to concentrate on the model-facing application, and that leaves permission sprawl across tool connectors, agent identities and inter-agent trust largely untested. LLM03 Excessive Agency is in the list, but it is one entry describing a symptom. A test built on it still needs someone to enumerate every MCP server, plugin, API key and service account the agent can reach, check whether each grant is scoped to the task, and confirm who can change those grants. Ask the engagement team to name the identities each agent runs under and the trust relationships between agents, because the LLM list does not give those a dedicated category.

A scope built only from the OWASP Top 10 for Agentic Applications for 2026 has the opposite gap. Its ASI entries focus on what the agent does, so output handling, sensitive data exposure and resource limits can slip through. Check whether model output is rendered, executed or passed to downstream parsers without validation (LLM10 Improper Output Handling), whether system prompts, retrieved documents or memory stores expose credentials or personal data (LLM02 Sensitive Information Disclosure and LLM08 Hidden Context Exposure), and whether requests, tokens or agent loops have hard limits (LLM06 Unbounded Consumption). Agentic scopes that skip these checks often miss the cheapest route to data loss.

Neither list replaces standard web, API and infrastructure testing. Injected content still reaches the application through ordinary HTTP endpoints, and the authorization logic in those endpoints still governs what an agent may touch, so a conventional application and API test remains necessary. For reporting, map each finding to MITRE ATLAS technique IDs such as AML.T0051.001 (indirect prompt injection) and AML.T0133 (Discover AI Agent Runtime Capabilities), both in ATLAS v2026.09, so that the work connects to adversary behavior. Confirm the ATLAS mapping for each finding against the ATLAS data release before you publish it.

Where the OWASP LLM Top 10 and Agentic Top 10 overlap

The two 2026 lists share a set of underlying failures, but the agentic list adds autonomy, delegated identity and multi-agent behavior. Each pairing below shows where a test of an LLM application already covers ground and what the agent version requires you to add.

Prompt injection and goal hijack

LLM01 Prompt Injection covers crafted input that changes model behavior. ASI01 Agent Goal Hijack carries the same mechanism into an agent that plans and acts, so a poisoned document or web page can redirect its objective. For a test, the LLM case checks whether input alters output, while the agent case checks whether it alters the next action. Build test cases that follow the agent through several steps and confirm the mapping in both source documents.

Excessive agency and tool misuse

LLM03 Excessive Agency, moved up to third place in the 2026 LLM list, is the closest match to ASI02 Tool Misuse. The LLM version asks whether a model holds more permissions than its function needs. The agentic version asks whether a legitimate tool can be called in unintended ways with unintended arguments. Test each tool separately, record which actions it allows, and check whether the agent can chain them beyond the intended workflow.

Identity and privilege abuse

ASI03 Identity and Privilege Abuse has no single LLM Top 10 entry, but it sits closest to LLM03 because excess permissions are the root cause in both. The agentic risk adds delegated identity: an agent acting under a user's token, a service account or inherited credentials. Test whether the agent's effective rights match the user's rights at each step, and whether tokens can be reused by another agent or tool. Confirm the mapping against the agentic list text.

Supply chain of models and agents

LLM04 Supply Chain addresses risky models, datasets and components. ASI04 Agentic Supply Chain Vulnerabilities extends this to tools, plugins, prompt templates and remote agents that an agent loads at runtime. A review of LLM04 asks where model artifacts came from and how they were verified. The agentic test adds the question of what the agent can install, discover or connect to after deployment, and whether its tool registry can be altered.

Output handling and code execution

LLM10 Improper Output Handling examines what downstream systems do with model output, such as rendering HTML or passing text to a shell. ASI05 Unexpected Code Execution appears when an agent generates and runs code, or triggers execution through a tool. The LLM test checks sanitization at each sink. The agent test also checks sandbox boundaries, filesystem and network reach, and whether generated code can escape its runtime.

Hidden context and memory poisoning

LLM08 Hidden Context Exposure covers sensitive content that leaks through system prompts, retrieved context or tool outputs. ASI06 Memory and Context Poisoning covers the write side: an attacker plants content in long-term memory, a vector store or shared context that later influences decisions. Test both directions. Check what the model reveals, then check whether instructions written to persistent memory survive sessions and reach other users or agents.

Which list drives the scope for each type of system

A text-only LLM application answers questions, possibly grounded in documents pulled from a vector store or search index. Its main exposure sits in what the model reads and what it reveals, so the OWASP Top 10 for LLM Applications 2026 should drive scope. Prompt injection (LLM01), sensitive information disclosure (LLM02), hidden context exposure (LLM08), vector and embedding weaknesses (LLM09) and improper output handling (LLM10) are the core areas. Because the system has no tool calls, the Agentic list is useful mainly as a reference point.

Retrieval corpus: test whether documents from restricted sources can surface for users who lack access.
Embedding store: check tenant separation and whether ingested content can be altered.
System prompt and context: confirm that internal instructions cannot be extracted through normal queries.
Output handling: verify that model output is treated as untrusted before it reaches a browser, query or downstream parser.
Test environment: provide a non-production copy of the index, representative user roles and logging that records prompts and retrieved chunks.

Confirm with your team that the application truly has no tools, plugins or write paths before narrowing scope to this list.

How to run one test scoped to both lists

This sequence turns the two lists into one test plan: each component of the system is mapped to the LLM and agentic risks that apply to it, then tested, validated and fed back into the risk register and detection work.

Inventory models, tools, identities and data
The system owner and the test lead list every component that shapes behavior: the model or models, system prompts, retrieval sources and vector stores, tools and APIs the model can call, the identities each tool runs under, the data stores it reads and writes, and every link to another agent or external service. Include memory and any state that persists between sessions. Done means one inventory, reviewed by the engineering and security owners, that names an owner for each component and states which ones act without a human approval step.
Map each component to LLM and ASI entries
For each inventory item, the test lead marks the relevant entries in the OWASP Top 10 for LLM Applications 2026 and the OWASP Top 10 for Agentic Applications for 2026. A tool with write access maps to Excessive Agency (LLM03) and Tool Misuse (ASI02), while a delegated identity maps to Identity and Privilege Abuse (ASI03). Where a component touches both lists, record both entries so the test case is not dropped from one list. Done means a matrix that links every component to at least one entry, with gaps explained in writing.
Agree rules of engagement and a non-production environment
The client and the tester sign rules of engagement that define permitted attacks, data that may be touched, accounts the tester may use, stop conditions and escalation contacts. NIST SP 800-115 provides a rules of engagement template in its Appendix B that can be adapted. Agentic tests need a staging environment with sandboxed tools, test identities with the same permissions as production, and mock or synthetic data, so that a successful goal hijack cannot send real payments or messages. Confirm with the vendor whether each tool supports a sandbox mode before the test is scheduled. Done means a signed document and a verified environment checklist.
Run tests across the mapped risks
Testers build scenarios from the matrix rather than from a generic checklist. Each scenario states the component, the entry, the attacker's starting position and the expected unsafe outcome, such as an injected instruction in a retrieved document that causes an unauthorized tool call. Prompt-level tests, tool-chain tests and identity tests are combined, because NIST SP 800-115 notes that organizations often combine techniques to reach an in-depth assessment at an acceptable level of risk. Done means a test log that records each scenario, the inputs used, the observed behavior and the evidence captured.
Validate findings and retest fixes
A finding is confirmed only when the tester can reproduce it from the recorded steps and show the unsafe effect, not just an unexpected model reply. Each confirmed finding gets the LLM or ASI entry it maps to, the affected component, the severity the client agrees to, and a fix owner. After remediation, the same scenario is run again against the changed system and the result is recorded. Done means every finding has a retest result of fixed, accepted with a named owner, or open with a date agreed by the client.
Feed results into the risk register
The security or risk lead records each validated finding in the risk register against the component and the entries it maps to, along with the residual risk after any accepted exception. Accepted risks are reviewed by the risk owner, not closed silently. Findings that show a risk the organization has not documented, such as an agent with unreviewed tool access, are added as new register entries. Done means the register reflects the tested system as it currently runs, with each open item traceable to a test scenario.
Turn test scenarios into detection work
The monitoring team takes the scenarios that succeeded or were partly detected and checks whether logs show the prompt, the tool call, the identity used and the downstream action. NIST SP 800-115 treats testing as an input to security improvement, and CIS Safeguard 18.4 asks that security measures be validated after a test so that detections cover the techniques testers used. Each gap becomes a detection rule, alert or log change with an owner. Done means each replayable scenario has a detection check that fires in staging, and the results are stored with the test report.

What you receive from an LLM-scoped test and an agent-scoped test

This table compares what a buyer should expect in writing from a test scoped to an LLM application against one scoped to an autonomous agent system. Read each row as a question to settle in the written scope before testing starts, since the list version, attack path evidence and ownership of fixes change with the system type.

Deliverable	LLM application test	Agent-scoped test
Scope document and list mapping	Scope mapped to the OWASP Top 10 for LLM Applications 2026, with LLM01 to LLM10 addressed or explicitly excluded	Scope mapped to the OWASP Top 10 for Agentic Applications for 2026 (ASI01 to ASI10), plus LLM items for the model layer it calls
List and version recorded	Name the list and edition used, for example the 2026 LLM edition, so results can be compared over time	Name the agentic list and release date used, for example the version released 9 December 2025, and any LLM items retained
Findings with reproduction steps	Each finding includes the prompt or input sequence, the observed output and the affected component	Each finding includes the goal, tool calls, identities and memory or inter-agent messages involved, so the sequence can be replayed
Attack paths used	Typically a chain from user or retrieved content to model output, then to downstream sinks such as rendering or data stores	Multi-step paths across tools, credentials, other agents and actions, showing where privilege or intent changed hands
ATLAS technique mapping	Ask for mapping to MITRE ATLAS techniques such as prompt injection and jailbreak entries, using the ATLAS release the report cites	Ask for mapping to agent-relevant ATLAS techniques, including the agent runtime discovery technique added in v2026.09, and the release version
Remediation guidance tied to owners	Fixes typically assigned to application developers, prompt and output handling owners and data teams	Fixes often span platform, identity, tool owners and agent builders, so each action should name who approves and who deploys
Retest results	Confirm which findings were rechecked, the build or configuration tested and the result for each	Confirm retests across tool permissions and identity changes, since a fix in one agent can change behavior in a connected one
Compliance evidence format	DeployOpen prepares evidence for compliance assessments but does not issue audit reports or certifications. Ask for the exact report format and evidence index in the written scope	Same boundary applies: evidence is prepared for an independent assessor. Confirm the report format, retention and sign-off roles before work starts

Cost and effort drivers for OWASP LLM Top 10 vs Agentic Top 10 testing

Testing an LLM application against the OWASP LLM Top 10 and testing an agent against the OWASP Agentic Top 10 are priced by different surfaces. The cards below cover the scope variables that move effort most, who is paid for each one, and what to request in a written quote so that two proposals can be compared on the same basis.

Tools and connectors in scope

Each tool, plugin or connector an agent can call adds an action surface that must be exercised for ASI02 Tool Misuse and LLM03 Excessive Agency. The tester pays time for every tool's parameters, error paths and side effects, and for each third-party connector whose behavior must be observed. Ask the quote to list every tool by name, its write permissions, and whether the testing team gets test credentials for each. Count the connectors your agent uses, not just the ones in the design document.

Agent identities and permission grants

Every agent identity and each grant of scope or role is a separate privilege to probe under ASI03 Identity and Privilege Abuse. Testers spend effort mapping which identity can reach which resource, then attempting escalation through delegation or token reuse. Ask for an inventory of service accounts, OAuth grants and role bindings, and state whether the quote covers each identity or a representative sample.

Agent-to-agent links

Each message channel between agents is an attack path for ASI07 Insecure Inter-Agent Communication and can carry ASI08 Cascading Failures across the system. Testing effort grows with the number of links and with the number of distinct orchestration patterns, because each pattern changes how trust is passed along. Ask the vendor to diagram every inter-agent link, including those created at runtime, and to say which ones will be tested with live traffic.

Staging with realistic data

A staging environment with non-production data that behaves like production lets testers run destructive tool calls and poisoning scenarios without risk to live records. Without it, scope narrows, and some ASI05 and LLM05 checks may be deferred or limited to read-only observation. The client usually pays for the environment and data masking, while the testing firm pays for the time to reproduce faults. Ask who builds and owns the staging copy and how long it takes to refresh.

Depth of cross-entry attack chains

Most findings in agentic systems matter only when chained, for example a prompt injection (LLM01) that leads to a tool misuse (ASI02) and then a privilege abuse (ASI03). Chained scenarios cost more than isolated checks because each step must be built, run and confirmed. Ask the quote to name the chains it will attempt, the number of entry points it will start from, and the criteria for calling a chain successful or stopped.

Retest cycles after fixes

Agent behavior changes whenever prompts, tools, models or permissions change, so retests often recur. Each retest is a recurring cost that the client pays under a retainer or a new scope, and it is easy to underestimate when only the first assessment is priced. Ask what counts as one retest, how many are included, and whether a model or prompt update triggers a new cycle.

Team skills and mix

Testing both lists well needs people who understand LLM behavior, identity systems, API security and the specific agent framework in use. A quote that relies on a single generalist usually covers less ground. Confirm which roles appear in the proposal, what each person has tested before, and whether the client's engineers must join to supply context. Rates for specialists are normally higher, so the mix changes the total.

Questions buyers ask before hiring outside help for agent and LLM testing

Can our team run an LLM or agent security test by itself?

Yes, a capable internal team can run parts of this work, and many do, but the answer depends on whether they have tested this attack surface before. Testing an LLM application means probing prompt injection, sensitive information disclosure, improper output handling and the web, API and data layers around the model, while an agent adds tool calls, delegated identities, memory and other agents. Each area needs a different skill set. Before deciding, check whether your team has written test cases for the OWASP LLM Top 10 risks and for any agentic risks that apply, whether it can build a safe attack environment, and whether it can judge severity for business impact. An outside team often adds independent findings and a second reviewer, but your internal team still has to provide access and context. Confirm what you would own and what the partner would own before you start.

What does our internal team need to provide before an agent test starts?

The test goes faster and finds more when the internal team prepares four things before the first day. First, system documentation: the model and version in use, the system prompt and its location, every tool the agent can call, the data sources it reads, and the other agents or services it talks to. Second, test accounts with the same roles real users and agents hold, including any non-human identities and the permissions they receive. Third, a non-production environment that mirrors the production integrations closely enough to show real tool behavior without exposing live customer data or triggering irreversible actions. Fourth, a named owner who can answer questions, approve test actions and decide on fixes. Ask the partner to list these inputs in writing as part of the agreed scope, so gaps are visible before fees are committed.

How long does an LLM or agent security test take, and what sets that length?

No duration is given here because the length depends on your system, and no researched figure applies to every system. The main drivers are the number of tools and integrations the agent can reach, how many distinct user roles and identities need testing, whether the test runs against a staging copy or a live system, how many model or prompt configurations are in scope, and how much work it takes to build a safe environment for tools that change data. Testing a single chat assistant with one retrieval source is a different job from testing a multi-agent workflow that can write to a ticketing system and a payment or records system. Ask for a phased schedule in the written scope that shows set-up, testing, retesting of fixes and reporting as separate steps, so you can see which part takes the time.

Does the OWASP Agentic Top 10 replace the OWASP LLM Top 10?

No. The two lists cover related but different risks, so one does not replace the other. The OWASP Top 10 for LLM Applications 2026, published in August 2026, focuses on risks in LLM applications, including prompt injection (LLM01), sensitive information disclosure (LLM02), excessive agency (LLM03) and improper output handling (LLM10). The OWASP Top 10 for Agentic Applications for 2026, released on 9 December 2025, focuses on autonomous agents that call tools, hold identities and communicate with other agents, with entries such as Tool Misuse (ASI02), Identity and Privilege Abuse (ASI03) and Insecure Inter-Agent Communication (ASI07). A system that is only a chat interface may need the LLM list most. An agent that acts on your behalf usually needs both, with the Agentic list used to add scope for tools, identity and multi-agent behavior.

How often should we retest after a model, prompt or tool change?

Retest whenever a change alters what the system can do or what it can reach, and the frequency depends on how often those changes happen. Changes that usually matter include a new base model or model version, a changed system prompt or guardrail, a new tool or a broader permission on an existing tool, a new data source for retrieval, a new agent or a changed agent-to-agent route, and changes to how identities are issued. Many teams separate two cadences: a targeted regression check of the affected tools and prompts after each change, and a broader test on a planned schedule. Ask the partner how retests are scoped and priced under a fixed-scope engagement or a retainer, and whether re-verification of fixes is included. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and the exact cadence is set in writing for each client.

Does a test result count as a certification or compliance proof?

No. A security test produces findings, evidence and a report for your own risk decisions. It does not certify that a system is secure, and it does not make your system compliant with any framework by itself. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies perform those assessments. When a regulator or customer asks for proof, ask them which test standard, which report format and which assessor they accept before you commission the work. Ask the testing partner what the report covers, what it does not cover, and how the findings map to the OWASP lists you have chosen.

What does an outside agent and LLM test cost, and what should we ask for in a quote?

The cost depends on the written scope, so no price is given here. Costs usually come from the number of systems, tools, identities and environments in scope, the depth of testing for each area, the set-up work for a safe test environment, reporting and the retest allowance. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and DeployOpen does not publish a price list, so a quote follows from that scope. Ask the partner to itemize set-up, testing, reporting, retesting of fixes and any ongoing retainer, and to state which items are one-time and which recur. Ask what internal effort you must supply, because your staff time is a real cost even when no fee is charged for it.

Why might a test miss issues in an agent that works in production?

A test covers the scenarios it was given, in the environment it was given, with the permissions it was granted, so gaps appear when any of those differ from production. Common causes include a staging environment with fewer integrations, test accounts with broader or narrower rights than real users, prompts or model settings that changed after testing, and multi-step attacks that span several tools or agents and were not in the scenario list. Some risks, such as Memory and Context Poisoning (ASI06) or Cascading Failures (ASI08), appear over time rather than in one session. Reduce this gap by agreeing the test scenarios in writing, testing against the configuration you run in production, and adding monitoring for tool calls and identity use so that unexpected behavior is detected after release.

How DeployOpen scopes, delivers and supports AI and agent security testing

DeployOpen plans and runs security testing for self-hosted AI systems inside the client's own infrastructure, including cloud accounts, data centers and air-gapped networks. For OWASP LLM Top 10 vs OWASP Agentic Top 10 questions, we start by deciding which list drives the scope, then document the tests, findings and evidence in a form your team can reuse.

How we scope

We confirm whether the system is a text-only LLM application, a tool-using agent, or both before choosing the risk list.
Engagements are fixed-scope, with the systems, identities, tools and data sources to test agreed in writing.
The written scope names which LLM and ASI risk IDs are in and out of test, and why.

How we build

We build test cases for prompt injection, excessive agency and tool misuse against your own deployed configuration.
Agent test environments mirror production tool permissions and identity paths, so results reflect how the agent really acts.
Test scripts and scenarios are documented so your team can rerun them after model or prompt changes.

How we hand over

Deliverables map each finding to the OWASP LLM Top 10 or Agentic Top 10 identifier and to the affected component.
Reports separate confirmed exploit paths from hypotheses, and list the remediation owner for each finding.
We document the test method, environment and evidence so an independent auditor can review what was tested.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the initial engagement.
Retesting after fixes is scoped in writing, so you know which findings were verified and which remain open.
Confirm with us in the quote which model versions, tool integrations and update cadence a retainer would cover.

OWASP LLM Top 10 vs OWASP Agentic Top 10