Since early October 2026, Microsoft Defender for Office 365 has blocked prompt injection attempts in email by default. The prompt injection protection works in the mail flow, so a poisoned message is stopped before an assistant such as Microsoft 365 Copilot ever reads it. It needs no setup, but admins still have to verify it and understand where it stops.

The prompt injection protection is a filter in the mail flow

In an indirect prompt injection, an attacker hides instructions inside an email, for example as invisible text, in HTML markup, in attachments or in quoted replies. An AI assistant that reads the mailbox may treat those instructions as a task and leak sensitive data. Microsoft therefore acts early: the detection sits in the mail flow and adds to the safeguards the language model already has.

Detected messages are classified as High Confidence Phish and moved to quarantine. The official guide to prompt injection protection also describes a detection technology called "Prompt Injection Protection" that you can filter on later. The feature was in preview from July 2026 and became generally available in early October.

The protection is on by default only with Plan 2 or Microsoft 365 E5

The feature is enabled for tenants with Defender for Office 365 Plan 2 and with Microsoft 365 E5, which includes Plan 2. If you run Plan 1, for instance through Microsoft 365 Business Premium, you do not get this automatic detection according to current documentation. Check which license your mailboxes actually carry before you rely on it.

You do not have to configure anything, but you should watch what it does. Automatic quarantine can produce false positives, and newsletters with hidden text elements or system mails with unusual HTML are likely candidates. The current changes are collected on the what's new page for Defender for Office 365.

In the Defender portal you can see what the protection catches in four steps

The diagram below shows the path of a message from arrival to review by your security team.

flowchart TD
    A["Incoming email"] --> B["Mail flow inspection"]
    B -->|"Instruction detected"| C["High Confidence Phish"]
    B -->|"Looks clean"| D["Delivered to mailbox"]
    C --> E["Quarantine"]
    E --> F["SOC review"]

A message flagged as prompt injection ends up in quarantine and is reviewed there.

You do the review in the Microsoft Defender portal at security.microsoft.com. You need at least a role such as Security Reader to view detections and Security Administrator if you want to release messages.

  1. Open Email & collaboration and then the "Explorer" page (Threat Explorer).
  2. Pick the time range you want to investigate, for example the last seven days.
  3. Filter by the detection technology "Prompt Injection Protection" if your tenant offers that value.
  4. Open individual hits and check sender, subject and delivery action. Release false positives from quarantine afterwards or report them to Microsoft.

According to the documentation, the detection technology is also available in advanced hunting and on the email entity pages. I deliberately do not name any table columns here, so check the schema reference in your tenant for the exact fields. More on working with the tool is in the Threat Explorer overview.

For false positives you should document the cause before releasing anything

For every false positive, note the sender, the subject and the reason the message stood out. If a pattern repeats, for example with one newsletter service, talk to the sender first instead of creating an exception right away. A blanket exception opens exactly the gap the filter is meant to close. Teams with many external partners benefit from keeping such cases in a short shared list.

A quick check with colleagues helps as well: ask whether anyone is missing expected mail. That shows you early whether quarantine gets in the way in daily work, and you can adjust deliberately before frustration builds up.

Quarantine policies decide who sees and releases the hits

Messages with the High Confidence Phish verdict are usually covered by the strictest quarantine policy. End users normally cannot release such mails themselves, which is the right behavior. How quarantine administration works is explained in the overview of quarantine in Microsoft 365.

Tip: Decide who on the team reviews prompt injection hits, and always talk to someone who knows the sender before releasing a message. A released mail goes back to the mailbox and therefore within reach of Copilot.

The filter works best in combination with other layers. I covered how to tune phishing policies in my post on impersonation protection in Defender against CEO fraud. If you also want to catch incidents in the Defender portal in time, the article on Defender XDR incident notifications has useful pointers.

The filter does not replace governance for AI assistants

A mail filter recognizes patterns, not intent. Well-hidden or unusually worded instructions can slip through, and prompt injection can also arrive through other channels such as documents or web pages. Treat the protection as one layer among several and keep the permissions of Copilot and agents tight.

Because Copilot works with the permissions of the person using it, you should also review which mailboxes, files and chats individual users can reach. The less an account can see, the less an injected instruction can do. Agents with access to mailboxes deserve a critical look too, since they often act without asking back. Awareness training for staff complements the technology well.

My suggestion for the next few days: check the license, watch the quarantine, clarify responsibilities and review the hits after two weeks. Then you will know whether your tenant sees mostly real attacks or mostly false alarms.