M365 Purview | DLP schließt externe E-Mails aus dem Copilot-Grounding aus

Jede Mail, die von außen in deinen Tenant läuft, ist für Microsoft 365 Copilot bisher gleichwertige Datenbasis. Copilot arbeitet im Sicherheitskontext des angemeldeten Benutzers und greift auf alles zu, was dieser Benutzer lesen darf. Ein Absender außerhalb deiner Organisation kann damit Inhalte in einen Kontext schreiben, den eine KI später zusammenfasst, zitiert und weiterverarbeitet, ohne dass der Benutzer die Nachricht je bewusst geöffnet hat.

Microsoft Purview bekommt dagegen eine neue DLP-Bedingung. Sie schließt E-Mails von externen Absendern aus der Grundlage aus, auf der Copilot seine Antworten bildet. Die Ankündigung steht in MC1301714 (Roadmap-ID 561552), die Public Preview lief im Juni 2026 aus, und die allgemeine Verfügbarkeit hat Microsoft im Update vom 17. Juli 2026 auf Ende Januar bis Ende Februar 2027 verschoben. Vorher war Juli und August 2026 geplant.

Der Aufbau folgt dem bekannten DLP-Muster aus Bedingung und Aktion. Als Bedingung wählst du E-Mail wird empfangen von > Externe Benutzer, als Aktion Verarbeitung von Inhalten durch Copilot verhindern. Beides gilt für den Speicherort Microsoft 365 Copilot und Copilot Chat.

Greift die Regel, fällt die Nachricht aus drei Verwendungen heraus: Sie wird nicht mehr als Grounding-Daten herangezogen, nicht mehr zusammengefasst und nicht mehr als Quelle zitiert. Antworten bildet Copilot weiter aus internen Quellen, für die der Benutzer Berechtigungen hat, also SharePoint, OneDrive und interne Exchange-Inhalte. Der Benutzer sieht in der Antwort einen Hinweis, dass Inhalte durch eine Organisationsrichtlinie ausgeschlossen wurden.

Die Prüfung selbst ist schmal gehalten. Bewertet wird ausschließlich die Absenderdomäne aus den Nachrichten-Metadaten, verglichen mit den akzeptierten Domänen deines Tenants. Der Nachrichtentext wird nicht inspiziert. Was nicht in der Liste der akzeptierten Domänen steht, gilt als extern, egal ob es sich um einen Angreifer, einen Lieferanten oder einen Newsletter handelt.

0Die Funktion ist standardmäßig aus. Ohne eine Richtlinie ändert sich nichts, und an Zustellung, Aufbewahrung, eDiscovery oder dem Zugriff des Benutzers auf sein Postfach ändert die Regel ohnehin nichts. Die Mail bleibt im Posteingang lesbar, sie wird für die KI-Schicht unsichtbar.

Die klassische Berechtigungslogik greift hier zu kurz. Sie fragt, wer auf eine Information zugreifen darf. Die neue Bedingung fragt, woher die Information stammt. Genau das ist der Unterschied, der Prompt-Injection-Angriffe möglich macht.

Bei einer Cross-Prompt-Injection schreibt ein Angreifer Anweisungen in einen Inhalt, den das Modell später verarbeitet. Der Benutzer stellt eine harmlose Frage, etwa nach einer Zusammenfassung seiner offenen Punkte, und die KI liest dabei die präparierte Nachricht mit. Die Anweisung darin wirkt, ohne dass jemand sie bewusst ausgeführt hat. Der Fall EchoLeak hat gezeigt, dass eine einzelne E-Mail als Träger genügt.

Der Hebel entsteht aus der Kombination: Copilot handelt mit den Rechten des Benutzers, verarbeitet auf Zuruf große Mengen an Inhalten und unterscheidet dabei nicht zwischen einer Sachinformation und einer als Text getarnten Anweisung. Bei Führungskräften mit weitreichenden Berechtigungen ist das ein Angriffsweg mit echtem Schadenpotenzial.

Vor der KI-Ära musste ein Benutzer eine Nachricht öffnen, lesen und handeln. Diese Bremse fällt weg, wenn ein Assistent Postfächer im Hintergrund durchsucht. Deshalb ist die Herkunft der Daten ein sinnvolles Kriterium, auch wenn sie inhaltlich nichts über die Gefährlichkeit einer Nachricht aussagt.

Der Speicherort für Copilot ist nur über die Vorlage Benutzerdefiniert erreichbar. Wählst du ihn aus, deaktiviert Purview alle anderen Speicherorte in derselben Richtlinie. Diese Richtlinie ist damit reine Copilot-Richtlinie, und ein Mischbetrieb mit Exchange- oder SharePoint-Regeln scheidet aus.

In der Regel setzt du die Bedingung auf E-Mail wird empfangen von > Externe Benutzer und die Aktion auf Verarbeitung von Inhalten durch Copilot verhindern. Für die Berechtigung genügt eine der Purview-Rollen für Copilot-Richtlinien, etwa Purview Data Security AI Admin. Der Griff zum Globalen Administrator ist dafür nicht nötig und verschlechtert nur dein Rollenkonzept.

