Agent Flows in Copilot Studio brauchen eine durchdachte Governance

Wer die Entwicklung von Microsoft Copilot Studio in den letzten Monaten verfolgt, bemerkt vor allem eine Veränderung. Mit Agent Flows in Copilot Studio bekommen Agenten mehr als bloßen Lesezugriff. Sobald Flows und Connectoren hinzukommen, können sie Aktionen auslösen und Daten verändern, im Extremfall sogar externe Systeme steuern. Damit wird Governance auf einmal zur Pflicht. In vielen Tenants, die ich betreue, schrillen die Alarmglocken spätestens dann, wenn die ersten produktionsnahen Szenarien entstehen oder die Compliance-Abteilung mitreden will. Wer Copilot-Agenten nicht konsequent absichert, riskiert Datenlecks und obendrein Manipulationen an Workflows und Systemen.

Agent Flows erlauben Agenten weit mehr als das Lesen von Daten

Technisch betrachtet sind Agent Flows in Copilot Studio deterministische Automatisierungen, die ein Agent als „Tools“ aufruft. Das kann eine einfache Aktualisierung eines Datensatzes in Dataverse sein oder ein Termin im Outlook-Kalender. Genauso gut kann der Flow aber in SharePoint schreiben, einen Genehmigungsprozess anstoßen oder über Connectoren Aktionen in Drittanwendungen ausführen. Ein Agent handelt dabei mit genau den Rechten, die ihm über Flows und Connectoren ausdrücklich eingeräumt werden. Diese Rechte reichen oft deutlich weiter, als man als Admin zunächst vermutet. Für die Risikoabschätzung kommt es vor allem darauf an, ob die Aktionen im Auftrag des Agenten-Erstellers (Maker) oder des jeweiligen Nutzers laufen.

DLP-Richtlinien bilden das Fundament jeder Agenten-Governance

Sobald Flows und Connectoren beteiligt sind, fliegt ein Copilot-Projekt ohne durchdachte DLP-Strategie für die Power Platform blind. Die DLP-Richtlinien bestimmen, welche Connectoren sich mit Agent Flows kombinieren lassen, und trennen dabei klar zwischen Business-, Non-Business- und geblockten Connectoren. Heikel wird es vor allem, wenn Agenten auf Systeme außerhalb von Microsoft 365 zugreifen, zum Beispiel auf SAP, SQL Server oder Web-APIs. Schon das Verschieben eines Connectors in eine andere Kategorie kann bestehende Automatisierungen stören. Ich rate deshalb immer dazu, die aktuellen DLP-Richtlinien regelmäßig im Power Platform Admin Center zu prüfen und jede Änderung sauber zu dokumentieren. Ausführlichere Hinweise dazu habe ich in einem eigenen Beitrag zusammengetragen: Copilot Studio Governance: Risiken und Kontrollen 2024.

Praxistipp: Prüft vor dem produktiven Einsatz der ersten Agenten, welche Connectoren in euren DLP-Richtlinien als geblockt eingestuft sind. Gerade ältere Tenants haben hier oft Lücken, die durch Agent Flows auf einmal sicherheitsrelevant werden.

Bei Connectoren entscheiden Endpunktfilter und Authentifizierung über die Rechte

Die grundsätzliche Freigabe in den DLP-Richtlinien ist nur der erste Schritt, spannend wird es bei der Konfiguration der Connectoren selbst. Für viele Connectoren bietet die Power Platform inzwischen sogenannte Endpunktfilter. Damit lässt sich etwa ein HTTP-Connector auf bestimmte Domains beschränken. Bei Agent Flows halte ich das für unverzichtbar, weil Agenten sonst beliebig in irgendwelche Systeme schreiben können. Noch schwerer wiegt die Wahl der Authentifizierung. Läuft ein Flow mit den Anmeldeinformationen des Makers, handeln im schlimmsten Fall alle Nutzer des Agenten mit dessen erweiterten Rechten. Läuft er dagegen im Kontext des jeweiligen Nutzers, ist das Risiko oft geringer, allerdings brauchen die Nutzer dann selbst die nötigen Rechte. Im Power Platform Admin Center könnt ihr diese Einstellungen pro Flow und Connector einsehen und verwalten. Weitere Details stehen in der offiziellen Dokumentation: Flows in Copilot Studio im Überblick.

