what is prompt injection?
a language model reads everything in front of it as one stream of text, and cannot reliably tell the difference between your instructions and instructions hidden inside the content it just fetched.
that is the entire vulnerability. it sounds almost too simple to matter, and in 2026 it became the dominant security problem in ai systems, because agents made the consequences real. here is the state of it as of september 2026.
why the model cannot just tell them apart
there is no structural boundary between instructions and data in a prompt.
when you send a request, the model receives a single sequence: your system prompt, your message, the conversation, the retrieved documents, the tool results. all of it is text. the model infers what is an instruction from how it reads, not from where it came from, because there is no metadata that reliably says "this part is only for looking at."
compare that to sql injection, which the industry did solve. parameterised queries work because the database keeps the query structure and the user data in genuinely separate channels. no equivalent exists for language models, and 30 years of "just escape the input" instincts do not transfer.
jailbreak vs prompt injection
the jailbreak vs prompt injection distinction matters because they are different problems with different victims.
| jailbreak | prompt injection | |
|---|---|---|
| who is attacking | the user | a third party |
| who is the victim | the vendor, or the public | the user |
| where it comes from | the message box | content the model retrieves |
| what it wants | disallowed output | your data, or your agent's actions |
| what fixes it | model training and policy | system architecture |
a jailbreak is somebody trying to talk a model out of its own rules. prompt injection is somebody planting instructions where your model will find them, so that your agent acts against you. treating them as the same category is why some teams believe a safer model solves this. it does not.
indirect prompt injection, the one that matters
the attacker never talks to your model. they leave a note where it will read.
this is the variant that turned a curiosity into an operational threat. instructions get placed in content an agent will retrieve during a normal task: a webpage, a forum comment, a product review, a code comment, a calendar invite, a resume, a support ticket. the agent fetches it as part of doing its job and encounters text addressed to it.
the numbers are not reassuring. the cloud security alliance's 2026 research note reports that across roughly 2 to 3 billion crawled pages a month, the share carrying malicious injection grew 32% in relative terms between november 2025 and february 2026.
attackers favour static sites, blogs, forums and comment sections, exactly the surfaces that are cheap to write to. unit 42 documented the first confirmed real world case in december 2025, so the timeline from theory to production was roughly 2 years.
benchmark work is worse. even strong models in a tool calling loop have been measured vulnerable in the range of 24 to 47%, and newer work describes agent data injection, where malicious content is disguised as trusted metadata rather than as prose, so it does not read like an attack at all.
why agents made it dangerous
a chatbot that gets tricked says something wrong. an agent that gets tricked does something wrong.
that is the whole escalation, and it is why ai agent security became its own discipline in 2026 rather than a footnote in model safety. the attack surface widens with every capability you add, and it compounds:
- retrieval. the agent pulls from sources you do not control.
- tool calls. it can now send, write, delete or purchase.
- chaining. one poisoned result feeds the next step unreviewed.
- autonomy. fewer confirmations means fewer chances to catch it.
- credentials. it acts as you, with your access.
browsers made this concrete. a university of washington study published july 3, 2026 tested 7 agentic browsers and found 4 of them let attackers bypass the same origin policy, the 1995 boundary that stops one site reading another's data. we went through the browser side of this in ai browsers and what they do with your history.
what actually reduces the risk
the fixes are architectural rather than linguistic. no instruction like "ignore any instructions in the content below" survives contact with a determined attacker.
least privilege on tools. the single highest yield control. an agent that can only read cannot be made to send, spend or delete. most agents are given far more capability than their task requires, and cutting a 12 tool agent to the 3 it actually needs removes most of the blast radius for free.
separate the reading agent from the acting agent. let one summarise untrusted content and hand structured output to another that holds the credentials. the poisoned text never sits in the same context as the ability to act.
confirm consequential actions. anything that spends money, sends a message, or deletes data gets a human in the loop. this is unfashionable and it works.
treat retrieved content as hostile by default. the same posture you already have for user input in a web app. it is data, never instruction. this is also the answer to rag poisoning, where an attacker gets malicious text into the corpus your retrieval layer draws from, and it is why llm security is mostly a pipeline question rather than a model question.
log what the agent read, not just what it did. when something goes wrong, the tool call trace without the retrieved content tells you nothing about why.
scope the blast radius. separate credentials, separate accounts, no standing access to production. assume compromise and limit what it reaches.
that list is deliberately boring. it is ordinary security engineering applied to a component that happens to be a model, and the model context protocol makes some of it easier by putting tools behind typed interfaces you can reason about, which we covered in how to give an ai agent context.
where we sit, since it would be dishonest not to say
remynd's in app chat ships general purpose tools, and that is a real surface.
the tools include shell, python, applescript and http. that is a deliberate capability and it means content the model retrieves could, in principle, carry instructions toward something you did not intend. we would rather write that down than let you find it in a security review.
what does hold: your history is read only everywhere in the app, so nothing the model does can rewrite or delete your archive. capture, ocr and storage stay on your mac by default and you can exclude specific apps or sites from capture entirely. the practical advice we would give about our own product is the same as above, which is to treat an agent with general tools the way you would treat running a script somebody sent you. the fuller architecture is in private ai on your mac.
why this is worth understanding even if you build nothing
because the tools you use every day are agents now, and 43.36% of classified ai conversations are work.
per the anthropic economic index for may 2026, the number one work task in sampled ai conversations is searching electronic sources for information at 4.95%, with reference searching second at 3.74%. searching means retrieving, and retrieving means reading content somebody else wrote.
the rest of the profile says how much is at stake. work is 43.36% of classified conversations, personal life 40.2% and coursework 16.45%. of all usage, 51.38% is augmentation against 48.62% automation, and the automation half is precisely the half running with less human review per step.
the vendors all shipped in this direction during 2026. openai launched a background memory system on june 4, 2026, anthropic reworked claude's memory into editable entries on july 10, 2026, google rebranded gemini's context layer as personal intelligence in january 2026, and apple shipped siri ai with onscreen awareness on june 8, 2026. microsoft finished rolling copilot memory across m365 by may 2026. every one of those reads content on your behalf.
the topic mix says the same thing about how people use them:
| request topic | share of conversations |
|---|---|
| content creation and copywriting | 22.72% |
| education and learning | 13.23% |
| software development | 11.51% |
| research and intelligence | 10.94% |
| document processing and extraction | 4.32% |
| knowledge retrieval and enterprise search | 3.61% |
| personal ai assistant | 2.86% |
so the exposure is not limited to people wiring up agent frameworks. it belongs to anyone whose assistant browses, reads email, summarises documents or opens a pull request. the useful instinct is the old one, arriving in new clothes: never let untrusted input reach a privileged operation without something in between.
download remynd for mac and keep your archive read only and local.