Article: At Black Hat USA 2026, researchers showed that Cascading Style Sheets (CSS) can be weaponised to make AI-driven email agents read content invisible to human users. The technique bypassed Outlook, Gmail, Yahoo and Proton, letting the agents exfiltrate passwords, authentication tokens and IP addresses.

Why CSS matters in email security

For years webmail providers have defended against malicious HTML by stripping scripts, sandboxing iframes and limiting what a message can do. Those measures stop classic attacks that rely on JavaScript or embedded objects. CSS, however, has always been treated as harmless presentation code. Its advanced selectors—attribute selectors, container queries and the like—let a page react to the DOM structure without any scripting.

The Black Hat demos proved those “harmless” selectors can become a side-channel for data leakage. By crafting style rules that only apply when certain hidden elements exist, attackers make text invisible to the user but still present in the rendered page that an AI agent parses.

How the attacks work

One proof-of-concept sent an email that looked ordinary to the recipient. Hidden inside were CSS rules that changed the colour of specific text to match the background, effectively cloaking it. A human never sees the text, but an AI agent that extracts the DOM or the accessibility tree does not apply the visual filter. When the agent processed the email, it read the cloaked text and transmitted it in a URL fragment—a part of a web address that browsers normally ignore when loading a page.

Another variant used indirect prompt injection. The email contained a hidden Slack token. The CSS made the token invisible to the user but kept it in the markup. The AI agent, trained to follow instructions embedded in the email, interpreted the token as a command and sent it back to the attacker’s server.

Both attacks succeeded against the same set of popular providers, showing that the vulnerability stems from the fundamental way CSS is rendered, not from a single platform’s implementation.

AI agents vs. human readers

Humans instinctively ignore text they cannot see; we trust the visual layout to tell us what matters. AI agents, by contrast, operate on the raw DOM or an accessibility tree that records every element regardless of visual state. When an AI reads a page, it does not apply the “if I can’t see it, I’ll ignore it” rule. That mismatch creates a blind spot: sanitisation pipelines built for human consumption no longer guarantee safety for automated readers.

The problem is not a new AI flaw. It is an old web flaw—CSS’s ability to affect layout without code—meeting a new type of consumer. Any service that hands off email content to an AI-powered assistant, summariser or classifier now faces the risk that the assistant will act on data a human never sees.

Who’s responsible for the defense?

The attacks raise a jurisdictional question. Webmail providers already scrub HTML to protect human users; browsers already enforce the same rules for rendering. Yet none of those layers consider a downstream AI that will parse the same markup. Should the email service add deeper CSS sanitisation? Should browsers expose a flag that marks elements as “invisible to scripts”? Or must AI vendors build filters that discard hidden nodes before processing?

Security teams building AI-driven email tools are being told to audit the full rendering pipeline, not just the HTML that reaches the inbox. That means checking the DOM after CSS is applied, inspecting the accessibility tree, and explicitly stripping or flagging any content that is not visible to a human eye.

What to watch next

  • Vendor testing – AI vendors are expected to incorporate real-world CSS attack vectors into their test suites. The web has thirty years of vulnerability research; AI agents have only a few.

If an AI assistant can be tricked into leaking credentials simply by hiding text with CSS, the security model that protects today’s inboxes is no longer sufficient. Developers, providers and regulators must treat the rendered page—not just the raw HTML—as the security boundary for any automated consumer. The hidden-text problem reminds us that a technology once relegated to “just styling” can become a conduit for data theft. The next wave of defenses will have to recognise CSS as a potential attack surface, not just a visual aid.