In vielen Mandanten, die ich betreue, gehören Copilot-Studio-Agenten mittlerweile fest zur Automatisierung und zur Digitalisierung von Prozessen. Gebaut sind sie oft schneller, als Governance und Sicherheit nachziehen können. Deshalb landet die Frage nach dem Teilen von Copilot-Studio-Agenten regelmäßig auf meinem Tisch. Wer darf mit wem teilen? Wie verhindert man, dass ein Agent aus Versehen für die gesamte Organisation oder gar nach außen freigegeben wird? Und mit welchen technischen Mitteln behält man die Kontrolle?

Managed Environments legen fest, mit wem Agenten geteilt werden dürfen

Mit Managed Environments bietet die Power Platform schon seit Längerem einen zentralen Ansatz, um den Wildwuchs bei Power Apps und Flows einzudämmen. Mittlerweile gelten die Sharing-Limits auch für Copilot-Studio-Agenten. Im Power Platform Admin Center (→ Environments → [gewünschte Umgebung] → Edit Managed Environments → Limit sharing) legt man genau fest, wie und mit wem Agenten in der jeweiligen Umgebung geteilt werden dürfen, etwa nur mit bestimmten Sicherheitsgruppen, grundsätzlich nicht mit externen Benutzern oder nur auf Einladung. Gerade in produktiven Umgebungen, in denen Fachbereiche ihre Agenten selbst bauen, ist das ein Steuerungsinstrument, auf das man nicht verzichten sollte. Voraussetzung ist allerdings, dass die Umgebung als Managed Environment konfiguriert ist und die Teams ihre Agenten auch tatsächlich dort erstellen. Welche Einstellungen es im Einzelnen gibt, steht in der Microsoft-Dokumentation.

Ohne begleitende Prozesse und klare Kommunikation bleibt es in der Praxis allerdings häufig bei einem guten Konzept auf dem Papier. Ich habe schon Fälle erlebt, in denen Agenten versehentlich in einer nicht gemanagten Umgebung entstanden und anschließend großzügig geteilt wurden, weil die Entwickler schlicht nicht wussten, dass die Limits dort nicht greifen. Abhilfe schafft Transparenz. Wer im Power Platform Admin Center regelmäßig die Agenten-Inventarliste (Environments → [Umgebung] → Copilot Studio → Agents) aufruft, sieht, welche Agenten in welcher Umgebung existieren und wie sie geteilt sind.

Praxis-Tipp: In größeren Umgebungen empfiehlt es sich, beim Teilen Sicherheitsgruppen als Ziel zu verwenden. Dann lässt sich zentral (z. B. über Entra ID) nachvollziehen, wer Zugriff erhalten darf, und Berechtigungen lassen sich gezielt wieder entziehen.

Sicherheitsgruppen und klare Besitzverhältnisse verhindern unkontrolliertes Teilen

Weist man Umgebungen Sicherheitsgruppen zu, kann man neben der Nutzung auch das Teilen von Copilot-Studio-Agenten fein abgestuft steuern. In meinen Projekten löse ich das gern so, dass jedes Team oder jede Abteilung eine eigene Gruppe bekommt und nur deren Mitglieder in der zugehörigen Umgebung Agenten teilen dürfen. Damit veröffentlicht niemand versehentlich unternehmensweit oder macht seinen Agenten gar extern zugänglich. Die Gruppen sollte möglichst das IT-Team verwalten und nicht die Ersteller der Agenten selbst, denn sonst unterläuft man das eigentliche Governance-Ziel.

Häufig unterschätzt wird die Frage, was mit einem Agenten geschieht, wenn sein Ersteller das Unternehmen verlässt. In der Agenten-Inventarliste der Umgebung sind die Besitzer sichtbar und lassen sich bei Bedarf ändern. Das muss man allerdings von Hand erledigen, weil es beim Offboarding derzeit noch keine automatische Übertragung der Besitzrechte gibt. Im Zweifel hängt der Entra- oder Power-Platform-Admin den Besitz um. Diese Aufgabe gehört fest in die regelmäßige Aufräumroutine.

Die Authentifizierung entscheidet, wer den Agenten überhaupt nutzen kann

