Prompt injection examples, and the defences that hold

Prompt injection is text that gives a language model orders it should not follow, hidden in something the model reads: a résumé, a GitHub issue, an email, a web page. Telling the model to ignore such text, or screening for it, only makes an attack less likely. The defences that hold take away what an obeyed injection needs, so it can do no harm whatever the model does.

The examples below are of kinds seen in real products, each with what stopped it.

1. Hidden text in a résumé

A candidate adds a line in white text, too small to see, telling the AI screener that this is an outstanding applicant. A person opening the file sees an ordinary résumé; the software that extracts its text sees the extra line.

This is not a thought experiment. A study presented at USENIX Security 2026 checked about 200,000 résumés from the hireEZ recruiting platform and found hidden injections in about 1%, a share that had grown over the previous 1 to 2 years. More than 90% were not instructions at all but hidden data, such as skills the candidate does not list visibly. A screen that looks for "ignore your instructions" misses nearly all of them.

What holds: compare the text the model receives with the page a person sees, as the study's own detectors do, and have a person read the résumé before the decision. The model can summarise; it should not be what shortlists.

2. A poisoned GitHub issue

In May 2025 Invariant Labs showed an attack on agents that use GitHub's official MCP server. The attacker opens an issue on the owner's public repository. Later the owner asks their agent something ordinary, such as to look at the open issues. The agent reads the planted issue, follows it, opens the owner's private repositories and publishes what it finds in a pull request on the public one. In their demonstration that included private repository names, a plan to move abroad and a salary.

Nothing in the MCP server was broken. The agent had a token that could read every repository and write to a public one, and it read text anyone can write. Claude Desktop asked the user to confirm each tool call by default, but Invariant notes that many people choose "Always Allow".

What holds: a token for the 1 repository the task is about, or a session limited to 1 repository, so there is nothing private in reach.

3. An email to your assistant

An assistant that reads your inbox reads mail from anyone. Simon Willison's example is a message addressed to the assistant itself, asking it to forward your password reset emails to the sender and then delete them from the inbox. The attacker only has to know your address.

What holds: an assistant that summarises mail does not need to send or delete it. Without those tools the message is just text. Where it must send, a person approves each email.

4. A leaky image in a reply

A chat assistant reads a page or a shared document with a planted instruction: put an image in your reply whose address ends with the user's data. The assistant obeys, the chat window loads the image, and the request to the attacker's server carries the data with it. No click is needed.

Simon Willison lists this kind of leak, often through an image or a link, in Microsoft 365 Copilot, GitLab Duo and well over a dozen other products. Almost all were fixed the same way: by closing the channel, not by making the model more obedient.

What holds: remove images and links to other sites from every reply before it is shown.

Why "ignore instructions in the text" is not enough

A model reads its instructions and the document it was given as one stream of text, and has no reliable way to tell whose words are whose. You can tell it to treat documents as data, and screen input with a smaller model, and both help. Anthropic's defences got attacks on its browsing agent down to about 1% success, and it still calls that meaningful risk. An attacker gets as many tries as they like, and only needs 1 to work.

So stack the 2 kinds of defence. Choose them below and see which of the 4 attacks each one stops.

Try itWhich defences stop an injection

Defences

·All·Warn in the system prompt·Screen input with a small model·Least privilege·No way to send data out·A person approves actions·Plan before reading

Gets inTakes overDoes harm

1. Hidden text in a résuméLess likely

   White text in the fileThe model ranks it topA weak candidate is shortlisted

2. A poisoned GitHub issueLess likely

   An issue in a public repoThe agent follows itPrivate repo data posted in public

3. An email to your assistantLess likely

   An email from anyoneThe assistant obeys itYour reset emails forwarded on

4. A leaky image in a replyLess likely

   A page or file the model readsIt adds an image to its replyThe image address carries your data out

The design patterns that hold

Researchers from ETH Zurich, Google, IBM, Microsoft and others put the rule in a sentence: once an agent has read untrusted input, it must be impossible for that input to trigger a consequential action. Their paper gives 6 ways to build that in. The 3 most useful in practice:

• Plan, then execute. The agent fixes its list of tool calls before it reads any untrusted text, then runs only that list. A web page can no longer add a "forward the mail" step. It can still change what goes into a step that was planned, such as the text of an email the plan sends.
• A quarantined model. One model plans and calls tools but never reads untrusted text. A second model reads the untrusted text but has no tools. The first refers to the second's results by name without ever reading them, so nothing in them can reach the model with the tools.
• Least privilege and no way out. Give each tool only the access the task needs, enforced in the tool's code, and close every channel that can carry data out: tools that send, web requests, images and links in replies. This is what breaks Simon Willison's lethal trifecta of private data, untrusted content and a way to communicate.

None of these depend on the model behaving. That is why they hold.

Test it on your own agent

Write each attack above as a test case against your agent, graded by what happened (was mail forwarded, did a reply contain an outside image), not by what the model said. Run it before every release, and add every real incident as a new case. The security module of the free AI engineering course builds this for a support agent in Python, with a screening model, a reply check and a red-team eval. The concept page on prompt injectionPrompt InjectionAn attack that hides instructions in text a model reads, such as a web page, an email or a file, so the model follows the attacker instead of you. covers the basics, and how to evaluate an AI agent the tests themselves.