# Prompt Injection: Why There Is No Patch, and What Actually Reduces Risk > Prompt injection is an attack where untrusted text reaching a language model is interpreted as instructions rather than data. Because models process instructions and content in the same token stream, there is no reliable syntactic boundary between them. Defences reduce blast radius through privilege separation and output handling rather than filtering malicious phrasing. Source: https://hackerlogs.com/blog/prompt-injection-no-patch Published: 2026-09-01 ## Key takeaways - Prompt injection is an architectural consequence of how transformers consume text, not a bug that a vendor can patch. - Indirect injection, where the payload arrives through retrieved documents or tool output, is the variant that matters for real applications. - Input filtering fails because the space of adversarial phrasings is unbounded; treat it as telemetry, never as a control. - The defences that hold are architectural: least privilege on tools, human confirmation on side effects, and treating model output as untrusted. - OWASP ranks prompt injection as LLM01, the top risk in its Top 10 for LLM Applications. Every few months someone announces that prompt injection has been solved. It has not been, and the reason is structural rather than a matter of effort. This piece explains where the problem actually comes from, why the obvious fixes do not work, and which defences are worth your engineering time. ## What is prompt injection? Prompt injection is an attack where untrusted text reaching a language model is interpreted as instructions rather than as data. The developer intends a document to be summarised; the attacker writes the document so that it is obeyed instead. The root cause is that a transformer receives one flat sequence of tokens. Your system prompt, the user's question, and a retrieved web page all arrive through the same channel. There is no `escape()` function, no prepared statement, no bit that marks a span as inert. Priority between them is a soft statistical preference learned during training, not an enforced boundary. This is why the SQL-injection analogy breaks down at the point where it matters most. SQL injection was solvable because the grammar of SQL permits a hard separation between code and parameters. Natural language has no such grammar, so the same fix has no equivalent. ## Direct versus indirect injection **Direct injection** is the user typing an adversarial prompt into your product. It matters, but the blast radius is usually limited to that user's own session. If someone talks your chatbot into insulting them, that is embarrassing rather than a breach. **Indirect injection** is where the payload arrives through content the model consumes on the user's behalf: a retrieved document, a web page, a calendar invite, the output of a tool call, the body of an email. The attacker never touches your product. They plant the text somewhere your system will later read. Indirect injection is the variant that produces real incidents, for three reasons. The victim is a different person from the attacker. The payload can sit dormant until retrieved. And the model is usually acting with the victim's privileges when it encounters it. Greshake et al. demonstrated the practical version of this in 2023, compromising LLM-integrated applications without any direct access to the prompt at all. ## Why filtering does not work The instinct is to scan input for malicious phrasing. This fails, and it is worth being precise about why. The attacker's search space is unbounded. "Ignore previous instructions" is trivially caught, and equally trivially rewritten: into another language, into base64, into a story about a character who receives instructions, into whitespace-separated glyphs, into an image of text. Every filter defines its own bypass, and the attacker gets to iterate against your filter while you cannot iterate against their next attempt. A classifier facing an adaptive adversary with an unbounded input space is a rate limiter, not a control. That does not make filtering worthless. It makes it *telemetry*. A blocked payload tells you that you are being probed, which is genuinely useful. Just do not put it in the load-bearing position of your threat model. ## What actually reduces risk The defences that hold are architectural. They assume injection succeeds and constrain what that success is worth. **Least privilege on tools.** The question is not whether the model can be tricked but what it can reach once it is. An agent with read-only access to one mailbox is a different risk from one holding a token that can send mail, delete files, and call internal APIs. Scope credentials per task, not per agent. **Human confirmation on side effects.** Reads can be automatic. Writes, sends, payments, and deletions should require a human to approve the specific action, with the actual parameters shown. This is the single highest-value control for agentic systems, and the most commonly skipped because it costs product smoothness. **Treat model output as untrusted input.** Output flowing into a shell, a SQL query, an HTML render, or another tool call is attacker-influenced data. It needs the same validation you would apply to a form field from the open internet. A large share of real-world LLM vulnerabilities are ordinary injection bugs downstream of the model, not exotic AI problems. **Separate the trust levels you actually have.** If a request mixes a trusted system prompt with an untrusted retrieved document, do not let the untrusted portion influence privileged operations. In practice this means splitting into multiple calls: one privileged planner that never sees untrusted text, and one unprivileged worker that does. **Log the full context.** When something goes wrong you need the exact token sequence the model saw, including retrieved content. Teams that log only the user's message cannot reconstruct an indirect-injection incident at all. ## Where this is heading Nothing on the research horizon closes the class. Instruction hierarchies, structured input channels, and dedicated boundary tokens all raise the cost of an attack, and all remain probabilistic. They are worth adopting as they mature, and none of them justify removing an architectural control. The practical stance is the one security engineering already knows: assume the boundary will be crossed, and design so that crossing it is not worth much. ## Sources - [OWASP Top 10 for LLM Applications](https://owasp.org/www-project-top-10-for-large-language-model-applications/) - [Not what you've signed up for: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection](https://arxiv.org/abs/2302.12173) (2023-02-23) - [NIST AI Risk Management Framework](https://www.nist.gov/itl/ai-risk-management-framework)