Prompt Injection in Email and Calendar Agents

Email and calendar agents are the most dangerous category of AI deployment in the enterprise today, and the danger is structural. They satisfy what what has been called the lethal trifecta: an agent that holds private data, ingests untrusted content, and can communicate externally is exploitable by design, and there is no patch that removes any one of those three properties without breaking the product. This piece traces how that structure got built, who proved it worked, and what happened once it reached production systems handling real mail and real calendars.

How enterprise adoption outran security controls built for a different threat model

Task-specific AI agents are projected to jump from under 5% of enterprise applications in 2025 to 40% by 2026, an eightfold rise inside a single year. That gap is the story here.

Enterprise email security was built on an assumption that held for decades: instructions come from authenticated users, through defined interfaces, and anything outside that channel is data. An agent dissolves that boundary. Once a system reads a document, a message, or a calendar invite and treats its contents as context for a decision, instructions can arrive from anywhere the agent looks, and the agent has no reliable way to tell a legitimate directive from a planted one.

In a direct attack, the user types the malicious prompt themselves, knowingly or not; in an indirect attack, or IPI, the payload sits inside a document, an email body, a calendar description, or a web page. In a direct attack, the user types the malicious prompt themselves, knowingly or not. In an indirect attack, or IPI, the payload sits inside a document, an email body, a calendar description, or a web page that the agent later ingests as routine data. The user never touches the payload. Someone else wrote it, and the agent found it on its own.

That distinction is what makes this categorically different from phishing. Phishing defenses train people to recognize risky behavior: don't click the link, don't open the attachment, check the sender address. None of that applies here, because the user did everything correctly. They asked their assistant to summarize an inbox or check a calendar, which is the entire point of the tool, and the compromise happened anyway. There is no habit to correct, because there was no mistake.

The 2023 proof of concept that established the mechanism before the agents existed to exploit it

Researchers demonstrated the mechanism behind all of this more than two years before agentic email and calendar tools reached the market. In April 2023, researcher Cristiano Giardina published a page called "Bring Sydney Back," carrying a hidden 160-word prompt written in invisible text. When Bing Chat users asked the bot to read that page, the hidden text told it that it was speaking with a Microsoft developer who had authority to override its normal rules. The page pulled in more than 1,000 visitors and drew Microsoft's attention within 24 hours because the mechanism worked every time it was tried.

In 2023 the worst case was a chatbot slipping into an unauthorized persona. Embarrassing, maybe a little alarming, but contained, because the chatbot's blast radius stopped at the text on the screen. The attack surface set the damage ceiling. Today the identical mechanism reaches inboxes, shared drives, and meeting rooms, because the systems reading the poisoned text now have hands.

The term "prompt injection" itself predates even that demonstration. Simon Willison coined it in September 2022, following Riley Goodside's early work exposing the technique against GPT-3. Researchers Greshake et al. later formalized the indirect variant in a dedicated paper, and by 2024 and into 2025, OWASP and MITRE had taken over canonical numbering and classification for the industry. The vulnerability class is well studied. What changed is what it now has access to.

The three landmark 2025 incidents and how the attack plays out in production

Three separate 2025 disclosures show the trifecta playing out against real, shipped products, not lab demos.

EchoLeak, tracked as CVE-2025-32711, was disclosed by Aim Security researchers Pavan Reddy and Aditya Sanjay Gujral and rated critical by Microsoft with a CVSS score of 9.3. It affected Copilot integrations across Word, Excel, PowerPoint, Outlook, and Teams. The attack chain starts with an ordinary-looking email carrying a hidden payload, embedded as an HTML comment or as white-on-white text invisible to the recipient. When Copilot retrieves that email through its retrieval-augmented generation context, it executes the attacker's instructions and can exfiltrate chat logs, OneDrive files, SharePoint content, or Teams messages to an external server, with no click and no user action required. The exploit bypassed Microsoft's XPIA classifier through careful phrasing, evaded link redaction using reference-style Markdown, and got past Content Security Policy restrictions through an allowlisted Teams image proxy. One documented variant even reconstructed a malicious link and presented it to the end user directly, which moves the point of compromise from email delivery, where scanners look, to the AI interaction itself, where they don't. Microsoft issued a server-side patch in May 2025 and stated that no customer action was required.

