In June 2025 an email arrived. Nobody opened it.

The assistant read it anyway, because that is the job. Buried in the message was text the recipient could never see, hidden the way spam has hidden text for twenty years, as a comment in the markup or as white letters on a white background. The assistant read that too. It treated the hidden text as instructions, went and collected internal files, and sent the contents to a server that did not belong to the company.

That is CVE-2025-32711, published in June 2025. Microsoft's own description is four lines long. "Ai command injection in M365 Copilot allows an unauthorized attacker to disclose information over a network."

It scored 9.3 out of 10.

The researchers who found it called it EchoLeak. The detail that matters is not the nickname. It is one field in the severity record.

Read the vector, not the headline

Every published vulnerability carries a scoring string that describes how it works. Most people skip it. This one is worth reading, because it settles the argument before it starts.

Two fields. Privileges required, none. User interaction, none.

None means none. Not one click, not one accepted dialog, not one careless employee to blame afterward. The attack proceeded because a message was delivered and an assistant did what assistants do. There is no training course that fixes this, because there was no human decision to train.

The scope field is set to changed, which is how these records say the damage crossed a boundary. Something reached out of the assistant and into systems it was only supposed to read for you.

The model was working correctly

This is the part that unsettles engineers when it lands.

A language model reads a single stream of text. Your instructions and the content it was asked to look at arrive in the same channel, in the same format, with no reliable marker separating them. When the assistant retrieved that email into its working context, the hidden sentences were simply more text.

The model did exactly what it was told. Not by you.

Nothing malfunctioned. No buffer overflowed. No credential leaked. The system read its input and followed it, which is the entire function you bought. Traditional security has a hundred years of practice separating code from data. This class of system has no equivalent, because the instruction and the data are the same substance.

Microsoft fixed this specific case on the server side and reported no exploitation in the wild. The category did not go anywhere.

Compare it to a threat your team already understands. SQL injection was solved by separating the query from the values, so the database can tell the difference between an instruction and a name. Thirty years of tooling grew out of that one idea. No equivalent separation exists here, because the assistant's power comes from reading anything you put in front of it, in whatever form it arrives.

Ninety-five percent is a failing grade

Simon Willison, who has tracked this problem since it was named, puts the state of play plainly. We still do not know how to reliably prevent it.

He also makes a point about vendor promises that belongs in every procurement conversation. Guardrail products advertise catching 95 percent of attacks. In security, he says, 95 percent is very much a failing grade.

Sit with the arithmetic. An attacker does not need to succeed often. They need to succeed once, and they can try continuously, at no cost, forever. A control that stops 95 of every 100 attempts is not a control. It is a delay.

That number would be excellent for a spam filter, where the cost of a miss is an annoying message. It is meaningless for exfiltration, where the cost of a miss is the document.

Three ingredients, and you only need to remove one

The useful contribution from that same work is a checklist rather than a technology. Willison calls it the lethal trifecta. An agent is exposed when it has all three of the following.

  • Access to your private data.

  • Exposure to content from outside your control.

  • A way to communicate outward.

Any two are survivable. An assistant that reads your files and can send email, but never touches untrusted input, is doing ordinary work. An assistant that reads the public web and can send email, but holds nothing confidential, is a research tool.

All three together is the exposure, and the third one is easier to remove than people assume. An agent that can read anything and act on anything but cannot originate outbound traffic has no way to hand your data to anyone.

The Copilot case had all three. Private mail and files, an inbox open to the world, and a path outward.

Run the test on something closer to home. A support agent that reads incoming tickets, looks up customer records, and posts replies has all three, and nobody thinks of it as risky because every part of it is ordinary. The ticket is untrusted content. The customer record is private data. The reply is the path out.

This is a category, not an incident

It would be comfortable to treat one CVE as a bug that got patched. The research says otherwise.

Two years ago a team at ETH Zurich built AgentDojo, an environment for testing exactly this class of attack against agents doing realistic work. Email management, banking, travel booking. It contains 97 tasks and 629 security test cases.

Nobody builds 629 test cases for an incident. You build them for a property.

Their finding was blunter than the number. Existing attacks break some security properties and not others, and the models fail plenty of the tasks even when nobody is attacking them.

What actually reduces the risk

The architectural move is the same one that keeps showing up whenever a probabilistic component meets a process with consequences. Separate the part that interprets from the part that acts.

Let the model read. Let it summarize, classify, extract, propose. Then have it hand a structured result to something that decides whether the proposed action is allowed, using rules a person wrote and can inspect.

The model can be persuaded by text it reads. A rule cannot. If the agent proposes sending 40 megabytes to an address nobody has ever contacted, the rule refuses, and it refuses identically whether the request came from your employee or from a comment hidden in an email.

One caution, because it is the popular answer and it is weaker than it looks. Putting a human in the loop helps only if the human can actually see what is being approved. Approving a summary tells you nothing about the tool calls that produced it. If the review step shows an outcome rather than an action, it is a signature, not a control.

This is unglamorous and it is not what the demo shows. The demo shows the agent doing the whole thing by itself, which is the version with all three ingredients.

The test to run this week

List every AI assistant and agent running in your organization. Include the ones a team enabled without asking anybody, because those are the interesting ones.

For each, answer three questions. Can it reach data you would not publish. Can it ingest content from outside your control, including email, documents, tickets and web pages. Can it send anything outward, including a web request, an email, a webhook or a code execution tool.

Count how many score three out of three.

Then ask the question that follows, which nobody enjoys. For each of those, who approved that combination, and what did they think the third one was for?

Sources