Seit Copilot-Studio-Agenten in vielen Microsoft-365-Tenants auftauchen, kommt die alte DLP-Frage wieder auf den Tisch. Es geht darum, wer worauf zugreifen darf, wohin Informationen fließen und wie sich verhindern lässt, dass ein KI-Agent Daten versehentlich (oder absichtlich) an die falschen Leute weitergibt. In Copilot Studio schließen Fachanwender mit wenig Erfahrung eigene Bots und Agenten an interne wie externe Datenquellen an. Eine DLP-„Pflichtübung“, die man einmal technisch abhakt, reicht dafür nicht aus. In den letzten Wochen bin ich immer wieder auf Tenants gestoßen, in denen Agenten auf erstaunlich viele Quellen zugreifen konnten, ohne dass das Adminteam davon wirklich etwas wusste. Copilot-Studio-DLP ist deshalb längst kein Randthema mehr. Ohne sie fehlt jeder ernst gemeinten Power-Platform-Governance ein tragender Baustein.

Die klassischen Power-Platform-DLP-Richtlinien gewinnen neu an Bedeutung

Im Power Platform Admin Center (Security → Data and privacy → Data policy) landen die meisten zuerst bei den bekannten Richtlinien zur Data Loss Prevention (DLP), den sogenannten „DLP policies“. Dort ordnet man Konnektoren den Gruppen Business, Non-business und Blocked zu und legt fest, welche Datenflüsse unterbunden werden, etwa von internen Quellen nach außen. Für Copilot-Studio-Agenten wirkt das überraschend gut. Viele wissensbasierte Agenten nutzen Konnektoren wie „SharePoint“ und „Outlook“, häufig aber auch „Websites“ oder „Custom connectors“. Setze ich für die Umgebung eine strenge DLP-Policy, fallen viele riskante Szenarien sofort weg. Dazu gehört, sensible Unternehmensdaten mit öffentlichen Websites zu kombinieren oder anonyme Nutzer ohne Entra-ID-Authentifizierung chatten zu lassen. Welche Konnektoren für Copilot-Studio-Agenten relevant sind und wie man sie klassifiziert, beschreibt Microsoft aktuell hier: Copilot-Studio-DLP.

Praxistipp: Wer DLP-Policies neu anlegt oder ändert, sollte die Auswirkungen zunächst in einer Testumgebung prüfen. Viele Apps und Agenten quittieren restriktive Policies mit Fehlermeldungen, deren Ursache sich oft nur mühsam zurückverfolgen lässt. Mit einem gestaffelten Rollout lassen sich größere Ausfälle vermeiden.

Gern übersehen wird, dass Power-Platform-DLP-Richtlinien immer auf Ebene der Umgebung greifen. Ausgerechnet das Default-Environment, in dem viele Experimente und erste Agenten entstehen, ist aber selten sauber abgesichert. Wer Copilot Studio tatsächlich im Griff haben will, muss an dieser Stelle umdenken.

Agenten gehören in eigene Umgebungen statt ins Default-Environment

Dass man das Default-Environment der Power Platform nicht für Entwicklung und Produktivbetrieb nutzen sollte, gilt in der Theorie seit Jahren als Best Practice. Mit Copilot Studio wird daraus eine Pflicht. Zwar lassen sich auch dort DLP-Policies setzen, doch bei so vielen Nutzenden und Apps verliert man schnell den Überblick. Sinnvoller sind eigene Umgebungen für Copilot Studio, die jeweils passende DLP-Richtlinien bekommen. Für einen bestimmten Fachbereich kann ich dann zum Beispiel festlegen, dass nur SharePoint- und Microsoft-365-Konnektoren (Business) erlaubt und öffentliche Webseiten gesperrt sind. Mit der Funktion Default Environment Routing lassen sich neue Apps und Agenten gezielt in kontrollierte Umgebungen umleiten.

