Microsoft Moves Prompt-Injection Defense Into Mail Flow—and Adds a Hard Gate for External Email
Microsoft has moved one layer of indirect prompt-injection defense in front of the inbox. In its July 30 security update, the company announced a preview of prompt injection protection in Microsoft Defender for Office 365 that identifies and isolates inbound email carrying malicious AI instructions before delivery. A separate Microsoft Purview preview can take a stricter approach: prevent Microsoft 365 Copilot and Copilot Chat from using any email received from an external domain for grounding, summarization, or citation.
These are not interchangeable controls. Defender makes a probabilistic verdict about message content and routes detections through the existing high-confidence-phishing path. Purview makes a deterministic trust decision from sender metadata and does not inspect the body at all. The first tries to preserve useful external mail while finding hostile instructions; the second accepts a larger productivity cost to remove an entire untrusted input class from Copilot.
The pairing is significant because email prompt injection is no longer confined to demonstrations. As our coverage of Proofpoint’s underground prompt-injection kits documented, sellers are packaging payload generation for email, attachments, calendar invitations, and webpages. Microsoft is responding at two distinct boundaries: before a message reaches a mailbox, and before Copilot can treat a delivered message as grounding data.
Defender now treats malicious AI instructions as a mail-flow threat
Microsoft’s product documentation says Defender for Office 365 evaluates inbound mail during the same filtering pipeline used for phishing, malware, and business email compromise. It combines large-language-model classification with existing sender and message signals. The analysis covers the subject and body, HTML markup and styling, hidden or off-screen text, quoted and forwarded content, and encoded or obfuscated segments after normalization.
A detection receives the existing High confidence phishing verdict plus a new Prompt injection protection detection-technology value. That value can be filtered in Threat Explorer, real-time detections, and Advanced Hunting. Microsoft says the capability applies to Defender for Office 365 Plan 1 and Plan 2 and requires no additional configuration to benefit from detection, while its July announcement describes the feature itself as being in preview.
Using an established phishing verdict has an operational advantage: organizations do not need a separate prompt-injection quarantine system before they can contain mail. It also creates a deployment question. The resulting action follows the tenant’s high-confidence-phishing handling, so administrators should verify that preset or custom policies produce the intended delivery and quarantine behavior rather than assuming the new classifier alone defines the response.
The detector is broader than a white-on-white-text rule. Microsoft explicitly lists zero-size and off-screen content, quoted-thread injection, Unicode and homoglyph tricks, fragmented phrasing, and encoded material among the relevant techniques. That matters after research repeatedly showed why merely stripping invisible text is insufficient, including attacks against AI-driven email filtering and the more recent document-borne Copilot chain.
Purview offers a coarser—but deterministic—boundary
The new Purview Data Loss Prevention condition is simpler. An administrator can target the Microsoft 365 Copilot and Copilot Chat policy location, select Email is received from → External users, and configure Prevent Copilot from processing content. Purview compares the sender domain with the tenant’s accepted domains. When it matches an external sender, Copilot excludes that message from grounding, summarization, and citation while the user retains normal access to the email.
Microsoft is explicit that this check evaluates metadata only; it does not inspect the email body. That makes it resistant to prompt obfuscation inside the message because content classification is irrelevant. It also means the policy cannot distinguish a trusted supplier’s ordinary mail from a hostile payload, and it does not address a compromised internal account or malicious content forwarded through an accepted domain.
The preview applies to Microsoft 365 Copilot and Copilot Chat email summarization and reasoning experiences. Policy changes can take up to four hours to appear, and the Copilot policy location is available only through a custom DLP template. Microsoft says DLP alerts, notifications, and simulation mode are supported. The external-message rule is narrower than a tenant-wide mail block: delivery and human access remain intact; only Copilot’s use of the message is removed.
This is the cleanest control for organizations whose requirement is “external email must never become agent context.” But it is a blunt default for teams that expect Copilot to summarize customer, partner, or incident-response correspondence. Those organizations may need Defender’s content-aware detection while limiting what the assistant can do after reading any message.
Neither layer is an authorization boundary
Pre-delivery classification reduces exposure, and excluding external grounding removes a large source of attacker-controlled instructions. Neither proves that the remaining content is trustworthy. Internal mailboxes can be compromised, accepted domains can include broad or poorly governed namespaces, legitimate external messages can be forwarded internally, and malicious instructions can arrive through documents, calendars, websites, chat, or connected applications.
Microsoft’s own zero-trust guidance says indirect prompt injection should be treated as inevitable and recommends layered probabilistic and deterministic mitigations: content marking, information-flow control, least privilege, plan-drift detection, and runtime monitoring. That framing is important. A mail filter should not be the control that prevents a summarizer from sending data, changing records, or invoking an administrative tool. Those actions need independent policy checks bound to the authenticated user and the intended task.
Microsoft has not published detection rates, false-positive rates, language coverage, or an evaluation corpus for the Defender preview in the referenced documentation. Defenders should therefore treat the launch as a new control to measure, not evidence that prompt injection in email has been solved.
What security teams should do now
- Verify the licensed rollout and actual verdict path. Confirm that prompt-injection detections appear in Threat Explorer or real-time detections and inspect how the tenant’s high-confidence-phishing policy handles them.
- Hunt by detection technology. Build queries and dashboards around the new Prompt injection protection value. Retain the sender, authentication results, delivery action, original location, and any post-delivery remediation.
- Use simulation before a broad external-email gate. Purview supports policy simulation. Measure which Copilot workflows depend on external correspondence before enforcing the rule, then document the expected loss of citations and summaries.
- Choose the boundary by workload. A finance or executive workflow with powerful mailbox access may justify excluding all external messages. A support queue may require content-aware filtering plus tightly constrained downstream actions.
- Test more than invisible text. Exercise visible instructions, quoted chains, HTML/CSS hiding, Unicode, encoding, and fragmented prompts. Include benign messages that discuss prompt injection so the evaluation measures false positives as well as misses.
- Keep actions outside model discretion. Require deterministic authorization for sending or forwarding mail, reading unrelated threads, accessing files, changing security verdicts, and calling connected tools. Minimize tokens and mailbox scopes for automated workflows.
- Cover the channels these controls do not. Threat-model calendar invitations, attachments processed outside mail flow, Teams messages, shared files, web grounding, plugins, and connectors. Preserve provenance when any of them enters an agent context.
The strongest part of Microsoft’s release is not a claim that one model can recognize every hostile instruction. It is the placement of controls at different trust boundaries. Defender can intercept suspicious content before delivery; Purview can stop an external message from becoming Copilot context even when the user still needs the mail. Organizations should use both as reductions in exposure while retaining the architectural rule that untrusted content never grants authority.
Sources: