Zero Click AI Agent Exploits: How Agents Leak Data Unprompted

A zero-click AI agent exploit lets an outsider steal data through an AI assistant or agent without the victim ever opening, clicking or approving anything. The attacker plants instructions in content the agent will read later, such as an email, a calendar invite or a public web form, and the agent's own access and output rendering do the rest. EchoLeak in Microsoft 365 Copilot, ForcedLeak and SalesBleed in Salesforce Agentforce and the Gemini calendar case all followed this pattern, and all were fixed by the vendor before or at disclosure. This guide explains how these chains work, why the usual controls miss them and what defenders who build, buy or run AI agents should change. It is for security architects, AI platform owners and detection engineers. Classic zero-click exploitation of phones and messaging apps is covered in the Zero-Click Exploits Guide.

Key takeaways

• The exploit is a data flow, not a bug in code. Untrusted content reaches the model, the model mixes it with privileged data, and an output channel carries that data out. Break any one of the three links and the chain fails.
• Rendering is the silent exfiltration channel. Images, link previews and unfurls make the client fetch a URL automatically, so data hidden in that URL leaves without a click (MITRE ATLAS AML.T0077 LLM Response Rendering).
• Allow lists are only as good as their weakest entry. EchoLeak abused trusted Microsoft services and ForcedLeak used an expired domain that was still on a content security policy allow list.
• Classifiers reduce risk but do not close it. EchoLeak's email was written to pass prompt injection classifiers; deterministic controls on output and egress are what stop the data leaving.
• The agent's identity sets the blast radius. Every case reached only what the agent's permissions allowed, so least privilege for the agent is the control that limits the damage when everything else fails.

What it is

A zero-click AI agent exploit is an indirect prompt injection (MITRE ATLAS AML.T0051.001 Indirect, OWASP LLM01:2025 Prompt Injection) where the injection arrives through a channel the attacker can write to without any account, and the exfiltration completes without any user decision. The victim only does what they always do: asks the assistant a normal question, or lets an agent process its queue.

Aim Security, which found EchoLeak, called the core weakness an "LLM scope violation": instructions from an untrusted source cause the model to access and disclose data from a more trusted scope, such as the user's mailbox or files. That framing is useful because it describes the problem in terms defenders already know, an information flow crossing a trust boundary without authorisation (NIST SP 800-53 AC-4 Information Flow Enforcement).

How it works

Every documented chain has the same four stages. The details below are described at the level defenders need to recognise and block them, not to reproduce them.

1. Plant: the attacker writes instructions into a source the agent trusts as data. Observed sources include inbound email (EchoLeak), calendar invite descriptions (Gemini), public Web-to-Lead forms whose description field accepts up to 42,000 characters (ForcedLeak), and messages in public collaboration channels (the Slack AI case recorded as ATLAS AML.CS0035).
2. Retrieve: the planted content is pulled into the model's context during normal use. Retrieval-augmented generation helps the attacker here: EchoLeak spread its payload across many topics so that ordinary questions would retrieve it, a technique its finders called RAG spraying.
3. Cross scope: the model follows the planted instructions and gathers data the attacker cannot read directly, such as other CRM records, private meetings or mailbox content, using the agent's legitimate access.
4. Exfiltrate: the data leaves through a channel that needs no click.

The no-click exfiltration channels

Why it matters

• No user behaviour to train: phishing awareness does not help when the victim does nothing unusual. The only defences are in the agent's design and configuration.
• Anyone can be the attacker: ForcedLeak and SalesBleed needed no login to the victim tenant, only a public form. Any agent that reads unauthenticated input inherits that exposure.
• Agents act under their own identity: SalesBleed's third flaw let the agent post Slack replies under its own identity without confirmation or attribution, which turns data theft into phishing from a trusted sender.
• The fix is often out of your hands: EchoLeak was fixed server-side and Microsoft said no customer action was required. Salesforce fixed ForcedLeak by enforcing Trusted URLs for Agentforce and Einstein AI from 8 September 2025. You still need your own layers for the next variant, and for agents you build yourself.
• Detection is hard after the fact: an image fetch or DNS lookup looks like ordinary client traffic. If you do not log agent outputs and tool calls, you may never know a leak happened. See Investigating Agent-Initiated Data Exfiltration.

None of the four public cases above had reported in-the-wild exploitation at the time of disclosure. They are research findings, but they show the pattern is repeatable across vendors, which is why it belongs in threat models now. Read the full incident pages: EchoLeak 2025, ForcedLeak 2025, SalesBleed 2026 and the Gemini AI Calendar Prompt Injection 2026.

Common misconceptions

