Seit dem Herbst tauchen in den Tenants, die ich betreue, Agents in SharePoint auf, und das Thema sorgt sofort für Gesprächsstoff. Auf einmal hat jede SharePoint-Site einen eigenen Agenten, der direkt auf ihre Inhalte und Metadaten zugreift. Das Prinzip kennt man bereits. Ein KI-Agent beantwortet Fragen zu Dokumenten, Listen, Seiten oder zur Struktur der Site, bleibt dabei aber strikt innerhalb ihrer Grenzen und der vorhandenen Berechtigungen. Das ist reizvoll und kann gefährlich werden, wenn man SharePoint nicht im Griff hat.

Agents in SharePoint arbeiten strikt entlang der vorhandenen Berechtigungen

Der Standard-Agent einer Site kennt nur das, was Nutzer:innen mit Zugriff auf diese Site ohnehin sehen. Er fügt sich sauber in das Berechtigungskonzept von SharePoint ein, ähnlich wie man es von Restricted SharePoint Search kennt (/blog/restricted-sharepoint-search-copilot-oversharing-eindaemmen). Wer sensible Bibliotheken oder Seiten versehentlich zu offen teilt, öffnet damit klassische Zugriffe und erlaubt außerdem dem Site-Agenten, Auskunft über diese Inhalte zu geben. Deshalb beobachte ich in vielen Tenants ein neues Bewusstsein für „Oversharing“. Die KI findet eben auch Daten, die bisher unbemerkt irgendwo lagen.

Das folgende Diagramm zeigt, wie Berechtigungen und die Interaktion mit dem Agenten ineinandergreifen:

flowchart TD
User["Nutzer:in stellt Frage"] --> Agent["SharePoint Agent"]
Agent --> AuthZ["Berechtigungsprüfung (Site)"]
AuthZ --> Data["Zugriff auf Site-Inhalte"]
Data --> Response["Antwort generieren"]
Response --> User

Abbildung: Ein Agent verarbeitet nur Inhalte der Site und respektiert dabei die SharePoint-Berechtigungen.

Besondere Aufmerksamkeit verdienen die .agent-Dateien, die sich direkt auf einer SharePoint-Site ablegen lassen. Wer Bearbeitungsrechte hat, kann damit eigene, gezielt trainierte Agents erstellen und teilen, sogar in Teams-Chats. Was ein solcher Agent „weiß“, hängt wiederum von den Site-Berechtigungen ab. Das Rollenmodell bleibt also der entscheidende Punkt, und hier lauern die bekannten Risiken: verwaiste Sites und zu großzügig vergebene Berechtigungen. Wer SharePoint Advanced Management einsetzt, hat jetzt einen weiteren Grund, Berechtigungen und Freigaben regelmäßig zu prüfen.

Ohne Copilot-Lizenz laufen geteilte Agenten über ein Pay-as-you-go-Modell

Neu ist die soziale Komponente. Agenten lassen sich direkt in Teams-Chats einbinden und gelangen so in andere Bereiche. Technisch klappt das, weil die Agent-Datei als SharePoint-Ressource referenziert wird. Verarbeitet werden aber weiterhin nur die Inhalte der Ursprungs-Site, und ob der Agent funktioniert, entscheiden die Rechte der jeweiligen Person. Spannend wird es bei Nutzer:innen ohne Copilot-Lizenz. Auch wer keinen Zugang zu „Microsoft 365 Copilot“ hat, kann Agents verwenden, dann allerdings über ein Pay-as-you-go-Modell. Abgerechnet wird tenantweit nach Nutzung, und je nach Aktivität steigen die Kosten schnell. Immer häufiger höre ich deshalb den Wunsch, die Nutzung über Reporting und Zuweisungsmodelle zu steuern. Details und aktuelle Preise sollte man trotzdem immer im Admin Center oder in den offiziellen Lizenzbestimmungen nachschlagen, denn das Modell ändert sich noch.

Praxistipp: In Tenants mit vielen Gästen oder externen Nutzer:innen lohnt es sich, gezielt zu prüfen, welche Sites Agents und damit KI-Zugriff anbieten. Vor allem die kostenpflichtige Nutzung lässt sich über die Kontrollen im SharePoint Admin Center gezielt steuern.

Das SharePoint Admin Center bietet erste Kontrollen für freigegebene Agents

Im SharePoint Admin Center sind einige neue Registerkarten zur Verwaltung von Agents hinzugekommen. Auf Site-Ebene sieht man dort, welche Agents es gibt, wer sie erstellt hat und ob sie freigegeben sind. In einer zentralen Liste lassen sich einzelne Agents als „approved“ markieren oder sperren, etwa wenn ein Custom Agent die Compliance-Vorgaben nicht erfüllt. Die Governance-Aufgaben ähneln denen in Copilot Studio (/blog/copilot-studio-governance-power-platform-dlp-richtlinien), fallen jetzt aber direkt in SharePoint an.

Derzeit sind das die wichtigsten Stellschrauben:

  • Übersicht aller Agents im Tenant einschließlich Teilungsstatus
  • Zentrale Genehmigung oder Sperrung einzelner Agents
  • Reporting zu Aktivität und Nutzung im Admin Center
  • Konfigurierbare Site-Policies für eigene Agenten

Mit SharePoint Advanced Management erhält man zusätzliche Einblicke und kann Policies für die Agenten im Tenant festlegen. Die Lizenz macht sich damit jetzt doppelt bezahlt.

Die Qualität der Inhalte entscheidet über den Nutzen jedes Agenten

Mit den Agents in SharePoint landet die klassische Content-Governance wieder auf dem Tisch der Verantwortlichen. Ein Agent antwortet nur so gut, wie die Inhalte gepflegt und strukturiert sind. Sites mit Wildwuchs, ungeklärtem Lebenszyklus oder dem Charakter eines Datenfriedhofs bringen nutzlose Agenten hervor und bergen zusätzlich Risiken. Mein Rat lautet daher, zuerst die Sites mit aktuellen, gut gepflegten und klar strukturierten Inhalten zu ermitteln und die Agenten gezielt dort zu aktivieren. Auf allen anderen Sites sollte man die Nutzung prüfen, das Reporting einschalten und Agents bei Bedarf ausdrücklich deaktivieren. Wer Restricted SharePoint Search und Agenten aufeinander abgestimmt steuert, bekommt die Risiken in den Griff.

KI in SharePoint läuft nicht von selbst

Agents in SharePoint zählen zu den auffälligsten Neuerungen der Ignite im Herbst 2024, eine Plug-and-Play-Lösung sind sie aber nicht. Wer noch Sites mit zu offenen Berechtigungen oder vernachlässigten Inhalten betreibt, bekommt die Folgen schneller zu spüren als bisher. Ich nehme das zum Anlass, Governance, Reporting und die Hygiene bei Berechtigungen wieder genauer anzuschauen. Die technischen Kontrollen gibt es, man muss sie aber pflegen und auch tatsächlich nutzen.