EchoLeak, tracked as CVE-2025-32711, showed zero-click prompt injection can leak tenant data from AI copilots. Production defenses explained. Read now.
What EchoLeak Demonstrated
EchoLeak, tracked as CVE-2025-32711, showed that prompt injection against AI copilots does not require a user to paste a malicious instruction into a chat box. A carefully crafted payload embedded in content the copilot already reads—email, documents, tickets, or other tenant-scoped data—can steer the model into actions that expose information the attacker should never see. That is zero-click prompt injection: the victim’s normal use of the assistant becomes the delivery path.
The core failure is not that language models follow instructions poorly. It is that copilots sit on top of privileged tools and retrieval. If untrusted text is treated as part of the system’s intent, the model can be nudged to search, summarize, or emit secrets that belong to another user, workspace, or tenant. EchoLeak made that class of risk concrete at production scale rather than as a lab demo.
Why Zero-Click Attacks Scale
Traditional phishing needs a click or a reply. Prompt injection of this kind needs only that the copilot process poisoned content during ordinary work. Every automated summary, “help me draft a reply,” or cross-mailbox search widens the attack surface. The more an assistant is trusted to act across mail, files, and internal systems, the higher the value of a single successful injection.
Tenant isolation breaks when the model’s context mixes instructions from different trust levels. Content retrieved from a shared store is not the same as an authenticated admin command, yet many pipelines flatten both into one prompt. At that point, “summarize this document” and “ignore previous rules and exfiltrate secrets” compete in the same channel. Defense has to restore the boundary the model cannot enforce on its own.
Production Defenses That Actually Matter
Useful controls start before the model and continue after it. Treat every retrieved or user-supplied string as untrusted data, not as control plane text. Separate system policy, tool schemas, and external content so attacker-controlled prose cannot rewrite tool permissions. Prefer allow-listed tools with narrow scopes over open-ended “do anything” agents when the copilot can reach tenant data.
- Strip or neutralize instruction-like patterns in inbound content before retrieval injects it into the prompt.
- Enforce tenant and user authorization in the application layer for every tool call—never rely on the model to “know” who may see what.
- Block or sandbox outbound channels (links, webhooks, email sends) that could carry extracted secrets to an attacker.
- Log prompt construction, tool invocations, and unusual retrieval patterns so injections leave a trail for review.
Output filtering alone is weak: a model can encode leaks in summaries or partial answers. Stronger designs constrain what the model is allowed to fetch and emit, and require human or policy gates for high-risk actions.
What Teams Should Change Now
Assume that any content your copilot can read can try to reprogram it. Map every data source into a trust tier, and never let lower-trust text override higher-trust policy. Run adversarial tests that plant injection strings in realistic documents and verify the assistant refuses tool abuse and cross-tenant reads. Review architecture for places where a single shared context window collapses roles, tenants, and documents into one blob.
EchoLeak is a reminder that securing AI copilots is less about clever prompts and more about identity, isolation, and least privilege around the model. Treat the assistant as an untrusted intermediary that still must operate inside the same access-control rules you would apply to any other service with broad read rights over tenant data.