Researchers Hijacked an AI Email Summarizer With Text You Cannot See

Estimated read time: 8 minutes

You probably do not read your email anymore. Not all of it. You read the summary at the top, the two-sentence version your inbox assistant generates before you have finished your coffee, and then you decide whether the actual message deserves your attention. That habit is now a security problem, and researchers at Forcepoint X-Labs have published a proof of concept that shows exactly how bad it gets.

Their setup was almost insultingly simple. They wrote an email. They added a few lines of HTML styled with zero font size and white text, which means the recipient sees nothing at all in Outlook. Then they ran the message through an AI summarizer. The invisible text was not invisible to the model. It was instructions, and the model followed them.

Ten out of ten runs produced a manipulated summary. Not eight. Not “sometimes under specific conditions.” Every single one.

What Forcepoint actually did

The technique has a name that sounds more academic than it deserves: indirect prompt injection. Direct prompt injection is when you type something malicious into a chatbot yourself. Indirect prompt injection is when you hide the malicious instruction inside content the model will read later, on someone else’s behalf, without that person ever seeing it.

Forcepoint isolated a single email summarizer running an unguarded pipeline, which is to say a normal one. Content goes in, model reads it, summary comes out. They embedded a hidden payload using ordinary HTML concealment tricks that have existed since the nineties, the same white-text-on-white-background nonsense that early spammers used to stuff keywords. Then they ran both clean and poisoned emails through the system with success criteria written down in advance, so nobody could squint at the results afterward and call it a fluke.

The numbers are the useful part. The message a human would see ran 537 characters. The content that reached the model ran 1,009. Nearly half of what the AI processed was text no person was ever meant to notice. The model driving the summarizer in this particular test was Claude Haiku 4.5, but that detail matters less than people want it to, and we will get to why.

The invoice detail is the whole story

Here is what the hijacked summary did. It moved an invoice deadline from August 21 to September 3. It also quietly deleted a name from the message.

Read that again, because it is not a party trick. It is the anatomy of a business email compromise attack, and it is more elegant than the versions that have been draining small business bank accounts for a decade. The old approach was to spoof a vendor, send a fake invoice, and hope nobody called to check. It works often enough to be a multibillion dollar criminal industry, but it has a weakness: the fraudulent email has to be convincing to a human, and humans occasionally get suspicious.

The injection version removes the human from the verification step entirely. The email is real. The vendor is real. The invoice is real. Only the summary is a lie, and the summary is the only thing anybody reads. You are not being asked to believe a forgery. You are being handed an accurate-looking digest of a legitimate message, generated by a tool you trust, and the digest has been edited by whoever sent the message.

Deleting a name is the subtler half. Summaries are compression, and compression always drops something, so a missing name reads as normal editorial judgment rather than tampering. If the dropped name is the person who was supposed to approve a payment, or the second signatory on a contract, or the compliance contact who needed to be copied, the omission changes the meaning of the message without ever contradicting it.

This is not a bug in one product

The temptation is to read this as a story about one model or one vendor, decide you use a different one, and move on. That would be a mistake, and it is worth being precise about why.

Large language models do not have a hardware-level separation between instructions and data. A traditional program knows the difference between code and the input that code operates on, because the boundary is enforced by the language and the runtime. A model receives one stream of text and works out from context which parts are commands. That inference is usually right and is fundamentally guessable, which is what makes injection possible in the first place. It is the same category of problem as SQL injection, except we do not yet have the equivalent of parameterized queries.

So the vulnerability is not really in the model. It is in the pipeline, in the decision to pass raw email HTML to a summarizer without stripping the parts a human would never see. Any product built that way is exposed, whatever model sits behind it. Forcepoint’s own research team has documented injection payloads showing up in real traffic rather than just in labs, which means this has already moved from theoretical to operational.

Why small businesses are the softest target

Large companies have a security team whose job is to worry about this. You have yourself, possibly a bookkeeper, and a managed service provider you call when the printer stops working.

More to the point, small businesses adopted AI inbox tools faster and more completely than enterprises did, because there was nobody to ask for permission. Gmail summarizes threads. Outlook Copilot summarizes threads. Superhuman, Shortwave, Spark, and a dozen smaller clients all pitch inbox triage as the headline feature. Every one of those is a place where text you cannot see gets read by a model on your behalf.

And the money moves faster. In a company with a procurement department, changing a payment date requires a ticket. In a five-person shop, it requires the owner glancing at a summary and deciding the wire can wait until after the long weekend. That gap between “I read the summary” and “I moved the money” is the entire attack surface, and at small scale it is measured in minutes.

