Prompt injection

Prompt injection is the vulnerability in which input changes a language model's behaviour or output in ways the system's designer did not intend. It sits at the top of the OWASP Top 10 for Large Language Model Applications as LLM01, a fair reflection of how common it is and how hard it is to close.

The definition hides a detail that catches people out: the input does not have to be visible. OWASP notes that injections can affect the model even if they are imperceptible to humans, as long as the model parses the content. White text, an unusual character encoding and an instruction inside an image are all in scope.

What is the difference between direct and indirect prompt injection?

Direct injection is when a user's own prompt changes the model's behaviour unexpectedly, deliberately or by accident.

Indirect injection is when the model reads content from an outside source, a website, a file, an email, and instructions inside that content are treated as instructions. This is the variant that matters to anyone publishing on the web, because nothing enforces the boundary between your page and someone's prompt.

OWASP's scenarios make it concrete. A user asks a model to summarise a page containing hidden instructions, which make it insert an image linking to a URL that exfiltrates the conversation. An attacker edits a document in a repository a retrieval-augmented generation app uses, so a matching query returns the malicious text. And unintentionally: a company hides an instruction in a job description to spot machine-written applications, and an applicant who polishes a résumé with a model triggers it without knowing.

Why can prompt injection not simply be patched?

The reason is architectural. A model receives one stream of tokens. A system prompt, a retrieved document and a user message are separated by convention, not by a hard boundary, and the model's job is to follow instructions in text. OWASP puts it plainly: given the stochastic way models work, it is unclear whether fool-proof prevention exists.

It also rules out the fixes people try first. Retrieval and fine-tuning aim at relevance and accuracy, but OWASP reports they do not fully mitigate the problem. Multimodal systems widen it, since instructions can hide in images beside harmless text. And connectors widen it again: an MCP tool description from an untrusted server is text that reaches the model, as the Model Context Protocol specification itself warns.

What actually reduces the damage?

OWASP's mitigations read best as a hierarchy, because most limit the blast radius rather than prevent the injection:

1. Constrain model behaviour with specific instructions about role, capabilities and limits.
2. Define and validate output formats, checked by deterministic code.
3. Filter input and output for sensitive categories.
4. Enforce least privilege: privileged functions in code, minimum access for the model.
5. Require human approval for high-risk actions.
6. Segregate and label external content so untrusted text has less influence.
7. Test adversarially, treating the model as an untrusted user.

Points 4 and 5 carry most of the weight. An agent that cannot spend money, send mail or write to a repository without a person approving is one where a successful injection is an embarrassment, not an incident.

What does a defended agent look like in practice?

Attensira's crew reads exactly the kind of text injection lives in: AI answers that quote pages nobody here controls, competitors' pages, and the web pages it researches. Its public documentation describes how that text is handled, and it maps onto OWASP's list:

• Untrusted text is data. Observations derived from AI answers are, in the words of the documentation, "fenced off and scrubbed before it reaches a conversation, so a stray instruction hidden in a quoted page cannot steer what the agent does next" (OWASP 6).
• Pages and drafts are judged, never obeyed. The decisions documentation states that a competitor's page "is read as text to judge, never as instructions", and that an instruction inside a draft, such as one copied from a page the agent read, "is judged as content and never followed" (OWASP 1 and 3).
• A person approves what leaves. New workspaces start in Draft, where nothing is published, sent or written outside the workspace without approval, and anything stating a price, number or competitor name waits in every mode (OWASP 5).
• Write access is narrow. On GitHub the crew opens pull requests on fresh branches, never pushes to your default branch and never touches CI configuration (OWASP 4).

None of that makes injection impossible; OWASP is right that no one can promise that. It makes a successful injection reach a person's Inbox instead of your site.

What does prompt injection mean for publishers?

There is a content side to this. If text in a page can steer a model, some people will plant text in pages, and those pages compete for the same answers as yours. Two things follow.

Treat any suggestion to hide instructions in your own markup as an attack you would be committing, not a tactic. It is the behaviour every mitigation above is built to detect, and being filtered out is the good outcome. And when an assistant says something wrong about your brand, remember it may have come through a retrieved page rather than the model's memory. That is a different failure from a hallucination, fixed in a different place: at the source the answer cited.

How does Attensira help when answers repeat injected or false claims?

By tracing the claim back to the page that planted it. An injected or false statement about you reaches an answer through a source the engine fetched, and across our own tracked questions only 1.6% of citations pointed at pages we control, as the chart at the top of this page shows. Attensira keeps every answer verbatim with the sources it cited and checks the factual claims it makes about you against facts you confirmed, so a contradicted claim arrives with its quote and the exact pages behind it. Then the deciding sources view shows how much weight each of those pages carries across your questions, which tells you whether one bad page is worth a correction request. The crew can draft that request or the replacement passage, and it waits in the Inbox for your approval before anything goes out.