Prompt injection: the attack that needs no click

Conventional software keeps instructions and data apart. Code is code, input is input, and a document cannot issue an order. A language model does not have that boundary. Everything it receives arrives as text, and text that looks like an instruction can be followed like one.

That is prompt injection, and OWASP ranks it first in its 2025 Top 10 for LLM applications, as LLM01.

The case that made it concrete

On 12 June 2025 The Hacker News reported a "zero-click" vulnerability that allowed attackers to “exfiltrate sensitive data from Microsoft 365 (M365) Copilot's context sans any user interaction”. It was found by Aim Security, given the identifier CVE-2025-32711, and scored 9.3.

The academic write-up describes it in one line: “EchoLeak (CVE-2025-32711), a zero-click prompt injection vulnerability in Microsoft 365 Copilot that enabled remote, unauthenticated data exfiltration via a single crafted email.”

Read what "zero-click" means here. The victim did not open an attachment or approve anything. The assistant read the mail as part of its ordinary work, and the instruction hidden in it was executed against the data the assistant could already reach.

Microsoft fixed it server-side in the June 2025 Patch Tuesday, and stated that “There is no evidence that the shortcoming was exploited maliciously in the wild.” The response was fast and the outcome was good. The lesson is not that the product was weak; it is that the attack surface exists wherever an assistant reads untrusted text and can reach trusted data.

The dangerous combination is not a clever model. It is a model that reads what strangers send and can reach what only staff should see.

Why retrieval raises the stakes

Retrieval-augmented generation exists to feed the model company documents. That is the feature. It also means every indexed document is model input, and an indexed document can be written by someone outside the company: a supplier's invoice, an emailed contract draft, a CV.

OWASP's list covers the consequences alongside injection itself: sensitive information disclosure at LLM02, excessive agency at LLM06, system prompt leakage at LLM07, and vector and embedding weaknesses at LLM08.

On-premise does not solve this

This has to be said plainly, because the opposite is implied constantly in this market. Local inference protects the data boundary. It stops a document being sent to an external service in normal operation. It does not stop a malicious document from steering the model.

A local model that can read the shared drive and send email has the same structural problem as a hosted one. The perimeter moved; the confusion between instruction and content did not.

What local deployment does change is the exfiltration path. An injected instruction still needs a way out, and EchoLeak's way out was an outbound fetch. A system with no outbound connectivity gives that instruction fewer places to send anything.

What actually reduces the risk

• Keep retrieved content and instructions structurally separate, and treat every document as untrusted
• Give the model the narrowest tool permissions that still do the job
• Enforce the user's own access rights at retrieval time, not after generation
• Validate outputs before another system acts on them
• Constrain where the system may connect, so a successful injection has nowhere to send data
• Test adversarially, with documents written to attack your own assistant

The single rule under all of them: never give an AI system more authority than the task requires. A model that reads documents is one risk. A model that reads documents, sends mail, queries the finance system and runs code is a different category of problem.