How the attack works
An attacker embeds content in a document or email that an AI email agent will process, containing an obfuscated version of their address such as 'contact[at]contact.com', 'contact＠contact', or 'contact@contact.com'. Because the address isn't written as a literal string with an '@' sign, naive keyword or regex filters looking for exact email addresses miss it. The AI agent, however, still parses the obfuscated text as a valid destination and uses it when composing a reply or forwarding data. This lets the attacker exfiltrate information the agent has access to, routed to a mailbox that evaded detection at input time.
Why it matters
Sensitive data the AI agent can access gets sent to an attacker-controlled mailbox without triggering address-based filters, resulting in a data leak that looks like normal outgoing email traffic.
What you can do
- Don't rely solely on literal '@' pattern matching to block or flag outgoing addresses; normalize text (decode HTML entities, fullwidth characters, spelled-out 'at'/'dot') before filtering.
- Review and restrict what external actions (sending email, posting data) an AI agent can take autonomously, especially in response to content it read rather than content a user typed.
- Log and audit AI agent outbound communications for review, particularly when the recipient was derived from ingested document content rather than a known contact list.
- Treat any content instructing an agent to contact a new or unusual address as suspicious, and require human confirmation before the agent sends data externally.
Known benign look-alikes
- A support page literally listing 'contact at contact.com' as a help address (rare; would need the exact contact/contact pairing)
- Documentation of email-obfuscation techniques that quotes these forms without an active directive