Ein Link zum Agenten ist noch kein Datenzugriff. Eine Copilot-Lizenz ist ebenfalls kein Datenzugriff. Und die Berechtigung auf einer SharePoint-Site bedeutet nicht automatisch, dass ein bestimmter Agent verwendet werden kann.
Für SharePoint Agents müssen Verantwortliche drei getrennte Gates prüfen:
- Berechtigung auf der
.agent-Datei: Darf die Person den Agenten öffnen oder bearbeiten? - Berechtigung auf den Wissensquellen: Welche Inhalte darf diese Person in den Antworten erhalten?
- Copilot- oder PAYG-Entitlement: Darf die Person den Dienst überhaupt nutzen?
Ein bestandenes Gate ersetzt keines der anderen. Genau diese Trennung gehört in das Berechtigungsdesign, in den Rollout-Test und in das Offboarding. Sie ist aber keine universelle Sicherheitsgarantie. Fehlkonfigurationen, überbreite SharePoint-Rechte, unklare Verantwortlichkeiten oder unzureichend getestete Verteilungswege bleiben möglich.
Gate 1: Die .agent-Datei steuert den Zugriff auf den Agenten
Ein individuell erstellter SharePoint Agent wird als .agent-Datei gespeichert. Wird er von der Site-Startseite erstellt, liegt die Datei unter Websiteinhalte > Site Assets > Copilots. Bei einer Erstellung aus einer Dokumentbibliothek wird sie im aktuellen Bibliotheksordner gespeichert.[1]
Microsoft beschreibt die Dateiberechtigung als Kontrolle dafür, wer den Agenten aufrufen oder bearbeiten kann. Damit verhält sich die Agent-Konfiguration in einem wichtigen Punkt wie ein SharePoint-Artefakt: Der Speicherort, Vererbungen, direkte Freigaben und Gruppenmitgliedschaften müssen bekannt sein.[2]
Das bedeutet nicht, dass eine Freigabe der .agent-Datei zugleich die zugrunde liegenden Sites oder Bibliotheken freigibt. Agent-Sharing ist nicht Site-Sharing. Ein Nutzer kann den Agenten öffnen und dennoch aus einer referenzierten Quelle keine Inhalte erhalten, wenn ihm dort die nötige Berechtigung fehlt.[2]
Für das Betriebsmodell sollten deshalb mindestens folgende Angaben dokumentiert werden:
- Speicherort und URL der
.agent-Datei, - Owner und fachlich verantwortliches Team,
- Leser- und Bearbeitergruppen,
- direkte Freigaben außerhalb dieser Gruppen,
- Verteilungswege nach SharePoint, Teams und Copilot Chat,
- Datum des letzten Berechtigungsreviews.
Gate 2: Quellberechtigungen bestimmen den Antwortinhalt
SharePoint Agents verwenden SharePoint-Inhalte als Wissensgrundlage. Microsoft nennt Sites, Seiten, Dokumentbibliotheken, Ordner und Dateien; die FAQ nennt aktuell maximal 20 Quellobjekte pro Agent.[2][3] Entscheidend ist aber nicht nur, was im Agenten konfiguriert wurde. Entscheidend ist die Schnittmenge aus konfigurierter Quelle und Berechtigung des jeweils fragenden Nutzers.
Microsoft formuliert das klar: Fehlt einer Person die Berechtigung auf einen eingebundenen Inhalt, soll dieser Inhalt in ihrem Chat mit dem Agenten nicht erscheinen.[2][3] Ein Agent erhält damit keine pauschale Identität, die alle Nutzerrechte ersetzt. Die Antworten werden für den jeweiligen Nutzer auf Basis seiner Zugriffsrechte auf die Daten gebildet.
Das ist eine wichtige Schutzwirkung, aber kein Grund, bestehende Berechtigungen ungeprüft zu lassen. Wenn eine Person bereits zu viel lesen darf, kann der Agent Inhalte aus diesem erlaubten Bestand leichter auffindbar machen. Die fachliche Aufgabe bleibt deshalb dieselbe wie vor Copilot: Zugriffe müssen nachvollziehbar, rollenbasiert und regelmäßig überprüft sein. Eine Einführung sollte auf einer belastbaren SharePoint-Grundlage aufsetzen; dazu gehört auch eine klare Informationsarchitektur. Mehr dazu im WITC-Artikel „Copilot in SharePoint scheitert selten am Modell – sondern an eurer Basis“.
Zusätzliche Governance-Funktionen können den Rahmen ergänzen. Microsoft nennt unter anderem Restricted Access Control, Restricted Content Discovery und Purview-DLP-Konfigurationen.[2] Diese Mechanismen haben jeweils einen eigenen Zweck und eigene Voraussetzungen. Restricted Content Discovery kann Agent-Funktionen auf einer markierten Site ausblenden und die Verwendung ihrer Inhalte in Copilot beziehungsweise der organisationsweiten Suche einschränken, lässt den eigentlichen Site-Zugriff aber unverändert.[2] Solche Kontrollen ersetzen daher weder das Berechtigungsmodell noch einen Test mit realen Zielrollen.
Gate 3: Copilot-Lizenz oder PAYG erlaubt die Nutzung – nicht den Datenzugriff
Für die Nutzung nennt Microsoft zwei Wege: eine zugewiesene Microsoft-365-Copilot-Lizenz oder eine PAYG-Konfiguration. Beim PAYG-Weg werden SharePoint Agents als Azure-Ressource eingerichtet, eine Billing Policy angelegt und mit dem Dienst verbunden. Nur Mitglieder der Security Group, die der Policy zugeordnet ist, erhalten über diesen Weg Zugang zu SharePoint Agents.[2][4]
Dieses Entitlement beantwortet nur die Frage: Darf der Nutzer den Dienst verwenden? Es verändert keine SharePoint-Berechtigung auf Sites, Bibliotheken oder Dateien. Die Mitgliedschaft in einer PAYG-Gruppe darf daher nie als Ersatz für eine Quellenfreigabe verstanden werden.[2][4]
Auch beim Erstellen gilt eine eigene Voraussetzung: Laut Microsoft benötigt eine Person eine Microsoft-Copilot-Lizenz und Edit-Rechte auf der SharePoint-Site.[1] Für Administratoren kommt eine weitere Stellschraube hinzu: Der Serviceplan „Microsoft 365 Copilot for SharePoint“ kann pro Nutzer deaktiviert werden. Microsoft weist darauf hin, dass dies auch Copilot in OneDrive sowie den SharePoint-Seitenauthoring-Copilot für diesen Nutzer deaktiviert.[2]
Das Ergebnis ist ein sauberes Prüfmodell:
Agent nutzbar =
.agent-Zugriff UND Quellenzugriff für den gewünschten Inhalt UND gültiges Copilot-/PAYG-Entitlement.
Fehlt ein Gate, muss sich das beobachtbare Verhalten ändern. Welches UI-Signal erscheint und wie schnell eine Änderung wirksam wird, sollte im eigenen Tenant gemessen werden – nicht aus einer Architekturzeichnung abgeleitet.
Dokumentationswiderspruch bei Microsoft Lists: offen benennen
Beim Thema Lists sind aktuell keine pauschalen Zusagen belastbar. Die Microsoft-Anleitung zur Agent-Erstellung zeigt die Aktion Create an agent auch in der Befehlsleiste einer SharePoint List.[1] Die aktuelle FAQ sagt dagegen ausdrücklich: „Agents currently don’t use data from Lists.“[3]
Beides kann gleichzeitig bedeuten, dass die Oberfläche einen Einstieg anbietet, Listendaten aber nicht als Wissensquelle verarbeitet werden. Die Dokumentation löst diese Abgrenzung derzeit jedoch nicht eindeutig auf. Deshalb gilt für Konzeption und Kommunikation:
- Eine List darf als Explorationsfall in einen Tenant-Test aufgenommen werden.
- Listendaten dürfen nicht als zugesicherte Wissensquelle beworben werden.
- Ein beobachtetes Ergebnis muss mit Tenant, Zeitpunkt, Agent-Konfiguration und Testprompt dokumentiert werden.
- Bis zur eindeutigen Klärung sollte ein produktiver Use Case nicht von Listendaten als Agent-Quelle abhängen.
Erlaubte und nicht erlaubte Aussagen
Zulässige Aussagen auf Basis der aktuellen Dokumentation
- „Die
.agent-Datei, die Quellberechtigungen und das Copilot-/PAYG-Entitlement sind getrennte Kontrollschichten.“[2] - „Ein Nutzer kann auf einen Agenten zugreifen und trotzdem keine Inhalte aus einer eingebundenen Quelle erhalten, wenn ihm dort die Berechtigung fehlt.“[2][3]
- „PAYG steuert über Azure-Ressource, Billing Policy und Security Group die Dienstnutzung; es verleiht keine Rechte auf Quelldaten.“[2][4]
- „Die Microsoft-FAQ nennt aktuell bis zu 20 Quellobjekte pro Agent.“[3]
Nicht zulässige oder zu starke Aussagen
- „Agent-Sharing ist Site-Sharing.“ Falsch: Agent-Datei und Quellen haben getrennte Berechtigungen.
- „PAYG gibt Zugriff auf die hinterlegten Dokumente.“ Falsch: PAYG ist ein Nutzungsentitlement.
- „Ein SharePoint Agent umgeht SharePoint-Berechtigungen.“ Durch die Quellen nicht belegt; Microsoft beschreibt nutzerbezogene Datenberechtigungen.[2][3]
- „Drei Gates machen den Agenten sicher.“ Zu absolut. Die Gates sind notwendige Kontrollen, aber keine vollständige Sicherheits- oder Compliance-Garantie.
- „SharePoint Agents verwenden Listendaten.“ Derzeit nicht belastbar, weil Erstelloberfläche und FAQ widersprüchliche Erwartungen erzeugen.[1][3]
- „Das Entfernen der Copilot-Lizenz schließt das Offboarding ab.“ Zu kurz: Datei-, Quellen-, PAYG-, Konto- und Verteilungsebene müssen separat geprüft werden.
- „Agent-Reports sind eine lückenlose CMDB.“ Nicht belegt. Reporting- und Auditdaten dürfen nur innerhalb ihrer dokumentierten Ereignis- und Aufbewahrungsgrenzen interpretiert werden.
Wiederverwendbares Artefakt: Agent Access Matrix + Offboarding Protocol
Die folgende Matrix ist eine Vorlage für einen kontrollierten Tenant-Test. Die Namen sind fiktive Testidentitäten, keine dokumentierte WITC-Praxiserfahrung.
| Testidentität | Rolle | .agent-Datei | Quelle A: Projektbibliothek | Quelle B: HR-Bibliothek | Copilot-Lizenz | PAYG-Gruppe | Erwartung |
|---|---|---|---|---|---|---|---|
| Anna Vollzugriff | Projektleitung | Lesen | Lesen | Lesen | Ja | Nein | Agent nutzbar; Antworten aus A und B möglich |
| Ben Projekt | Projektmitarbeiter | Lesen | Lesen | Kein Zugriff | Ja | Nein | Agent nutzbar; B darf keinen Antwortinhalt liefern |
| Carla OhneEntitlement | Fachanwenderin | Lesen | Lesen | Lesen | Nein | Nein | Quellenrechte vorhanden, Agent-Dienst nicht nutzbar |
| David PAYG | Externer Projektmitarbeiter | Lesen | Lesen | Kein Zugriff | Nein | Ja | Agent nutzbar; B bleibt verborgen |
| Eva Offboarding | austretende Mitarbeiterin | zunächst wie Anna | stufenweise entziehen | stufenweise entziehen | stufenweise entziehen | entfernt | Nach vollständigem Offboarding keine Nutzung und keine neuen Inhaltsantworten |
TESTPLAN – gestufter Tenant-Test, noch nicht durchgeführt
Teststatus: Plan. Die folgenden Ergebnisse sind Erwartungen aus der Dokumentation, keine protokollierten Produktbeobachtungen.
Stufe 0 – Kontrollierte Ausgangslage
- Einen Test-Agenten mit eigener
.agent-Datei anlegen. - Quelle A und Quelle B mit jeweils einem eindeutigen, nicht sensiblen Testfakt befüllen.
- Die fünf Identitäten exakt gemäß Matrix berechtigen.
- Je Identität denselben Prompt zu Quelle A und Quelle B ausführen.
- SharePoint, Teams und Copilot Chat getrennt prüfen; Zeitpunkt, Oberfläche, Prompt, Zitate und Antwort protokollieren.
Abnahmekriterium: Anna sieht erlaubte Testfakten aus A und B; Ben und David erhalten keinen Inhalt aus B; Carla kann den Agent-Dienst trotz Quellenrechten nicht nutzen.
Stufe 1 – .agent-Recht entziehen
Bei Eva zuerst nur das Leserecht auf der .agent-Datei entfernen. Direkte Links, zuletzt verwendete Elemente sowie Einträge in SharePoint, Teams und Copilot Chat erneut prüfen.
Abnahmekriterium: Kein neuer Agent-Zugriff über den entzogenen Dateipfad. Abweichende Sichtbarkeit oder Cache-/Propagationsverhalten mit Zeitstempel erfassen.
Stufe 2 – Quellenrechte entziehen
Die Rechte von Eva auf Quelle A und Quelle B nacheinander entfernen. Nach jedem Schritt quellspezifische Prompts stellen.
Abnahmekriterium: Inhalte der jeweils entzogenen Quelle erscheinen nicht mehr in neuen Antworten. Propagationszeit und vorhandene Chat-Historie separat dokumentieren.
Stufe 3 – Entitlement entziehen
Zuerst die Copilot-Lizenz beziehungsweise den SharePoint-Copilot-Serviceplan entfernen, danach – falls für die Identität vorhanden – die Mitgliedschaft in der PAYG-Security-Group. Beide Schritte einzeln testen.
Abnahmekriterium: Keine neue Agent-Nutzung über den jeweiligen Entitlement-Pfad. Die Entfernung von Entitlement darf nicht als Nachweis für entfernte Quellenrechte gewertet werden.
Stufe 4 – Konto deaktivieren und Verteilungswege prüfen
Das Testkonto deaktivieren. Danach direkte Agent-Links, SharePoint, Teams und Copilot Chat prüfen. Zusätzlich Owner, Bearbeitergruppen, geteilte Links und verbleibende Gruppenmitgliedschaften kontrollieren.
Abnahmekriterium: Kein Login und keine neue Nutzung. Offboarding-Protokoll enthält pro Ebene Maßnahme, Soll, Ist, Zeit bis Wirksamkeit, Admin-/Audit-Signal und Rückrollbarkeit.
Stufe 5 – Lists als separater Explorationsfall
Eine SharePoint List nur in einer isolierten Testkonfiguration verwenden. Einen eindeutigen Testwert ausschließlich in der List hinterlegen und mit einem reproduzierbaren Prompt abfragen.
Abnahmekriterium: Kein vorab zugesagtes Ergebnis. Befund als tenant- und zeitpunktbezogene Beobachtung dokumentieren; wegen des Dokumentationswiderspruchs nicht verallgemeinern.[1][3]
Was vor dem Rollout entschieden werden muss
Die Access Matrix sollte nicht erst nach dem ersten Berechtigungsproblem entstehen. Vor dem Rollout braucht jeder Agent einen Owner, definierte Nutzergruppen, benannte Quellen, ein Entitlement-Modell und einen Offboarding-Verantwortlichen. Dazu kommen Wiederholungstests nach Änderungen an Gruppen, Quellen, Agent-Datei oder Verteilung.
Wer die zugrunde liegende Dokumentenstruktur noch ordnen muss, findet im Beitrag „SharePoint Online – Die Basis für modernes Dokumentenmanagement“ die fachliche Grundlage. WITC unterstützt bei der Aufnahme des Ist-Zustands, beim Berechtigungs- und Governance-Design sowie bei einem dokumentierten Pilot mit Testidentitäten. Für die Einordnung des eigenen Tenants führt der direkte Weg über walther-it-consulting.de/kontakt.
Weiterführende WITC-Artikel
- Copilot in SharePoint scheitert selten am Modell – sondern an eurer Basis
- SharePoint Online – Die Basis für modernes Dokumentenmanagement
Sources
[1] https://support.microsoft.com/en-us/sharepoint/copilot-in-sharepoint/create-an-agent-in-sharepoint — Microsoft Support: Create an agent in SharePoint (abgerufen am 04.09.2026) [2] https://learn.microsoft.com/en-us/sharepoint/manage-access-agents-in-sharepoint — Microsoft Learn: Manage access to agents in SharePoint (abgerufen am 04.09.2026) [3] https://support.microsoft.com/en-us/sharepoint/copilot-in-sharepoint/frequently-asked-questions-about-copilot-in-sharepoint — Microsoft Support: Frequently asked questions about Copilot in SharePoint (abgerufen am 04.09.2026) [4] https://learn.microsoft.com/en-us/sharepoint/sharepoint-agents-azure-billing — Microsoft Learn: Use agents with pay-as-you-go billing (abgerufen am 04.09.2026)