What Is Prompt Injection?

Prompt injection is an architectural problem rather than a bug, and that is why it has no complete fix. A language model receives instructions and data through the same channel, and has no reliable mechanism for deciding which parts of the text carry authority.

A conventional application can separate the two — that is precisely what a parameterised query does. A model cannot, because the separation would have to be semantic rather than syntactic.

Direct and indirect

Direct injection is a user telling the model to disregard its instructions. It matters mainly where the system prompt is sensitive or the model holds privileges the user does not.

Indirect injection is the serious case. Instructions are planted in content the model will process later — a retrieved web page, a summarised document, an email, a support ticket, a code comment, a calendar invitation.

Why filtering does not solve it

Input filtering fails for the same reason spam filtering never finished: the space of phrasings is unbounded, attackers adapt, and attempts can be encoded, translated, split across documents or hidden in markup.

Guardrail models help and are worth deploying. They are a probabilistic layer that reduces the rate — not a boundary you can rely on. Designing as though filtering is sufficient produces a system that fails silently the first time someone phrases it differently.

What actually contains it

The second row is also the one most often removed for convenience. Sending, paying, deleting or modifying records should involve a person, and an agent designed without that checkpoint has concentrated the entire risk into a single point.

Testing an AI feature for it

Injection is testable, and the test is mostly about capability rather than cleverness. Establish what the model can do, then check whether hostile content in its input can make it do those things.

• Enumerate the tools and permissions the model holds, including anything reachable through a retrieval layer
• Plant instructions in every content source it ingests — documents, tickets, pages, emails, calendar entries
• Check retrieval scoping by asking, as a low-privilege user, for something only a higher-privilege user should see
• Test the output boundary, since injected content frequently chains through a second component that trusted the model
• Verify the confirmation step genuinely blocks the action rather than merely displaying a prompt

The third and fifth items find the most serious issues. A retrieval layer querying with a service account rather than the user's own permissions is a data exposure independent of any injection.

Where to start

List what your AI features can do without a human confirming. If anything on that list is consequential and also processes content from outside your organisation, that is where the confirmation step belongs.

See prompt injection risks for business applications and AI vendor risk. GuardsArm tests AI-enabled applications through application penetration testing.