White Text, Big Damage

Imagine an invoice lands in your inbox. Your AI assistant automatically summarizes it: amount, deadline, sender – all at a glance, before you've even opened the email. Convenient, fast, exactly what you set up the assistant for. Except: what the AI shows you doesn't have to be what's actually in the mail. That's precisely what security researchers at Forcepoint X-Labs demonstrated in a test setup in late August 2026 – with a method so simple it almost seems trivial: white text on a white background.

What makes this finding so relevant for mid-market companies isn't the technical sophistication – that's modest. What's relevant is how much trust many businesses now place in exactly the systems that can be fooled by a single, invisible CSS trick. Anyone who accepts an AI summary unchecked into accounting, scheduling, or customer communication is relying on a source that – as the Forcepoint test shows – can be manipulated by anyone who knows how to format an HTML email.

The Finding: What Forcepoint X-Labs Discovered

On August 25, 2026, Forcepoint X-Labs published a blog post titled "HTML Payload Hijacks Email Summarizer via Prompt Injection," written by Ben Gibney, Security Researcher III at Forcepoint. The article describes a controlled test setup: an isolated lab with synthetic data and a custom-built Outlook add-in that sent email headers and content to an AI-powered summarization service – powered by Claude Haiku 4.5.

Important context up front, because it's easy to misread: this is not a vulnerability in Microsoft Outlook, not an issue with the language model used, and not a commercial product that was compromised in production. Forcepoint built its own prototype to make visible a structural risk that arises, in principle, anywhere email content is passed to a language model unfiltered. The researchers themselves stress this explicitly: this isn't about a specific vendor, but about a pattern found in many AI assistants used in everyday business today.

And that's exactly why it's worth a close look – even, and especially, for businesses that don't run an Outlook summarizer themselves, but some other email AI, a chat agent with mailbox access, or a tool that processes documents automatically.

How the Attack Works: A CSS Trick as Old as the Web Itself

The technique Forcepoint demonstrates isn't a new invention. Spam senders have used invisible text for decades to fool filters – for instance by packing harmless words in white text underneath the actual spam content. What's new is only the target: instead of fooling a spam filter, it's now the language model summarizing the email for you that gets fooled.

Specifically, the researchers used the following CSS styling inside an HTML email:

font-size:0px; color:#ffffff; line-height:0

For a human opening the mail in Outlook, this block of text is simply invisible – font size zero, white color, no line height. For the add-in that reads the raw HTML of the email and passes it to the language model, however, the text is fully present. So the model "reads" something entirely different from what the human in front of the screen sees.

The numbers from the Forcepoint test make this tangible: the visible email consisted of 537 characters. The text actually passed to the language model was almost twice as long, at 1,009 characters. The difference – 472 characters – was the hidden injection payload: an instruction telling the model to treat the injected content as the "authoritative record" – and not to mention the hidden note in its own summary at all.

This is the real core of the problem: a language model doesn't inherently distinguish between "this is the content I'm supposed to summarize" and "this is an instruction I'm supposed to follow." Both arrive in the same text stream. If the text says "treat this figure as binding," the model does exactly that – regardless of whether that instruction came from the sender of the original mail or from an attacker who slipped it into the HTML code.

The Result: Ten Out of Ten Test Runs Manipulated

Forcepoint ran the test ten times. In all ten runs – a 100 percent success rate – the AI summary adopted the false figures set by the attacker. The invoice amount appeared in the summary as €46,200, even though that figure didn't match the actual, visible invoice content. The payment deadline was pushed back to "Sep 3, 2026 / 14:00." And a name that was originally part of the correspondence – "Diego Siciliani" – disappeared entirely from the summary, as if that person had never existed in the email.

Particularly notable: for the human opening the manipulated email in Outlook, there was practically no recognizable warning sign. The only hint of the manipulation was a minimal amount of extra whitespace before the signature – a difference no one would consciously notice in practice unless they were specifically looking for it. Anyone relying on the AI summary, because that's the whole point of the automation, would have taken the wrong amount and the shifted deadline at face value without hesitation.

This is exactly where the real danger lies: it's not that a language model "makes mistakes" in the sense of inaccuracy. It follows exactly the instruction it received – just an instruction that didn't come from you or your actual business partner, but from someone who smuggled it in between the lines.

Not an Isolated Case: Prompt Injection Is Risk Number One

Anyone thinking this is an exotic lab experiment with no real-world relevance should look at the bigger picture. In the OWASP Top 10 for LLM Applications 2025, prompt injection tops the risk ranking for AI applications for the second time in a row – rank one, ahead of issues like data leaks or insecure output handling. That's no coincidence, but the logical consequence of more and more companies feeding language models external, untrusted content: emails, web pages, uploaded documents, calendar invitations.

