CVE-2025-32711 showed a zero-click Copilot flaw could expose enterprise context through prompt injection. Learn how to detect and block leaks. Read now.
What EchoLeak Exposed
CVE-2025-32711, known as EchoLeak, showed that a zero-click flaw in Copilot could surface enterprise context through prompt injection. The attacker did not need the user to paste a malicious instruction or click a suspicious link. Content that the assistant already ingested—mail, documents, chat history, or other connected sources—could be steered so the model treated untrusted text as higher-priority instructions and then echoed sensitive material in a place the attacker could observe.
That pattern is the core of prompt leakage: untrusted input reshapes model behavior so private context leaves the intended trust boundary. Enterprise assistants are especially exposed because they sit on top of broad retrieval and tool access. A single weak boundary between “data the model may read” and “instructions the model may follow” is enough to turn helpful retrieval into an exfiltration channel.
How Leakage Actually Happens
Most leaks are not glamorous jailbreaks. They are ordinary products of how assistants are wired. Retrieved snippets are concatenated into a prompt. Tool results and prior turns are treated as reliable. Safety filters focus on blocking harmful generation rather than on whether the answer contains secrets that should never leave the tenant. Injection hides in plain content—headers, footers, comment fields, ticket descriptions—where the model is trained to be cooperative and thorough.
Zero-click matters because the victim never has to “run” the attack. Opening a message or letting the assistant index a document can be enough if that content is later retrieved into a session the attacker can influence or observe. The failure is architectural: treating all retrieved text as equally authoritative, and treating model output as free of confidential fields by default.
Detecting Prompt Leakage
Detection starts with treating model outputs and tool calls as security-relevant events, not just product logs. Watch for answers that restate tokens that should never appear outside a vault: API keys, session identifiers, internal URLs, customer identifiers, or full document bodies when the user only asked a high-level question. Correlate retrieval traces with outputs: if a turn pulled a sensitive document and the reply includes verbatim spans from it without a clear, authorized need, flag the session.
- Log prompt composition at a redacted level: which sources were retrieved, which tools ran, and whether output matched sensitive patterns.
- Run canary strings in low-privilege documents and alert if those strings ever appear in outbound answers or external tool payloads.
- Review sessions where untrusted content (email, web, tickets) sits next to high-privilege retrieval in the same prompt window.
Blocking Leaks Before They Ship
Hard boundaries beat clever wording. Separate instruction channels from data channels so retrieved text cannot override system policy. Constrain tools so the model cannot send full context to external endpoints without an explicit, audited user action. Apply output filters that strip or refuse known secret formats and tenant-specific markers, and fail closed when confidence is low. Prefer least-privilege retrieval: only the fields required for the task, with short time-to-live on cached context.
Operationally, treat every new connector as an attack surface review. Ask what untrusted parties can write into the corpus, what the model can read in the same turn, and where answers go next. EchoLeak’s lesson is practical: assume injection will arrive as ordinary enterprise content, design so that content cannot rewrite policy, and verify continuously that private context never becomes the reply.