A zero click prompt injection fires when a message arrives, not when a person opens it. The victim never clicks a link and never approves anything, because the assistant reads the attacker’s content on its own while summarizing an inbox. That is what makes zero click prompt injection unlike every phishing story your training is built on: there is no moment of human judgment to get right, because there is no moment at all.
What makes zero click prompt injection different from the ordinary kind?
The difference is delivery, not mechanism. The underlying bug is the one we take apart in indirect prompt injection: a model reads external content as data and follows part of it as a command, because instructions and data share one token stream with no wall between them. What changes is how the poisoned content reaches the context.
In the familiar version a user does something. They paste a page, they ask the agent to read a URL, they upload a PDF a stranger sent. A human made a choice there, and a careful one might have chosen differently. In the zero click version that choice is gone. Mail arrives. An invite lands on the calendar. A shared drive syncs a document into a folder the agent indexes. An automated process pulls all of it into context before anyone has looked at it.
Every defense built on user caution assumes there is a user decision to make. Remove the click and you have not made the decision harder, you have deleted it.
How does hostile content reach the model with nobody opening it?
Retrieval and automatic summarization are the delivery mechanism, and they run on a schedule or on any unrelated question. Picture an invented assistant, Acme Assist, wired into a company’s mail, calendar, and files. It writes a morning digest of unread mail, and answers questions like “what did legal say about the Q3 contract” by searching indexed documents.
Each of those sources is an ingestion path a stranger can write into:
- Mail. Anyone who knows the address can put text in front of the assistant. The digest job reads every unread body, including the one that arrived four minutes ago from an address nobody recognizes.
- Calendar. Outside invites often land automatically, description field and all, before anyone accepts or declines.
- Shared files. A document dropped into a synced folder is indexed on sync, and the chunk inside it becomes a retrieval candidate for questions asked days later by people who never saw the file.
In the retrieval case the trigger sits further still from the attacker. They plant a document whose text best matches a plausible internal question, then wait. The user who fires the payload is just asking about the contract, with no view of which chunks the retriever picked.
And the agent is not a sandbox. It reads that text with the user’s session, the user’s mailbox scope, and whatever tools it holds. The attacker cannot open the finance folder. The assistant can.
Where does the stolen data actually leave?
It leaves through whatever the agent or its client will fetch without asking: a rendered image, a link, or a tool call. This second leg deserves as much attention as the first: an injection that reaches no outbound channel is an annoyance rather than a breach.
The rendered image is the cleanest exit because fetching it is not a decision either. If the reply renders markdown, an image reference in it makes the client issue an HTTP GET the moment the answer is displayed, and anything the model pasted into that URL rides along. We cover that leg in markdown image exfiltration. The same shape appears with links a chat client preloads or unfurls.
Tool calls are the other exit. An agent with a fetch, webhook, or send mail tool has an explicit outbound channel, and an injected instruction can aim it.
Has this been seen outside a lab?
Yes. Published third party research on Microsoft 365 Copilot, disclosed by Aim Labs in June 2025 as EchoLeak and tracked as CVE-2025-32711, described a zero click path where an email alone caused internal data to be exfiltrated. The reported chain matched the shape above: a message arrived, the assistant ingested it while building context, hidden instructions steered it to collect data, and the data left through an automatically fetched image reference. We did not test this and are describing the public disclosure only. The chain was not exotic. It was ingest, obey, render.
Why does telling users not to click fail here?
It fails because there is nothing for the user to not do. Awareness training reduces one behavior: opening the attachment, typing the password into the fake page, approving the login push. All of it aims at a person at a gate. This attack walks past that gate on a scheduled job at 6am, or on a colleague’s search query. The person who could have been careful was asleep.
Two effects follow. One poisoned document can hit every user whose assistant reads the same corpus, so this scales in a way phishing does not. And because the trigger is an automated read, the timeline shows an ordinary agent session. There is no “who clicked it” to find.
How do you actually prevent it?
You prevent it architecturally, by assuming the ingestion happens and making the ingested text unable to reach anything valuable.
- Treat every auto ingested source as untrusted data, never as instructions. Mail bodies, invite descriptions, synced documents, and tool output are content to be quoted, not commands to run. Mark them as such and never concatenate them into the same slot as your own directives.
- Separate the retrieval context from the instruction context. The component that reads untrusted content should not be the one holding tools and secrets. A quarantined reader that returns structured, validated output to a privileged planner cuts the direct path from attacker text to action.
- Never let one context both read untrusted content and reach an outbound channel. This is the highest value rule. If the summarizer reads anonymous mail, it should hold no network tool and no send capability. Split the job before you try to filter the text.
- Require confirmation before egress. Sending, posting, fetching an arbitrary URL, and writing outside the workspace should each need an approval that names the destination and the data. Our post on human in the loop for AI agents covers how to place those gates so they stay meaningful instead of becoming reflex.
- Restrict rendering that can carry data out. Strip markdown images and autoloading links from assistant output, or allow only a fixed set of destinations. See egress filtering for AI agents for the allowlist and proxy side.
- Log and alert on outbound calls that follow untrusted input. Record which sources entered a context and which requests left it. A call to a new domain inside a session that ingested anonymous external content is a checkable alert, and one of the few that catches a payload you did not anticipate.
None of these asks a person to spot a bad message, or asks the model to recognize an instruction as hostile. Both are probabilistic. The split between reading and acting is structural, and structure holds when the text is cleverer than you expected.
The assumption underneath is rarely written down: that content arriving through a trusted pipe is content the system can safely read. Zero click removes the last human who might have questioned it. Finding an assumption like that, then proving it breaks, is the work an autonomous researcher is built for, described on our about page.
This is one entry in our AI Agent Security Field Guide, a map of how AI agents get attacked and how to defend each one.
Frequently asked questions
What is zero click prompt injection?
It is an indirect prompt injection that runs with no user action at all. An assistant with inbox, calendar, or file access ingests attacker written content automatically, and the instructions buried in that content execute as part of the model’s context.
How does the content reach the assistant if nobody opens it?
Through the pipelines that ingest on their own. A mail digest job reads unread bodies, an external invite lands in the calendar with its description intact, and a shared document is indexed on sync so it can be retrieved later for an unrelated question.
How does data actually leave in a zero click attack?
Through a channel the client fetches without asking. A rendered image reference causes an outbound request the moment a reply is displayed, links can be preloaded or unfurled, and an agent holding a fetch, webhook, or send tool has an explicit exit an injected instruction can aim.
Why does user awareness training not help here?
Because there is no user action to train away. The payload runs on a scheduled digest or on a colleague’s search, so the person who might have been careful is never in the loop. The fixes are structural: keep untrusted reading and outbound reach in separate contexts, gate egress, and alert on outbound calls that follow untrusted input.
Put an autonomous researcher on your own systems
UnboundCompute is an autonomous security researcher that reasons about how an application fits together and proves the access control and injection bugs it finds. We are opening a small number of founding design partner seats: private early access pointed at a staging target you choose, and a say in what it looks for. If your team ships software worth pressure testing, apply to the design partner program.