How to Prevent Prompt Injection in LLM Apps: What Holds When Filters Fail

Anyone selling you a filter that stops prompt injection is selling something that does not exist. A language model reads instructions and data as one stream of text, so a sentence in a support ticket can steer it the same way your system prompt does. You cannot patch that away. What you can do is design the system so that a fooled model can do very little damage. Here is how we would do that, in order, and what we would skip.

Why Filters Cannot Solve This

SQL injection has a real fix, because parameterized queries keep code and data apart. Prompts have no equivalent. In December 2025 the UK's National Cyber Security Centre put it plainly: "Current large language models (LLMs) simply do not enforce a security boundary between instructions and data." Its author suggested treating the model as an "inherently confusable deputy", and warned buyers to "beware any" vendor that claims it can stop prompt injection.

OpenAI said the same about its own browser agent that month: prompt injection, "much like scams and social engineering on the web, is unlikely to ever be fully 'solved.'" OWASP's entry for its top risk says it is unclear whether fool-proof prevention exists. Simon Willison points out that guardrail products claiming to catch 95% of attacks would earn a failing grade anywhere else in web security. An attacker gets to try until one gets through.

What Attacks Look Like in the Wild

This has moved past research demos, though it is easy to overstate. Google scanned the public web and reported a 32% relative rise in malicious injection content between November 2025 and February 2026, while finding most of it unsophisticated and giving no absolute count. Palo Alto Networks' Unit 42 documented 12 real cases and 22 techniques in March 2026, including what it called the first reported attempt to bypass an AI ad review system, with 24 injection attempts on one scam page. It knows of no confirmed success there. The Cloud Security Alliance's April note lists payloads seen by Forcepoint and others: a sudo rm -rf aimed at backups, a fixed $5,000 PayPal transfer, and an instruction to leak an API key.

Note what is absent from that chart: clever hacking. Unit 42 found 85.2% of jailbreak attempts relied on social engineering, phrasing commands as authority overrides or routine tasks. The model is being talked into it.

The damage in real incidents usually comes from what the agent could reach. OWASP's first-quarter round-up covers eight incidents from January 1 to April 11, 2026, and these three teach the most:

The Lethal Trifecta: A Test for Any Agent

Simon Willison's framing is the most useful single idea here. An agent becomes dangerous when it combines three capabilities: access to your private data, exposure to untrusted content, and the ability to communicate externally. Remove any one, and this kind of data theft has no route. Here are the three in a typical support agent. Select one to remove it, and see what you give up.

Untrusted content is wider than most teams assume. It includes tickets, emails, PDFs, web pages, calendar invites, CRM fields, code comments and log lines: anything a person outside your company can write to. If your retrieval index ingests any of those, a chatbot has that exposure too.

Watch an Attack Move Through a Support Agent

Here a poisoned attachment enters a support agent. Turn on defenses and replay it to see where the attack stops. One thing is deliberate: separated context never stops the attack here. It lowers the odds, and it depends on the model behaving, so the simulation assumes it failed. The other three are enforced in code, so they hold even when the model has been fooled.

How to Prevent Prompt Injection Damage, in Order

1. Map what each agent can reach

List every agent, every tool and every credential, and mark which ones touch untrusted content. The Cloud Security Alliance puts this inventory first, and so would we. Most teams learn something uncomfortable in the first hour.

2. Give tools the least privilege, enforced in code

Give the model the narrowest tool that does the job, and take sensitive arguments away from it. If the customer ID comes from the session rather than the model, no injected sentence can change it.

// Bad: the model chooses whose data it reads
get_customer({ customerId })

// Better: your code binds the scope, the model picks the order
async function getMyOrder({ orderId }: { orderId: string }, ctx: Ctx) {
  return db.orders.findFirst({
    where: { id: orderId, customerId: ctx.session.customerId },
    select: { id: true, status: true, total: true },
  });
}

OWASP's guidance is to keep privileged functions in code rather than exposing them to the model. Use short-lived credentials, and give each agent its own identity. The trade-off is more tools, each doing less, which means more to build and maintain. That cost is worth paying.

3. Put a person in front of irreversible actions

