Identität und Governance

Identität und Governance

0:00 Heute wechseln wir die Perspektive. Bisher haben wir gebaut — jetzt schauen wir mit den Augen derer auf den Agenten, die ihn freigeben müssen. Und die stellen andere Fragen: Wer ist dieser Agent eigentlich? Mit welchen Rechten handelt er? Was passiert mit den Daten? Und wer ist verantwortlich, wenn etwas schiefgeht? Die gute Nachricht: Copilot Studio bringt für all das Werkzeuge mit, mehr als die meisten erwarten. Die weniger gute: Fast nichts davon ist voreingestellt. Man muss es tun.

Identität und Governance

0:31 Vier Themen liegen vor uns. Zuerst die Authentifizierung — drei Optionen, von denen eine alles öffnet. Dann Umgebungen, Rollen und Datenrichtlinien, also der Rahmen, den Ihre Administration setzt. Im dritten Kapitel geht es um Risiken und darum, dass der Agent inzwischen selbst auf sie hinweist. Und zum Schluss um den Teil, der keine Technik ist und trotzdem über den Erfolg entscheidet: Freigaben und Verantwortlichkeiten.

Authentifizierung und Berechtigungen

0:58 Beginnen wir bei der Identität. Drei Optionen stehen zur Wahl, und die Unterschiede sind größer, als die Namen vermuten lassen. Keine Authentifizierung, Anmeldung mit Microsoft, manuelle Authentifizierung. Diese Wahl entscheidet über drei Dinge auf einmal: wer mit dem Agenten sprechen darf, welche Kanäle möglich sind und welche Variablen im Gespräch zur Verfügung stehen.

1:20 Das ist ungewöhnlich weitreichend für eine einzelne Einstellung — und genau deshalb gehört sie an den Anfang eines Projekts und nicht ans Ende. Wer sie spät trifft, hat unter Umständen für eine Bühne gebaut, die ihm die Einstellung wieder wegnimmt. Die zweite Spalte ist die interessante: Wer darf sprechen? Bei fehlender Authentifizierung kann das jeder, der den Link hat — und Sie können es nicht einschränken.

1:44 Bei der Anmeldung mit Microsoft und bei Entra ID steuern Sie es über die Agentenfreigabe. Und dann die vierte Zeile, die überrascht: Bei generischem OAuth2 darf jeder angemeldete Nutzer mitreden, die Freigabe steuert dort nichts mehr. Die Fußzeile ist die praktisch wichtigste Zeile der ganzen Folie — Teams und Microsoft 365 vertragen nur die Anmeldung mit Microsoft. Jede andere Option blockiert diese Kanäle.

2:09 Diese Eigenheit kostet Nerven, wenn man sie nicht kennt. Sie ändern die Authentifizierung, speichern — und nichts passiert. Erst mit der nächsten Veröffentlichung greift die Änderung. Beim Wechsel kommt eine zweite Unannehmlichkeit dazu: Variablen in Topics können zu unbekannten Werten werden, und die müssen Sie vor dem Veröffentlichen reparieren.

2:29 Der dritte Punkt schließt an gestern an — wer die Authentifizierung abschaltet, legt Werkzeuge mit Nutzerrechten lahm. Und der vierte ist eine Nebenwirkung, an die niemand denkt: Ohne Anmeldung gibt es keine Kennzahlen zu aktiven Nutzenden. Der erste Punkt ist der gefährlichste im ganzen Seminar: Die fehlende Authentifizierung bleibt aus der Bauphase stehen — und geht so in den Kanal.

2:51 Der zweite ist die Kombination, die nicht funktioniert: für Teams gebaut, manuell authentifiziert, Kanal blockiert. Der dritte ist der Test mit dem falschen Konto, den wir schon kennen. Und der vierte ist der Klassiker der Veröffentlichung: gespeichert, aber nicht veröffentlicht — und dann versteht niemand, warum sich das Verhalten nicht ändert.

Umgebungen, Rollen und Datenrichtlinien

3:11 Jetzt zum Rahmen, den Ihre Administration setzt. Und zu einer Erkenntnis, die man früh braucht: Vieles, was im Agenten unmöglich scheint, ist gar keine Eigenschaft des Agenten. Die Grenze ist die Umgebung, nicht der Agent. Das ist der Satz, den man aus diesem Kapitel mitnehmen sollte. Eine Power-Platform-Umgebung bestimmt Sicherheitsrollen, Datenrichtlinien und die Trennung von Entwicklung, Test und Produktion. Sie ist damit gleichzeitig Heimat und Zaun.

3:39 Und Datenrichtlinien im Power Platform Admin Center steuern, welche Fähigkeiten ein Agent überhaupt nutzen darf — unabhängig davon, was sich der Maker wünscht. Das ist kein Misstrauen, sondern eine gesunde Arbeitsteilung. Die vier Schichten zeigen die Reichweite, und die ist beachtlich. Ganz oben die Authentifizierung — welche Optionen Maker und Nutzende überhaupt verwenden dürfen.

4:03 Darunter Wissen und Werkzeuge, also Quellen, Aktionen, Konnektoren und HTTP-Anfragen. Dann die Veröffentlichung: In welche Kanäle darf ein Agent gestellt werden? Und unten die Auslöser und die Telemetrie. Wenn Sie diese vier Ebenen kennen, verstehen Sie auch, warum manches im Test geht und in der Produktion nicht. Es ist selten ein Fehler — meist ist es eine Richtlinie.

4:26 Der Nutzen ist ganz handfest: Ein Versuch in der Entwicklungsumgebung berührt keinen produktiven Agenten. Das klingt selbstverständlich, ist es aber nicht — in vielen Organisationen bauen alle im Standardbereich, weil dort niemand etwas beantragen muss. Zwei konkrete Empfehlungen stehen dahinter: Produktion wird als Produktionsumgebung angelegt, alles andere als Sandbox.

4:49 Und eine Entra-Sicherheitsgruppe je Umgebung begrenzt, wer überhaupt hineinkommt. Das Umgebungsrouting gibt neuen Makern dabei automatisch einen abgegrenzten Ort. Der erste Punkt ist genau die eben beschriebene Bequemlichkeit — alle in der Standardumgebung. Der zweite ist eine Frage der Reihenfolge: Die Datenrichtlinie entsteht erst, wenn schon Agents produktiv sind, und dann ist jede Einschränkung ein Eingriff statt einer Vorgabe.

5:14 Der dritte sorgt für die berühmten „bei mir geht es"-Momente: Test und Produktion unterscheiden sich in den Konnektoren, und niemand weiß das. Und der vierte ist die Rollenvergabe, die einmal gemacht und nie überprüft wird.

Risiken erkennen

5:27 Jetzt zu den Risiken. Erfreulich ist: Sie müssen sie nicht alle selbst finden — das Produkt hilft inzwischen mit. Unerfreulich ist, dass die Hinweise nur etwas nützen, wenn jemand sie liest. Copilot Studio prüft einen Agenten inzwischen laufend. Schon beim Konfigurieren von Wissen, Werkzeugen und Aktionen bekommen Maker Befunde angezeigt, und vor dem Veröffentlichen erscheint eine Sicherheitswarnung, wenn sichere Voreinstellungen geändert wurden.

5:54 Dazu kommt ein Schutzstatus, den man auf der Agentenseite sieht. Das ist eine bemerkenswerte Entwicklung: Governance wandert aus dem Handbuch in das Werkzeug selbst. Nur ersetzt sie damit nicht das Nachdenken — sie erinnert nur zuverlässiger daran. Bemerkenswert an dieser Aufstellung ist, dass alle vier Gegenmaßnahmen aus den letzten Tagen stammen.

6:15 Das zu weit reichende Werkzeug begrenzen Sie mit Nutzerrechten, engem Aufgabenbereich und Bestätigung — alles Themen von gestern. Datenoffenlegung begrenzen Sie über den Zuschnitt der Wissensquellen, also Dienstag. Und der Agent ohne Anmeldung ist das Thema von vorhin. Governance ist also weniger ein eigenes Kapitel als die Summe sauberer Entscheidungen.

6:35 Die Fußzeile ergänzt eine nützliche Sichtbarkeit: Die höchste Vertraulichkeitsstufe der genutzten Quellen erscheint in der Antwort. Dieser Punkt ist neu für viele und lohnt Aufmerksamkeit. Ein Dokument in einer Wissensquelle kann Anweisungen an das Modell enthalten — Text, der nicht für Menschen geschrieben ist, sondern für den Agenten.

6:55 Je weiter Sie anbinden, desto weniger ist jede einzelne Datei verantwortet. Dasselbe gilt für Oberflächen: Computer Use kann eine solche Aufforderung auf einer Webseite vorfinden. Deshalb gibt es dort eine menschliche Aufsicht per Mail. Die eigentliche Gegenmaßnahme ist aber schlichter — binden Sie nur an, was jemand verantwortet.

7:15 Der erste Punkt ist menschlich und ärgerlich: Die Sicherheitswarnung vor dem Veröffentlichen wird weggeklickt, weil sie zwischen einem und dem nächsten Termin steht. Der zweite ist die unverantwortete Wissensquelle. Der dritte klingt technisch, ist aber organisatorisch: Ein Werkzeug darf mehr, als der Fall braucht, weil die zugrunde liegende Rolle so zugeschnitten ist — dann hilft keine Einstellung im Agenten.

7:39 Und der vierte ist der Dauerbrenner: einmal bewertet, nie wieder geprüft. Risiken ändern sich aber mit jeder Änderung.

Freigaben und Verantwortlichkeiten

7:46 Zum Schluss der Teil ohne Technik — und mit der größten Wirkung. Hier gibt es nichts einzustellen und nichts zu klicken. Es geht schlicht darum, Namen zu benennen, bevor sie gebraucht werden. Drei Fragen machen aus einem gebauten Agenten einen betriebsfähigen: Wer verantwortet ihn fachlich? Wer darf ihn ändern? Und wie werden Änderungen freigegeben?