• "A prompt injection classifier will catch it." Microsoft describes Prompt Shields, a classifier in Azure AI Content Safety, as one detection layer among several. EchoLeak's email was phrased to pass the cross-prompt injection classifier, which is why Microsoft also relies on deterministic blocking of known exfiltration techniques.
• "We only allow trusted domains." Trust in a domain is not trust in every endpoint on it. Embed, preview and redirect services on trusted platforms can fetch arbitrary URLs, and allow list entries can expire.
• "The user would see the data leaving." Image and link payloads can be invisible or look like a broken image, and ATLAS notes data can be split across multiple requests.
• "It is the vendor's problem." Vendors fix specific chains. Which data the agent can reach, which connectors are enabled, whether external content is ingested and whether outbound actions need approval are your decisions.
• "A better system prompt will fix it." Hardened system prompts help, but the model cannot reliably tell instructions from data. Treat the model as an untrusted component and enforce policy outside it.

Defences that work

Microsoft's published defence model for indirect prompt injection has three layers: prevent the injection, detect it, and prevent the impact. The impact layer is the one that has stopped every public zero-click chain, so prioritise it.

Design patterns for agents you build

Researchers from several AI companies and institutes published "Design Patterns for Securing LLM Agents against Prompt Injections" (2025), which Microsoft cites as foundational. The shared idea: once an agent has read untrusted input, constrain what it can do next. In practice that means an agent that reads external email should not also hold a tool that sends data to arbitrary destinations in the same session, or a privileged planner should decide actions before untrusted content is read and never let that content change the plan.

Phased rollout

1. Inventory: list every assistant and agent, its data connectors, its untrusted input sources and its output channels (rendered chat, Slack or Teams posts, email, tool writes).
2. Rank by exposure: agents that read unauthenticated input and have broad data access and any no-click output channel come first.
3. Close output channels: disable image rendering and unfurling for agent output, or proxy them, and test with benign canary URLs that you control.
4. Tighten allow lists: replace domain wildcards with exact hosts, remove embed and preview endpoints, and check every entry for ownership and expiry.
5. Add confirmation for external writes, piloting with one team first and measuring how often users approve without reading.
6. Red-team in a test tenant with planted content in each input source, then add the cases to regression tests. See AI security regression testing.
7. Roll back safely: keep rendering and connector changes as tenant or feature flags so you can revert a single control if it breaks a business process, rather than disabling the assistant.

Detection and measurement

• Log: retrieved source IDs per response, tool calls with parameters, rendered URLs and agent-initiated network requests.
• Alert on: agent output containing URLs to hosts never seen before, long or high-entropy query strings in rendered URLs, writes to external recipients after reading external content, and DNS queries for unusual subdomains from agent runtimes.
• Metrics: percentage of agents with image rendering disabled or proxied; number of wildcard or unverified allow list entries; percentage of external-facing writes requiring confirmation; red-team canary exfiltration success rate (target zero); mean time to apply a vendor advisory for an AI feature.

Related concepts

ATLAS records several of these chains as case studies, including AML.CS0059 (EchoLeak), AML.CS0035 (Slack AI) and AML.CS0066 (ZombieAgent, an indirect injection through ChatGPT connectors demonstrated by Radware), which are useful inputs for threat modelling.

Where identity fits

The agent is a non-human identity acting with delegated access. Give each agent its own identity rather than a shared service account, scope its connectors to the minimum data, and make its outbound actions attributable. After a suspected leak, revoke the agent's tokens and connector grants, then reissue from a clean configuration. See the Agent Identity and Access Guide.

Practitioner checklist

• Inventory every AI assistant and agent with its untrusted input sources, data connectors and output channels.
• Disable or proxy image rendering, HTML and link unfurling for model output wherever the use case allows.
• Replace domain-level allow list entries with exact hosts, remove embed and preview endpoints, and review entries for expired domains each quarter.
• Require human confirmation for agent writes visible outside the tenant or to new recipients, and attribute agent-posted messages clearly.
• Scope each agent's identity and connectors to the minimum data, and apply sensitivity labels and DLP to keep labelled data out of responses.
• Log retrieved sources, tool calls and rendered URLs, and alert on new external hosts and long encoded query strings.
• Red-team each agent with planted content in every input source and keep the cases as regression tests.
• Track AI vendor advisories and confirm server-side fixes in your tenant, since many have no CVE or KEV entry.

Standards and references

• OWASP: LLM01:2025 Prompt Injection
• OWASP: LLM05:2025 Improper Output Handling
• MITRE ATLAS: AML.T0077 LLM Response Rendering
• MITRE ATLAS: AML.CS0059 EchoLeak case study
• Microsoft MSRC: How Microsoft defends against indirect prompt injection attacks
• arXiv: Design Patterns for Securing LLM Agents against Prompt Injections
• NIST: SP 800-53 Rev. 5 Security and Privacy Controls

Related NHI Mgmt Group resources: Zero-Click Exploits Guide · Prompt Injection Guide · Agent Egress Control and Network Isolation Guide · Prompt Injection Incident Response Playbook · Enterprise AI Assistant Buyer's Guide