The second incident, titled "Invitation Is All You Need," came from researchers Ben Nassi, Stav Cohen, and Or Yair, targeting Google's Gemini. The vector here was calendar invite titles, email subjects, and shared document names carrying embedded prompts. Of the threats the team identified, 73% were rated high to critical risk, and documented capabilities included stealing emails, tracking a user's location, streaming video calls without consent, and manipulating connected home devices such as lights, window shades, and heating. Google acknowledged the research through its AI Vulnerability Rewards Program and published a blog in June 2025 outlining a multi-layer mitigation approach. The calendar invite, in this case, is the trifecta compressed into a single object: the description field is the untrusted content, the calendar itself holds the private meeting data, and Gemini's scheduling actions are the channel for external communication.

A separate, distinct vulnerability in Gemini's calendar handling was disclosed by Miggo Security, with Head of Research Liad Eliyahu identifying the mechanism. Malicious natural-language instructions embedded in a calendar event description sat dormant until the victim asked Gemini an entirely innocent scheduling question. At that point Gemini read the hidden instructions, exfiltrated private meeting data into a new calendar event visible to the attacker, and created deceptive events of its own, all without the victim ever interacting with the malicious content directly. Eliyahu said: "Because Gemini automatically ingests and interprets event data to be helpful, an attacker who can influence event fields can plant natural language instructions that the model may later execute." Google Calendar's own privacy controls did nothing to stop it, because the victim only had to ask a normal question about their day.

The third case, AgentFlayer, came out of Black Hat USA 2025, presented by Zenity co-founder and CTO Michael Bargury alongside threat researcher Tamir Ishay Sharbat. It documented zero-click and one-click exploit chains against ChatGPT, Copilot Studio, Cursor paired with Jira's MCP integration, Salesforce Einstein, Google Gemini, and Microsoft Copilot, using email and calendar invites as entry points. Once an agent engaged with the poisoned content, it could be turned into what amounts to a deceptive insider: serving falsified financial data, running phishing attempts from a trusted internal address, impersonating colleagues, or quietly exfiltrating past conversation history. Modern AI assistants have "grown arms and legs," gaining access to emails, documents, and calendars along with the ability to act across enterprise systems, and an external attacker needs nothing more than a target's email address to take over their agent. Vendor response to the disclosure split sharply. Some vendors patched the issues. Others declined, characterizing the behavior as intended functionality, which is itself a significant data point about how the industry currently thinks about this risk.

The retail bank incident: what happens when no one is watching the agent's context window

In February 2026, a retail bank deployed an internal copilot built to read employee email, summarize attachments, and draft replies through a multi-step agent loop. Three weeks in, the security operations center noticed something odd: an analyst's mailbox was forwarding a one-line message to a competitor's domain, empty body, subject line a single base64-encoded string.

The concealment techniques documented across the incidents above, white-on-white text, invisible fonts, HTML comments, are precisely the kind of payload that would survive routine document review and reach an agent's context window undetected.

From the model's point of view, such an instruction sits in the same context window as the trusted system prompt, as plain tokens with no marker distinguishing command from content. No safety filter catches it, because nothing in a conventional pipeline is built to ask whether an instruction belonged there. It just uses language.

The specific techniques attackers use to make payloads invisible to humans and legible to agents

The concealment methods across these incidents follow a consistent logic: they make the payload invisible to a human reader while keeping it fully legible to whatever model parses the raw text or markup that carries it.

HTML comments and white-on-white text are the simplest version, confirmed in EchoLeak: an email client renders nothing unusual, but the LLM engine parsing the underlying markup sees the full instruction. The retail bank incident shows the same idea applied to documents, using a one-point white font that no reviewer would ever notice on a printed or scrolled page.

