EchoLeak and the Zero-Click Lesson for Every AI Agent Owner

Awareness training rests on a quiet assumption: a chain needs the target to do something. Open the attachment. Approve the dialog. Tap the link. Withhold that action and the chain stalls. An assistant wired into your mailbox retires the assumption, because whatever reads the hostile text is no longer a person capable of hesitating.

The clearest public demonstration of that shift carries a name. Aim Labs reported the finding against Microsoft 365 Copilot, and it is tracked as CVE-2025-32711, which SOC Prime's write-up of the disclosure describes as critical with a CVSS score of 9.3, notes Microsoft's advisory called fully resolved with nothing required from customers, and reports with no evidence of actual exploitation. Everything below sits at defender level: mechanism, blast radius, and the controls that shorten it. No payload text, no reproduction procedure.

Why "Nobody Clicked" Still Reads as Safety

The belief is simple to state. Absent a human action, an inbound message is inert. Two decades of phishing programs trained everyone to locate the decision point and defend it, and for a mail client that decision point genuinely existed.

Retrieval assistants dissolve it. The product's whole value is that it consumes your correspondence, documents and channels without waiting for permission per item. Instruction-following is the feature, not a defect, and nothing in a transformer distinguishes a sentence a colleague wrote from a sentence an outsider planted. The consumer of the attacker's prose is software your company bought precisely because it reads everything.

The belief also persists because it keeps working everywhere else. Endpoint controls, mail gateways and browser isolation are all built around a human decision point, and they still earn their licence cost on ordinary traffic. Nothing about an assistant invalidates that estate. It simply adds one component that sits outside the estate's central assumption, and a control model fails quietly when a new component violates the premise the whole model was tuned against.

Where the Assumption Collapses in a Live Assistant

Coverage of the research describes a sequence of four defeated controls, which is the right abstraction level for threat modelling. Infosecurity Magazine reported that Aim Labs published in June 2025, having first contacted Microsoft in January of that year, with the fix finalised in May. The four defeated controls it names:

• An injection classifier evaded. Hostile instructions phrased as ordinary correspondence addressed to a human read as benign to a filter trained on attack-shaped text.
• Link redaction evaded. The layer meant to strip references out of assistant output did not catch every reference format.
• Image redaction evaded. Neither did the equivalent layer for image references, which matters because images load without a decision from anyone.
• Content security policy evaded. The browser-level restriction on where the rendered page may reach did not hold either.

Aim Labs labelled the root idea an LLM Scope Violation: outside text steering a model into privileged material it should never touch for that text's benefit. Press framing called this the first known zero-click attack against an AI agent, per the SOC Prime report linked above. That superlative belongs to the reporting, not to a census, and the only honest reading is that it is the first one disclosed this crisply.

"This is a novel practical attack on an LLM application that can be weaponized by adversaries."

Aim Labs, quoted by Infosecurity Magazine

The Model That Replaces "Find the Click"

Simon Willison's lethal trifecta is the sharpest naming of the preconditions. He lists access to your private data, exposure to untrusted content, and the ability to externally communicate. Hold all three in one session and a leak is reachable; drop any one and the specific chain dies.

The instructive leg here is the third. Nothing in the chain called a send-mail tool. Rendering an outbound reference was itself the transmission, which is why an inventory of an agent's declared tools understates its egress. Meta's published agent security guidance turns the same observation into a design budget, capping a session at two of three properties: processing untrustworthy input, reaching sensitive systems, and changing state or communicating outward. Treat a hosted assistant as subject to that budget too, because the product tier does not change the arithmetic.

So the working rule for review: anything the agent can read, an outsider can probably author, and anything the rendering surface can fetch is an exit. We are still arguing in this field about how to label provenance inside a context window, and until that argument resolves, structural separation beats trusting the model to behave.

If this chain is new to you, the background on production prompt injection defenses and on adversarial instructions crossing agent boundaries covers the underlying class before you start inventorying.

One more consequence is worth stating plainly, because it changes who owns the remediation. The legs are rarely owned by one team. Retrieval scope belongs to whoever configured the index, the rendering surface belongs to a client or a front-end group, and the identity the agent borrows belongs to platform engineering. A finding that nobody can fix alone tends to sit in a backlog, so name an owner per leg before you name a deadline.

Controls That Actually Remove a Leg

Inventory the rendering surface, not just the tool list. Enumerate every way agent output reaches a screen or a downstream service. Automatic image loading, unfurled link previews, markdown renderers that resolve references, and webhook sinks are all exits. Each one is either disabled, or restricted to destinations you enumerate.

Audit the allow-list you already trust. A policy that permits a broad collaboration platform, a redirector or a caching proxy is weaker than its length suggests, because an outsider can frequently write content on those hosts. Narrow entries beat long ones.

Keep outside text out of the privileged retrieval pool. External senders and internal files sharing one index is the condition that made scope violation possible. Tag provenance at ingest. Where the workflow genuinely needs both, split it: one stage reads the untrusted material and emits a constrained summary, a second stage holds the data access and never sees raw outside prose.

