Prompt Injection Explained: What It Is and How to Protect Your Team
Prompt injection in plain language: how hidden instructions trick AI tools, why AI agents raise the stakes, and five defences any manager can use.
Prompt injection is when someone hides instructions inside content an AI tool reads, such as a web page, an email or a PDF, and the AI follows those instructions instead of yours. In the 2025 edition of its Top 10 for LLM Applications, OWASP ranked it first (LLM01:2025). No single product fixes it. What protects you is limiting what your AI can do without you.
What is prompt injection, in simple terms?
Large language models (LLMs) are the engines behind AI assistants like ChatGPT, Copilot, Gemini and Claude. They read text and decide what to do next.
The problem: they can't reliably tell the difference between your instructions and text that only looks like instructions.
The UK's National Cyber Security Centre (NCSC) puts it plainly: "Current large language models (LLMs) simply do not enforce a security boundary between instructions and data." (NCSC)
So if a document your assistant reads contains a line addressed to the AI, the AI may treat it as a request from you. That's prompt injection.
What is the difference between direct and indirect prompt injection?
OWASP and MITRE ATLAS (a public knowledge base of attacks on AI systems) both split prompt injection into two main types: direct and indirect.
| Direct injection | Indirect injection | |
|---|---|---|
| Who writes it | The person using the AI | Someone else, hidden in content the AI reads |
| Where it lives | The chat box | Web pages, emails, documents, shared files |
| Typical goal | Get the AI to ignore its rules | Get the AI to act against its user |
| Who carries the risk | Mostly the AI provider | You, and everything the AI can access |
Direct injection is a user trying to talk a chatbot out of its guardrails. OWASP defines it as a user's prompt that "directly alters the behavior of the model". It matters to the companies that build AI tools. For most professionals, it isn't the main worry.
Indirect injection is the one to understand. OWASP describes it as what happens when an LLM "accepts input from external sources, such as websites or files." You didn't write the instruction. You may never see it: it can be hidden in formatting or buried deep in a long document. You only asked your assistant to summarise something.
Why does prompt injection matter more now that AI agents can take actions?
A chatbot that only writes text can only do limited harm. The worst case is usually a wrong or misleading answer, which you can still catch before you use it.
An AI agent is an AI tool that can take actions for you, not just write text. Many tools can now browse the web, read your inbox and open files in shared drives, then act: send an email, accept a meeting, update a record, run code. When an AI that can act reads untrusted content, an injected instruction can turn into a real action.
OWASP's 2025 list has a separate entry for this: Excessive Agency (LLM06:2025), which covers giving an AI more functions, permissions or independence than its job needs. Prompt injection is the trigger. Excessive agency is what makes it costly.
The NCSC article quotes a useful rule from researcher Simon Willison: "when an LLM processes information from a party, the privileges it has drops to that of the party." Put simply: when your assistant reads an email from a stranger, treat it as if that stranger is at the keyboard.
What does prompt injection look like in practice?
These are illustrative scenarios, not reported incidents. They show the shape of the risk without the mechanics. Two documented cases, in Microsoft 365 Copilot and Slack AI, follow in the deeper section below.
- The biased summary. You ask an AI browser to compare three suppliers. One supplier's site contains hidden text aimed at AI assistants, asking them to describe it as the best choice. Your summary comes back quietly tilted.
- The inbox assistant. Your AI email assistant can read and send mail. An incoming message carries instructions aimed at the assistant, asking it to forward recent messages to an outside address. If the assistant can send without asking you, it might.
- The shared document. A file from a partner includes a comment addressed to AI tools. You ask your assistant to "summarise this and email the team", and the comment tries to change what gets sent.
- The CV. An applicant hides text in a CV telling AI screening tools to rate them highly. Nobody is "hacked", but a hiring decision is skewed.
What these have in common: the AI read something you didn't write, and it had the power to do something with it.
Can prompt injection be fixed?
Not completely, at least not yet. The NCSC says "it's very possible that prompt injection attacks may never be totally mitigated in the way that SQL injection attacks can be." It also warns that blocking known bad phrases is unreliable, because an attack can be reworded endlessly.
That is an honest assessment, and it changes the goal. You won't stop every injected instruction. You can make sure that when one gets through, it can't do much damage.
The NCSC recommends focusing on "deterministic (non-LLM) safeguards that constrain the actions of the system". In plain terms: rules enforced by ordinary software and by people, not by asking the AI to behave.
How do you protect your team from prompt injection?
Five defences, in the order I'd put them in place. Each one lines up with mitigations published by OWASP or the NCSC.
1. Require human approval before actions
Any AI action that sends, pays, deletes, shares or publishes should pause for a person to confirm. OWASP lists human approval for high-risk actions as a core mitigation. Turn on "ask before acting" settings wherever your tools offer them. This one control turns many injection scenarios from incidents into near-misses.
2. Limit what an injected instruction could reach
An assistant that summarises documents doesn't need permission to send email. One that drafts replies doesn't need the finance drive. Review what each AI tool is connected to and remove anything it doesn't use. The NCSC's version: don't let an AI that reads email from strangers have access to privileged tools.
3. Keep untrusted content separate
OWASP recommends separating and clearly labelling untrusted external content. For you, that means being deliberate about mixing. An AI session that browses the open web or reads outside email shouldn't also hold your sensitive files and be able to act on them. Where your tools allow it, use separate assistants or profiles for "reading the outside world" and "working on internal data".
4. Treat what the AI hands back as untrusted
If the AI read something you didn't write, its output may carry that content's agenda. Check summaries, links and recipients before you act on them. The NCSC also advises logging AI inputs, outputs and tool calls so suspicious activity can be spotted.
5. Ask vendors two injection questions
- Do you label or isolate outside content before the model sees it, and can you show me how?
- Have you tested the product against indirect injection hidden in pages, emails and files, and will you share what you found?
If a vendor's whole answer is "our model is trained to ignore injected instructions", ask the follow-up: what happens when that training fails? For the wider list, covering permissions, identity, logging and cost, see the vendor questions in my AI agents guide.
Going deeper: for security and IT teams
Identifiers. OWASP tracks the vulnerability as LLM01:2025. MITRE ATLAS tracks the technique as AML.T0051 LLM Prompt Injection: "An adversary may craft malicious prompts as inputs to an LLM that cause the LLM to act in unintended ways." Its sub-techniques are AML.T0051.000 Direct, AML.T0051.001 Indirect and AML.T0051.002 Triggered. The indirect entry says these prompts arrive "via separate data channel ingested by the LLM" and "may be hidden or obfuscated from the user." For agents, OWASP's Top 10 for Agentic Applications files the outcome under ASI01 Agent Goal Hijack. Use these IDs in red-team reports and your risk register so findings line up.
Mechanism. The model receives one token sequence. The system prompt, the user's request, retrieved documents and tool output are concatenated into it, and role markers are a convention the model learned, not a boundary the runtime enforces. Every retrieval or connector call carries attacker-controllable text across your trust boundary. The injected text does nothing on its own. Harm needs a capability: a tool call, or an output path such as a rendered image or link that makes the client fetch a URL and carry data with it.
Threat model. The attacker needs no account in your tenant, only a way to put text in front of the model: an email to a monitored mailbox, a public page, a shared file, a channel the assistant indexes. What they get is capped by the assistant's read access and its output channels.
In practice: EchoLeak. Microsoft's CVE record for CVE-2025-32711, published 11 June 2025, reads: "Ai command injection in M365 Copilot allows an unauthorized attacker to disclose information over a network." It scores CVSS 3.1 base 9.3, CWE-74. The case study by Reddy and Gujral describes one crafted email enabling remote, unauthenticated exfiltration with no click. The chain got past Microsoft's XPIA (cross prompt injection attempt) classifier, evaded link redaction with reference-style Markdown, and used auto-fetched images. The lesson: a detection classifier was one layer, and it was not enough.
In practice: Slack AI. PromptArmor reported on 20 August 2024 that instructions planted in a public channel could steer Slack AI's answers to other users, potentially exposing content from private channels the attacker had not joined. Slack's reply, quoted in the write-up, called public-channel search "intended behavior".
Injection-specific defences, probabilistic to deterministic.
- Provenance marking. Spotlighting (Hines et al., 2024) transforms untrusted input so the model can tell where it came from. MSRC describes three modes: delimiting, datamarking and encoding. In the paper's experiments on GPT-family models, attack success fell from above 50% to below 2%.
- Detection. MSRC calls Prompt Shields in Azure AI Content Safety "a probabilistic classifier-based approach". It integrates with Microsoft Defender for Cloud, so alerts can reach the Defender XDR portal.
- Deterministic output controls. Block the exfiltration channel whether or not the injection was caught. MSRC describes deterministically blocking a markdown image exfiltration technique and "certain untrusted links". Strip or proxy images and links in model output.
- Architectural isolation. Simon Willison's Dual LLM pattern keeps a privileged model with tools away from untrusted text, which only a quarantined model without tools reads; ordinary code passes references between them. Willison himself calls it "pretty bad" for usability. CaMeL (Debenedetti et al., 2025), which Willison credits to Google DeepMind, stops untrusted data from changing program flow and enforces policy on tool calls. It solved 77% of AgentDojo tasks with provable security, against 84% undefended.
Detection and testing. Log the full prompt context with the source of each segment. Alert on model output that references domains outside an allowlist. In a test tenant, plant documents carrying harmless instructions and check whether the assistant obeys them. Ask vendors which of the four layers they ship, and which are deterministic.
Key takeaways
- Prompt injection is hidden instructions in content your AI reads, followed as if they came from you.
- Indirect injection, through web pages, emails and files, is the version most professionals should focus on.
- The risk grows with what the AI can do. An AI that can send, pay or delete needs tighter controls than one that only drafts text.
- There's no complete fix yet, so limit the damage: human approval, least privilege, separation, and checking what the AI hands back.
- Ask vendors how they keep outside content apart from your instructions, and whether they've tested against indirect injection.
Checklist: before your AI reads outside content
- Anything it could send, pay, delete or share pauses for a person to confirm.
- The assistant that reads web pages and outside email can't also reach your sensitive files.
- You check its summaries, links and recipients before acting on them.
- The vendor has answered the two injection questions above.
Sources
- OWASP Gen AI Security Project: LLM01:2025 Prompt Injection (definitions of direct and indirect injection, mitigations)
- OWASP Gen AI Security Project: Top 10 for LLM Applications 2025 (ranking, including LLM06:2025 Excessive Agency)
- OWASP Gen AI Security Project: Top 10 for LLM Applications 2026. OWASP published this update on 3 August 2026. I haven't confirmed its rankings, so every ranking in this post is from the 2025 edition.
- MITRE: AML.T0051 LLM Prompt Injection, the MITRE ATLAS technique as referenced in MITRE D3FEND, with direct, indirect and triggered sub-techniques. Full matrix at MITRE ATLAS.
- MITRE: AML.T0051.001 Indirect (ATLAS sub-technique definition, as referenced in MITRE D3FEND)
- OWASP Gen AI Security Project: OWASP Top 10 for Agentic Applications, 9 December 2025 (ASI01 Agent Goal Hijack)
- UK National Cyber Security Centre: Prompt injection is not SQL injection (it may be worse), 8 December 2025
- CVE Program: CVE-2025-32711 (Microsoft as CNA; description, CVSS 3.1 9.3, CWE-74), published 11 June 2025
- Pavan Reddy and Aditya Sanjay Gujral: EchoLeak: The First Real-World Zero-Click Prompt Injection Exploit in a Production LLM System, arXiv, 6 September 2025
- PromptArmor: write-up on data exfiltration from Slack AI, 20 August 2024 (disclosure timeline, Slack's response)
- Hines et al.: Defending Against Indirect Prompt Injection Attacks With Spotlighting, arXiv, 20 March 2024
- Microsoft MSRC (Andrew Paverd): How Microsoft defends against indirect prompt injection attacks, 29 July 2025 (Spotlighting modes, Prompt Shields, deterministic blocking)
- Simon Willison: The Dual LLM pattern for building AI assistants that can resist prompt injection, 25 April 2023
- Debenedetti et al.: Defeating Prompt Injections by Design (CaMeL), arXiv, 24 March 2025, revised 24 June 2025