Seit Microsoft gestern autonome Agenten in Copilot Studio angekündigt hat, wird in vielen Admin- und Governance-Runden kaum über etwas anderes gesprochen. Verlockend ist die Idee durchaus. Eine einmal eingerichtete Automatisierung arbeitet völlig selbstständig, ohne dass jemand einen Prompt eingibt. Den Anstoß gibt etwa eine eingehende E-Mail, ein neuer Datensatz in einer Datenbank oder ein anderes externes Ereignis. In den Tenants, die ich betreue, kam allerdings schnell die Frage auf, wie sich solche Agenten sauber in die vorhandenen Daten- und Sicherheitsmodelle einfügen.

Autonome Agenten starten ohne menschlichen Auslöser

Bei klassischen Copilot- oder Flow-Szenarien stößt ein Mensch den Ablauf an. Autonome Agenten dagegen starten von selbst, sobald ein Trigger greift. Für Unternehmen steckt darin viel Potenzial, zugleich steigen die Ansprüche an Governance und Transparenz. Besonders gespannt bin ich auf die zehn vorgefertigten Agenten für Dynamics 365, die Microsoft angekündigt hat. Dort hängen Datenflüsse und Automatisierungen ohnehin eng mit Prozessen und Berechtigungen zusammen. Noch läuft das alles als Public Preview, manche Teile sind sogar erst für die Ignite im November angekündigt. Trotzdem berührt schon das Konzept mehrere Governance-Themen, die mich im Power-Platform-Umfeld seit Jahren begleiten.

Die Identität des Agenten entscheidet über Rechte und Nachvollziehbarkeit

Das größte Governance-Risiko sehe ich in der Frage, unter welcher Identität ein autonomer Agent eigentlich arbeitet. Schon bei gewöhnlichen Power-Automate-Flows lässt sich nicht immer eindeutig sagen, ob eine Aktion im Namen des Makers läuft, also der Person, die den Agenten gebaut hat, oder im Kontext des aufrufenden Nutzers. Bei autonomen Agenten in Copilot Studio wiegt das noch schwerer, denn hier gibt es gar keine direkte Eingabe eines Nutzers. Laut Microsoft sollen sowohl die „Maker-Identität“ als auch eine „User-Delegation“ möglich sein. Vollständig dokumentiert sind die Details derzeit aber noch nicht. Gerade bei heiklen Aktionen wie dem Schreiben von Daten oder dem Anstoßen von Zahlungen muss das Identitätsmodell sauber zwischen Rollen, Kontexten und technischen Service-Accounts unterscheiden.

flowchart TD
    Trigger["Ereignis-Trigger"] --> Agent["Autonomer Agent"]
    Agent --> Identity["Aktionen unter Identität"]
    Identity --> Maker["Maker-Account"]
    Identity --> User["User-Delegation (sofern unterstützt)"]
    Agent --> Connectors["Zugriff auf Konnektoren"]

Abbildung: So hängen Identität und Ausführung bei autonomen Agenten in Copilot Studio zusammen.

Für Governance und Security ist das vor allem im Hinblick auf Service-Accounts und privilegierte Zugänge wichtig. Wie im Diagramm zu sehen, kann der Agent entweder unter der Identität seines Erstellers oder delegiert im Kontext eines Benutzers handeln. Davon hängt unmittelbar ab, wie gut sich seine Aktionen auditieren lassen und wie die Rechte vergeben werden müssen.

DLP-Richtlinien regeln den Zugriff auf Konnektoren und Daten