8:08 Nachvollziehbar wird das über Audit-Protokolle in Microsoft Purview und Microsoft Sentinel sowie über Solutions und Quellcodeverwaltung. Die Technik liefert also die Spur. Die Zuständigkeit liefert sie nicht — die müssen Sie benennen. Und zwar bevor der erste Vorfall eintritt, nicht danach. Fünf Festlegungen, und die letzte ist die wichtigste: Wer schaltet den Agenten ab, wenn etwas schiefgeht?

8:32 Diese Frage klingt dramatisch, ist aber eine ganz normale Betriebsfrage — wie bei jeder anderen Anwendung auch. Davor stehen die Verantwortlichen je Quelle und Werkzeug, die Änderungsrechte, der Freigabeweg und die Beobachtung. Und beachten Sie die Fußzeile, die uns morgen wiederbegegnet: Freigaben und geteilte Zugriffe sind nicht solutionfähig. Sie müssen in jeder Umgebung erneut gesetzt werden.

8:56 Ein Protokoll zeigt, was geschehen ist. Es zeigt nicht, wer es hätte genehmigen müssen — das ist der Unterschied zwischen Nachvollziehbarkeit und Verantwortung. Dazu eine Feinheit, die man kennen sollte: Audit-Telemetrie fällt nicht unter Customer Lockbox, sie läuft über Purview. Wer mit strengen Vorgaben arbeitet, sollte das mit der eigenen Sicherheitsabteilung besprechen.

9:19 Und der letzte Punkt ist der organisatorische Kern: Wer abschalten darf, muss vorher feststehen. Im Vorfall ist keine Zeit, das zu klären. Der erste Punkt ist in Pilotprojekten fast immer der Fall: Der Maker ist faktisch auch der Fachverantwortliche — nur weiß er es nicht, und niemand hat es entschieden. Der zweite ist das Nebenbei-Ändern, weil die Änderung klein wirkt.

9:40 Der dritte ist der Fehler, vor dem die Fußzeile eben gewarnt hat: Freigaben in der Entwicklung gesetzt, in der Produktion vergessen. Und der vierte ist der leiseste: Niemand beobachtet den Agenten im Betrieb, also merkt auch niemand, wenn er schlechter wird.

Übung

9:55 Jetzt bringen Sie all das in eine Form, die man einer Sicherheitsabteilung vorlegen kann. Eine Seite, auf der zu jedem Zugriff steht, warum es ihn gibt und wer dafür geradesteht. Der Lernlotse ist inzwischen ein vollständiger kleiner Agent: eine SharePoint-Wissensquelle, ein lesendes und ein schreibendes Werkzeug auf Kursbuch, dazu die Übergabe an die Personalentwicklung.

10:17 Er soll in Teams laufen und allen 1.800 Beschäftigten offenstehen. Damit ist er kein Experiment mehr, sondern eine Anwendung mit Zugriff auf interne Daten — und genau so wird ihn jede Freigabestelle behandeln. Das Lernziel steht im Nebensatz: aus dem Aufgabenbereich ableiten, nicht aus der Bequemlichkeit im Test. Denn genau das ist der Unterschied zwischen einer Matrix, die trägt, und einer, die den Ist-Zustand dokumentiert.

10:43 Fünf Angaben je Eintrag: benötigte Berechtigung, gewählte Zugangsdaten, erkanntes Risiko, Gegenmaßnahme, verantwortliche Rolle. Wer früh fertig ist, beschreibt zusätzlich, wer den Agenten abschaltet — und woran diese Person den Anlass überhaupt erkennt. Die zweite Hälfte dieser Frage ist die schwierigere. Achten Sie auf die Formulierung in Schritt zwei: die benötigte Berechtigung, nicht die vorhandene. Das ist der ganze Unterschied.

11:10 In Schritt drei kommt die Entscheidung über Nutzer- oder Makerrechte samt Begründung — Sie wissen seit gestern, warum das nicht nebenbei passieren sollte. Schritt vier ergänzt Risiko und Gegenmaßnahme. Und Schritt fünf ordnet jedem Eintrag genau eine verantwortliche Rolle zu. Genau eine. Zwei Rollen bedeuten im Zweifel keine.

11:30 Der erste Punkt ist erstaunlich wirksam: Wer Abteilungen statt Rollen nennt, erreicht niemanden — eine Abteilung fühlt sich nicht gemeint. Der zweite ist die Übernahme der Testeinstellungen. Der dritte macht die Matrix wertlos: allgemein beschriebene Risiken, die man deshalb nicht behandeln kann. Und der vierte wird fast immer übersehen — die Übergabe an Menschen fehlt in der Matrix, obwohl auch dort Daten weitergegeben werden.

11:54 Im nächsten Modul messen wir dann, wie gut der Agent wirklich ist.