Environment Routing hält Copilot-Studio-Agents aus der Default-Umgebung

Wer Copilot Studio produktiv einsetzt, merkt schnell, wie viel davon abhängt, in welcher Umgebung gearbeitet wird und wer das steuert. In vielen Tenants, die ich begleite, landen die ersten Copilot-Experimente von Fachbereichen oder Power Usern fast immer in der Default-Umgebung. Meist hat schlicht niemand erklärt, welche Umgebung zu wählen ist, oder die Nutzer gelangen direkt über Office.com in Copilot Studio. Riskant ist das trotzdem. In der Default-Umgebung fehlen häufig grundlegende Schutzmaßnahmen, Berechtigungen sind kaum eingeschränkt, und Data Loss Prevention (DLP) greift meist zu grob oder überhaupt nicht.

Die Default-Umgebung bietet Copilot-Studio-Agents kaum Schutz

In der Default-Umgebung der Power Platform können theoretisch alle Benutzer Agents bauen, Datenquellen anbinden und Konnektoren verwenden, ohne Governance und oft ohne jede Kontrolle. Heikel wird es, sobald Copilot-Studio-Agents produktiv laufen und etwa sensible Inhalte aus M365-Diensten oder sogar aus Drittquellen verarbeiten. Ist ein solcher Agent erst einmal freigeschaltet, wird er schnell unkontrolliert geteilt oder mit Datenquellen verbunden, die in keinem Schutzkonzept vorkommen.

In meinen Projekten stelle ich immer wieder fest, dass für die Default-Umgebung keine DLP-Regeln und Konnektor-Beschränkungen existieren oder dass sie viel zu lax sind. Noch problematischer ist, dass oft niemand genau weiß, wer überhaupt Agents bauen darf. Missbrauch lässt sich so kaum verhindern. Wer Copilot Studio sicher und nachvollziehbar betreiben will, braucht eine eigene Umgebung pro Team oder Use Case. Wie man diese Umgebungen am besten zuschneidet, darüber wird nach wie vor gestritten. Jede durchdachte Lösung ist aber besser als das Durcheinander in der Default-Umgebung.

Environment Routing schickt Maker gezielt in die passende Umgebung

Seit einiger Zeit gibt es das Environment Routing, und ich empfehle es jedem Tenant-Admin. Unter Power Platform Admin Center → Einstellungen → Produkt → Features → Environment Routing legt man fest, wohin Maker beim Öffnen von Copilot Studio (und anderer Power-Platform-Apps) standardmäßig geleitet werden. Neue Anwendungen und Agents landen dann nicht mehr automatisch in der Default-Umgebung, sondern zum Beispiel in einer persönlichen Entwicklerumgebung oder, bei anspruchsvolleren Szenarien, in einer Managed Environment.

Das Routing lässt sich für einzelne Benutzergruppen getrennt einstellen (z. B. nach Lizenz, Rolle oder Entra-ID-Gruppe). Endanwender erhalten dann etwa beim ersten Start eine eigene Developer-Umgebung, Fach-IT oder Power User landen direkt in einer eigens eingerichteten Team-Umgebung. Ein echter Fortschritt ist, dass sich Maker sogar an Managed Environments mit vordefinierten DLP- und Compliance-Richtlinien binden lassen. Nach der Umstellung dient die Default-Umgebung nur noch als Sammelstelle für Altlasten, in der nicht mehr jeder tun und lassen kann, was er will.

graph TD
    Benutzer["Benutzer startet Copilot Studio"] --> Routing["Environment Routing greift"]
    Routing --> Dev["Persönliche Developer-Umgebung"]
    Routing --> Team["Team-Umgebung (Managed)"]
    Routing --> Default["Default-Umgebung (Legacy)"]
    Dev --> DLPDev["Eigene DLP-Regeln"]
    Team --> DLPTeam["Strikte DLP & Compliance"]
    Default --> Risiko["Kaum Kontrolle"]

Abbildung: Environment Routing legt fest, in welcher Umgebung Copilot Studio geöffnet wird, und jede Umgebung bringt ihre eigenen Schutzmaßnahmen mit.

