When an AI Assistant Reads Your Email: Keeping It from Being Hijacked

An email can contain information your assistant needs and instructions it has no business following. That is the uncomfortable part of connecting AI to your inbox: the person writing the email is suddenly contributing text to a system that may also have access to your company information.

I want our assistant to read outside material. That is useful work. I also want a clear boundary between what an email says and what I have authorised the assistant to do.

Our operating instructions describe a layered process as the required route for external data in our own system. The source material does not independently demonstrate its execution or coverage. I am explaining that documented approach, rather than reporting a security test. A business owner buying an AI assistant should be able to ask for more than reassurance that the model is clever enough to spot trouble.

TABLE OF CONTENTS: Reading versus authority; our external-data pipeline; what the layers prove; access and actions; questions for your vendor; deciding where to start.

The risk is an outside message becoming an instruction

Prompt injection is an attempt to make an AI follow instructions placed inside material it was supposed to read as data. When that material is an email, document or web page rather than the user's own request, we call it indirect prompt injection.

The distinction matters. You asked for a summary. The author of the source material did not receive permission to change your request, retrieve unrelated information or decide where an answer should be sent.

Our research notes cover examples of instructions hidden in email content and documents. Some of the source videos make dramatic claims that the dossier explicitly marks as unverified. I will not turn those claims into evidence that every assistant is compromised, or that a particular model always resists an attack.

The useful design question is simpler: when outside text enters the assistant's working context, what keeps it in the role of evidence?

For an owner, the consequence is not limited to an odd answer. If the assistant can access sensitive information or take actions, an instruction mistake can become a disclosure or an unauthorised change. The permissions around the assistant determine how far that mistake could reach.

Even an answer that stays inside the company can create work. Someone has to recognise that the result has been redirected, check the source and redo the task. If the purpose of introducing AI was to remove administrative work, that verification burden belongs in the business calculation.

How we handle external data before the main assistant reads it

Our internal operating instructions name sanitize.py as the route for external data before it reaches Claude. They explicitly include emails, calendar events, tickets and social content.

The documented process has 3 layers: a deterministic pattern check, a semantic evaluation by Haiku, and an XML trust boundary. Each addresses a different part of the problem.

A deterministic check applies written rules rather than asking a model to make a judgement. Here, those rules use regular expressions, which are patterns for finding particular text structures. This gives us a place to identify recognisable suspicious content before asking the main assistant to work with it.

That description does not establish which attacks the rules catch. The operating note does not provide the pattern list, a detection score or a record of bypass tests. I can describe the control we have documented without pretending it has a measured level of protection that the supplied evidence does not show.

The next layer uses Haiku for semantic evaluation. In plain language, a model examines meaning rather than only matching text patterns. The reason to combine those approaches is that an instruction attempt need not use an obvious or consistent phrase.

There is a boundary worth being precise about here: this process is before the main assistant, not before every model. The semantic evaluator is itself a model. If you are assessing confidentiality, you should ask what reaches that evaluator as well as what reaches the assistant that completes the task (in Bulgarian).

The final layer wraps the material in XML tags, structured markers around a piece of text. Our instructions explicitly say that anything inside <external_data> is untrusted.

That is the separation we want the main assistant to preserve. It may use the content to answer the authorised question. The content does not acquire authority to issue new instructions just because it arrived through a connected tool.

Why the layers belong together

The pattern check, the meaning check and the explicit boundary do different jobs. I would not describe any of them as a complete security system on its own.

The practical value is that we are no longer relying only on the assistant to remember a general instruction to be careful. There is an explicit processing path and an explicit distinction between external material and authorised directions.

But tags are text, not a physical barrier. A model-based check is still a model-based check. And a documented rule that external data must pass through a pipeline is not the same thing as an independent audit showing that every integration follows it.

This is where I want an honest conversation with any supplier, including us. Show the intended route. Show how you check that incoming content uses it. Explain what happens when a check cannot complete or returns an uncertain result.

