Power Automate Plugin für GitHub Copilot CLI und Claude Code

Executive Summary

Microsoft hat im Feature-Update für Juli und August 2026 etwas versteckt, das größer ist, als die zwei Zeilen im Blogpost vermuten lassen: Das Power-Automate-Plugin für GitHub Copilot CLI und Claude Code ist Generally Available. Nicht Preview, nicht Private Preview mit Anmeldeformular – GA. Du installierst es über den Power Platform Skills Marketplace und baust, bearbeitest, startest und debuggst Cloud Flows danach im Klartext aus dem Terminal.

Das ist ein kultureller Bruch. Power Automate war zehn Jahre lang das Werkzeug, mit dem die Fachabteilung an der IT vorbei automatisiert hat – klickbunt, im Browser, mit einem Designer, der bei jedem zweiten Release umgebaut wurde. Jetzt landet dasselbe Werkzeug in genau der Umgebung, in der Entwickler ohnehin den ganzen Tag sitzen. Der Citizen Developer bekommt Gesellschaft von jemandem, der Git kennt.

Die gute Nachricht: Technisch ist das sauber gebaut. Das Plugin bringt einen eigenen MCP-Server mit, der komplett lokal läuft – kein Remote-Host, kein npm install, kein Gateway. Voraussetzung sind Node.js 18 oder neuer und ein Azure-CLI-Login. Neun Skills decken den kompletten Lebenszyklus ab, von der Einrichtung über den autonomen Flow-Bau bis zur Fehleranalyse. Und Microsoft war so freundlich, vorher die Bremse einzubauen: Advanced Connector Policies sind seit Juni 2026 GA und arbeiten mit einer Default-Deny-Allowlist.

Die schlechte Nachricht: Diese Bremse ist standardmäßig aus. Und ein Agent, der sich per az login mit deinem Entra-Token anmeldet, hat exakt deine Berechtigungen – inklusive der Rollen, die dir vor drei Jahren jemand „nur für die Migration“ gegeben hat. Wenn du in deinem Mandanten heute noch keine Antwort auf die Frage hast, welche Connectors in welcher Umgebung erlaubt sind, dann ist der richtige Zeitpunkt für diese Antwort gestern gewesen.

Zeitstrahl: Erst die Governance-Werkzeuge, dann das Werkzeug, das sie nötig macht.

Worum geht es im Detail?

Fangen wir mit dem an, was du tatsächlich tippst. Der Skills Marketplace ist ein GitHub-Repository von Microsoft, das mehrere Power-Platform-Plugins bündelt – neben Power Automate auch Power Pages, Model Apps, Code Apps, Canvas Apps, Mobile Apps und MCP Apps. Du hängst das Repository als Marketplace in deinen Agenten ein und installierst daraus das Plugin. Danach einmal neu starten, damit die Skills als Slash-Commands auftauchen.

Das war es. Kein Installer, keine Registry-Keys, kein „bitte wenden Sie sich an Ihren Administrator“. Genau das ist der Punkt, an dem du als Verantwortlicher kurz zusammenzucken solltest: Die Hürde für die Einführung liegt bei ungefähr vierzig Sekunden. Deine Entwickler brauchen dich dafür nicht. Sie brauchen nur Node.js, das sie sowieso haben, und ein Azure-Login, das sie sowieso benutzen.

Unter der Haube arbeitet der FlowAgent-MCP-Server. MCP steht für Model Context Protocol – das ist der Standard, über den Sprachmodelle mit externen Werkzeugen reden. Microsoft liefert diesen Server nicht als Cloud-Dienst aus, sondern als selbstständiges ESM-Bundle direkt im Plugin-Verzeichnis. Ein Node-Bootstrap löst den Pfad auf und lädt das Bundle. Der Server stellt über 50 Tools bereit: Flows anlegen, bearbeiten, kopieren, publizieren, deaktivieren, löschen; Run-Historie lesen, Details abrufen, Läufe abbrechen und erneut einreichen; Connections verwalten inklusive Auto-Discovery; dazu Unterstützung bei Ausdrücken, Batch-Deployment und Desktop-Flows.

