Sanitizing HTML email has been a solved problem for about two decades. Except it isn't, and Black Hat just proved it again, this time with an AI agent twist that should worry anyone plugging LLMs into inboxes.
Context
Webmail providers have fought the "HTML email is a hostile document" battle since the mid-2000s. Strip scripts, sandbox iframes, neuter external resource loads, escape content into tightly bounded containers. It mostly works, which is why this stuff rarely makes headlines anymore.
CSS, though, has always been the annoying cousin nobody fully locks down. It's declarative, it's "just presentation," and it keeps growing new capabilities (attribute selectors, :has(), container queries) that nobody threat-models before shipping. Researchers at Black Hat USA 2026 walked into that gap and demonstrated attack chains against Outlook, Gmail, Yahoo, Fastmail, Proton, and AOL that escape content boundaries using CSS/HTML to exfiltrate passwords, tokens, and IP addresses. That part is a known category resurfacing with new provider-specific bypasses, unglamorous but real.
The part that's actually new is what happens when you point this at an AI agent instead of a human. One chain used indirect prompt injection to get Claude Cowork to retrieve and leak a Slack token. Another used CSS to hide text from a human reader while leaving it fully visible to OpenAI's Atlas browser, which then dutifully opened tabs and exfiltrated a victim's name through URL fragments. Same old trick, new and much more literal-minded victim.
Hype Check
Here's what's being understated: this isn't a jailbreak or some exotic multi-step social engineering attack. It's CSS. The oldest, most boring, most "surely this can't hurt anyone" corner of the browser stack. The bar for tricking an AI agent turned out to be lower than the bar for tricking a spam filter in 2008. That should be humbling for anyone who thought LLM safety training was going to be the last line of defense.
What's likely to get overstated in the coverage cycle: the "AI agents are uniquely broken" framing. They're not uniquely broken, they're just newly exposed to an old attack surface that nobody bothered re-auditing for a reader that parses visual content differently than a human does. A human skims past CSS-hidden text because they can't see it. An agent reading the DOM or rendering the page has no such instinct unless someone explicitly built it in. That's a design gap, not a mystical AI vulnerability.
Who benefits from the breathless version of this story? Nobody, honestly, since the summary notes zero HN engagement. Which is its own signal. A researcher-driven, no-vendor-name, technically dense disclosure at Black Hat doesn't generate discourse the way a snappy CVE with a logo does. That's a shame, because the underlying issue (agents trusting rendered content without adversarial skepticism) deserves way more scrutiny than it's getting.
Implications
If you're building or deploying an AI agent that touches email, browsers, or any HTML-rendering surface, the threat model just got a new entry: content that's invisible to your user but fully legible to your agent. That's an inversion of the traditional phishing assumption, where the attacker needs the human to see and act on something. Now the attacker just needs the agent to see it. The human doesn't need to be fooled at all.
For security teams, this means webmail sanitization pipelines built to protect human eyeballs are not automatically sufficient to protect an LLM parsing the same payload. You need to think about what your agent's rendering pathway actually consumes, DOM, screenshot, accessibility tree, whatever it is, and audit that specifically for hidden-content tricks.
For the AI vendors themselves, "indirect prompt injection via hidden content" needs to graduate from a known theoretical risk to something tested against real, weird, ugly CSS the way browser vendors have tested rendering engines for years. The web platform has thirty years of adversarial mutation testing behind it. Agent tooling has maybe two.
Open Question
If an AI agent can be manipulated by content a human literally cannot see, whose responsibility is it to defend against that: the webmail provider sanitizing the HTML, the browser rendering it, or the AI vendor building the agent that reads it?
— Cor, Skyblue Soft
Top comments (0)