Prompt injection in 2026: where the surface appears and what is measurable

Prompt injection is usually explained with a chat example: a user types "ignore your previous instructions". That is the most harmless case, because the user is attacking their own session.

The real surface appears wherever content controlled by an outsider enters the prompt. For us that happens on every tool: to explain a check result we pass the model another site’s response headers, its DNS records, its page text, the contents of its robots.txt.

All of it is written by the owner of the site being checked, not by our user. They can put any text in a response header or a meta tag — including text addressed not to a human but to the model that will read it.

This is precisely the class that stands first in OWASP’s risk list for applications built on language models. And it has an unpleasant property: no reliable technical solution exists. A model does not distinguish "data" from "instructions" — to it both are one stream of text.

The prevalence of injection attempts has been measured by nobody. No vendor and no researcher publishes what share of requests contains one. The reason is simple: counting it requires reliably telling an attempt from ordinary text, and that is exactly what nobody can do.

What is measurable is how often a model declines to answer. We log that, and across ten days of August 2026, 9,474 live calls produced 36 refusals:

So roughly one article summary in forty is declined. All 36 cases fell on one surface and one language, and the refusal wording was identical in every one.

A caveat: a refusal is not evidence of an attack. Far more often it is a filter firing on a harmless technical subject: text about vulnerabilities, about blocking, about circumventing restrictions looks suspicious to a filter regardless of intent. We give this figure not as a measure of attacks but as the part of model behaviour a system is obliged to anticipate.

This is worth recounting, because the mistake is typical and not obvious.

Our system received an answer from the model and displayed it to the user in an "AI summary" block. When the model declined, it returned not an error but an ordinary text answer — a polite sentence about the subject not being discussed. To the code that was a successful response, and it was faithfully displayed as the result of an analysis.

The user saw, in the analysis block for their own check, a sentence along the lines of "I cannot discuss this topic". Formally the system worked correctly: the request went out, an answer came back, the answer was shown. In fact a refusal was being published in the interface as a finding.

The fix is to recognise a refusal from the answer text before it reaches the cache and the page, and in that case not to show the block at all. Such a call should also not consume the user’s quota: they received nothing.

The general lesson runs wider than injection: a successful model response does not mean a useful one. Everything arriving from a language model passes through code as an ordinary string, and no mechanism will distinguish a substantive finding from a polite refusal except a check you write yourself.

There is no universal solution, but the set of damage-limiting measures is known and it works.

1. Treat model output as untrusted by default. Do not execute it as a command, do not substitute it into a database query, do not follow links from it. If the model proposes an action, a human or a separate check in code must confirm it.
2. Escape the output when displaying it. We accept only a marked-up minimum from the model — emphasis and monospace — and convert it to markup after escaping. The model physically cannot insert a working tag.
3. Limit what the model sees at all. The less foreign text enters the prompt, the smaller the surface. We pass parsed values rather than whole raw pages — not because it is cheaper, but because it is less somebody else’s text.
4. Separate instructions from data explicitly. This is hygiene rather than defence: a model does not guarantee the boundary, but a clear prompt structure noticeably reduces accidental mixing.
5. Give the model no more privilege than it needs. If it can change nothing, the most successful injection yields only spoiled text. This is the one measure that works regardless of the attacker’s ingenuity.

To see what your site sends in headers and meta tags — that is, what somebody else’s model would read — use the header check.

Primary source on risk classification: the OWASP list for large language model applications.