Rank redaction as a layer, never as the control. Format variants defeated two redaction layers in this case. A filter that fails open on an unfamiliar encoding is a speed bump worth keeping and worth never relying on.

Alert on the shape of the output. Novel hostnames in generated references, long opaque strings inside a reference, and a sudden jump in outbound fetches from a rendering client are all detectable without understanding the prompt. Pair that with the monitoring signals worth collecting for agents, and you get a chance at noticing the next variant rather than reading about it.

When the Vendor Patch Belongs to Someone Else

Microsoft shipped this fix on its own infrastructure, so tenants inherited it. That is the pleasant case and it is not your common case. The assistants multiplying inside most companies are assembled in-house from a model endpoint, a retrieval index and a handful of connectors, and for those, you hold the vendor's obligations without the vendor's release process.

Three questions per agent settle most of it. What outside prose can reach its context? What confidential material sits in that same context? What can the agent or its display layer cause to be fetched? Teams that cannot answer all three have found their first task, and the answers usually arrive faster than a procurement cycle for a new control. The same reasoning applies to neighbouring cases: see the indirect injection lessons from a CRM assistant and the wider pattern in zero-click chains against agents.

What the Platform Vendor Published Afterwards

The useful follow-up document is the vendor's own. In July 2025, shortly after this disclosure, Microsoft's Security Response Center set out how it defends against indirect prompt injection, and the structure of that post is more instructive than its contents. It sorts the work into preventing the injection, detecting it, and preventing the impact, and it labels the first two as probabilistic. Hardened system instructions and a technique called Spotlighting, which marks untrusted text in three documented modes so the model can tell data from instruction, sit in the first group. A classifier called Prompt Shields, shipped inside the content safety service, sits in the second.

The third group is the one that maps onto the chain described above. The post names data governance through sensitivity labels, including a data loss prevention policy that stops the assistant summarising a labelled file at all, and deterministic blocking of known exfiltration routes, with image injection in markdown called out by name. That is the same route the reporting describes here. It also names threat protection for AI workloads in the cloud defender product, with alerts arriving in the vendor's extended detection portal, and human approval patterns where a person has to press send. Two items on the page are research rather than product, an information flow control approach and a technique that inspects a model's internal activations, and they should not go into anyone's control matrix yet.

For the severity and patch wording specific to this identifier, go to the vendor's advisory entry for CVE-2025-32711 rather than to coverage of it, and confirm the state of your own tenant. Press accounts and advisories drift apart over time, and the advisory is the artefact an assessor will ask for.

The class did not close with the fix, either. In August 2026 the same researchers who demonstrated chains against enterprise agents described a follow-on class against agentic browsers, in which hidden instructions collide with the user's real request, and reported that some vendors patched quickly while others treated the behaviour as intended. That is a finder describing its own work without independent reproduction, so label it as a claim. The direction of travel is still the point: the surface moved from the mailbox to the browser, and the shape held.

Where the Trifecta Framing Falls Short

The three-leg model is the best diagnostic available for this class, and as a remediation plan it quietly misleads. Its promise is that dropping any one leg kills the chain. In practice two of the three legs are negotiable and the third is almost never dropped, because external communication is not a tool you can remove from a list. It is a property of anything that renders. A link preview resolves. An image loads. A markdown reference fetches. An agent with no outbound tool at all still has an exit as long as something displays its output, which is exactly what happened here: nothing called a send-mail function.

Follow the framing literally and a team spends its quarter trying to make the egress leg go away, enumerating render paths, tightening a content policy, and discovering that the last remaining path is a product feature somebody bought the suite for. The vendor's own list is the tell: it files deterministic blocking of exfiltration routes under limiting the impact, not under removing the capability, which is an admission that the capability stays.

So the leg to attack is the private data leg, specifically the shared retrieval pool. Separating outside prose from confidential material at ingest is unglamorous, it is owned by whoever configured the index, and it is the only one of the three a team can actually finish. Use the trifecta to decide which agents to look at, and do not use it to decide which leg to cut.

This does not hold on a platform that genuinely lets you turn off every form of reference resolution and asset fetching in the display surface, and where you can prove it with a harmless destination you own. On that platform, cutting egress is cheap and correct, and it should be done first. It is worth testing for rather than assuming in either direction, because the answer differs between two surfaces inside the same product suite.

Ordered by Effort, Starting This Week

1. Write the three trifecta legs for every agent that ingests mail, tickets, chat or web content from outside the company. One page per agent.
2. Check whether that agent's output can cause an automatic outbound fetch, using a harmless host you own as the destination. This is a configuration question, not an exploit.
3. Re-read the content security policy and the proxy allow-list of the surfaces that display agent output, looking for user-writable hosts.
4. Ask each assistant vendor how untrusted content is isolated during retrieval, and request their disclosure and patch history in writing.
5. Add the scenario to the next tabletop: outside text changes what the assistant does, so what leaves, and which log would show it.
6. Rebuild the highest-risk agent so that no single session holds all three legs. This is the expensive item and the only one that removes the class.

None of this is an audit of your environment or a legal opinion on your disclosure duties. It is analysis of a patched, publicly reported issue, and production risk decisions need a qualified security professional looking at your actual topology.