Copilot Studio authentifizieren und in Teams oder Websites veröffentlichen

Copilot Studio Authentifizierung vor dem Kanal festlegen

Copilot Studio Authentifizierung bestimmt, wer einen Agenten nutzen kann und in wessen Kontext Daten oder Tools aufgerufen werden. Diese Entscheidung sollte vor der Veröffentlichung in Teams oder einer Website fallen. Ein Agent, der im Testfenster funktioniert, kann im Zielkanal andere Identitäts- und Sitzungsbedingungen haben.

Zuerst werden Zielgruppe, Datenquellen und erlaubte Aktionen beschrieben. Interne Beschäftigte, Gäste, Partner und anonyme Websitebesucher benötigen unterschiedliche Vertrauensmodelle. Ein einziger Agent sollte diese Gruppen nur bedienen, wenn Daten- und Funktionsgrenzen technisch eindeutig bleiben.

Ersteller-, Agenten- und Benutzeridentität unterscheiden

Der Ersteller bearbeitet den Agenten in einer Power-Platform-Umgebung. Der Agent besitzt für Kanäle und Dienste eine eigene technische Identität. Der Endbenutzer meldet sich im veröffentlichten Erlebnis an. Diese drei Identitäten dürfen in Architektur und Support nicht miteinander verwechselt werden.

Verbindungen können zusätzlich einen eigenen Besitzer haben. Ein erfolgreicher Zugriff im Autorenkonto kann auf dessen weitreichender Verbindung beruhen. Produktionstests verwenden deshalb normale Benutzerkonten und prüfen den tatsächlich verwendeten Identitätsfluss.

Microsoft-Authentifizierung für interne Agents

Für interne Nutzung in Teams, Power Apps oder Microsoft 365 Copilot ist Microsoft-Authentifizierung typischerweise der passende Ausgangspunkt. Benutzer werden über Entra ID erkannt. Der Agent kann Datenquellen und Tools im Benutzerkontext oder über definierte technische Verbindungen verwenden.

Die Anmeldung allein garantiert keine korrekte Autorisierung. Jede Quelle und Aktion benötigt eine eigene Berechtigungsprüfung. Der Agent zeigt keine sensible Information nur deshalb an, weil der Benutzer im Tenant existiert.

Entra Agent Identity einordnen

Neuere Copilot-Studio-Agents können Entra Agent Identities verwenden. Dabei erhält der Agent eine als Agent erkennbare Dienstidentität, die Verwaltung und Sichtbarkeit gegenüber klassischen App-Registrierungen verbessert. Ältere Agents können weiterhin auf vorhandenen App-Registrierungen beruhen.

Die Identität wird wie ein technisches Sicherheitsobjekt behandelt. Berechtigungen, Eigentümer und Lebenszyklus werden dokumentiert. Unbenutzte oder ersetzte Identitäten werden kontrolliert entfernt, nachdem Abhängigkeiten geprüft wurden.

Benutzerkontext gegen technische Verbindung abwägen

Beim Zugriff im Benutzerkontext gelten die Rechte des angemeldeten Benutzers. Das eignet sich für persönliche oder berechtigungsgetrimmte Daten. Eine technische Verbindung ermöglicht zentrale Prozesse, darf aber nicht pauschal Ergebnisse an unberechtigte Benutzer ausgeben.

Für jede Aktion wird entschieden, welches Modell fachlich korrekt ist. Ein Ticket im Namen des Benutzers kann dessen Identität benötigen, während eine zentrale Benachrichtigung über ein Servicekonto laufen kann. Auditdaten müssen später zeigen, wer die Aktion ausgelöst und welche Identität sie ausgeführt hat.

App-Berechtigungen begrenzen

Agents und Tools können App-Berechtigungen oder delegierte Berechtigungen benötigen. Der Umfang folgt dem Least-Privilege-Prinzip. Breite Leserechte auf alle Sites werden nicht gewählt, wenn ein engerer Zugriff oder eine API mit fachlicher Autorisierung möglich ist.

Admin Consent wird dokumentiert und regelmäßig geprüft. Der bestehende Beitrag App-Berechtigungen und Admin Consent prüfen beschreibt Rollen, Inventar und Review. Geheimnisse und Zertifikate erhalten zusätzlich ein Ablaufmonitoring.

Teams als internen Kanal bereitstellen

Teams bietet einen vertrauten Zugriffspunkt für interne Agents. Vor der Bereitstellung werden App-Richtlinien, Zielgruppen, Installation und Verfügbarkeit geprüft. Der Agent wird zunächst einer Pilotgruppe bereitgestellt und nicht automatisch tenantweit sichtbar gemacht.