Zwei Details entscheiden über den Rollout. Erstens dauert es bis zu vier Stunden, bis eine geänderte Richtlinie in der Copilot-Erfahrung wirkt. Wer direkt nach dem Speichern testet, misst den alten Zustand. Zweitens unterstützt der Speicherort den Simulationsmodus. Fahr die Richtlinie erst dort, sieh dir an, wie viele Treffer entstehen, und schalte danach scharf.

Eine Regel darf die Bedingungen Inhalt enthält > Vertraulichkeitsbezeichnungen und Inhalt enthält > Vertrauliche Informationstypen nicht gleichzeitig führen. Beide gehören in getrennte Regeln innerhalb derselben Richtlinie.

Naheliegend wäre, den Block zuerst nur auf gefährdete Konten anzuwenden, etwa Geschäftsführung und Assistenzen. Der übliche Weg dafür sind administrative Einheiten. Genau der funktioniert hier nicht: Microsoft dokumentiert für den Speicherort Microsoft 365 Copilot und Copilot Chat ausdrücklich, dass administrative Einheiten nicht unterstützt werden.

Was bleibt, sind die Ein- und Ausschlusslisten im Speicherort selbst. Du nimmst eine Pilotgruppe auf, prüfst die Wirkung und weitest den Kreis danach aus. Die Standardrichtlinie, die Microsoft für den Copilot-Speicherort mitliefert, umfasst dagegen alle Benutzer und Gruppen des Tenants. Für eine erste Erzwingung ist das der falsche Zuschnitt.

Plane die Kommunikation mit ein. Der Ausschluss wirkt rückwirkend, also auch auf Nachrichten, die längst im Postfach liegen. Für Benutzer heißt das: Auf dieselbe Frage liefert Copilot ab dem Stichtag eine andere Antwort als am Vortag. Ohne Vorankündigung landet das als Störungsmeldung im Helpdesk.

Die Bedingung kennt genau zwei Zustände, akzeptierte Domäne oder nicht. Das ist einfach umzusetzen und in mehreren Konstellationen zu grob.

Betreibst du eine Multi-Tenant-Organisation, gehören die anderen Tenants zwar organisatorisch zu dir, ihre Domänen stehen aber nicht in der Liste der akzeptierten Domänen deines Tenants. Ihre Nachrichten gelten damit als extern und fliegen aus dem Grounding. In einer MTO, die laut Microsoft bis zu 100 Tenants umfassen darf, trifft das ganze Konzernbereiche. Dasselbe gilt für Zulieferer, Steuerberater oder Projektpartner, deren Mails fachlich wertvoll sind.

Eine Ausnahmeliste für einzelne vertrauenswürdige Domänen sieht die Bedingung nicht vor. Die Entscheidung fällt pro Benutzergruppe, nicht pro Absender. Wer viel Fachinformation über externe Mail bezieht, muss also abwägen, statt pauschal zu blocken.

Der zweite Punkt betrifft die Wirkungstiefe. Da nur Metadaten bewertet werden, greift der Schutz beim Absender, nicht beim Inhalt. Leitet ein interner Kollege eine präparierte Nachricht weiter, stammt sie aus einer akzeptierten Domäne und bleibt für Copilot sichtbar. Der Block reduziert die Angriffsfläche, er schließt sie nicht.

Die neue Bedingung ist eine sinnvolle Ergänzung im Copilot-Regelwerk, aber kein Sicherheitsprodukt für sich. Sie senkt das Risiko, dass eine präparierte Nachricht von außen in die Antwortbildung gerät, und sie tut das mit minimalem Aufwand: eine Richtlinie, eine Bedingung, eine Aktion. Der Preis ist ein Informationsverlust, dessen Höhe von deinem Geschäftsmodell abhängt. In einer Organisation, die Aufträge, Spezifikationen und Zeitpläne per Mail von Kunden bekommt, schneidest du Copilot von einem großen Teil des Arbeitskontexts ab.

Praktisch heißt das: erst Simulationsmodus, dann eine kleine Pilotgruppe mit hoher Exposition, dann die Auswertung im Activity Explorer, und erst danach die Entscheidung über eine Ausweitung. Rechne die vier Stunden Wirkzeit und die rückwirkende Wirkung in deinen Testplan ein, sonst deutest du Messergebnisse falsch.

Für die Dokumentation ist die Bedingung ein dankbarer Baustein. Wer nach ISO 27001 oder im Rahmen von NIS2 nachweisen muss, wie er den Einsatz von KI-Systemen kontrolliert, kann hier eine technische Maßnahme mit klarer Wirkung benennen, statt auf eine Richtlinie im Intranet zu verweisen. Ein Restrisiko bleibt, und es gehört genauso ins Protokoll: Der Schutz endet an der Absenderdomäne. Bis zur allgemeinen Verfügbarkeit Anfang 2027 solltest du außerdem damit rechnen, dass sich Verhalten und Benutzerhinweise noch ändern.