The New OWASP LLM Top 10 Isn’t a Pentest Checklist

OWASP released the 2026 edition of its Top 10 for LLM Applications in August. There are some notable changes in the ranking, but from a penetration testing perspective, the bigger change is what sits behind the model now.

LLM applications are increasingly connected to internal data, APIs, tools and business systems. That means a successful attack against the model may no longer end with an odd response or a leaked system prompt. Instead, it may lead to something more useful.

That is also why we would not treat the new Top 10 as a pentest checklist. The categories are useful for describing weaknesses, but the real test is understanding how those weaknesses connect and what an attacker can ultimately achieve.

Before getting into that, here is a quick summary of the main changes in the 2026 list.

What changed in 2026?

Observation: The Excessive Agency's movement is probably the one that stands out most to us. It reflects a broader shift in how these applications are being built, as models are increasingly given more to actually do.

Naturally, that changes how we would test it.

Proving Prompt Injection Is Only the Start

Prompt Injection is still number one, which is not especially surprising.

If an application accepts natural language input, there is always going to be some opportunity to influence how the model interprets instructions. We could try different payloads, indirect injections, encoding techniques and instruction conflicts to see whether the model can be tricked outside it's intended behavior.

But simply proving that it can be influenced is not necessarily the interesting finding.

For example, let's take an internal HR chatbot that answers questions from a public or low-sensitivity employee handbook. If we can make it ignore an instruction or reveal part of its hidden prompt, there may not be much further to go.

Now compare that with an AI support agent that can query customer records, open tickets, call internal APIs and send messages.

The injection might be almost identical but the impact is not.

What we would want to understand is what the attacker gets after the model has been manipulated. Can they access data they should not see? Can they trigger a tool? Can they influence an action performed under a more privileged identity?

A system prompt saying “never access another customer’s data” does not provide much protection if the backend API will return that data when asked.

We Wouldn’t Start by Testing the Model

Before sending a large number of prompts at an application, we would normally want to understand what the model is connected to.

A basic LLM application might look like:

A connected enterprise application may look more like:

That second environment would give an attacker considerably more to work with.

Hence, we would want to know what the model can retrieve, which tools it can invoke, which identity is used when those tools are called and what happens to its output afterwards. Those details tell us whether a successful manipulation is likely to remain inside the chat interface or cross into another part of the environment.

This is also where traditional penetration testing becomes relevant again. Authentication, authorisation, least privilege and trust boundaries do not stop mattering because an LLM has been placed in front of them.

Excessive Agency Changes What an Injection Is Worth

Let's suppose an AI assistant has access to an internal customer management API.

The common questions to ponder are fairly ordinary:

• Which API functions can the model invoke?
• Which account is used for those requests?
• Are permissions checked by the API itself?
• Can the model perform write or administrative actions?
• Do sensitive actions require explicit approval?

If the assistant only needs to retrieve account information, there is probably no or little reason for it to also have access to record deletion, administrative changes or other high-impact functions.

If those functions are available anyway, an attacker who successfully influences the model has a much more useful position.

This is why Prompt Injection and Excessive Agency commonly go together.

Prompt Injection may get the attacker through the first boundary. Excessive Agency determines what is available on the other side.

Hidden Context Can Help an Attacker Go Further

The move from System Prompt Leakage to Hidden Context Exposure is also useful because it better reflects what the model actually sees.

A modern application may provide the model with developer instructions, RAG content, tool schemas, workflow logic, user information, memory and application configuration before it responds.

So asking the model to reveal its system prompt is only one small part of the test.

A more useful question is whether any of that hidden context improves the attacker’s position.

For example, a leaked tool schema could reveal a function that is not exposed elsewhere in the interface. Internal instructions might explain how approval logic works. Retrieved content might expose another tenant’s information or reveal identifiers that can be used in a follow-up request.

RAG Creates Another Trust Boundary

RAG (Retrieval-Augmented Generation) systems create similar issues around retrieval and authorisation.

Let's imagine multiple customers’ documents are stored in the same vector database. Where is access control actually applied?

If another tenant’s content reaches the model context before access control filters it, the security boundary may already have failed.

That is not really an LLM-specific problem. It is an access-control problem happening inside a different architecture.

During a test, we would look at whether retrieval is scoped correctly, whether document metadata can influence access, whether one user can place content that another user later retrieves, and whether retrieved content can introduce indirect prompt injection.

The Chain Is the Finding

From a penetration testing perspective, this is probably the most significant part of the updated Top 10

The individual OWASP categories are useful for describing risks, but a real attack may move through several of them.

Take a hypothetical internal AI assistant that can read documents and send email.

You could describe that as Prompt Injection. You could also describe part of it as Sensitive Information Disclosure. The reason the attack succeeds may ultimately be Excessive Agency. All three labels are useful for classification, but none of them tells the whole story by itself.

The more important question is why an untrusted document was able to influence a model that had enough access to retrieve sensitive information and then communicate it externally. That is the attack path.

This is also not particularly new from a penetration testing perspective. A low-severity information disclosure might reveal an internal endpoint. That endpoint may contain an authorisation weakness, which in turn exposes another piece of functionality.

What We'd Want to Know Before Testing

Let's say we're working with a client. Before we get anywhere near testing an AI-enabled application, we'd usually want a decent picture of the architecture, enough to actually see where the major trust boundaries sit.

We don't need every implementation detail up front. But we do need to know roughly what the model can see and what it can do, otherwise we're not really scoping a test, we're guessing at one.

That last question "what's the worst realistic outcome if the model gets manipulated" tends to shape how we approach the rest of the test.

And really, an application that answers questions from public documentation has a very different attack surface from an agent with access to SharePoint, customer records, internal APIs and email.

They should not receive the same test.

OWASP Is the Starting Point, Not the Test Plan

The updated OWASP LLM Top 10 is useful. It gives security teams a common way to describe the risks that appear in modern AI applications, and the 2026 changes reflect the move towards more connected and agentic systems.

But we would not approach an engagement by working through ten categories and stopping when each one has been checked. Instead, we would use the list as a reference, then follow whatever paths the application gives us, starting with prompt injection perhaps, moving into hidden context, reaching a tool with excessive permissions, and eventually exposing data through a completely different system entirely.

The category helps describe the weakness.

The attack path tells us why it counts.