The supplied operating note does not describe those failure behaviours. I will not fill that gap with an invented claim that every suspicious item is automatically blocked, quarantined or sent for approval. Those are implementation details to verify, not benefits to assume. Before relying on this route for a business task, I would require an explicit answer about whether processing stops or continues when screening fails, and who resolves the uncertain item.

Filtering cannot repair excessive access

Our security research also separates prompt injection from excessive access. An assistant can expose information because it follows a malicious instruction, but it can also surface information that the company has already made too widely available.

Our checked Copilot research makes that distinction explicit: the product works within the user's existing permissions, and poorly governed content remains a problem. This is a finding from our source review, not an independent test of our own pipeline or a blanket verdict on enterprise assistants.

The owner-level lesson is to examine the information the assistant can reach before celebrating how easily it can search it. If the underlying permissions are broader than the job requires, a useful search feature can make that existing problem more visible.

I would apply the same scrutiny to actions. Reading a ticket, drafting a response and sending a response are different permissions. A sensible purchasing conversation names which of those the assistant can do and who authorises changes.

Our research lists restricted permissions and human approval for actions that change data or send messages among the design principles to consider. I treat those as requirements to discuss and verify for each system, not as evidence that every connector in our own environment already implements them identically.

That is why a supplier's answer about filtering is only part of the answer. You also need to know what remains possible if the filter misses something.

The same boundary matters outside the inbox

Email makes the problem easy to recognise, but our documented rule deliberately includes other external sources. A calendar entry can contain text supplied by somebody outside the company. A ticket carries the words of the person asking for help. Social content arrives from authors who have no authority over your internal assistant.

The same question applies when the source is a web page: are we asking the assistant to read it, or accidentally allowing the page to direct the work? The research discusses retrieved content as a source of instruction attempts. The short operating note, however, does not establish the coverage of every browser or web connector, so that coverage needs checking separately.

For an owner, I would map this by task rather than by product logo. What outside material does the task use? What internal information can the assistant combine with it? What can it do with the result?

This keeps the review connected to actual work. An assistant that organises incoming requests and an assistant that can send information elsewhere may use similar language models, while requiring different operating boundaries.

It also prevents a narrow inbox review from becoming an unsupported promise about the whole business. Adding a source or a tool changes the route that needs checking.

What I would ask any AI vendor to demonstrate

I would ask a supplier to walk through an incoming item from retrieval to output. Where is it examined? How is it marked as external? What happens if it contains an attempt to redirect the task?

Then I would ask them to explain the model used for screening. Does screening itself send the content to a model service? What information is included? A claim that data is checked before reaching AI is incomplete if an AI model performs the check.

I would also ask for evidence about the limits. What tests have been run? What failures are known? Can the supplier distinguish an architectural description from an observed result? A diagram of controls and evidence that the controls work answer different questions.

Finally, I would ask what the assistant can do after reading the material. The answer should name access, outbound actions, approval points and the record available for investigation. A vendor who explains the input filter but cannot explain the action permissions has left the business consequence unresolved.

I do not need a promise that nothing can ever go wrong. I need enough detail to decide what work the system can responsibly take on, and what should remain under human review (in Bulgarian).

Start with work whose boundaries you can explain

Our research folder is still a research project. Its decisions and artifacts folders contain no substantive implementation evidence for this pipeline. The concrete account of our own external-data handling comes from the internal operating instructions, not from a published security benchmark.

That distinction is part of the article, not something I want hidden beneath a confident claim. We have a documented layered approach. The supplied material does not establish a detection rate, a complete audit of integration coverage or a guarantee against prompt injection.

For a business owner, a narrow starting scope to discuss is email summarisation with a person reviewing the result. Specify which messages are available and whether the assistant has any permission to send or change anything. This is a proposed scope for assessment, not a claim that our dossier proves it safe. The useful starting point is a task whose information sources, permissions and outputs can be described clearly. Then ask what evidence supports the safeguards around that task. The potential benefit is less manual reading and coordination; the decision still needs to account for review, exceptions and responsibility when something goes wrong.

If you are considering an assistant for email or other outside content, bring the process to a free audit. We can examine where your team's hours go, what information the assistant would need and which boundaries must be clear before you rely on it.