Can one email make your AI assistant hand over internal data

When an organisation connects Microsoft 365 Copilot, which Microsoft now calls Microsoft Copilot, or ChatGPT to the inbox, the documents and the web, the assistant starts reading text written by people outside the organisation. Copilot prompt injection, and the same thing in ChatGPT, is when that text contains instructions the model follows instead of what the user asked for. Every data source that is switched on is therefore also a way in, and what a single email can extract in the worst case is set by what the assistant can reach.

What is prompt injection, and why does it concern the assistant you already have?

Prompt injection is not a fault in one product but a property of the technology. The UK's National Cyber Security Centre, NCSC, wrote in December 2025 that current language models do not enforce a security boundary between instructions and data inside a prompt. To the model it is all text, and a sentence in an email can steer the answer even though the user never wrote it.

The variant that concerns most organisations is called indirect prompt injection. The attacker never writes to the assistant. The attacker writes an email, a document or a web page, and waits for the assistant to read it on someone else's behalf. In its explainer on prompt injection from November 2025, OpenAI describes how the instructions are often hidden in ordinary content such as a web page, a document or an email, and writes that the risks increase as the assistant gains access to more sensitive data and takes on more initiative.

That is why permissions matter. Microsoft writes in its Copilot documentation that the assistant only surfaces organisational data to which the individual user has at least view permissions. That protects against someone seeing data they have no right to, but it also means the assistant's reach is the user's reach. Anything an employee can open, including folders that were shared too widely long ago, the assistant can pull into an answer.

One email was enough: the Copilot prompt injection called EchoLeak

The case that showed the pattern in a major product came in 2025. Researchers at Aim Labs, then part of Aim Security, found a vulnerability in Microsoft 365 Copilot that they called EchoLeak and reported it to Microsoft. Microsoft published it on 11 June 2025 as CVE-2025-32711 and rated it critical, at 9.3 out of 10 in its own assessment. The US National Vulnerability Database, NVD, put it at 7.5. Both assessments state that the attack required neither privileges nor any action by the user.

Aim Labs' own account, now published by Cato Networks, where the research group is today, describes the mechanism. The attacker sent an email worded as if it were addressed to the recipient and never mentioning AI or Copilot. That is why Microsoft's filter against injected instructions did not catch it. When the user later asked a question that led Copilot to retrieve the email, the assistant followed the instructions and placed the most sensitive data it had in front of it into an address in its answer. The address was fetched automatically, so the data left the organisation without anyone clicking. This also required the attacker to get around Microsoft's own safeguards against links and images in Copilot's answers. According to Aim Labs, anything in Copilot's context could leak: the chat history and what the assistant had retrieved from the user's mail, files and channels.

The email needed no permissions of its own, because it borrowed the assistant's.

The vulnerability has been fixed. Microsoft writes that it is fully mitigated and that customers need take no action, and at publication the company assessed that it had not been exploited. Aim Labs states that Microsoft confirmed no customers were affected. What makes the case relevant, then, is not the vulnerability itself but the pattern: an email from outside got access to what lay inside, because the assistant read both in the same stream.

Don't the filters catch this?

Often, but not always, and the difference is what counts. A large open measurement of how filters hold up against an attacker who is really trying is LLMail-Inject, a challenge organised by Microsoft together with ISTA and ETH Zurich and accepted to the Findings track of the EMNLP 2026 conference. Participants sent an email to a simulated email assistant and had to make it send an email the user never asked for, in other words to make the assistant act rather than merely answer. Each sub-level of the challenge had one of several defences, and some sub-levels had all of them at once. In the main phase, from December 2024 to February 2025, 292 teams submitted 370,724 attempts, not all of which were attacks.

The outcome can be read two ways, and both readings are right. The great majority of attempts never got the assistant to send anything. The researchers write that there were many obstacles on the way to a successful attack, and that stacking defences on top of each other gave a significant improvement. But around 7,200 submissions made the assistant call its send function without any defence stopping it. An attacker does not need to succeed often. Succeeding once in the right inbox is enough. The challenge concerned a simulated assistant that could send email and models that are older today, so the figures say something about how defences behave against persistent attackers and nothing about the level in any particular product. The researchers later replayed the attacks from the challenge against models released afterwards, without adapting them, and a substantial share still succeeded.