Tests umfassen persönliche Chats, gegebenenfalls Teamkontexte und verschiedene Gerätetypen. Links, adaptive Karten und Authentifizierungsdialoge können sich zwischen Desktop, Web und Mobilgerät unterscheiden. Supportunterlagen benennen den erwarteten Einstiegspunkt.

Microsoft 365 Copilot als Kanal verwenden

Ein Copilot-Studio-Agent kann Microsoft 365 Copilot erweitern und dort Wissen oder Tools bereitstellen. Freigabe, Lizenzierung und enthaltene Nutzung hängen vom konkreten Agenten- und Benutzerszenario ab. Administratoren steuern, welche Agents verfügbar sind.

Der Agent erhält einen eindeutigen Namen und eine Beschreibung, damit Benutzer ihn vom allgemeinen Copilot unterscheiden. Zuständigkeit, Datenbereich und mögliche Aktionen werden bereits in der Einführung erklärt. Der Leitfaden Copilot Studio Agent erstellen liefert den vollständigen Entwicklungsrahmen.

Websitekanäle getrennt absichern

Eine Website kann interne, partnerbezogene oder öffentliche Nutzer erreichen. Anonyme Veröffentlichung eignet sich nur für Inhalte und Aktionen, die ohne Identitätsnachweis zulässig sind. Ein Chatfenster auf einer öffentlichen Seite darf keinen indirekten Zugriff auf interne Wissensquellen eröffnen.

Für authentifizierte Websites werden Anmeldung, Tokenfluss, Sessiondauer, Abmeldung und Fehlerbehandlung entworfen. Die Webanwendung prüft zusätzlich Autorisierung und schützt Tokens. CORS, Content Security Policy und Einbettung werden passend zur Zielarchitektur konfiguriert.

Sitzungen und Kontext begrenzen

Der Gesprächskontext kann Angaben aus früheren Nachrichten enthalten. Bei gemeinsam genutzten Geräten, abgelaufener Anmeldung oder Kanalwechsel darf keine Sitzung einem falschen Benutzer zugeordnet werden. Abmeldung und Sessionablauf werden getestet.

Der Agent speichert nur den benötigten Zustand. Sensible Werte werden nicht unnötig in Variablen oder Protokollen gehalten. Bei einer Eskalation an einen Menschen wird transparent festgelegt, welcher Gesprächskontext übertragen wird.

Freigaben und Zielgruppen verwalten

Bearbeitungsrechte am Agenten, Nutzungserlaubnis und Kanalveröffentlichung sind verschiedene Berechtigungen. Maker dürfen einen Agenten ändern, ohne automatisch produktive Freigaben allein zu bestimmen. Benutzergruppen erhalten nur die erforderliche Nutzung.

Gruppenbasierte Zuweisung erleichtert Pilot und Rollout. Gäste und externe Konten werden gesondert geprüft. Die Verwaltung von Gastbenutzern hilft bei Eigentum, Ablauf und Reviews.

Zugriff mit einer Testmatrix prüfen

Eine Testmatrix verbindet Identität, Kanal, Datenquelle und Aktion. Sie enthält berechtigte und nicht berechtigte Fälle. Tests werden nicht nur mit Administratoren durchgeführt, weil deren breite Rechte Fehler verdecken.

Für jeden Fall werden Anmeldung, sichtbare Funktionen, Quellenzugriff, Toolberechtigung und Abmeldung geprüft. Eine erfolgreiche Antwort bei fehlender Berechtigung ist ein kritischer Fehler. Ein erwarteter verweigerter Zugriff muss verständlich und ohne interne Details erklärt werden.

• interner Standardbenutzer in Teams
• Fachgruppenmitglied mit zusätzlicher Datenberechtigung
• interner Benutzer ohne Quellenzugriff
• Gastkonto mit begrenztem Zugriff
• angemeldeter Websitebenutzer
• anonymer Websitebesucher ohne interne Funktionen

Fehlerdiagnose entlang des Identitätsflusses durchführen

Bei einem Zugriffsfehler wird geprüft, welcher Benutzer angemeldet ist, welche Agentenidentität verwendet wird, welche Verbindung greift und welches Zielsystem ablehnt. Ein erneutes Veröffentlichen löst keine falsch erteilte Berechtigung.

Korrelations- und Auditdaten werden gesichert. Benutzer sehen eine knappe Fehlermeldung und einen Supportweg. Technische Details bleiben im Betriebsprotokoll und werden nur befugten Rollen zugänglich gemacht.

So bleibt der Agent in jedem Kanal kontrolliert

Copilot Studio Authentifizierung ist eine Ende-zu-Ende-Entscheidung aus Benutzer, Agent, Verbindung und Zielsystem. Teams und Microsoft 365 erleichtern interne Anmeldung, während Websites eine eigene Sicherheitsarchitektur benötigen. Kanalwahl und Datenzugriff werden deshalb gemeinsam getestet.