Beim Teilen von Copilot-Studio-Agenten kommt es entscheidend darauf an, welche Authentifizierung eingestellt ist. In den Agent-Einstellungen legt man fest, ob sich Nutzer mit ihrem Microsoft-Konto (bzw. über Entra ID) anmelden müssen, ob eine manuelle Identifikation genügt oder ob der Agent ganz ohne Authentifizierung auskommt. Vor allem die letzte Variante ist riskant. Wer einen Agenten zum Beispiel über den Website-Kanal ohne Authentifizierung veröffentlicht, macht ihn für jeden zugänglich. Meine Empfehlung aus der Praxis lautet daher, immer die Option „Authenticate with Microsoft“ zu nutzen, sobald ein Agent in irgendeiner Form auf Daten zugreift oder Unternehmensfunktionen bereitstellt. Wie sich die Authentifizierung richtig konfigurieren lässt, beschreibt Microsoft in der Dokumentation.

Jeder Veröffentlichungskanal bringt eigene Tücken mit

Copilot-Studio-Agenten lassen sich mittlerweile über mehrere Kanäle veröffentlichen, etwa in Microsoft Teams, in der Microsoft 365 Copilot App (dem Nachfolger der Microsoft 365 App) oder direkt als Web-Chat, den man beispielsweise in eine SharePoint-Seite einbetten kann. Jeder Kanal hat seine eigenen Einschränkungen beim Teilen und beim Zugriff. In Teams bleibt die Veröffentlichung meist auf die Organisation beschränkt (oder je nach Einstellung auf ausgewählte Teams bzw. Gruppen). Die Option „Website“ dagegen führt sehr schnell zu ungewollter Öffentlichkeit, vor allem wenn keine Authentifizierung verlangt wird. Auch die Kanäle, über die Agenten veröffentlicht wurden, kann man im Power Platform Admin Center einsehen und verwalten. Mehr zu den einzelnen Kanälen steht in der Microsoft-Dokumentation.

Bevor ich einen größeren Rollout freigebe, prüfe ich jedes Mal, ob die Kanäle sauber konfiguriert und die Authentifizierungsoptionen passend gesetzt sind. Als Gedankenstütze dient mir dabei dieses Diagramm:

flowchart TD
    agenten["Agenten-Ersteller"] --> umgebung["Managed Environment"]
    umgebung --> gruppe["Sicherheitsgruppe"]
    umgebung --> sharinglimit["Sharing-Limit"]
    agenten --> authentifizierung["Agent-Authentifizierung"]
    authentifizierung --> kanal["Veröffentlichungskanal"]
    kanal --> teams["Teams/M365 App"]
    kanal --> website["Website"]

Abbildung: So hängen Managed Environment, Gruppen, Sharing-Limit, Authentifizierung und Veröffentlichungskanal bei Copilot-Studio-Agenten zusammen.

DLP-Richtlinien ergänzen die Freigabesteuerung um den Blick auf die Daten

Wer sich mit dem Teilen von Copilot-Studio-Agenten befasst, sollte die DLP-Richtlinien (Data Loss Prevention) der Power Platform immer mitdenken. Unabhängig davon, wer mit wem teilen darf, bestimmen sie, welche Konnektoren ein Agent überhaupt verwenden kann. Sobald sensible Daten betroffen sind, wird das zu einem wichtigen Baustein der Governance. Konkrete Steuerungsmöglichkeiten habe ich bereits im Beitrag Copilot Studio DLP: Agenten und Datenflüsse im Griff beschrieben. Darüber hinaus lohnt es sich, die neuesten Governance-Funktionen in Copilot Studio anzusehen, etwa rund um autonome Agenten und ihre Überwachung. Mehr dazu findet ihr unter Autonome Agenten in Copilot Studio: Governance im Blick.

Wer Copilot-Studio-Agenten produktiv einsetzen möchte, braucht ein durchdachtes Zusammenspiel aus Managed Environments, Sicherheitsgruppen, Authentifizierungs- und Veröffentlichungsoptionen sowie DLP. Zwischen Agilität und Kontrolle muss man dabei immer wieder neu abwägen. Mit passenden Einstellungen und regelmäßigen Prüfungen im Power Platform Admin Center lässt sich das Risiko jedoch deutlich senken.