The NCSC draws the same conclusion from the technology itself. It writes that prompt injection will remain a residual risk that cannot be fully mitigated with a product or appliance, and that it has to be managed through how the system is designed, built and operated. Microsoft in effect says the same about its own protection. According to Microsoft's description, Defender for Office 365 Plan 2 detects prompt injection in inbound email, but the protection focuses on three kinds of attempt, among them exfiltrating data through a URL, and Microsoft itself writes that the safeguards inside the assistant are still needed for what the filter in the mail flow cannot see.

Which data sources should your AI assistant be allowed to read?

The practice that makes prompt injection expensive is not using the assistant. It is switching it on with the user's full reach, without anyone asking what that reach contains or who can write in what the assistant reads. Microsoft states that Copilot grounds its answers in content in Microsoft Graph, such as emails, chats and documents the user has permission to access. The inbox therefore comes with it, and the inbox receives text from the whole internet. Shared documents and shared channels can be edited by customers and partners. Web search fetches pages anyone may have published.

Reading the inbox is often the whole point of the assistant, which is why everything else decides how far an email can reach. Much of what lies within reach is the result of old sharing decisions. A project site holding customer contracts that someone once shared with the whole organisation becomes reachable by every assistant reading on behalf of an employee, and that is changed in the sharing, not in the assistant. Microsoft offers tools for that work itself, among them a feature that temporarily limits the discovery of content from selected SharePoint sites in search and in Copilot's answers while permissions are reviewed. The feature does not change the permissions themselves, only what can be found. The administrator also chooses which agents may be used and can affect whether web search is available, and OpenAI gives organisations control over which features may be used in their ChatGPT workspaces. OpenAI gives the same advice for its own agents: where possible, limit an agent's access to only the sensitive data it needs for the task.

Work on permissions therefore acts on something other than the filters do. Anyone who clears out old broad sharing and decides which agents and connections are switched on has reduced what an email can reach, whatever technique the next attack uses to trick the assistant. When the assistant is also allowed to act on its own, sending and booking, the question becomes a different and larger one, covered in Agentic AI governance: limits belong in the system, not the prompt.

The objection: settings would not have stopped EchoLeak

There is a countervailing point that carries weight. Aim Labs writes that, to the best of the researchers' knowledge, no admin configuration and no user behaviour could have prevented EchoLeak from being exploited. What closed the hole was Microsoft's own fix, made before the vulnerability became public. Anyone reading the case as an argument that an organisation can stop prompt injection itself by getting the settings right has read it wrongly.

There is also a price to restricting. An assistant that may not read the inbox cannot summarise the inbox, and that may be exactly what staff want help with. Switching off sources out of caution can produce an assistant nobody uses, and then the organisation has paid for security in the form of a tool that sits idle.

The vendor closes the holes, but you decide how much sits on the other side of them.

The objection therefore moves the question rather than settling it. That the attack was possible at all, and that the data had a way out, lay with the vendor, and it was the vendor that closed it. What the attack could reach was another matter. According to Aim Labs it was everything in the assistant's context, meaning the conversation and what Copilot had retrieved from Microsoft Graph. According to Microsoft, Copilot only retrieves what the user has permission to access, and those permissions are for the organisation itself to decide.

How open is your AI assistant?

Two organisations with the same licence can have entirely different exposure, and the difference does not show in the licence list. Take the assistant you use and write down every data source it is connected to. Next to each source write two things: who outside the organisation can put text into it, and what the assistant reaches when it reads it. Only you can fill in those two columns.

The answers divide organisations. One whose assistant reads only internal sources no outsider can write in, such as a bounded knowledge base, has a small surface and can widen use as fast as the work requires. One whose assistant reads the inbox and areas shared with customers, while also carrying broad permissions nobody has reviewed, has given every unknown sender a possible path to everything the employee can reach. One that cannot fill in the first column does not know which ways in are open, and then the next step is the mapping, not another filter.

The same mapping is the starting point when the AI tools you already pay for are to be used properly: plain answers about which data may go where unlock more use than a cautious switch-off does.