Prompt InjectionAI SecurityThreat Intelligence
Most email defences share an assumption so basic that nobody writes it down: an email is one document. The gateway scans it, the recipient reads it, and if the organisation has bolted an AI assistant onto the inbox, the assistant summarises it. Three readers, one message.
That stopped being true some time ago. Two pieces of research published nine days apart make the point from opposite directions. In one, attackers hid words from the filter while leaving them readable to the human. In the other, researchers hid instructions from the human while leaving them readable to the AI. Same underlying gap, pointed two different ways, and the second one lands on an approval workflow a lot of finance teams have quietly adopted.
On September 3, 2026, Microsoft's security research team published an analysis titled ASCII smuggling crosses over from AI prompt injection to phishing evasion. BleepingComputer and The Hacker News covered it over the following days.
The campaign itself was not new. It targeted small-business owners and US Small Business Administration loan applicants with funding and credit lures, sent through the ActiveCampaign marketing platform so that its links and sending reputation looked like ordinary marketing traffic. What Microsoft documented was how it evaded keyword detection.
The operators inserted characters from the Unicode Tags block (U+E0000–U+E007F) into the middle of high-signal words — funding, capital, loan, advance, credit. A tag character renders as nothing at all. To the recipient, fun⟨U+E0020⟩ding reads as funding. To a signature or regex looking for the contiguous string funding, the bytes no longer match.
The scale was not small. Microsoft identified the cluster on February 9, 2026, across 148 finance-themed sender domains. Security Boulevard reported that signature hits jumped in a single day from about 21,000 messages to more than 1.3 million, with volume reaching 2.37 million messages on some weekdays. The high-volume phase ran for roughly three months and fell away sharply after May 15.
The name of Microsoft's post is the important part. Tag characters are not a phishing technique that happened to turn up in AI research. It went the other way. They became well known because language models read them: security researcher Johann Rehberger has documented for more than a year that "Unicode Tags are often directly interpreted as instructions" by LLMs, including instructions that a human looking at the same text cannot see. Microsoft's own recommendation spells out the connection. Defenders should strip or normalise tag characters and other invisible code points before applying keyword, regex or signature detection, and apply the same normalisation before email content is handed to AI assistants.
Nine days earlier, on August 25, 2026, Forcepoint X-Labs researcher Ben Gibney published a proof of concept showing an HTML payload hijacking an email summariser. CSO Online covered the research on August 27.
The setup was deliberately ordinary. An Outlook add-in collected the headers and body of an email and sent them to a Python summarisation service backed by claude-haiku-4-5, with a one-line system prompt: "You are an email summarizer. Summarize the email the user provides." No guardrails, which describes a lot of internal AI tooling built in an afternoon.
Into an invoice email, Forcepoint inserted a block of text styled font-size:0px; color:#ffffff; line-height:0. Outlook rendered nothing. The summariser got all of it. The recipient saw 537 characters; the model received 1,009, of which 472 were injected instructions.
The outcome is what finance teams should look at:
The injection succeeded in all 10 runs. The benign version of the email, run the same ten times, never produced the altered output.
Gibney is careful about scope, and it is worth repeating: "The attack is not against Outlook, any named summarizers, or the model used to drive the summarizer." Nobody is claiming a specific commercial product did this. The claim is narrower and more useful. Any pipeline that feeds raw HTML to a model, and puts the model's output in front of a person making a decision, has this property until someone designs it out.
Put the two findings side by side and the mechanism is the same. What an email renders as and what an email parses as are different documents, and every reader in your stack picks one:
| Reader | What it sees | What the attacker exploits |
|---|---|---|
| Keyword filter | Raw code points | Invisible characters break the match |
| Human recipient | Rendered output | Hidden styling removes text from view |
| LLM summariser | Raw text or HTML | Content the human never saw becomes instructions |
Microsoft's campaign exploited the gap between the filter and the human. Forcepoint's exploited the gap between the human and the model. Nobody should assume a third campaign won't exploit the gap between the filter and the model. The Unicode Tags block is the obvious tool for it, because it is invisible to people and readable by LLMs.
There is a pattern here that goes beyond email. Two days ago we wrote about DUSTMAKER planting weapons-jailbreak text at the top of malware so that LLM code scanners would refuse to read further, and ESET reported UAC-0099 doing the same in VBS scripts aimed at Ukrainian targets. That was content written for the machine reader to reject. Forcepoint's payload is content written for the machine reader to obey. Attackers are now writing the machine-facing layer of a document deliberately, as a separate text from the one people see.
A phishing email that gets through the filter still has to convince a person. A tampered summary gets a head start the email never had. It comes from inside the organisation's own tooling, with the authority of the assistant already read this for you.
That matters most exactly where AI summaries have been adopted fastest: accounts payable queues, shared finance inboxes and executive assistants triaging hundreds of messages a day. Business email compromise has always depended on a changed amount, a changed date or a changed bank detail getting past a busy human. A summariser that silently changes the amount while the original email stays clean shifts the fraud from something the reader could have spotted to something they would have had to go looking for. And every mitigation that says a human reviews it assumes the human is reviewing the same content the machine acted on.
We made a related point when GhostSplice assembled an agent attack from three harmless fragments: the unit of attack is the assembled context, not the visible message. An email summariser is a single-message version of the same problem, and a far more common one.
One boundary first: Obiguard does not render your email. Making sure a summariser sees only what the recipient sees is a pipeline design decision, and it has to be made before the model call. No gateway can make it for you.
What Governance AI changes is what happens at the model call itself, and what you can prove afterwards.
Inspection sees the bytes the model sees, not what Outlook rendered. The inspection layer sits in-path and synchronous. Every prompt and system message is evaluated before the request reaches the model, and every completion before it is delivered. That position matters for this attack class specifically. A control inside the mail client inherits the client's view, where the 472 hidden characters do not exist. A control on the request inherits the model's view, where they do, and scores them against the jailbreak and injection detector. We will not claim any single detector catches every payload, which is the argument for layering. The practical point is that inspection is looking at the same input as the thing being attacked.
Be honest about your own matchers. Inspection also supports keyword, regex and ban-list criteria, and Microsoft's research applies to those as much as to anyone's mail filter. A literal-string rule is exactly what an interleaved tag character defeats. Normalise text upstream of the call and keep the ML and LLM-judge criteria in the policy set rather than relying on string matches alone. Policy sets bind detectors to actions — block, flag or escalate — per workload. A summariser that touches the accounts-payable inbox can get a stricter set than an internal drafting tool.
Least privilege for the summariser, enforced rather than intended. Forcepoint's recommendations include limiting what a summariser can do. If yours can draft replies, create tasks or forward messages, allow-lists validate each tool call against what that workload is registered to invoke. A call to a tool the workload was never registered to use is blocked and logged with full context, not just discouraged in a system prompt.
When the payment has already gone out, the evidence matters more than the detector. The hardest question after a tampered-summary fraud is not was the email malicious. The email the finance team can see is clean. The question is what was the model actually given, and what did it actually say. The audit ledger is an append-only, signed record of every prompt, response and policy decision, with the original preserved even where content was redacted or blocked. That turns the AI told us the amount from an unverifiable claim into a record you can hand to an investigator, an insurer or an auditor.
For years the security industry has told people to look carefully at what is in front of them: hover over the link, check the sender, read the amount twice. That advice assumed that what is in front of them is the email.
Increasingly, what is in front of them is a model's account of the email, produced by a pipeline that read a different document than the one they could have checked. Microsoft's campaign is a reminder that invisible characters are already routine in commodity phishing at millions of messages a day. Forcepoint's proof of concept is a reminder of how little effort it takes to point the same idea at the AI layer. The two pieces of research met in the middle within nine days of each other, and not by coincidence.
Human-in-the-loop only works if the human and the machine are looking at the same thing.
Explore Governance AI or talk to us about how many AI summarisers are reading your finance inboxes today — and whether you could show exactly what any of them was given.
Obiguard sits in front of every AI request your organization makes — screening prompts and outputs against the guardrails, compliance frameworks, and audit trails that stories like this one make necessary.
See how it works →