Copilot Agents in Microsoft 365 haben sich im vergangenen Jahr enorm schnell entwickelt. In vielen Tenants, die ich betreue, finden sich neben den Agents von Microsoft inzwischen immer mehr Partnerlösungen und selbst gebaute Agenten aus Copilot Studio, seit Kurzem auch die neuen SharePoint Agents. Damit wächst den Admins eine zusätzliche Governance-Aufgabe zu. Wer Copilot Agents verwalten will, muss mehr tun als genehmigen oder blockieren. Man braucht Transparenz darüber, wie ein Agent entstanden ist, wo er veröffentlicht wurde, mit wem er geteilt ist und wer ihn nutzt. Seit Microsoft 365 Copilot Chat und die neue Copilot-App verfügbar sind, gibt es noch mehr Agents, und sie fallen den Anwendern auch deutlich stärker ins Auge.

Copilot Agents stammen aus immer mehr unterschiedlichen Quellen

Gerade diese Vielfalt erschwert Admins den Überblick. Zu den Agents, die Microsoft selbst bereitstellt, kommen Partnerangebote aus dem Marketplace, Agents von Dienstleistern und natürlich Eigenentwicklungen. Eigene Agents baut man entweder mit dem einfachen Agent Builder in Copilot Studio, etwa für schnelle FAQ-Bots oder Prozessassistenten, oder mit der Vollversion von Copilot Studio. Dort lassen sich auch komplexe agentengestützte Workflows mit Aktionen und Integrationen umsetzen. Seit Januar 2025 sind außerdem die SharePoint Agents stark präsent. Man erstellt sie direkt auf einer SharePoint-Site, sie greifen auf deren Inhalte zu und lassen sich für die Mitarbeitenden freigeben. Im Pilottest wirkt das alles noch überschaubar. Im Produktivbetrieb verliert man dagegen schnell den Überblick, vor allem wenn mehrere Teams oder Abteilungen eigene Agents veröffentlichen. Ohne saubere Übersicht geht es deshalb nicht.

Das folgende Diagramm zeigt den Weg eines Agents von der Erstellung über das Teilen bis zur Kontrolle durch den Admin:

flowchart TD
    AgentBuilder["Agent Builder (Copilot Studio)"] --> AgentErstellt["Agent erstellt"]
    CopilotStudio["Copilot Studio (voll)"] --> AgentErstellt
    SharePoint["SharePoint Site"] --> AgentErstellt
    PartnerMarketplace["Partner/Marketplace"] --> AgentErstellt
    AgentErstellt --> Teilen["Teilen mit Nutzern"]
    Teilen --> AdminFreigabe["Admin-Freigabe/Blockieren"]
    AdminFreigabe --> NutzerVerfuegbar["Agent für Nutzer verfügbar"]

Abbildung: Von der Agent-Erstellung zur Freigabe für Anwenderinnen und Anwender.

Das Admin Center zeigt jeden Agent und erlaubt das gezielte Blockieren

Zentral gesteuert werden Copilot Agents heute im Microsoft 365 Admin Center unter Einstellungen → Integrierte Apps, und zwar im Copilot-Abschnitt für Agents. Dort erscheinen sämtliche Agents, egal ob sie von Microsoft, von Partnern oder aus dem eigenen Haus stammen. Ich kann nur dringend empfehlen, sich diesen Bereich regelmäßig anzusehen. Sind die Berechtigungen in Copilot Studio oder SharePoint zu locker eingestellt, tauchen dort manchmal ohne Vorwarnung neue Agents auf. Zu jeder App und jedem Agenten zeigt das Portal Publisher, Beschreibung, Datenzugriffe und Aktionen an. Besonders aufschlussreich ist der Bereich „Datenquellen“. Er verrät, ob ein Agent beispielsweise auf Unternehmensdaten, SharePoint-Inhalte oder externe Datenbanken zugreift oder sich auf öffentliche Webquellen beschränkt. Auch die Angaben zum Publisher lassen sich hier kontrollieren. Wirkt ein Drittanbieter-Agent fragwürdig, blockiert man ihn im Zweifel einfach.

Eine besonders gründliche Prüfung ist in diesen Fällen angebracht:

  • Zugriff auf sensible M365-Daten oder SharePoint-Sites
  • Nutzung von Actions (z. B. E-Mails senden, Daten ändern)
  • Publisher ist unbekannt oder nicht verifiziert
  • Agent stammt aus Copilot Studio und ist breit geteilt
  • Unklare Beschreibung oder mehrere ähnliche Agents

Klare Berechtigungen verhindern Wildwuchs bei Erstellung und Freigabe