Wenig überraschend steht für mich bei autonomen Agenten die Kontrolle über Konnektoren und Aktionen ganz oben. Die Power Platform bringt dafür mit den Data-Loss-Prevention-Richtlinien (DLP) ein solides Werkzeug mit, auch wenn die Einrichtung nicht immer trivial ist. Damit legt man fest, welche Konnektoren (z. B. Outlook, SQL, Salesforce) sich miteinander kombinieren lassen und welche Aktionen gesperrt sind. Gerade wenn Prozesse ohne menschliches Zutun ablaufen, möchte niemand erleben, dass sensible Daten auf einmal bei Drittanbietern landen. Konfiguriert werden die DLP-Richtlinien zentral im Power Platform Admin Center. Spätestens seit es Managed Environments gibt, sind Monitoring und Durchsetzung der Richtlinien deutlich besser als noch vor zwei Jahren. Wer tiefer einsteigen möchte, findet Details in der Microsoft-Dokumentation zu DLP für Copilot Studio oder in meinem Beitrag zu Governance und DLP in Copilot Studio.

Mein Tipp aus der Praxis: Übernehmt die DLP-Policies eurer klassischen Flows nicht einfach für autonome Agenten. Schaut euch vorher an, welche Trigger und Abläufe typischerweise vorkommen. Häufig müssen die Einschränkungen deutlich strenger ausfallen.

Ein eigenes Environment erleichtert Überwachung und Audit

Wie wichtig die Wahl des passenden Power-Platform-Environments ist, wird nach meiner Erfahrung oft unterschätzt. Mit Managed Environments lassen sich die Mindestanforderungen inzwischen gut abdecken. Dazu gehören eine zentrale Überwachung, die Protokollierung von Deployment-Events und vor allem eine klare Trennung zwischen produktiven und experimentellen Automatisierungen. Für autonome Agenten kann das bedeuten, ein eigenes Environment mit gezielt vergebenen Zugriffsrechten und klar geregelten Freigaben aufzusetzen. Änderungen an Agenten lassen sich über das Audit-Log nachvollziehen. Wer dagegen jede Ausführung lückenlos überwachen will, muss derzeit noch viel von Hand erledigen. Ich hoffe, dass Microsoft hier bald nachbessert und mehr Telemetrie und Alerting für autonome Agenten einbaut.

Menschliche Freigaben und Kosten brauchen mehr Aufmerksamkeit

Ganz offen gesagt sehe ich noch viel Luft nach oben, wenn es darum geht, Human-in-the-Loop-Elemente einzubinden. Gemeint ist, dass ein Agent zwar eigenständig arbeitet, bei bestimmten Aktionen aber wartet, bis ein Mensch zustimmt. Bei riskanten Prozessen halte ich das für unverzichtbar. Technisch gibt es dafür erste Ansätze mit adaptiven Karten oder Genehmigungsworkflows. Zwischen dem automatischen Agentenlauf und dem Eingreifen eines Menschen hakt es aber oft noch spürbar.

Dazu kommt, dass jeder Agent Nachrichten erzeugt und damit Kosten verursacht. Wie bei anderen Power-Platform-Diensten richtet sich die Abrechnung in Copilot Studio nach der Zahl der Transaktionen bzw. Nachrichten. Wer viele autonome Agenten im Tenant laufen lässt, sollte die Nachrichtenkontingente deshalb genau im Auge behalten. Zwar sind die neuen Agenten noch im Preview-Status, grundlegend ändern dürfte sich am Preismodell aus meiner Sicht aber nichts.

Einen Tag nach der Ankündigung halte ich den Schritt für logisch

Autonome Agenten in Copilot Studio sind für mich eine folgerichtige und spannende Weiterentwicklung. Governance und Security gehören allerdings von Beginn an dazu. Fehlen klare Identitätsmodelle, restriktive DLP-Policies und eine lückenlose Überwachung, können diese Agenten schnell neue Schatten-IT hervorbringen. Wer jetzt schon einen Pilot starten will, sollte vom ersten Tag an ein eigenes Environment nutzen, strenge DLP-Regeln setzen und produktive Szenarien konsequent von Experimenten trennen. Ich bin neugierig, welche Best Practices sich herausbilden, sobald die Public Preview zur Ignite startet, und werde das Thema hier weiterverfolgen.