Closing the Exits: Limiting Data Exfiltration When AI Assistants Read Untrusted Content

An AI assistant that can read your mailbox, search your file shares and summarise a stranger's web page is useful because it combines all three. That combination is also the problem. When the same assistant processes text written by an outsider, that text can steer it, and a well-placed instruction can make it hand internal data to someone outside.

This is not a theoretical worry. In June 2025 Microsoft fixed CVE-2025-32711, known as EchoLeak, a critical issue in Microsoft 365 Copilot where instructions hidden in an external email could cause the assistant to mix privileged internal data into its output and send it out, with no click required. Microsoft fixed it server-side and reported no evidence of exploitation in the wild. As assistants gain more connectors and tools, the lesson matters for every deployment: you cannot rely on the model to tell instructions from data, so you have to control where data can go.

Why prompt injection is a design problem, not a bug to patch

The UK NCSC put it plainly in December 2025: current large language models "simply do not enforce a security boundary between instructions and data". SQL injection was largely solved by parameterised queries, which keep input from ever being read as a command. There is no equivalent for LLMs today, so the NCSC suggests treating prompt injection as a residual risk to be reduced, and warns readers to be wary of products that claim to stop it.

OWASP's LLM01 entry defines the indirect form: the model takes in content from external sources such as websites or files, and that content changes its behaviour in unintended ways. The source can be an email, a shared document, a support ticket or a page the assistant was asked to summarise.

The practical consequence is a change of question. Instead of asking "can we block every malicious prompt?", ask "if an injection succeeds, what can it reach and where can it send it?"

The three ingredients of an exfiltration path

Simon Willison's lethal trifecta is a useful mental model. Data theft becomes possible when one agent setup has all three of:

• access to private data, such as mail, files or internal systems;
• exposure to untrusted content, meaning any text or image an outsider can influence;
• a way to communicate externally, which can carry data out.

Remove any one of the three for a given workflow and the exfiltration path closes. Most of the controls below are ways of removing or narrowing one ingredient.

Know the exits

The third ingredient is often less obvious than it sounds. Microsoft's description of its own defences lists the channels it treats as exfiltration routes:

• Rendered images. If the client displays an image from a URL the model wrote, loading that image sends a request, and anything encoded in the URL goes with it, without any user action.
• Links. A generated link can carry data to an outside server when the user clicks it.
• Tool calls. Any tool that sends mail, posts a message, writes to a shared location or fetches a URL can move data directly, and side effects can act as covert channels.

Microsoft says it deterministically blocks known channels such as markdown image exfiltration and certain untrusted links, rather than relying only on detecting malicious prompts. That is the right pattern for anyone building or configuring an assistant: probabilistic filters help, but the controls that hold are the ones that do not depend on the model behaving.

Controls that hold even when the model is fooled

Limit what the assistant can read

Injection attacks borrow the user's permissions, so over-shared data is exposed data. Microsoft notes that this part of the risk can be mitigated deterministically with fine-grained permissions and access controls, including sensitivity labels and data loss prevention policies that stop an assistant summarising labelled files. Before you widen an assistant's connectors, clean up sharing that nobody intended, and exclude the most sensitive repositories from retrieval entirely.

Separate untrusted content from privileged work

The NCSC cites the principle that when an LLM processes information from a party, its privileges should drop to those of that party. In practice, a workflow that reads inbound email or public web content should not also hold write access to internal systems or the ability to send messages externally. Where one assistant must do both, split the task: one step summarises the untrusted input with no tools, and a separate step acts on the summary with the narrowest tools it needs.

Close or constrain outbound channels

Disable image rendering from arbitrary domains in assistant output, or restrict it to an allow-list. Treat generated links as untrusted, and strip or flag those pointing outside approved domains. For tools that send data out, enforce destinations in code rather than in the prompt, as OWASP recommends by handling privileged functions outside the model.

Keep a human on irreversible actions

For high-impact steps such as sending external mail, sharing a file or changing records, require explicit user approval. Microsoft's example is Copilot in Outlook, where the user must approve and send the generated email themselves. It costs some convenience, and it is one of the few controls that works regardless of what the model was told.

Log enough to investigate

The NCSC advises logging enough to spot suspicious activity, potentially including the model's full input and output, tool use and API calls. Failed tool calls can be an early sign that someone is probing.

A checklist for this week

1. List every assistant and agent in use, including features switched on inside existing SaaS tools.
2. For each, record whether it has the three ingredients: private data, untrusted input and an external channel.
3. For any that has all three, decide which ingredient to remove or constrain, and assign an owner.
4. Check whether assistant output can render images or links from arbitrary domains, and restrict it.
5. Review the permissions the assistant inherits, and fix broad sharing on the repositories it indexes.
6. Require user confirmation for any action that sends data outside the organisation.
7. Confirm that prompts, outputs and tool calls are logged and retained long enough to investigate an incident.
8. Add indirect injection to your test plan: plant benign test instructions in a document or email and check that nothing leaves.

Conclusion

Prompt injection will not be patched away, so the goal is to make a successful injection boring: the assistant reads the planted text, and nothing of value can leave. That comes from ordinary security engineering applied to a new component: least privilege on what it can read, separation between untrusted input and privileged action, deterministic limits on outbound channels, and human approval where the stakes are high.

Much of that work rests on access control you may already be consolidating. A shared identity layer such as OXU Identity can help keep the permissions an assistant inherits consistent across systems, but the design decisions above apply whatever tools you use.

Sources

• NCSC: Prompt injection is not SQL injection (it may be worse)
• OWASP GenAI: LLM01 Prompt Injection
• Microsoft MSRC: How Microsoft defends against indirect prompt injection attacks
• Simon Willison: The lethal trifecta for AI agents
• The Hacker News: Zero-click AI vulnerability exposes Microsoft 365 Copilot data