Copilot Managed Runtime: Governance für Vibe-Coded Apps

Seit dem 25. September kann in deinem Tenant jeder Apps bauen, der Copilot Studio öffnen darf. Ohne Ticket, ohne Freigabe, ohne eine Zeile Code. Der Schalter dafür steht ab Werk auf An.

Was das in der Praxis heißt, habe ich letzte Woche bei einem Kunden im Ruhrgebiet erlebt. Wöchentlicher IT-Jour-Fixe, der Controlling-Leiter erwähnt ganz nebenbei, dass er sich „da so ein kleines Tool” gebaut hat. Eine App, die seinem Team jeden Montag die aktuellen Umsatzzahlen direkt aus dem Controlling-System aufbereitet. Gebaut in Copilot Studio, nur per Prompt. Selbst geschrieben hat er keine einzige Zeile Code.

Die IT-Leiterin neben mir wurde kurz blass. Sie wusste von nichts. Da lief eine App mit Zugriff auf Finanzdaten, geteilt mit seinem Team, und niemand in der IT hatte sie je gesehen.

Jetzt die gute Nachricht, und die meine ich ernst: Die App lag nicht auf irgendeinem privaten Rechner. Sie lief in der Copilot Managed Runtime, also im eigenen Tenant, und stand die ganze Zeit im M365 Admin Center. Die schlechte Nachricht: Da hatte noch keiner reingeschaut.

Und wie kam die App überhaupt ans Controlling-System, wenn ab Werk nur Microsoft-Konnektoren erlaubt sind? Weil im Tenant noch alte Power-Platform-Umgebungen ohne Connector Policy hingen. Ohne Policy ist eben auch nichts verboten.

Genau darum geht es hier. Die Runtime holt Vibe-Coded Apps aus dem Schatten. Steuern musst du sie trotzdem selbst.

Was die Managed Runtime tatsächlich ändert

Vibe Coding heißt: Du beschreibst in natürlicher Sprache, was die App tun soll, und die KI schreibt den Code. Bisher ging es danach meistens so weiter: Der Business-User exportiert den Code und hostet ihn irgendwo, mal im Azure App Service, mal auf einem privaten Rechner. Ab dann war die IT blind. Niemand wusste, welche Datenquellen angebunden sind, keine DLP-Regel hat gegriffen und Compliance-Doku gab es auch keine. Aus DSGVO-Sicht ein Albtraum, weil der ganze Datenfluss unter dem Radar läuft.

Mit der Copilot Managed Runtime bleiben Code und Ausführung im Tenant. Sie besteht aus zwei Teilen:

• Host: stellt die Laufzeitumgebung innerhalb der M365-Tenant-Grenze.
• SDK und CLI: die npm-Pakete @microsoft/managed-apps und @microsoft/managed-apps-cli mit dem Befehl ms, für alle, die code-first arbeiten.

Zur Runtime führen mehrere Wege: Copilot Studio (standardmäßig an, der Weg unseres Controllers), Copilot Cowork als chatbasierter App-Builder (aktuell nur im Frontier-Programm), Copilot Code und die CLI (standardmäßig aus). Inzwischen öffnet Microsoft die Runtime per SDK auch für externe Builder-Tools, Lovable ist der erste genannte Partner. Gebaut wird also überall, ausgeführt an einem Ort.

Endnutzer finden die fertigen Apps in einem eigenen Web-Portal. Du verwaltest alles im M365 Admin Center unter Apps, inklusive Inventar, Nutzungszahlen und Health-Monitoring mit Alerts. Jede App authentifiziert über Entra ID. Conditional Access, DLP, Advanced Connector Policies und Sharing-Limits greifen automatisch. Ab Werk dürfen Apps nur 18 Microsoft-eigene Konnektoren nutzen, die ausschließlich über Entra ID authentifizieren. Selbst dort blockiert Microsoft die Hintertüren: Offene „Send an HTTP request”-Aktionen oder „Run script” sind standardmäßig gesperrt.

Microsoft hat den Launch-Post „Build where you want, run with confidence” genannt. Das ist ausnahmsweise mehr als ein Slogan. Die Runtime schließt eine echte strukturelle Lücke, die Schatten-KI in den letzten zwei Jahren aufgerissen hat.

Wo der Kaffee bitter wird

Jetzt der ehrliche Teil, den meine Kunden auch so von mir hören.

Erstens: Preview ist Preview. Die Doku trägt den Stempel „prerelease, subject to change”, es gelten die ergänzenden Nutzungsbedingungen für Previews. Eine SLA-Zusage für den Produktivbetrieb gibt es nicht. Wichtige Bausteine wie serverseitige Logik und die eingebaute Datenbank fehlen in der Public Preview noch komplett. Ein Verbot für den Produktivbetrieb ist das nicht. Eine Einladung aber auch nicht.

Zweitens: Sichtbarkeit ist noch keine Governance. Für mich der wichtigste Punkt. Im Admin Center siehst du unter „Data & tools”, welche Konnektoren, Datenquellen und Abhängigkeiten eine App nutzt. Exakte Zielendpunkte, dynamisch aufgelöste Adressen, tatsächlich ausgeführte Aktionen oder die Berechtigungen pro User siehst du dort nicht, das schreibt Microsoft selbst so in die FAQ. Noch ein Haken: Das Admin Center zeigt dir die Allow-Liste der Advanced Connector Policy, aber nicht zwingend die Einschränkungen aus klassischen DLP-Policies. Und wenn du einem User den App-Zugriff entziehst, behält er trotzdem seine Rechte auf die Daten dahinter.

Drittens: Der Owner geht, die App bleibt. Jede App entsteht in der persönlichen Entwicklerumgebung ihres Erstellers. Was passiert, wenn der Controller das Unternehmen verlässt? Wer wird neuer Owner, wer wartet die App? Für diesen ganz alltäglichen Fall habe ich in der öffentlichen Doku keinen Prozess zur Owner-Übertragung gefunden. Blockieren und löschen kannst du als Admin, mehr nicht. Diese Lücke musst du selbst schließen.

Viertens: Die Rechnung kommt pro Nutzer. Bauen in Copilot Studio kostet Copilot Credits, und zwar ab dem ersten Prompt, nicht erst nach dem Veröffentlichen. Ausführen kostet ebenfalls Credits, abgerechnet pro Nutzer, außer jemand hat eine Power Apps Premium Lizenz. In der Preview bekommen Nutzer ohne Credit-Abdeckung erst eine Warnung, nach 20 App-Aktionen oder fünf Minuten ist Schluss. Wenn das Controlling-Team am Montagmorgen die App öffnet und nach fünf Minuten nichts mehr geht, landet das Ticket bei dir. Nicht beim Controller.

Was du jetzt konkret tun musst

Die Managed Runtime gibt dir den Ort. Was du daraus machst, ist deine Aufgabe. Sieben Schritte, mit denen du die Runtime vom ersten Tag an im Griff hast.

Was bleibt

Experimentierst du schon mit der Managed Runtime oder hast du ähnliche Schatten-KI-Fälle in deinem Tenant gefunden? Schreib mir auf LinkedIn. Mich interessiert, welche Governance-Lücken ihr in der Praxis zuerst entdeckt habt.

#EspressoM365Fusion