CompoundTrust

EchoLeak: when the user is no longer your control point

A researcher sent one email. The recipient never opened it, never clicked anything, never downloaded anything. Days later they asked their assistant an ordinary question, and their private files left the tenant inside the answer.

Episode 10 · 8 min read · Zero-click · Scope violation · Retrieval logging

Zero-click means what it says

Every phishing control you own assumes a human decision. Someone opens something. Someone clicks something. Someone approves something. Awareness training exists because of that assumption, and so does most of your detection.

Retrieval removes the assumption.

An assistant with access to a mailbox reads everything in that mailbox. It does not wait to be asked about a particular message. It searches for context and takes what it finds — which means an attacker who can put text in front of the retriever no longer needs the user at all.

That is the whole shift. The attacker needs the retriever, not the person.

Four controls, each one opened

Microsoft had defences in place. This is worth sitting with, because the interesting thing about EchoLeak is not that controls were missing. They were present, individually reasonable, and bypassed in sequence.

That last one is the pattern worth generalising. Any trusted domain that will fetch a URL on your behalf is an egress path, whatever your allow-list says.

Nothing was escalated, which is why nothing fired

Aim Labs called this an LLM scope violation. Untrusted content persuades the model to apply privileged access it legitimately holds.

No credential was stolen. No permission was escalated. No vulnerability was exploited in the traditional sense. The assistant did exactly what it was entitled to do, for a reason it should not have accepted.

That is precisely why a detection stack built around anomalous access stayed quiet. There was no anomaly. There was an authorised read, followed by an authorised send.

Three places this already exists in an ordinary enterprise

The recruitment assistant. It reads CVs and covering letters — documents written by strangers, submitted deliberately, in formats that carry hidden text comfortably. It holds candidate records and internal scoring notes. It can draft and send email. Untrusted content in, private data held, outward channel available.

The support copilot on the ticket queue. Your customers write the untrusted content, and they write it directly into the system, which is the entire point of the product. The assistant holds account history for every other customer. It replies to the ticket. Same three ingredients, arriving through the front door.

The finance assistant on the shared inbox. Invoices are attachments from outside. The assistant holds payment records and supplier details. It can compose email, and in more automated setups it can raise a payment request. This is the one I would look at first, because the outward channel has money attached to it.

None of these is an exotic deployment. All three are things organisations are switching on this quarter.

The general rule

Three ingredients: the assistant reads untrusted content, it holds private data, and it can communicate outward.

Any system with all three can be made to leak. Meta published a rule of thumb for this in October 2025 — no more than two of the three, without a human in the loop. It is blunt, and it is the most useful blunt instrument available.

What I would actually do

Cut egress before you tune the filter. Disable automatic image and link rendering in assistant output. Allow-list what remains. Then treat any trusted domain that will proxy an arbitrary request as untrusted, because that is exactly what defeated Microsoft's content security policy.

Inventory assistants by capability, not by product. The question is not which vendor you bought. It is: what untrusted content reaches this, what does it hold, and where can it send things. Three columns. Most organisations can fill the first two immediately and stall on the third.

Log which documents entered the context window. Almost nobody does this. Most log the prompt and the answer, and both look innocuous in this class of incident — the instruction was in the middle, in material the system chose to read and chose not to record. Without retrieval logging you cannot investigate it. You will not even know it happened.

Stop treating the classifier as the boundary. It is worth having. It is not what is holding the risk. What is holding the risk is whatever constrains the outward channel, and if the answer is nothing, that is the finding.

Three questions for a vendor

  1. What untrusted content can reach this system, and through which paths?
  2. What can it send outward, to where, and can that list be enumerated?
  3. Do your logs record which documents entered the context window for a given answer?

The third question is the one that separates a product built by people who have thought about incident response from one that has not.

The part that is architecture, not configuration

Zero-click means the user is no longer your control point. Scope violation means permissions are no longer your control point.

What remains is architecture — what the system can reach, what it holds, and where it can send things. Those are design decisions, and they are made once, usually early, usually by someone who was not thinking about this.

Put the three questions to one system this week. If all three answers are large, you have found your next piece of work.

Sources

Nobody was phished. Nobody made a mistake. The user did everything right — and that is the part your current controls have no answer for.

← All field notes