Prompt Injection: Why There Is No Filter That Fixes It

Prompt injection is what happens when text a language model reads gets treated as instructions rather than as data. It is the defining security problem of model-backed systems, and it is genuinely unsolved in the sense that no known input filter reliably prevents it. That is an uncomfortable thing for a vendor to say and an important thing for a buyer to understand, because it determines what you should actually build.

The distinction that matters

Direct prompt injection is a user typing something intended to override the system's instructions. It gets the attention because it is easy to demonstrate, and it is mostly a content-policy problem: the blast radius is bounded by what that user could already access. Embarrassing, occasionally reputationally awkward, rarely a breach.

Indirect prompt injection is the serious one. The instruction arrives inside content the system retrieved and chose to trust: a web page, a support ticket, a PDF, a calendar invite, a code comment, a product review. Nobody typed it into your interface. And when an agent acts on it, the action runs with the agent's privileges rather than the attacker's.

That privilege inversion is the whole problem. An attacker who never authenticated, never had an account, and never touched your product can cause an action to execute as your trusted agent. Every other consideration is downstream of that sentence.

Why filtering does not solve it

Injection is not a syntax problem, so there is no pattern to match. Instructions and data are the same thing to a language model: text. The boundary you imagine between your system prompt and retrieved content is a convention the model approximates rather than a security control it enforces.

Classifiers help at the margins and are worth having as one layer, but they are probabilistic, and the space of ways to express an instruction is effectively unbounded. Any defence whose success depends on recognizing malicious phrasing is in an arms race it does not win. Treat filtering as friction, not as a control you would testify to.

What actually reduces the risk

Constrain privilege. The single highest-value control. Scope each agent's tools and credentials to its specific task, and scope them per user rather than giving the agent a service account that can read everything. An agent that cannot reach the payroll data cannot be induced to exfiltrate it, regardless of what any document tells it. Most serious AI incidents we would expect to see are not clever injections; they are over-privileged agents doing exactly what they were permitted to do.

Gate the consequences. Separate reading from acting. Retrieval and summarization can run freely; anything that moves money, sends external communication, modifies records, or deletes should require human approval or a hard-coded policy check outside the model. Injection you can survive is not a breach. Design so the worst realistic outcome is a wrong answer rather than a wrong action.

Distrust retrieved content structurally. Keep retrieved material in a clearly separated channel, strip active content, and do not let a document's contents alter which tools are available. Where a retrieval corpus accepts user-submitted or externally scraped content, treat every item in it as attacker-controlled, because some of it eventually will be.

Log and test. Record prompts, retrieved sources, and tool calls, because you cannot investigate what you did not log, and an AI incident with no trace of which document caused it is unresolvable. Then test adversarially rather than waiting to find out.

What this means for buying decisions

Two practical implications. First, be sceptical of any product positioning a prompt-injection filter as a complete solution; ask what happens when the filter is bypassed, and if the answer involves the agent's full privileges, the filter is not the control. Second, when scoping your own build, spend the architecture effort on privilege and approval gates rather than on prompt hardening. Prompt hardening is cheap to attempt and cheap to defeat.

This is also why an ontology or a similarly governed data layer helps: an agent that can only invoke defined, permissioned actions against known objects has a much smaller usable attack surface than one holding database credentials, as covered in what is an ontology.

Where it sits in governance

Prompt injection is the clearest example of why AI governance has to be wired into the build rather than written as policy. A document stating that agents must not exfiltrate data does nothing; a permission scope enforced in code does. Both ISO/IEC 42001 and the NIST AI Risk Management Framework expect controls to be implemented and evidenced rather than declared, and the practical build sequence is in how to build an AI governance framework. Which framework you anchor to is covered in ISO 42001 vs NIST AI RMF.

Where BD Emerson fits

We test these systems as systems, not as chatbots, through AI-augmented offensive security: prompt injection reaching real tools, retrieval sources an attacker can poison, agent permissions scoped wider than the task, and human checkpoints that exist in the policy but not in the code. Because the same firm runs enterprise AI implementations and AI governance programs, the remediation advice comes from people who have built these architectures rather than only broken them.