Dass das Ding offline läuft, ist keine Marketing-Fußnote, sondern der Grund, warum du es überhaupt in einem regulierten Umfeld diskutieren kannst. Es gibt keinen Microsoft-gehosteten Zwischenserver, der deine Flow-Definitionen sieht. Was rausgeht, geht über die normale Power-Platform-API – und, das solltest du im Hinterkopf behalten, an den Modellanbieter deines Agenten. Der Prompt und die Flow-Definition landen im Kontextfenster eines Sprachmodells. Wenn in dieser Definition ein SQL-Connection-String oder ein Kundenname steht, dann ist er dort.

Architektur: lokaler Agent, lokaler MCP-Server, deine Entra-Identität – und die Governance-Schicht als einziger echter Türsteher.

Die neun Skills im Überblick:

Der interessanteste Unterschied steckt zwischen create-flow und build-flow. Der eine führt dich durch den Prozess und fragt nach. Der andere baut autonom aus einer Beschreibung. Genauso bei debug-flow gegen diagnose-flow: interaktiv gegen selbstständig. Microsoft hat hier bewusst zwei Geschwindigkeiten eingebaut, und die Wahl zwischen ihnen ist keine Geschmacksfrage, sondern eine Governance-Entscheidung. In der Entwicklungsumgebung darf build-flow gerne durchmarschieren. In Produktion hättest du gern jemanden, der vorher liest, was da eigentlich gebaut wird.

Und das ist die eigentliche Stärke des Plugins: Es legt die generierte Flow-Definition offen. Du kannst reviewen und testen, bevor du aktivierst oder publizierst. Wer schon einmal im klassischen Designer versucht hat nachzuvollziehen, warum ein Apply-to-each auf einmal achtzehn Minuten braucht, weiß, was es wert ist, die Definition einfach als Text vor sich zu haben.

Nebenbei hat Microsoft im selben Update noch zwei Dinge nachgeschoben, die zum Thema gehören. Flow Groups sind GA: Du kannst die Kapazität einer Process-Lizenz – also 250.000 Aktionen pro Tag – auf bis zu 25 solution-aware Cloud Flows aufteilen. Das klingt nach Lizenzklein-Klein, ist aber genau der Hebel, den du brauchst, wenn Entwickler plötzlich Flows in Serie produzieren. Und für Desktop Flows gibt es KI-gestützte Reparatur von UI-Automatisierung in der Preview – für alle, deren RPA-Skripte jedes Mal sterben, wenn ein Dialogfeld zwei Pixel wandert.

Was sind Chancen? Was sind Risiken?

Reden wir zuerst über das Gute, damit die Stimmung nicht zu früh kippt.

Die größte Chance ist nicht der Bau von Flows, sondern deren Instandhaltung. Flows zu erstellen war noch nie das Problem – das kann jeder, der einen Browser bedienen kann. Das Problem beginnt am Tag 400, wenn niemand mehr weiß, warum dieser Flow existiert, der Ersteller das Unternehmen verlassen hat und die Connection auf ein Konto läuft, das seit dem letzten Offboarding-Lauf deaktiviert ist. Ein Agent, der die komplette Inventarliste, die Run History und die Flow-Definitionen im selben Kontext hat, ist genau für diese Archäologie gebaut.

Zweitens: Der Bruch zwischen Pro-Code und Low-Code wird kleiner. Bisher lief das so, dass die Entwickler ihre Pipelines in Git hatten und die Automatisierung irgendwo in einer Solution-ZIP-Datei, die einmal im Quartal jemand exportierte. Wenn beides aus derselben Kommandozeile bedienbar ist, hast du zumindest die Chance, dass beides auch in derselben Disziplin behandelt wird.

Drittens: Debugging-Zyklen. Das interaktive Debugging über die Run History spart im Alltag erschreckend viel Zeit – nicht weil der Agent klug wäre, sondern weil er unermüdlich ist. Er klickt sich nicht durch dreihundert Runs und wird dabei müde. Er liest sie einfach.

Und jetzt die Rechnung.

Dieselbe Technologie, zwei Ergebnisse. Der Unterschied sind drei Entscheidungen, keine drei Produkte.