Ein geregeltes Modell trennt Erstellen, Veröffentlichen und Nutzen. Identitäten besitzen begrenzte Rechte, Sitzungen laufen kontrolliert ab und negative Zugriffstests gehören zur Freigabe. Damit bleibt derselbe Agent auch bei mehreren Kanälen nachvollziehbar.

Sitzungs- und Abmeldeverhalten prüfen

Authentifizierung endet nicht mit dem ersten Login. Zu testen sind abgelaufene Tokens, Kontowechsel, Inaktivität, Browserwechsel und Abmeldung. Ein gemeinsam genutztes Gerät darf keine vorherige Sitzung oder deren Gesprächskontext weiterreichen.

Der Kanal muss verständlich reagieren, wenn eine erneute Anmeldung erforderlich ist. Endlosschleifen zwischen Website und Identitätsdienst werden durch Tests mit unterschiedlichen Browser- und Cookieeinstellungen sichtbar. Sitzungsdauer folgt dem Risiko des Anwendungsfalls.

Teams-Bereitstellung organisatorisch freigeben

Für Teams werden App-Paket, Richtlinien, Zielgruppen und Updateweg festgelegt. Eine technische Veröffentlichung macht den Agenten nicht automatisch für alle Benutzer auffindbar. Pilotgruppen und genehmigte Kataloge erlauben eine kontrollierte Ausweitung.

Tests umfassen Desktop, Web und mobile Nutzung, soweit der Zielprozess sie erfordert. Auch Deep Links, Benachrichtigungen und Mandantenwechsel können sich unterscheiden. Support erhält die genaue App-Version und den Bereitstellungskanal.

Websites gegen direkten Missbrauch absichern

Ein eingebetteter Agent darf nicht nur über die sichtbare Webseite geschützt sein. Endpunkt, Tokenausgabe, erlaubte Ursprünge und API-Aufrufe benötigen eigene Kontrollen. Ein Angreifer kann Requests außerhalb der Benutzeroberfläche senden.

Eingabelimits, Rate Limits und Sicherheitsüberwachung begrenzen automatisierten Missbrauch. Bei externen Zielgruppen werden Einwilligungs-, Datenschutz- und Aufbewahrungstexte in den tatsächlichen Gesprächsablauf integriert. Die Verantwortlichen prüfen außerdem Barrierefreiheit und mobile Darstellung.

Kanaltests als wiederholbaren Abnahmesatz pflegen

Ein gemeinsamer Testkern prüft Anmeldung, zulässige Fragen, verbotene Daten, Toolaktionen, Abbruch und Übergabe. Kanalspezifische Fälle ergänzen Darstellung, Sitzungen und Identitätsübergabe. Jeder Release durchläuft mindestens die kritischen Pfade.

Ergebnisse werden mit Kanal, Agentenversion, Benutzerrolle und Zeitpunkt dokumentiert. Dadurch kann ein Fehler einer Konfigurationsänderung zugeordnet werden. Ein bestandener Test in der Autorenoberfläche ersetzt diese Ende-zu-Ende-Prüfung nicht.

Identitätswechsel zwischen Kanal und Tool nachvollziehen

Der Benutzer kann im Kanal angemeldet sein, während ein Tool über eine andere Verbindung oder technische Identität arbeitet. Diese Übergänge werden pro Aktion dokumentiert: Wer authentifiziert den Benutzer, welches Token erreicht den Agenten, mit welcher Identität ruft das Tool das Zielsystem auf und wo wird die Berechtigung geprüft? Nur so lässt sich Least Privilege Ende zu Ende beurteilen.

Im Test werden Benutzer mit unterschiedlichen Rollen durch denselben Gesprächspfad geführt. Die sichtbare Antwort, der Toolaufruf und der Auditnachweis müssen zum jeweiligen Zugriff passen. Wechselt ein Kanal auf eine anwendungsbasierte Identität, darf die Systemanweisung keine fehlende Autorisierung ersetzen. Die fachliche Aktion benötigt dann eigene Filter, Freigaben und eine klare Verantwortlichkeit.

Gast- und externe Benutzer separat entscheiden

Ein interner Teams-Agent ist nicht automatisch für Gäste geeignet. Das Team prüft Mandantenzugehörigkeit, Conditional Access, Lizenzvoraussetzung, Datenquellen und Toolberechtigungen für jede externe Zielgruppe. Auf einer öffentlichen Website benötigt der Agent ein anderes Identitäts- und Missbrauchsmodell als im angemeldeten Mitarbeiterkanal. Statt dieselbe Veröffentlichung für alle zu öffnen, können getrennte Agents oder Kanalkonfigurationen sinnvoll sein. Die Entscheidung wird mit negativen Zugriffstests belegt und bei Änderungen an Gastregeln oder Zielgruppen erneut geprüft.