Your team approved the email summarizer add-in because it saves time. You vetted the vendor's SOC 2 report. You confirmed the LLM runs in an isolated environment. The tool shows you a clean summary of each message, and your team moves faster through their inbox.
But here's what you didn't account for: the AI might be reading completely different content than what appears on your screen.
Myth 1: If the Email Looks Clean in Outlook, It's Clean to the AI
Reality: HTML and CSS can hide entire instruction sets from human readers while delivering them intact to the LLM.
Forcepoint X-Labs demonstrated this using basic styling: font-size:0px; color:#ffffff; line-height:0. The visible email contained 537 characters. The content sent to the model contained 1,009 characters, including 472 characters of hidden injection text. Ten out of ten test runs produced manipulated summaries that changed a deadline from August 21, 2026, to September 3, 2026, and omitted a name mentioned in the original email.
The only visible difference? Extra whitespace between paragraphs. Even that could be eliminated with minor adjustments.
This isn't a theoretical vulnerability. It's exploitable today using HTML techniques that predate modern web standards. If your email summarizer ingests raw HTML without stripping invisible content, you're processing two different messages: one for humans, one for the AI.
ISO/IEC 27001 Control 8.16 (Monitoring activities) requires you to know what your systems are actually processing. If your monitoring shows "email summarized" but doesn't validate that the input matches what the user saw, you've got a gap.
Myth 2: The LLM Provider's Security Controls Protect You
Reality: The vulnerability isn't in the model. It's in how you're feeding it data.
Forcepoint used Claude-haiku-4-5 for their proof-of-concept, but they explicitly noted there's no specific issue with that model or any LLM provider. The problem is architectural: an Outlook add-in collected email headers and body, a Python script merged them into a single prompt, and the system sent everything to the LLM with no guardrails separating instructions from content.
The system prompt was straightforward: "You are an email summarizer. Summarize the email the user provides." No input validation. No content filtering. No separation between trusted instructions and untrusted email content.
Your vendor's SOC 2 Type II report tells you how they protect their infrastructure. It doesn't tell you whether your implementation treats email content as untrusted data. That's on you.
SOC 2 CC6.1 (Logical and Physical Access Controls) requires you to restrict access to data and system components. But if your pipeline blindly trusts email content as input to an AI system that takes instructions, you've created a control bypass that no amount of vendor certification will fix.
Myth 3: AI-Generated Summaries Are Trustworthy Because They're Consistent
Reality: Consistency doesn't mean accuracy. It means the injection worked every time.
In Forcepoint's test, all ten runs of the injected email produced the same manipulated output. The summary consistently reported the wrong deadline and consistently omitted the specified name. This wasn't a hallucination or a random error. It was deterministic execution of hidden instructions.
If you're using AI summaries to make decisions about invoice payments, contract deadlines, or security incidents, you need verification controls. ISO/IEC 27001 Control 5.10 (Acceptable use of information and other associated assets) requires you to define rules for information processing. "Trust the AI summary" isn't a control. "Cross-reference AI output against source content" is.
Consider what happens when your accounts payable team processes an invoice summary that quietly shifts a payment deadline. Or when your incident response workflow routes an alert based on a summary that omits critical details. The AI didn't malfunction. It did exactly what the hidden prompt told it to do.
Myth 4: Detecting Prompt Injection Requires Advanced AI Security Tools
Reality: Basic input validation would prevent most of these attacks.
Forcepoint's recommendations are straightforward:
- Extract only content visible to the user
- Detect hidden or suspicious HTML/CSS styling
- Separate email headers from the body in your prompt structure
- Treat all email content as untrusted data
- Validate AI-generated summaries against the original source
None of these require specialized AI security platforms. They're standard input validation practices that should already be part of your secure development lifecycle.
If you're building or configuring AI tools that process external content, ISO/IEC 27001 Control 8.25 (Secure development lifecycle) applies. You need to identify security requirements during design. "Don't let email senders inject instructions into the LLM prompt" is a security requirement.
SOC 2 CC7.2 (System Monitoring) requires you to detect anomalies. A 472-character discrepancy between visible content and processed content is an anomaly. If your logging doesn't capture input length, content hash, or style attributes, you won't detect the attack even after it succeeds.
Myth 5: This Only Matters for Email Summarizers
Reality: Any AI tool that processes untrusted input without guardrails has this problem.
Email is just one attack surface. Consider:
- Customer support chatbots that process user-submitted text
- Document analysis tools that ingest uploaded files
- Slack bots that summarize channel discussions
- Calendar assistants that parse meeting invites
- CRM tools that auto-categorize incoming messages
If your AI pipeline doesn't separate instructions from data, you're vulnerable wherever you accept external input. The technique scales to any content type that supports formatting or metadata: PDFs with hidden layers, Word documents with white-on-white text, web forms with hidden fields.
ISO/IEC 27001 Control 8.24 (Use of cryptography) won't help you here. Neither will network segmentation or endpoint detection. This is an application-layer vulnerability that requires application-layer controls.
What to Do Instead
Start with your inventory. Which AI tools in your environment process external content? Email summarizers, document parsers, chatbots, anything that takes input you don't control.
For each tool, document the data flow. Where does untrusted content enter? How does it get formatted into prompts? What separates user data from system instructions?
Then implement guardrails:
Input sanitization: Strip HTML/CSS from email content before sending it to the LLM, or extract only plain text. If you need to preserve formatting, parse it into a structured format that can't contain hidden instructions.
Prompt structure: Use clear delimiters between your system instructions and user content. Some frameworks support separate message roles (system vs. user). Use them.
Output validation: Don't trust AI summaries for critical decisions without verification. Log both the original content and the summary. Make it easy for users to compare them.
Monitoring: Track input length, content hashes, and processing time. A 537-character email that generates a 1,009-character prompt should trigger an alert.
Your external auditor won't ask about prompt injection during your next ISO/IEC 27001 surveillance audit. But they will ask how you ensure the integrity of automated processing (Control 8.1) and how you validate that systems behave as intended (Control 8.6). If your answer is "we trust the AI," you've got a nonconformity waiting to happen.
The attack Forcepoint demonstrated isn't sophisticated. It's basic HTML styling that any attacker can implement. Your defense shouldn't be sophisticated either. It should be systematic: treat external input as untrusted, validate AI outputs against source data, and monitor for discrepancies between what users see and what your systems process.
