Phishing emails have acquired a second reader. Security researchers have documented a campaign in which each message carries two payloads: a conventional social-engineering lure meant for the person who opens it, and a set of concealed instructions aimed at the AI assistant that summarizes, prioritizes and triages the inbox before any human sees it. A report published on October 7 by the security firm Barracuda, written by threat analyst Guruprasad Kenja, dissects a real sample built precisely this way.
- Two targets, one email: the visible layer uses familiar tricks such as a password-protected attachment, while a hidden layer carries prompt-injection text designed to steer the assistant’s summary.
- Four concealment methods: HTML comments, CSS-invisible text, Base64-encoded blocks and zero-width Unicode characters keep the instructions out of sight but still inside the raw document the model parses.
- Structural, not incidental: language models do not separate the content they are supposed to read from the commands they are supposed to obey, which makes indirect prompt injection a persistent risk rather than a patchable bug.
- No confirmed fix: vendors describe layered mitigations, but none claims the class of attack has been closed.
A message engineered to look boring
The sample described in the research was designed to survive reputation-based filtering as much as to fool a reader. Its sender and recipient addresses pointed to the same mailbox, it originated from a public-sector domain, it carried a favorable spam-confidence score, and it referenced an ordinary business process alongside a document attachment. The attachment was password-protected, with the password written into the message body — a configuration that creates a blind spot for traditional email security controls, which cannot open the file to inspect it.
Everything the recipient can see looks routine. Everything the model reads does not. Barracuda catalogues four recurring techniques for hiding the second layer:
- HTML comments — instructions placed inside comment tags that never render in a mail client but remain in the raw source the assistant ingests.
- CSS-hidden text — zero-pixel font sizes, white-on-white styling or fully hidden blocks that occupy no visible space.
- Base64-encoded content — for example inside what appears to be an image data string, decoded as plain text by the model.
- Zero-width Unicode characters — invisible glyphs interleaved with ordinary text to smuggle or obfuscate a payload.
What the hidden layer actually asks for
The documented scenarios share a common thread: the assistant is persuaded to lend its neutral, authoritative tone to the attacker’s request. In one case an invoice email contains a hidden block instructing the summarizer to surface a fake priority action that changes a vendor’s bank details, nudging an employee toward wiring money to a different account. In another, invisible text inside a résumé tells an AI screening tool to award the candidate a perfect score and recommend an immediate interview. Other examples include a customer-service bot coaxed into revealing its configuration through a request disguised as “authorized maintenance mode,” and a coding assistant fed poisoned documentation that leads it to generate a line leaking credentials.
The underlying weakness is architectural. The model receives retrieved text and operational instructions through the same channel, with no reliable boundary between them. Indirect prompt injection was already formalized in an academic paper in February 2023, and it remains the top entry in OWASP’s risk catalogue for applications built on language models.
External content, the report argues, must be handled always and in every case only as data — never as instructions.
Mitigations exist; a solution does not
No vendor is claiming victory. OpenAI published guidance in March on how it designs agents to resist prompt injection, acknowledging that defence “cannot rely on input filtering alone” and that safe interaction with a hostile external environment is a prerequisite for fully autonomous agents. The document describes concrete mitigations shipped in its products while explicitly leaving the problem open, and cites an externally reported attack that succeeded 50 percent of the time.
AI-enabled browsers have already supplied uncomfortable precedents. Security firm Guardio managed to lure Perplexity’s Comet browser into a scam that ended with credentials being typed into a fraudulent page in under four minutes.
The defensive playbook running through the research is consistent: strip hidden elements, comments and invisible characters from email before it reaches the assistant; constrain what the assistant is permitted to do; validate its output before it triggers any action; and require human sign-off for payments and vendor-account changes. For individual users the advice is simpler — if a summary points to money or sensitive data, open the original message, and confirm any change of bank details through a separate channel, exactly as with classic CEO fraud.
The more interesting finding here is behavioural rather than technical. A decade of awareness training taught people to distrust email; the reading of that email has now been delegated to a system that received none of that training. A summary arrives clean, ordered and tonally neutral, and that veneer of authority is precisely what the attacker is buying. It is worth keeping the evidence in proportion, too: the research publishes no figures, names no products tested, and no AI vendor has responded to this specific investigation. This is a well-documented warning from a company that sells email security — a credible signal, not an independent measurement.
Sources & References