Sind die Berechtigungen zu großzügig verteilt, wuchern die Agents in der Praxis schnell unkontrolliert. Copilot Studio erlaubt es, sowohl den Agent Builder als auch das Vollprodukt fein abgestuft zu reglementieren. Die entscheidenden Einstellungen finden sich im Microsoft 365 Admin Center und im Adminbereich von Copilot Studio. Dort lege ich fest, wer Agents erstellen, testen und veröffentlichen darf und ob sich Agents für Gruppen oder gleich für das ganze Unternehmen freigeben lassen. Bei SharePoint Agents ist besondere Vorsicht angebracht, denn jeder Site Owner kann Agents für alle Nutzer seiner Site bereitstellen. Wer Governance ernst nimmt, richtet die Governance für Copilot Studio frühzeitig ein und erlaubt das Erstellen und Veröffentlichen nur bestimmten Gruppen. Ausführlicher bin ich darauf bereits in den Beiträgen zu Copilot-Studio-Governance mit Power-Platform-DLP-Richtlinien und zur Governance autonomer Agenten in Copilot Studio eingegangen.

Praktischer Tipp: Wer wissen will, welche Agents im Tenant aktiv sind, sollte den Copilot-Bereich im Admin Center regelmäßig durchgehen und dabei vor allem auf neu hinzugekommene Agents achten. Gut bewährt hat sich dafür ein monatlicher Review-Termin im Admin-Team.

Unlizenzierte Nutzer verursachen nutzungsbasierte Kosten

In Projekten überrascht viele eine Besonderheit immer wieder: Verwenden Nutzer ohne passende Copilot-Lizenz einen Agent, kann Microsoft dies nach dem Pay-as-you-go-Modell abrechnen. Das betrifft vor allem Agents, die für größere Gruppen oder für alle Mitarbeitenden freigegeben sind. Abgerechnet wird auf Tenant-Ebene, einsehen lässt sich das im Microsoft 365 Admin Center unter Abrechnung → Nutzungsbasierte Dienste. Agent-Admins und das Controlling sollten das unbedingt wissen, damit am Monatsende keine unangenehme Rechnung ins Haus flattert. Ich rate daher, Freigaben gezielt und eher sparsam zu erteilen, die Nutzer regelmäßig zu informieren und die Abrechnung im Blick zu behalten. Weitere Details zur Verwaltung von Agents und zu den lizenzrechtlichen Folgen beschreibt Microsoft auf dieser Supportseite.

Bei unklaren Agents blockiere ich zuerst und frage dann nach

Liegt ein neuer Agent zur Freigabe vor, sehe ich mir grundsätzlich Publisher, Datenquellen und gegebenenfalls die Actions an. Das gilt ganz besonders für Agents aus Copilot Studio oder von Partnern. Im Microsoft 365 Admin Center sind die wichtigsten Informationen dafür gebündelt. Bleiben Zweifel, blockiere ich den Agent erst einmal und hake gezielt beim Ersteller nach. Hinter einem scheinbar harmlosen FAQ-Agent steckt nämlich gar nicht so selten ein weitreichender Zugriff. Bei SharePoint Agents sieht es ähnlich aus. Die häufigsten Fallstricke und die vorhandenen Kontrollmöglichkeiten habe ich im Beitrag über Governance und Berechtigungen von Agents in SharePoint zusammengestellt.

Ein freigegebener Agent lässt sich übrigens jederzeit im Admin Center wieder entfernen oder einschränken. PowerShell-Skripte für die Verwaltung gibt es bislang nicht, sämtliche Einstellungen nimmt man im Admin-Portal vor. 

# Einen Agent im Admin Center blockieren:
# Voraussetzungen: Globaler Admin oder App-Administrator
# Ort: Microsoft 365 Admin Center → Einstellungen → Integrierte Apps → Copilot-Agents
# (Im Portal: Agent auswählen, dann 'Blockieren')

Wenige gut geprüfte Agents bringen mehr als viele ungeprüfte

Aus meiner Praxiserfahrung kann ich nur raten, früh klare Prozesse und Zuständigkeiten festzulegen. Das verhindert Wildwuchs und schützt vor ausufernden Kosten. Starten Sie lieber mit einer kleinen Zahl sorgfältig geprüfter Agents, vergeben Sie Freigaben mit Bedacht und behalten Sie im Auge, was das für Nutzer und Abrechnung bedeutet. Für die neuen SharePoint Agents und für autonome Agents aus Copilot Studio gilt das ganz besonders, denn hier ist Kontrolle besser als Nachsicht.