Managed Environments mit ALM und DLP bringen Ordnung in die Agent-Entwicklung

Sobald mehrere Teams oder Use Cases mit Copilot Studio arbeiten, führt an Managed Environments kein Weg vorbei. Sie bringen eine Reihe praktischer Funktionen mit, darunter zentrales Monitoring, eingeschränkte Konnektoren, eigene DLP-Richtlinien pro Umgebung und eine bessere Übersicht darüber, wer was baut. Für produktive Szenarien rate ich zu Managed Environments mit strikter Steuerung von Berechtigungen und Konnektoren. Test- und Produktivumgebung gehören klar getrennt. Agents und Komponenten werden dann über Solutions und einen ALM-Prozess (Application Lifecycle Management) verwaltet und ausgerollt. Dieses Vorgehen hat sich bewährt, vor allem dort, wo Governance und Nachvollziehbarkeit Vorrang haben.

Steht dieses Fundament, kann man für jede Umgebung eigene Data Policies konfigurieren. Das zahlt sich spätestens dann aus, wenn ein Agent in der Testumgebung auf produktive Daten zugreifen will, denn genau dann greift der DLP-Block. Auch das Auditing ist in Managed Environments besser gelöst als in der Default-Umgebung. Wie Managed Environments in der Power Platform im Detail funktionieren, beschreibt Microsoft in der offiziellen Übersicht.

Das Anlegen neuer Copilot-Studio-Umgebungen gehört in wenige Hände

Viele unterschätzen, wie schnell bei der Umgebungserstellung Wildwuchs entsteht. Standardmäßig dürfen Power-Platform-Admins neue Umgebungen anlegen, je nach Tenant-Konfiguration aber auch andere Rollen. Wer Governance ernst nimmt, schränkt diese Berechtigung ein und führt einen verbindlichen Prozess ein. Bewährt hat sich häufig, dass alle Umgebungen zentral über das Power Platform Admin Center beantragt und genehmigt werden. Gerade in größeren Tenants verhindert man so, dass irgendwo Schattenumgebungen entstehen, die dann niemand mehr im Blick hat.

Mein Tipp aus der Praxis: Legt eine zentrale Dokumentation an, in der ihr alle Copilot-Studio-Umgebungen mit ihrem Zweck, den Verantwortlichen und den jeweils geltenden DLP-Policies festhaltet. Dann behaltet ihr den Überblick und könnt Compliance-Anforderungen jederzeit sauber belegen.

Die Frage der Umgebungssteuerung betrifft übrigens nicht nur Copilot Studio. Bei Power Automate, Power Apps und Co. stellen sich ganz ähnliche Aufgaben. Wer tiefer einsteigen möchte, findet viele Parallelen zu den DLP- und Governance-Fragen, die ich letztes Jahr in meinem Beitrag zu Risiken und Kontrollen bei der Copilot-Studio-Governance 2024 behandelt habe.

Ein tragfähiges Umgebungsmodell setzt sich in der Praxis zunehmend durch

Den einen richtigen Weg gibt es nicht. Die folgende Struktur begegnet mir in Projekten aber immer häufiger:

• In der Default-Umgebung gelten strikte DLP-Regeln, produktive Daten haben dort nichts zu suchen.
• Environment Routing ist für alle Endanwender aktiviert, Sandbox-Tests laufen in persönlichen Developer-Umgebungen.
• Produktive Agents laufen ausschließlich in Managed Environments, getrennt nach Test und Produktion und mit ALM-Prozess.
• Neue Umgebungen werden zentral angelegt, und für jede gibt es feste Verantwortliche.
• Pro Umgebung sind die DLP- und Compliance-Regeln klar dokumentiert, sichtbar und werden regelmäßig überprüft.

Wer seine Copilot-Studio-Umgebungen nach diesem Muster aufbaut, hat Governance, Kontrolle und Compliance deutlich besser im Griff und dämmt den Wildwuchs in der Power Platform spürbar ein.