Prompt Injection Prevention: The ISO 27090 Approach

Prompt injection prevention starts with an uncomfortable fact: a language model cannot reliably tell the instructions you gave it from the data it is reading. Anything that reaches the prompt, whether it is a user’s message, a retrieved document, a web page or a tool result, can try to act as an instruction. ISO/IEC 27090 builds its guidance around that fact, and so should you.

This guide covers the two forms of the attack, why filtering alone does not stop it, the controls ISO 27090 recommends, and the design rule that matters more than any of them: limit what a successfully injected model can reach and do.

What this guide covers

• What prompt injection is
• What goes wrong when prompt injection prevention fails
• Why detection alone is not prompt injection prevention
• The ISO 27090 controls for prompt injection prevention
• Prompt injection prevention by architecture
• The design rule: assume injection will sometimes succeed
• Testing your prompt injection prevention
• Frequently asked questions
• Making prompt injection prevention auditable

What prompt injection is

ISO 27090 describes prompt injection as content in an input instruction that makes an AI system behave in ways its builders did not intend. It comes in two forms.

Indirect injection is the one that should worry most teams. A help-desk assistant that summarises customer emails, or a research assistant that reads web pages, takes instructions from whoever wrote that content. Hidden text, invisible to a human reader, is enough.

What goes wrong when prompt injection prevention fails

The standard identifies two kinds of loss.

• Integrity: wrong, harmful or attacker-chosen output. Where that output feeds a decision or triggers an action, the damage moves from embarrassing to financial or physical.
• Confidentiality: disclosure of the system prompt, of retrieved documents the user should not see, or of data in connected systems.

Both get worse with agency. A chatbot that can only answer questions leaks text. An agent that can send email, change records or call APIs can be steered into doing those things.

Why detection alone is not prompt injection prevention

ISO 27090 is frank about the limits of detection. Because the model cannot distinguish data from instructions, injected content can look exactly like legitimate input. The standard lists useful detection techniques: classifiers on input and output, using a language model to spot induced responses, and logging with heuristics for known patterns. It also says blocklists of phrases have limited effectiveness, because open natural-language input is far harder to validate than a structured query.

So treat detection as one layer, not the defence. The OWASP Top 10 for LLM Applications makes a similar point in its LLM01:2025 entry: it is unclear whether fool-proof prevention methods exist.

The ISO 27090 controls for prompt injection prevention

Taken together, the mitigations in ISO 27090 clause 6.9 and its zero trust measures form a layered set. We group them into a baseline every LLM system should have and a few risk-driven additions.

Baseline

1. Validate and filter input. Run classifier-based filtering on prompts and on added context. It will not catch everything, but it raises the cost of casual attacks.
2. Harden the system prompt. Write internal instructions that tell the model to resist injection and define refusal behaviour. Keep secrets out of it: assume it will leak.
3. Segregate untrusted content. Wrap retrieved documents and other untrusted text in clear delimiters, and instruct the model that everything inside them is information to use, never instructions to follow.
4. Vet retrieval sources. Only admitted sources feed the context, and content added to them is checked. A retrieval repository is a write path into your model’s behaviour.
5. Limit the model’s reach. Give it the minimum data sources and tools it needs, authorise each retrieval against the end user’s own rights, and require confirmation for consequential actions.
6. Limit queries. Cap consecutive queries and session length per user, which slows systematic probing.
7. Regression test. Keep a library of injection test cases and run it on every release.

Risk-driven additions

• Check output before it is displayed or acted on, and treat model output as untrusted input to whatever consumes it.
• Separate privileged and unprivileged model calls, so a model that reads untrusted content cannot call tools directly.
• Where you control the model, train and test it on representative injection examples. For hosted models this sits with the provider.

Prompt injection prevention by architecture

The right mix of controls depends on what the model can read and what it can do. Five common patterns, from lowest to highest exposure:

Notice how the weight shifts down the table. For a plain chatbot, prompt injection prevention is mostly about input and output. For agents it is mostly about privilege, because no filter is reliable enough to stand between untrusted content and a tool that moves money or data.

The design rule: assume injection will sometimes succeed

The most important prompt injection prevention control is architectural. If injection cannot be reliably blocked, the question becomes what an attacker gains when it works.

ISO 27090’s guidance on least privilege for AI agents answers it: privileges belong to the agent, scoped to the task and expiring when it ends; API-integrated agents go through mediated access with pre-execution checks; computer-use agents run in restricted environments with action allow-lists. An assistant whose worst case is “reveals the public help-centre article it was summarising” is a very different risk from one whose worst case is “emails the customer database to an outside address”. Our AI agent security guide sets out that model in full.

Testing your prompt injection prevention

Write test cases that match how your system is attacked, and use a harmless canary string so the result is unambiguous. A useful starter set:

• Instruction overrides, role-play framings and fake “system” messages that ask the model to output the canary.
• Requests to repeat the system prompt verbatim.
• Encoded instructions (for example base64) and the same attack in another language.
• Hidden instructions planted in a test document, web page, email or mock tool result the system will read.
• Requests for another user’s data, or for documents beyond the tester’s access rights.
• Requests for actions outside the agent’s scope, and for bulk actions.
• Payloads the output might carry into a browser or database, such as script tags.

Add every successful attack from red teaming or an incident to the library, so it is tested forever after. A clean run proves the cases you thought of fail; it does not prove the system is immune.

Frequently asked questions

Can prompt injection be fully prevented?

Not with current techniques. ISO 27090 treats detection as challenging because the model cannot separate data from instructions. Prompt injection prevention is therefore about layered controls plus limiting the damage of the attacks that get through.

Is jailbreaking the same as prompt injection?

Jailbreaking is a form of direct prompt injection aimed at bypassing the limits or filters placed on a system. ISO 27090 treats it under the same heading.

Does retrieval-augmented generation make injection worse?

It adds an indirect route. Any document in the retrieval store can carry instructions, so the store needs the same write controls and vetting you would apply to training data.

Where does prompt injection sit in a risk assessment?

As one of the AI-specific compromise types assessed for every LLM-based system. Our guide to generative AI risk assessment shows how, and the ISO 27090 overview lists the other types to assess alongside it.

Making prompt injection prevention auditable

The controls above only count if you can show them: a written standard, a system prompt policy, a list of admitted retrieval sources, agent permission records, test results and logs. Comparing frameworks first? See ISO 27090 vs ISO 42001.

Our ISO 27090 Toolkit includes a Prompt Injection Defence Standard, an AI Output Handling and Encoding Standard, an AI Agent Least Privilege Standard with a permission register, and a ready-to-run Prompt Injection and Jailbreak Test Library of 26 cases mapped to the OWASP list. Whatever you use, the principle holds: filter what you can, segregate what you cannot trust, and make sure a hijacked model cannot do much.