Die folgende vereinfachte Darstellung zeigt, wie Agent Flow, Copilot Studio, Connectoren, DLP und Authentifizierung ineinandergreifen:

flowchart TD
  Agent["Copilot Agent"] --> Flow["Agent Flow"]
  Flow --> Connector["Connector"]
  Connector --> Action["Aktion im System"]
  Flow -- "DLP geprüft" --> DLP["DLP-Richtlinie"]
  Connector -- "Endpointfilter" --> Endpoint["Endpoint-Filter"]
  Flow -- "Authentifizierung" --> Auth["User/Maker Credentials"]

Abbildung: Für seine Aktionen nutzt der Agent Flow Connector, DLP und Endpunktfilter, über die Rechte entscheidet die Authentifizierung.

Genehmigungsschritte und Protokolle machen kritische Flows nachvollziehbar

Bei kritischen Flows, die weitreichende Änderungen an Systemen auslösen, lohnen sich Genehmigungsschritte (Approvals) direkt im Flow. Sie sind vor allem dann wichtig, wenn ein Mensch die Aktionen eines Agenten kontrollieren soll, statt sie vollautomatisch laufen zu lassen. In der Praxis begegnet mir das meist bei Self-Service-Prozessen, Zugriffsanträgen oder HR-Workflows. Im Power Platform Admin Center lässt sich nachvollziehen, welche Flows veröffentlicht wurden, wer sie veröffentlicht hat und welche Änderungen es gab. Wie weit Logging und Überwachung reichen, hängt allerdings vom Connector und vom Flow-Typ ab. Wer Compliance-Anforderungen erfüllen muss, sollte deshalb früh klären, wie Flow- und Agentenaktivitäten auditiert und archiviert werden. Auch in die offizielle DLP-Dokumentation schaue ich regelmäßig, weil sich dort laufend Details ändern.

Nicht jeder im Tenant sollte Agenten veröffentlichen dürfen

In Projekten werde ich immer wieder gefragt, wer im Tenant überhaupt einen Agent Flow in Copilot Studio veröffentlichen darf. Das hängt stark von der Power-Platform-Governance ab. Viele Unternehmen fahren mittlerweile restriktive Umgebungsstrategien, in denen nur klar benannte Maker in dedizierten Umgebungen veröffentlichen dürfen. Für produktive Agenten setze ich fast immer auf separate Umgebungen mit eingeschränktem Zugriff und auf Genehmigungs-Workflows für Veröffentlichungen. Wer Flows oder Agenten veröffentlichen darf, steuert ihr granular im Power Platform Admin Center und über Entra-ID-Gruppen.

Mit Agent Flows wird Governance in der Power Platform zur Sicherheitsfrage

In klassischen Power-Apps-Projekten wurde vieles davon noch als „Klickschutz“ belächelt. Mit Agent Flows in Copilot Studio ist daraus eine ernsthafte Sicherheitsfrage geworden. Jeder Agent mit Systemzugriff ist ein möglicher Angriffsvektor, und die alte Trennung zwischen Citizen Developer und Admin verschwimmt. Wer jetzt konsequent auf DLP, restriktive Connectoren, Endpunktfilter und durchdachte Authentifizierungsmodelle setzt, ist besser geschützt und erspart sich später teure Aufräumarbeiten. Ich rate euch deshalb, euch früh mit den Governance-Möglichkeiten der Power Platform vertraut zu machen und sie umzusetzen, bevor die ersten Agenten mit Schreibzugriff in Produktion gehen.