OWASP's round-up names the actions plainly: delete, send, pay and publish need hard confirmation and easy rollback. Show the reviewer exactly what will happen, including full URLs. Approval fatigue is real, so reserve it for actions that matter and let safe reads run freely.

4. Treat output as untrusted too

This is the step most teams miss. If your interface renders Markdown, an image tag is an outbound request that needs no tool call and no click. GrafanaGhost used exactly this route. The CSA recommends restricting Markdown images to allowlisted domains and blocking protocol-relative URLs.

const IMAGE_HOSTS = new Set(["cdn.yourapp.com"]);

function safeImageUrl(src: string): string | null {
  if (src.startsWith("//")) return null; // protocol-relative
  try {
    const url = new URL(src);
    return url.protocol === "https:" && IMAGE_HOSTS.has(url.hostname) ? src : null;
  } catch {
    return null;
  }
}

// Back it up in the browser with a Content-Security-Policy header:
// img-src 'self' https://cdn.yourapp.com; connect-src 'self'

5. Separate and label untrusted content

Mark external content clearly so the model treats it as data, and strip zero-width text, off-screen elements and HTML comments before it reaches the prompt. Unit 42 calls this spotlighting. It helps, and it costs little. Think of it as lowering the odds, because it asks the model to behave.

6. Filter and monitor, last

Detection for phrases such as "ignore previous instructions", combined with action verbs like send or delete, will catch lazy attacks and give you useful logs. Unit 42 notes the need to go beyond pattern matching. We would add this after the steps above, never in place of them. Watch for unexpected outbound traffic and odd tool sequences, and log every tool call with its input.

7. Attack it yourself

Put a poisoned document in your test set, and check that the outcome is safe rather than that the model refused. OWASP recommends treating the model as an untrusted user in penetration tests. Run the set whenever you change a model or prompt, as we describe in our GPT-4o migration guide. A new model can shift behavior with no change to your code.

OWASP Top 10 for LLM in 2026: Which List Applies?

Many people search for the "OWASP Top 10 LLM 2026". As of this writing, the LLM list on OWASP's site is the 2025 edition, with prompt injection at LLM01, improper output handling at LLM05 and excessive agency at LLM06. The 2026 document is a separate one: the Top 10 for Agentic Applications, published on December 9, 2025. If your system calls tools, read both.

How We Apply This in Production

We do not claim our products are immune, and nobody should. The pattern we keep returning to is to let the model propose and let fixed code decide.

• Authors approve changes in BlurbBio. In our AI writing platform, only evidence and character presence are accepted automatically. Everything else waits in a review inbox, so the AI cannot quietly rewrite a book's facts. Authors get an inbox to work through, and we treat that as the correct cost.
• Findings must quote the source. A verifier checks each BlurbBio finding against the manuscript and marks what it could not ground. Fewer findings reach the author, and each run costs more.
• Routing decisions come from measurements. AskOrac, our AI chatbot platform, scores confidence from retrieval signals rather than asking the model, and those scores decide whether it replies, falls back or brings in a person.
• The widget is isolated. AskOrac's website widget runs in an iframe, with message origins pinned and validated, because it loads on sites we do not control.

Where This Is Heading

Four dated facts point the same way: more attacks, more agents, and thin public tracking of the flaws.

• Attacks are expected to improve. Google's April 2026 report found them mostly crude today, and its authors expect both scale and sophistication to grow as agents become more valuable targets.
• Attack kits are appearing. The CSA note says Google and Forcepoint both saw shared injection templates across unrelated sites, which suggests common tooling.
• CVEs will not warn you. Of the eight incidents in OWASP's round-up, the CSA notes that only Flowise received a CVE. Scanners will not flag most of this, so ask vendors how they disclose prompt injection flaws.
• Standards now cover agents. OWASP's agentic list, published in December 2025, had more than 100 contributors. If you sell to enterprises, read it before a buyer's security team does.

Before You Give an Agent More Access

Send us what your agent can read and what it can do, and we will map the path a poisoned document would take and tell you the first control to add. Our AI integration service covers this design work. If you only need answers from your own content, a retrieval chatbot with no write access removes much of the risk by design, and our comparison of chatbots and AI agents will help you decide. If a model never needs to act, do not let it.