Auf diese Weise lassen sich Entwicklung, Test und Produktivbetrieb von Agenten viel leichter trennen, und jede Stufe erhält die Kontrollen, die zu ihr passen. Wer weiter gehen möchte, aktiviert Managed Environments und bekommt damit unter anderem eine bessere Überwachung, App-Limits und eigene Freigabeprozesse. In größeren Organisationen zahlt sich das für sämtliche Copilot-Studio-Projekte aus.

Copilot Studio bringt eigene Konnektoren und Authentifizierungsoptionen mit

Knifflig wird Copilot-Studio-DLP bei den Konnektoren und Einstellungen, die es bei klassischen Power Apps überhaupt nicht gibt. Das betrifft vor allem die Wissensquellen. Agenten können neben SharePoint und OneDrive auch öffentliche Websites, interne Datenbanken oder sogar offene APIs anzapfen, solange keine DLP-Policy den jeweiligen Konnektor blockiert. Im Administrationsportal von Copilot Studio (bzw. im Power Platform Admin Center für die betreffende Umgebung) erkenne ich schnell, welcher Konnektor in welcher Gruppe steckt, und kann gezielt nachsteuern. Heikel ist außerdem die Option, Chats ohne Entra-ID-Authentifizierung zuzulassen. Damit sind anonyme Zugriffe möglich, und in produktiven Szenarien sollte diese Einstellung so gut wie immer deaktiviert sein.

Das folgende Diagramm zeigt, wie DLP-Policies, Umgebungen und die wichtigsten Kontrollpunkte für Copilot-Studio-Agenten zusammenhängen:

graph TD
    Admin["DLP-Policy admin"] --> Policy["DLP-Policy"]
    Policy --> Env["Umgebung"]
    Env --> Agent["Copilot Studio Agent"]
    Agent --> Konnektor["Konnektor (z.B. SharePoint, Website)"]
    Konnektor --> Datenquelle["Datenquelle"]
    Policy --> Blocked["Blockierte Konnektoren"]
    Agent --> Auth["Authentifizierungseinstellung"]

Abbildung: Die DLP-Policy legt fest, welche Konnektoren und Datenquellen Copilot-Studio-Agenten nutzen dürfen und welche Authentifizierungsoptionen zulässig sind.

Fünf Kontrollfragen gehören zu jeder Umgebung

Für jede Power-Platform-Umgebung, in der Copilot Studio genutzt wird, gehe ich mittlerweile diese fünf Punkte durch:

  • Gibt es eine eigene DLP-Policy, die speziell auf Copilot-Studio-Agenten zugeschnitten ist?
  • Liegen alle produktiven Agenten außerhalb des Default-Environments?
  • Sind kritische Konnektoren (z. B. Websites, offene APIs) ausdrücklich gesperrt?
  • Ist die Authentifizierung so konfiguriert, dass niemand anonym zugreifen kann?
  • Werden Änderungen an Policies, Agenten und Umgebungen regelmäßig überwacht?

Nach meiner Erfahrung hakt es meistens bei den ersten beiden Punkten. Wer bei der Wahl der Umgebung und der Gruppierung der Konnektoren schlampt, hat nach ein paar Wochen Agenten im Produktivbetrieb, die auf einmal externe Quellen abfragen oder sich anonym nutzen lassen. Abhilfe schafft nur eine konsequente Governance, bei der die bestehenden Einstellungen regelmäßig überprüft werden.

Eine durchdachte DLP-Strategie trägt die gesamte Agenten-Governance

Ich sehe Copilot-Studio-DLP nicht als lästige Compliance-Auflage. Für mich ist sie der wichtigste Hebel, um Agenten und ihre Datenflüsse überhaupt beherrschbar zu machen. Klare DLP-Policies, ein durchdachtes Umgebungskonzept und eine gezielte Kontrolle der Copilot-spezifischen Funktionen schützen schon heute am wirksamsten vor Datenschutzpannen und ungewolltem Oversharing. Wer außerdem Managed Environments und Routing klug einsetzt, behält den Überblick über eine Power-Platform-Landschaft, die einem sonst schnell entgleitet. Mehr zur Umsetzung und Verwaltung von Copilot-Studio-Agenten steht in meinen Beiträgen zur Governance in Copilot Studio und zum Verwalten von Agenten.