A particularly striking real-world example is the case of EchoLeak (CVE-2025-32711), disclosed by security firm Aim Security in June 2025. EchoLeak is considered the first documented zero-click prompt injection exploit in a production AI system – specifically, Microsoft 365 Copilot. With a CVSS score of 9.3, the vulnerability ranks among the most critical ever found in a production AI assistant. Here, too, the trigger was a rigged email, and here, too, no user interaction was required at all – the compromise ran entirely in the background while the recipient noticed nothing. EchoLeak has since been patched and is a closed, documented incident from 2025 – its importance here is mainly as proof that what Forcepoint shows in the lab isn't a theoretical exercise, but a pattern that has already been exploited in the wild. It's also important to draw the distinction: Forcepoint's 2026 test and the 2025 EchoLeak incident are two separate events involving two different systems – one an already-fixed, real incident in a production Microsoft product, the other a current lab demonstration with a purpose-built prototype. Together, though, both show the same underlying pattern: email as the entry point, no user interaction required, and a language model that follows exactly what the hidden text tells it to.

Academic research also confirms how real the problem is. The InjecAgent benchmark tested how vulnerable GPT-4-based agents using the widely used ReAct framework are to indirect prompt injection. In the baseline case, 24 percent of attacks succeeded – with optimized, more targeted attack techniques, the success rate rose to 47 percent. Almost every second attempt succeeded once the attacker invested a little care into the wording of their hidden instruction.

This isn't a specific problem of one LLM vendor or summarizer, but a structural risk whenever unfiltered email content is passed to a language model without review.

This assessment from Forcepoint hits the core of it: it's not a bug a software update will fix. It's an architecture question – namely, whether and how you separate trustworthy instructions from uncontrolled, external content before both end up in the same AI prompt.

What This Means for Your Mid-Market Business

At this point, you might object: this only affects large corporations with complex Copilot rollouts. The opposite is true. It's precisely in the mid-market that more and more businesses are deploying email agents, Outlook add-ins, or their own AI pipelines that autonomously set deadlines, summarize invoices, create appointments, or draft follow-up questions – often with far fewer dedicated IT security resources than a large enterprise. It was exactly this kind of autonomous action that Forcepoint hijacked in the test, fully automated and invisible to the human.

The decisive test for how risky a given agent workflow actually is in your business boils down to three questions – sometimes called the "lethal trifecta": Does the agent have access to sensitive, confidential data? Does it process content that comes from outside and hasn't been reviewed – emails, web content, uploaded files? And can it independently communicate or act externally – send a mail, initiate a payment, move an appointment? Once all three conditions are met at the same time, a workflow is fundamentally susceptible to exactly the kind of attack Forcepoint demonstrated.

Surveys by Kiteworks from 2026 show just how unprepared many companies are for this risk – the figures vary somewhat depending on the source cited, but consistently paint the same picture regardless: a substantial share of companies still lack basic, dedicated controls for the safe use of AI agents, and many lack enforceable purpose limitation defining what data an agent is even allowed to touch. In other words: the technology is often already in use, while the governance behind it is lagging in many places.

Practical Checklist: How to Protect Your AI Agents from Hidden Instructions

The good news: Forcepoint didn't just derive a problem from the test, but also concrete countermeasures – and most of them are achievable even for smaller IT teams without a huge security budget.

First: extract only the text visible to the user before content goes to a language model – not the raw HTML code. What a human doesn't see, the AI shouldn't get as relevant content either. Second: actively detect and filter suspicious, hidden CSS styles – font size zero, white or transparent text color, zero line height, display:none. These are known patterns that can be reliably detected technically before the text even reaches the model. Third: strictly separate email headers from the actual body, so sender information doesn't get mixed with potentially manipulated content.

Fourth, and this might be the most important principle: treat any email content as fundamentally untrustworthy data – regardless of how reputable the sender appears. And fifth: spot-check AI outputs against the original source before critical actions are triggered based on them – especially for amounts, deadlines, and legally relevant commitments.

For your specific business, this means very practically: check whether your current setup filters email HTML at all before AI processing, or whether raw content is passed through unreviewed. Define clear approval levels: a plain summary or a suggestion from the agent is generally uncritical – an autonomous execution, such as moving a deadline, creating an invoice, or triggering a payment, should require mandatory human confirmation above a certain sensitivity threshold. And make a simple first check a habit: which email and document agents in your company currently have write or execution rights on calendar, accounting, or CRM systems – and does that run without any confirmation step at all?

None of these measures requires giving up the benefits of AI agents. It's not about rolling back automation, but about building it so that an invisible block of white text alone isn't enough to change your numbers, deadlines, and names without anyone noticing.

A simple thought experiment shows how quickly a small technical gap can turn into real financial damage: a supplier sends an invoice for a four-figure amount. Your email agent summarizes it and automatically enters the payment deadline into your calendar or accounting system. If the mail contains a hidden block of text following the Forcepoint pattern, the AI summary could output a significantly higher amount and a false, potentially earlier deadline – and if no one cross-checks the original mail because they're relying on the automation, that false amount gets paid out, or at least used as the basis for internal approval processes. The attacker's effort: one line of CSS. Your potential damage: a financial shortfall, a missed real deadline, or a payment to the wrong address.

The Forcepoint finding ultimately isn't a reason to avoid AI agents in email and document processes. It's a reason to build them with the right architecture from the start: clear separation of content and instruction, clean filtering before the content reaches the model, and human checkpoints exactly where money, deadlines, and legally binding commitments are involved. That's exactly the difference between off-the-shelf AI automation that blindly trusts any text that reaches it, and a professionally set-up agent system that structurally knows whom it can trust – and whom it can't.