Thread poisoning works differently. An attacker replies into an existing email thread and buries instructions inside the quoted section of the reply. Agents that process the full thread as context ingest the poisoned history right alongside the legitimate messages, and early-planted instructions can be especially durable when agents process the full thread as context.

Role assumption is the fourth technique, and it works by forging authority rather than hiding text. An email formatted to resemble an IT policy update or an administrative announcement can trick an agent into treating its contents as a system-level instruction rather than user data. HiddenLayer's "Policy Puppetry" research found that formatting prompts as structured policy files, in XML, INI, or JSON, and combining that formatting with roleplaying language, bypassed safety guardrails across every major LLM the researchers tested.

A newer, more systematic approach emerged in 2025 under the name Email-Specific Prompt Injection, or ESPI. Standard template-based injection attempts are not especially effective against email agents on their own, achieving attack success rates of only 4.58% to 8.13% in tested settings. ESPI does better by combining techniques that reframe the attacker's desired action as a necessary remediation step, convincing the agent that fixing a fabricated problem requires doing what the attacker wants. Across 480 controlled trials, ESPI reached a 73.54% attack success rate, and across 870 black-box test instances it successfully hijacked all 63 evaluated applications, needing an average of only 1.84 to 1.89 attempts to land the first successful hijack. Responsible disclosure around this research produced formal risk acknowledgment from 22 vendors and the assignment of 16 CVE identifiers.

Exfiltration itself doesn't have to go through the obvious channel. Researcher Johann Rehberger demonstrated against ChatGPT plugins as early as 2023 that an agent instructed to render a Markdown image, whose URL secretly encodes stolen data, will exfiltrate that data over ordinary HTTP traffic. That route sidesteps outbound email filtering entirely, since nothing about it resembles an email leaving the network.

Prompt injection classifiers, the tools built specifically to catch this class of attack, perform at close to chance, with an AUROC between 0.43 and 0.59, whenever an attack works through context manipulation. Prompt injection classifiers, the tools built specifically to catch this class of attack, perform at close to chance, with an AUROC between 0.43 and 0.59, whenever an attack works through context manipulation instead of obvious injection vocabulary. A context-informed red-team loop that targets context parameters directly, rather than searching for suspicious phrasing, achieves a 96.7% attack success rate against a tested email assistant. The classifiers are looking for the wrong thing.

Why conventional email security tools

Everything documented above points to the same structural failure: conventional email security was built to inspect messages, not to inspect what an autonomous reader does with those messages afterward. Spam filters, reputation scoring, attachment sandboxing, and link rewriting all operate on the assumption that a human is the one deciding to trust the content. They check whether a sender's domain is spoofed, whether a link matches a known malicious pattern, whether an attachment carries a known malware signature. None of that machinery has any concept of an instruction embedded in body text, because for the entire history of email security, body text was never something the system itself obeyed.

Agents change what the message actually is. A calendar invite is no longer just data about a meeting; it's a set of tokens that will sit inside a model's context window and potentially get treated as an instruction. An email is no longer just a communication between two people; it's a payload delivery mechanism that requires no attachment, no link, and no malicious domain to succeed, because the entire attack lives in plain language that any scanner would wave through as ordinary conversation.

The EchoLeak bypasses illustrate this: the exploit got past a purpose-built classifier (XPIA), past link redaction, and past Content Security Policy, three separate layers of defense, each doing what it was designed to do, none of them designed to catch a sentence that just happens to be an order. The 0.43 to 0.59 AUROC figure for context-based attacks says the same thing in statistical terms. A defense built to recognize the vocabulary of an attack fails once the attack stops needing unusual vocabulary.

None of this means the tools in place are worthless. Sender authentication, attachment scanning, and link reputation still stop the older classes of attack they were built for. But they were never built to answer a different question, the one that now matters most: not "is this message dangerous to the person reading it," but "is this message dangerous to the agent acting on their behalf." Until that question has its own layer of defense, the trifecta stays open, and every inbox and calendar running an agent stays exposed by design.