Risiko 1: Die Identitätsfrage. Der Agent authentifiziert sich über Azure CLI, also mit dem Benutzerkonto des Entwicklers. Das ist sauber und nachvollziehbar – und genau deshalb gefährlich. Denn in den meisten Mandanten, die ich sehe, haben genau die Leute, die als erste ein solches Plugin installieren, historisch gewachsene Rechte. Der Agent erbt sie alle. Er fragt nicht nach, ob du diese Rolle noch brauchst.

Risiko 2: Auto-Approve. Microsoft warnt in der Dokumentation ausdrücklich davor, Auto-Approve-Einstellungen außerhalb vertrauenswürdiger Umgebungen zu nutzen, weil der Agent damit Zugriff auf dem Niveau deiner Maschinenrechte bekommt. Immerhin lässt sich granular festlegen, welche Tools automatisch freigegeben werden. Nach meiner Erfahrung landet diese Granularität etwa drei Tage nach der Installation bei „allen“, weil das Bestätigungsfenster nervt.

Risiko 3: Connector-Wildwuchs. Der Agent verwaltet Connections inklusive Auto-Discovery und legt bei Bedarf neue an. Auf deinen Namen. Ein Entwickler, der drei Tage lang experimentiert, hinterlässt problemlos zwanzig Verbindungen, die niemand je wieder anfasst und die trotzdem in deinem Mandanten gültige Tokens halten.

Risiko 4: Falsche Umgebung. Es gibt einen eigenen Skill fürs Environment-Routing. Dass Microsoft es für nötig hielt, dafür einen Skill zu bauen, sagt dir alles über die Wahrscheinlichkeit, in der falschen Umgebung zu landen. „Welche Umgebung war das nochmal?“ ist der teuerste Halbsatz der Power Platform.

Und die gute Nachricht bei alldem: Microsoft hat das Gegenmittel bereits ausgeliefert, bevor das Gift auf den Markt kam. Advanced Connector Policies sind seit dem 4. Juni 2026 allgemein verfügbar. Sie ersetzen das alte Modell aus Business, Non-Business und Blocked durch eine einzige Default-Deny-Allowlist: Alle zertifizierten Connectors und alle Aktionen sind gesperrt, bis sie ausdrücklich hinzugefügt werden. Das gilt beim Authoring genauso wie zur Laufzeit, lässt sich bis auf einzelne Aktionen herunterbrechen und deckt ausdrücklich auch MCP-Server ab. Für Custom Connectors bleiben die klassischen DLP-Richtlinien zuständig.

Was müssen wir jetzt schon vorbereiten?

Die ehrliche Antwort lautet: Das meiste davon hättest du ohnehin tun sollen. Das Plugin macht nur sichtbar, was du bisher aussitzen konntest. Hier ist die Reihenfolge, die sich in der Praxis bewährt hat.

Erstens: Inventur, bevor du irgendetwas abschaltest. Das Power-Platform-Inventory-Werkzeug zeigt dir, welche Connectors bei euch tatsächlich im Einsatz sind. Wer eine Default-Deny-Allowlist scharf schaltet, ohne vorher zu wissen, was läuft, legt am Montagmorgen die Reisekostenabrechnung lahm. Das ist beruflich überlebbar, aber unangenehm.

Zweitens: ACP zuerst in einer Testumgebung. Genau so empfiehlt es Microsoft auch. Allowlist aufbauen, Verhalten beobachten, dann auf Umgebungsgruppen ausrollen. Der Parallelbetrieb mit bestehenden DLP-Richtlinien ist während der Übergangsphase ausdrücklich unterstützt – nutze das, statt einen Stichtag zu erfinden.

Drittens: Eine dedizierte Entwicklungsumgebung für Agenten. Nicht die persönliche Standardumgebung, in der ohnehin schon alles liegt, was in den letzten fünf Jahren jemand ausprobiert hat. Eine Umgebung mit eigener Allowlist, eigener Datenbasis und der klaren Ansage, dass hier nichts Produktives entsteht.

Die Checkliste für die nächsten vier Wochen:

Rechte-Audit: Wer hat Systemadministrator in Produktion? Und warum noch?

