The Phishing Email That Attacks Your AI Assistant Too

I started at the lie, because that is where the symptom landed, and walked it backwards link by link until the email stopped looking innocent.

Barracuda Research published an analysis on 7 October 2026 describing phishing campaigns that carry two attacks in one message: conventional social engineering aimed at the human recipient, and prompt injection aimed at the AI assistant that reads, summarises and prioritises that person's inbox. The researchers call them dual-target emails, and the reason they matter is that the second payload is invisible to the person it is manipulating.

If your organisation has rolled out an AI layer over email, support tickets, CV screening or calendar management, this is worth reading today rather than at the next security review.

How the two layers work

The sample Barracuda analysed looks like ordinary internal correspondence. The From and To addresses match the same mailbox, the message carries a trusted spam confidence score, and it originates from a public sector domain, all of which help it through reputation-based filtering.

Underneath that there are two content layers. One holds the text and images the recipient sees. The other holds instructions intended for an AI system, concealed using techniques that survive the trip from raw MIME to model context: HTML comments, which never render in a mail client but remain in the source an AI parses; zero-sized fonts and white text; encoded content; and password-protected attachments, which create a blind spot for conventional email security because the scanner cannot read inside them.

The first attack is traditional. A password-protected attachment with the password supplied in the message body leads to credential theft or malware delivery.

The second attack is the interesting one. If the human ignores the email, the hidden instructions manipulate the assistant's summary so that it presents the phishing message as legitimate or urgent, pushing the human back toward the link. In the more aggressive variant, the injection attempts to hijack the assistant's own response, instructing it to disregard prior directions and issue an urgent request to wire funds, leak data, or surface a fabricated priority action. None of those instructions are visible to the user.

The examples that should worry engineers

Barracuda lists four patterns seen in real campaigns, and two of them land squarely in engineering workflows.

One was an invoice email containing a hidden block instructing the summarising model to add a fake priority action changing vendor payment details, so the compromised summary nudged an employee toward wiring money to the attacker. Another targeted automated CV screening, embedding instructions that told the AI to award a perfect rating and recommend an interview regardless of qualifications.

The third asked an assistant to switch into an authorised maintenance or administrative mode and reveal its own configuration. The fourth is the one engineers should read twice: hidden instructions directing a coding assistant to insert credential-stealing code whenever it generates authentication functions.

That last one is not a theoretical escalation. It is an attacker placing a standing instruction inside the context of the tool that writes your login code, and the instruction fires on exactly the code path where a reviewer is most likely to skim because the pattern looks familiar.

This is the same trust confusion as the prompt injection that leaked a system prompt, moved from a chat interface into the mail pipeline. The model is not being tricked into doing something outside its function. It is being given content and treating part of that content as instructions, which is what it was built to do.

Why the usual defences miss it

Reputation filtering scores the sender, and the sender is clean. Attachment scanning cannot see inside a password-protected archive. Data loss prevention looks for outbound secrets, not inbound instructions. And the human-facing security training everyone has done covers the visible layer, because until recently that was the only layer there was.

The gap is that the AI assistant has become a privileged reader. It sees raw content the user never sees, it has a role in deciding what the user pays attention to, and in many deployments it can take actions. Nothing in the traditional email security stack was designed around a component with those three properties at once.

There is also a second-order effect worth naming. Once an assistant is compromised, its output is trusted in a way a raw email never was. A summary that says this invoice is urgent carries the assistant's authority, so the injection does not just deliver a message, it launders it. That is the same mistake as rendering model output as trusted HTML, where the output of a system that consumed untrusted input was then treated as trusted itself.

What to do

Treat all external content as data, never as instructions. This is the single control Barracuda emphasises, and it is architectural rather than procedural. If the assistant cannot be prevented from reading hidden text, the system around it must not grant its output authority.

Separate the summariser from the actor. An assistant that reads and summarises is a different risk from one that can send mail, approve invoices, change payment details or write code. If the same component does both, an injection that reaches the reader reaches the actor.

Strip or flag non-rendered content before it reaches the model. HTML comments, zero-sized and white text, and encoded blocks are all detectable. Removing them or surfacing them as a warning removes most of the concealment surface for very little cost.

Require a human decision on anything consequential. Payment detail changes, credential operations, configuration disclosure and code touching authentication should not be actionable on an assistant's recommendation alone, however confident the summary sounds.

Audit the assistant's context, not just its output. If you cannot see what the model was shown, you cannot diagnose a manipulation after the fact. Log the context the same way you would log a request.

Review generated authentication code with specific suspicion. Given the fourth example, any AI-generated auth function deserves a reviewer who is looking for the injected pattern rather than skimming a familiar shape.

The takeaway

A single email can now carry one attack for the human and a second, invisible one for the AI assistant that processes it. Treat external content as data rather than instructions, separate the summariser from the actor, strip non-rendered content before it reaches the model, and keep a human in the loop for anything consequential.

Barracuda's own summary of the risk is the right one: the most dangerous thing about this is how ordinary the email looks. A message can now be simultaneously a phishing lure and a set of standing instructions to the system your organisation trusts to tell it what matters, and the person being manipulated by the second payload is the same person being asked to spot the first.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud