Prompt injection comes in two basic forms: direct, where a user's own input changes the model's behavior, and indirect, where instructions hidden in content the model reads do it. Variants add obfuscation, repeated attempts, multi-turn setups, hidden markdown, poisoned retrieval and manipulation of agent tools.
Definitions
OWASP defines a prompt injection vulnerability as user prompts altering the model's behavior or output in unintended ways. The input does not have to be readable by a person, as long as the model parses it.
Direct injection. The attacker is the user, or the user's input carries the instruction.
Indirect injection. The model ingests external content such as a web page, file, email or code comment that contains instructions.
Types in a table
| Type | How it works | Where it shows up |
|---|---|---|
| Direct | Crafted input overrides instructions | Chat boxes, forms |
| Indirect | Instructions inside retrieved content | Browsing agents, document summaries, code review bots |
| Encoding and obfuscation | Base64, hex, invisible Unicode, hidden text | Anywhere a filter looks for plain phrases |
| Typoglycemia | Scrambled words that humans and models can still read | Keyword filters |
| Best-of-N | Many prompt variations until one slips through | Any endpoint without rate limits |
| Role-play and hypotheticals | Framing that invites the model to ignore rules | Chat assistants |
| Multi-turn and persistent | Instructions built across turns or stored in memory | Assistants with memory |
| HTML and markdown injection | Output with links or images that send data out | Chat UIs that render markdown |
| Multimodal | Instructions inside images or documents | Vision and file features |
| RAG poisoning | Malicious text planted in the knowledge base | Retrieval apps |
| Agent attacks | Forged tool outputs or reasoning, tool manipulation, context poisoning | Tool-using agents |
| System prompt extraction | Coaxing the model to reveal its instructions | Any app with a system prompt |
Why simple filters fail
The NCSC explains that language models have no built-in boundary between instructions and data, unlike a database that separates query structure from values. It advises avoiding deny-lists of known attack phrases because rewording evades them. OWASP's cheat sheet treats filters as illustrative, not complete.
What helps instead
- Least privilege for tools and data, enforced outside the model.
- Human approval for high-impact actions, checked against the exact action.
- Treat model output as untrusted before it reaches a browser, shell or database.
- Separate and label untrusted content, knowing that labels alone do not enforce a boundary.
- Rate limit and watch for repeated attempts, which counters best-of-N.
- Log inputs, outputs and tool calls, without sensitive data. Repeated failed calls can show an attacker refining an approach.
- Test with your own channels. See how to test for prompt injection.
Quick check
Is prompt injection the same as jailbreaking?
They overlap but differ. Jailbreaking tries to make a model ignore its safety rules. Prompt injection tries to override an application's instructions, often through content the user did not write.
Can prompt injection be fully fixed?
The NCSC says it may never be fully eliminated and recommends reducing likelihood and impact. OWASP says no foolproof prevention is known.
Which type is most dangerous for agents?
Indirect injection, because the attacker never touches the app. The content the agent reads carries the instruction, and tools turn it into action.
Where Safeguard fits
Safeguard offers an MCP Guardrail and agent policies that limit what a tool-using agent can do, and a free scan at gold.safeguard.sh/scan for the dependencies in your app.
Sources
- OWASP LLM01 Prompt Injection
- OWASP LLM Prompt Injection Prevention Cheat Sheet
- NCSC on prompt injection
Last reviewed: 19 October 2026.