There is a broader pattern here that we have written about before in the context of auditing your software stack for AI risk. Features arrive in tools you already pay for, switched on by default, and the risk assessment happens after the fact if it happens at all.

Six things to change this week

None of this requires a security budget. It requires about ninety minutes and a willingness to write down a rule your team will actually follow.

1. Make one rule absolute: money never moves on a summary. Any email that changes a payment amount, a bank detail, a deadline, or a recipient gets opened and read in full. No exceptions for busy weeks. This single rule neutralizes the entire attack class described above.
2. Verify payment changes on a second channel. Call the vendor on the number you already have, not the one in the email. This is old advice and it is old because it works. AI summaries make it more necessary, not less.
3. Turn off automatic HTML rendering where you can. Reading email in plain text is inconvenient and it also makes hidden styling impossible. If that is too austere for daily use, at least do it for invoices and anything financial.
4. Ask your email vendor one specific question. Not “is your AI secure,” which will get you a paragraph of nothing. Ask: does your summarizer receive the rendered visible text, or the raw HTML source? That is the question with a real answer, and the answer tells you whether you are exposed.
5. Treat summaries as leads, not facts. A summary is a reason to open something. It is not a substitute for having opened it. Train whoever handles your inbox on that distinction explicitly, because it is not obvious and the tools are designed to make you forget it.
6. Write it into your onboarding. Whatever rules you land on are worthless if only you know them. Put them in the document new hires read in week one, next to the password manager instructions.

Forcepoint’s own recommendations run along the same lines from the vendor side: extract only content that is visible to the user, detect hidden or suspicious HTML and CSS styling, keep headers separated from the body, treat all email content as untrusted input, and validate generated summaries against the source. Those are engineering fixes and they are the right ones. They are also not shipped yet in most products you use today.

The part nobody has solved yet

Content sanitization catches the version of this attack that Forcepoint demonstrated, and vendors will ship it, probably within months. Strip white-on-white text, strip zero-size fonts, strip off-screen positioning, pass only what rendered. That closes the door the researchers walked through.

It does not close the underlying one. An instruction can hide in a footer that is technically visible but that nobody reads. It can hide in an attached PDF. It can hide in a calendar invite description, a shared document, a support ticket, a scraped web page, or any of the other places an AI agent now reaches on your behalf. The more autonomy these tools get, the more surfaces there are, and each surface is a place where content authored by a stranger becomes input to a system acting with your authority.

That is the real lesson here, and it applies well beyond email. If you are handing tasks to AI agents that act on your behalf, you have accepted that anything they read is potentially something that instructs them. Right now the industry’s answer to that is “we are working on it,” which is honest and not especially comforting.

The good news, such as it is, is that the defense at your scale is not technical. It is procedural, it is cheap, and it is the same discipline that has always protected small businesses from wire fraud: when money is involved, look at the actual document, and call the actual person.

Frequently asked questions

Does this mean I should stop using AI email summaries?

No, and that would be an overcorrection. Summaries are genuinely useful for triage. The fix is to stop treating them as authoritative for anything consequential, particularly money, deadlines, and who is authorized to do what.

Would I be able to tell if this happened to me?

Not from the summary, which is the point. You would only notice by opening the original email and comparing it, which is exactly the step the summary exists to let you skip. In practice the tell would be downstream: a payment sent late, a vendor confused about a date you were sure of, an approval that never happened.

Is one email provider safer than another right now?

There is no reliable public ranking, and any vendor claiming immunity should be treated with suspicion. The meaningful difference is whether the summarizer is fed rendered visible text or raw source HTML. Ask that question directly and judge the answer.

Is this the same thing as phishing?

Related but distinct. Phishing tries to fool a person. This fools the tool that summarizes for the person, which means the usual phishing training, look for typos, check the sender domain, hover the link, does not help. The email can be entirely legitimate in every visible respect.

Does an email security gateway catch this?

Traditional filters look for malicious links, attachments, and spoofed senders. A prompt injection payload contains none of those. Some vendors are adding detection for hidden styling specifically, so it is worth asking your provider whether they have shipped it rather than assuming your existing filter covers it.

Related Coverage

• Which of Your SaaS Tools Are at Risk From AI: the same audit habit that catches this, applied to your whole stack.
• AI Agents Explained: what these tools actually do on your behalf, and where the authority boundary sits.
• How Google AI Search Changed the Rules: another case of an AI layer quietly sitting between you and the source material.

Faceted Media Magazine covers business, AI, and entrepreneurship for the people building what’s next.