Solution-aware als Pflicht: Flows außerhalb von Solutions sind nicht deploybar, nicht versionierbar und nicht in Flow Groups aufnehmbar. Das gilt für Agenten wie für Menschen.

Connection-Owner definieren: Produktive Verbindungen laufen auf ein Dienstkonto, nicht auf den Entwickler, der zufällig als erster „Verbinden“ geklickt hat.

Auto-Approve-Regel schriftlich: Erlaubt in Dev, gesperrt in Test und Prod. Ein Satz im Entwicklerhandbuch, nicht drei Seiten Richtlinie, die niemand liest.

Pipelines statt Handbetrieb: Power Platform Pipelines für den Weg von Dev nach Prod. Der Agent baut, die Pipeline transportiert.

Namenskonvention: Agenten-erzeugte Flows erkennbar kennzeichnen. In sechs Monaten willst du wissen, was ein Mensch entschieden hat und was ein Modell vorgeschlagen hat.

Kapazität im Blick: Flow Groups einrichten, bevor die Drosselung dich findet. 250.000 Aktionen pro Tag klingen nach viel, bis jemand einen Trigger auf eine Tabelle mit Massen-Updates legt.

Datenschutz klären: Welche Modellanbieter dürfen Flow-Definitionen sehen? Diese Frage beantwortest du besser vor dem ersten Prompt als nach dem ersten Audit.

Zum Schluss noch eine Einordnung, die über dieses eine Plugin hinausgeht. Microsoft baut hier gerade einen Marketplace für Agenten-Fähigkeiten auf, der sich über die gesamte Power Platform legt – Power Pages, Model Apps, Canvas Apps, Code Apps, Mobile Apps, MCP Apps. Power Automate ist nur der Teil, der dieses Mal fertig geworden ist. Wer jetzt Governance für Flows baut, baut sie beim nächsten Plugin nicht noch einmal. Wer jetzt nichts tut, macht dieselbe Diskussion in sechs Monaten noch einmal – dann aber mit sieben Werkzeugen gleichzeitig und einem Vorstand, der bereits eine Meinung hat.

Häufig gestellte Fragen

Brauche ich eine Lizenz, um das Plugin zu nutzen?

Für das Plugin selbst nicht – es ist ein kostenfreies Open-Source-Paket aus dem Power Platform Skills Marketplace. Lizenzpflichtig ist wie immer das, was dahinter passiert: die Power-Automate-Umgebung, die genutzten Premium-Connectors und gegebenenfalls Process- oder Managed-Environments-Lizenzen.

Läuft der MCP-Server in der Cloud oder auf meinem Rechner?

Der FlowAgent-MCP-Server ist als eigenständiges Bundle im Plugin enthalten und läuft vollständig lokal, ohne npm install und ohne Remote-Host. Nach außen geht nur die Kommunikation mit der Power-Platform-API – und alles, was dein Sprachmodell-Anbieter im Rahmen der normalen Agentennutzung ohnehin zu sehen bekommt.

Kann ich verhindern, dass Entwickler das Plugin einfach installieren?

Die Installation selbst kannst du nur über Endpoint-Management einschränken, denn sie passiert lokal im Agenten. Wirksamer ist die andere Seite: Mit Advanced Connector Policies und DLP-Richtlinien legst du fest, was in welcher Umgebung überhaupt gebaut und ausgeführt werden darf – unabhängig davon, welches Werkzeug den Aufruf macht.

Ersetzen Advanced Connector Policies meine bestehenden DLP-Richtlinien?

Nur teilweise. Advanced Connector Policies gelten für zertifizierte Connectors und MCP-Server; für Custom Connectors bleiben die klassischen DLP-Richtlinien zuständig. Beides lässt sich parallel betreiben, und es gibt optional einen reinen ACP-Modus ohne DLP-Auswertung.

Kann der Agent einen produktiven Flow versehentlich löschen?

Technisch ja, denn die Lifecycle-Operationen umfassen Löschen und Deaktivieren, und der Agent handelt mit den Rechten des angemeldeten Benutzers. Genau deshalb gehört in Produktivumgebungen weder Auto-Approve noch ein Konto mit Schreibrechten in die Hände eines Agenten.