A model can be persuaded to produce almost any sentence, and demonstrating that is neither difficult nor useful. It becomes a security finding at the point where something acts on it — output rendered into a page, inserted into a query, or handed to a tool with permissions of its own. That line is what this class is worked to.
Class and boundary
The exclusion is the important card. It is the first thing a specialist will ask about, and answering it is what makes the other three answerable.
Direct injection from somebody using the application, and indirect injection through whatever the application retrieves and treats as trustworthy — a document, a page, a record, a message. The second reaches applications nobody is attacking directly.
The interface in front of the model: authentication, what it will accept, rate and cost limits, what leaks through it, and whether the model behind it can be extracted through the endpoint.
Tool misuse, the autonomy boundary, privilege escalation through what a tool is permitted to do, and chaining nobody designed. The newest of the three and the one this class is most opinionated about.
B-52 is itself an agentic penetration testing platform. That is the opposite job from this class — testing software with autonomy, rather than using autonomy to test software — and it has its own page.
AdjacentThe interface in front of a model is an API, and everything the API class works applies to it — authentication, what it accepts, rate and cost limits, what leaks through. Form two is that work done with the model in mind.
Where the model came from, and whether its training data was interfered with, are outside this class. Saying so is not a caveat; it is what makes the rest of the page checkable.
Two jobs, four words
The same phrase describes two opposite pieces of work. One is using autonomy to test software, which is what B-52 is and what the rest of this site is about. The other is testing software that has a model inside it, and in the third form, software that can act on its own. This page is the second. Keeping them apart matters for more than tidiness: a buyer who arrives at the wrong one gets a confident, detailed answer to a question they were not asking, and finds out several weeks later.
Who this page is for
Both are answered here. Where they should start is not the same.
The run
Every phase matters. On this class the last one does the work that keeps the report from being a collection of transcripts.
Phase one
What the application actually does with a model: where input reaches it, what it retrieves and treats as trustworthy, which tools it can invoke, and what each of those tools is permitted to do.
Phase two
The scope: which interfaces, which retrieval sources, which tools, and — separately — what the run may cause the application to actually do. Signed in writing. In the fully autonomous model it is the last human action.
Phase three
Breadth across the injection and disclosure surface, direct and indirect. This phase produces candidates. Nothing leaves it as a finding.
Phase four
A candidate becomes a finding when the application did something as a result: returned data it should not have, produced output that something downstream acted on, or reached a tool it should not have reached.
Phase five
Each finding with the input in full, the output, and what happened next — landing in your dashboard as it is confirmed.
Phase six
The last phase separates a model saying something undesirable from an application doing something undesirable. Only the second is a security finding, and this is the gate that enforces it.
The line that decides everything
A model can be talked into producing almost any text, and a report full of transcripts demonstrating that is a product-quality document rather than a security one. The point at which it becomes a security finding is the point at which something acts on the output: rendered into a page, inserted into a query, passed to a command, written to a path, or handed to a tool that holds permissions of its own. Everything in this class is worked to that line. It is also why the most valuable output of an engagement is frequently a permission change rather than a change to an instruction.
The boundary
Two different permissions, and on this class they are worth agreeing separately. Asking an application to do something and letting it happen are not the same act.
| State | What it means | What follows |
|---|---|---|
| Causing the application to act on the outside world | Where a tool sends mail, moves money, writes to a record or calls another system, establishing that it can be reached is the finding. Letting the call complete is the next act. | Stops and waits, in writing. |
| Reading real user data through the application | What the application will disclose is proved with a single record. Collecting what it would disclose next is a separate decision. | Stops and waits, in writing. |
| Persistence and movement past the entry host | Where output reaching a command or a query yields a foothold on the infrastructure behind the application, going further is an internal network question. | Stops and waits, in writing. |
| Everything else inside the authorised scope Terminal | Mapping the retrieval and tool surface, direct and indirect injection, endpoint and disclosure work, chaining, and reporting. | Runs without asking. |
On the symmetry
The third form asks what an agent is permitted to do without being asked again — which is the same question this platform answers about itself on every engagement: a scope signed in writing, three actions that stop and wait, and a record of what was permitted and what was refused. That is not a rhetorical parallel. It is why the autonomy boundary is the part of this class we are most opinionated about, and it is why the scope agreement asks separately what the application may be caused to do rather than folding that into what may be sent to it.
Against the published list
The current OWASP list for LLM applications, 2025 edition. Two of the ten are outside this class, and naming which two by number is the point of the table.
| Entry | What this class does with it |
|---|---|
| LLM01 Prompt injection | The first form. Direct injection from a user, and indirect injection through content the application retrieves and treats as instruction rather than as data. |
| LLM02 Sensitive information disclosure | What the application will reveal about its own data, its other users, and the systems behind it — through the interface and through the endpoint. |
| LLM03 Supply chain | Not claimed. Where the model came from is outside this class, and it is stated here rather than left to be discovered. |
| LLM04 Data and model poisoning | Not claimed. Training-data and fine-tuning integrity are outside this class. |
| LLM05 Improper output handling | Where model output reaches a browser, a query, a command or a file path. This is the entry that turns an injection from a curiosity into a finding. |
| LLM06 Excessive agency | The third form. What the tools can do, what the model may invoke without being asked again, and what a chain of invocations reaches. |
| LLM07 System prompt leakage | What the application will disclose about its own instructions — and, more usefully, what those instructions were being relied on to enforce. |
| LLM08 Vector and embedding weaknesses | Where a retrieval store is inside the authorised scope, it is assessed as a data store: what it will return, to whom, and what was permitted to write into it. |
| LLM09 Misinformation | Assessed where the application acts on its own output. A wrong answer shown to a person is a product question; a wrong answer that triggers an action is this one. |
| LLM10 Unbounded consumption | The second form. What the endpoint will accept, at what rate, and what it costs whoever is paying — demonstrated rather than driven to exhaustion. |
LLM01 Prompt injection
LLM02 Sensitive information disclosure
LLM03 Supply chain
LLM04 Data and model poisoning
LLM05 Improper output handling
LLM06 Excessive agency
LLM07 System prompt leakage
LLM08 Vector and embedding weaknesses
LLM09 Misinformation
LLM10 Unbounded consumption
Three of them, worked
The first is the one everybody tests. The second is the one that reaches applications nobody is attacking. The third is the one that does something.
Methodology
Two of these are pinned to a version and two are deliberately not. Each row says which it is and why, because on this subject a stale citation is the fastest way to lose a technical reader.
| Standard | Version | What it carries here |
|---|---|---|
| OWASP Top 10 for LLM Applications | 2025 edition, released 12 March 2025. Read 2026-09-14 | The category every finding is reported under. The table above works through all ten entries and marks the two this class does not cover. |
| The current edition, and the source of the entry numbers used on this page. | ||
| MITRE ATLAS | Current release. Read 2026-09-14 | The adversarial technique vocabulary for AI systems — the counterpart to ATT&CK, and where the agentic techniques live. |
| Deliberately not pinned to a number: ATLAS publishes on a rolling cadence, so the report names the release each finding was mapped against rather than this page naming one that goes stale between engagements. | ||
| NIST AI RMF | AI 100-1, 26 January 2023, with the Generative AI Profile AI 600-1, 26 July 2024. Read 2026-09-14 | The governance vocabulary a report has to land in when its reader is a risk committee rather than an engineering team. |
| AI 100-1 is under revision and no version 2.0 has been published, so 1.0 is what is cited. | ||
| CVSS | v4.0, November 2023. Read 2026-09-14 | The severity vector on findings that have one — an injection that reaches a query does. |
| Not applied to everything. A model producing an undesirable sentence has no vector, and scoring one as though it did would be inventing precision. | ||
OWASP Top 10 for LLM Applications
The current edition, and the source of the entry numbers used on this page.
MITRE ATLAS
Deliberately not pinned to a number: ATLAS publishes on a rolling cadence, so the report names the release each finding was mapped against rather than this page naming one that goes stale between engagements.
NIST AI RMF
AI 100-1 is under revision and no version 2.0 has been published, so 1.0 is what is cited.
CVSS
Not applied to everything. A model producing an undesirable sentence has no vector, and scoring one as though it did would be inventing precision.
Before a run starts
Deliberately excluded
Per finding
Exactly what was sent — including the retrieved content, where the injection arrived through something the application fetched rather than through something a person typed. A paraphrased prompt is not reproducible.
Not what the model said. What the application did with what the model said, and what that reached. That is the finding; the transcript is the evidence for it.
The tool that was reached and what it was authorised to do — so remediation can be a permission change rather than another sentence added to an instruction that has already failed once.
The OWASP LLM entry at the 2025 edition, the ATLAS technique, the CWE where one applies, and a CVSS v4.0 vector where the finding has one.
In the model with no auditor in it, findings pass a second automated gate before they are reported. It is a check on top of the proof, not a substitute for it.
Where this sits
No vendor is named here — these are categories of work. Two of them are worth having and neither of them is this.
| A guardrail or filtering layer | Model red-teaming | Testing the application only | B-52 | |
|---|---|---|---|---|
| What it is looking at | Inputs and outputs, against rules. | The model’s behaviour, against a taxonomy of undesirable output. | The application, with the model treated as a box that returns strings. | The application, the endpoint behind it, and what its tools are permitted to do. |
| Reaches indirect injection | Some, where the retrieved content passes through it. | Not its object. It is testing a model, not a retrieval path. | Only where somebody thought to write into what the application fetches. | Worked as a form in its own right, starting from who can write to each source. |
| Reaches excessive agency | No. It does not see the tool call. | No. The tools are not part of the model. | Where the tools happened to be in scope. | Worked from the tool permissions outward, which is also where the fix is. |
| What a finding costs you to confirm | Not applicable; it blocks rather than reports. | Judgement about whether the behaviour matters in your product. | Usually nothing; it was proved. | Nothing. The input, the output and what happened next arrive together. |
| Cadence | Continuous. | When the model changes. | When it is scheduled. | The interval you set, or the pipeline that built the release. |
| Whose signature it carries | None. | The team that ran it. | The firm that ran it. | Security Brigade’s, in the two models with an empanelled auditor in them. |
What it is looking at
Reaches indirect injection
Reaches excessive agency
What a finding costs you to confirm
Cadence
Whose signature it carries
On model red-teaming
Testing a model against a taxonomy of undesirable output is a real discipline, and it belongs to whoever built or fine-tuned the model. Where you bought the model rather than trained it, that work has already been done by people with access you do not have, and repeating it tells you very little about your own product. What nobody has done is assess what your application does with that model — what it retrieves and trusts, what it renders, what it can be made to invoke, and what happens when the answer is acted on. That is what is left over, and it is the whole of this class.
Filing
Coverage is identical across the three delivery models. What differs is whose signature the report carries.
Findings map into the Govern, Map, Measure and Manage functions of AI 100-1 and into the Generative AI Profile, so a technical report reaches a risk committee without being translated on the way.
Where a testing cycle names applications and APIs, this is one of them — and the endpoint in front of a model is an API. The obligation reaches it through the scope that already exists.
On this class a finding usually closes on a permission change or an output-handling change rather than on a patch, and it closes on a retest where the same input no longer produces the same action.
Where the report goes to a regulator or an assessor, start with the expert-verified model.
Worked example
Four steps. No user was targeted, no credential was stolen, and nothing in the transcript looks unusual.
| Link | Alone | In sequence |
|---|---|---|
| 1 A document the application reads | A file, uploaded by somebody entitled to upload files. | The application retrieves it and places its contents in front of the model. |
| 2 An instruction nobody typed | A sentence inside that document. | It arrives as context, indistinguishable from the rest of the context. |
| 3 A tool the application may invoke | A function with a name and a permission. | The instruction asks for it, and nothing between the two disagrees. |
| 4 What the tool did | A successful call. | The action happened. Each permission in the chain was granted separately, by somebody reasoning about it separately. |
Measured
B-52 and Security Brigade’s expert assessment team were run against the same targets in parallel and their findings pooled into one set, each item counted once. B-52 reached 90–95% of that set. The figure describes the platform rather than any single coverage class, and it is stated here for the reason it is stated everywhere on this site: it is the measurement behind the claim that autonomy is not a compromise, and a claim of that size should arrive with the thing that was measured.
One scan is one application or target, and the entry tier is $500. The list of tools your application may invoke is what decides how much this class can find, so it is the thing worth bringing to the conversation.