Claude an Microsoft 365 anbinden
MCP-Konnektor, Berechtigungskette und Governance-Punkte für den UnternehmenseinsatzClaude an Microsoft 365 anbinden: Konnektoren und MCP
„Kann Claude nicht einfach unser SharePoint durchsuchen?“ Die Frage kommt meistens aus dem Vertrieb, spätestens drei Wochen nach den ersten Lizenzen, und die Antwort lautet: ja. Nur eben nicht mit einem Haken im Menü, sondern über eine Kette aus vier Freigaben, an deren Ende die Berechtigungen stehen, die ihr in den letzten zehn Jahren in SharePoint vergeben habt.
Dieser Artikel beschreibt, wie die Anbindung technisch funktioniert, wer an welcher Stelle zustimmen muss, was der Konnektor darf und was nicht — und wie ihr das Ganze wieder einfangt, wenn es sein muss. Am Ende geht es kurz über Microsoft hinaus: Derselbe Mechanismus trägt auch eure eigenen Systeme.
Was der Konnektor ist — und was nicht
Ein Vermittler, kein Datenspeicher
Technisch ist der Microsoft-365-Konnektor ein von Anthropic betriebener Vermittlungsdienst nach dem offenen Konnektor-Protokoll MCP. Er nimmt die Anfrage aus dem Chat entgegen, ruft mit dem Zugangstoken des angemeldeten Nutzers den Microsoft Graph auf und liefert das Ergebnis zurück in die Antwort. Entscheidend für die Sicherheitsbewertung: Die Inhalte werden nur während der laufenden Anfrage abgerufen, es gibt keinen Zwischenspeicher für Dateiinhalte, und eure Dokumente bleiben in eurem Tenant. Gespeichert werden verschlüsselte Zugangstoken — und das, was als Ergebnis in einem gespeicherten Chatverlauf landet.
Bei der Einrichtung entstehen in eurem Verzeichnis zwei Unternehmensanwendungen, die ihr dort auch wiederfindet und verwaltet. Die Anmeldung läuft über den üblichen delegierten Weg mit Zustimmung; ein Passwort sieht Anthropic dabei nie. Die Anwendung selbst ist von Microsoft herausgeberverifiziert — für die Sicherheitsabteilung ein Punkt, den man kurz erwähnen sollte, weil er die erste Rückfrage beantwortet.
Was er kann und was er nicht kann
Lesend deckt der Konnektor SharePoint, OneDrive, Outlook mit Postfach und Kalender sowie Teams-Chats ab. Damit funktioniert die unternehmensweite Suche über verbundene Quellen: eine Frage, Treffer aus Dokumenten, Mails und Chatverläufen. Was nicht geht: Teams-Nachrichten schreiben, mit einem Dienstkonto arbeiten, fremde Postfächer ohne Delegation lesen oder Freigabeeinstellungen umgehen. Und private Microsoft-Konten funktionieren gar nicht — es braucht ein Geschäftskonto in eurem Verzeichnis.
Die andere Richtung — kurz zur Abgrenzung
Verwirrung entsteht regelmäßig, weil es zwei Wege gibt, Claude und Microsoft 365 zusammenzubringen. Der Konnektor zieht Inhalte zu Claude: Ihr fragt im Chat, Claude holt sich die Treffer aus eurem Tenant. Die Office-Add-ins gehen andersherum und bringen Claude als Seitenleiste in Word, Excel, PowerPoint und Outlook, wo es an dem Dokument arbeitet, das ohnehin offen ist. Beides lässt sich parallel betreiben, beides hängt an derselben Identität — aber es sind getrennte Freigaben mit getrennten Auswirkungen. In diesem Artikel geht es um den Konnektor; die Add-ins sind Installationssache und werfen deutlich weniger Governance-Fragen auf.
Abb.: Konnektor-Architektur — Anfrage, Vermittler, Graph, Tenant. Und was dabei gespeichert und protokolliert wird.
Die Berechtigungs-Kette
Vier Tore bis zum Dokument
Bis Claude die erste Datei sieht, müssen vier Türen aufgehen. Erstens gibt ein Owner den Konnektor in der Claude-Organisation überhaupt frei — vorher existiert er für eure Leute nicht. Zweitens stimmt ein globaler Administrator im Verzeichnis einmalig für die gesamte Organisation zu. Drittens meldet sich jeder Nutzer selbst an, inklusive eurer Mehrfaktor- und Zugriffsregeln. Und viertens greifen die Berechtigungen, die im SharePoint und im Postfach ohnehin gelten. Jedes dieser Tore lässt sich einzeln wieder schließen; eines reicht, und der Zugriff endet.
Warum Tor 4 das eigentliche Thema ist
Der Konnektor arbeitet mit delegierten Rechten. Claude sieht also genau das, was der angemeldete Mensch sehen darf — nicht mehr, aber eben auch nicht weniger. Genau hier wird es für viele Häuser unangenehm, denn die Suche über SharePoint läuft tenantweit; eine Einschränkung auf einzelne Websites ist deshalb nicht vorgesehen. Wer in den letzten Jahren großzügig geteilt hat, stellt beim ersten Test fest, wie großzügig. Das ist kein Fehler des Konnektors, sondern die schonungslose Auswertung eurer Berechtigungslandschaft. Aufräumen gehört vor die Freigabe, nicht danach.
Token, Fristen und was die Nutzer davon merken
Ein Detail für die Betriebsplanung: Die Verbindung hält nicht ewig von allein. Zugangstoken laufen im Bereich einer guten Stunde ab und werden automatisch erneuert, das merkt niemand. Das dahinterliegende Erneuerungstoken verfällt dagegen nach längerer Inaktivität — voreingestellt sind 90 Tage —, und dann muss sich die Person erneut anmelden. Über eine Richtlinie im Verzeichnis lässt sich diese Frist an eure Vorgaben anpassen. Praktisch heißt das: Gelegenheitsnutzer werden alle paar Monate zur Neuanmeldung gebeten, was regelmäßig als Störung gemeldet wird und keine ist. Ein Satz in der Anleitung erspart euch diese Tickets.
Abb.: Die Berechtigungs-Kette — vier Tore, ihre Zuständigen und die Grenzen des Konnektors.
|
INFO Die Suche ist tenantweit — das ist Absicht Weil die zugrunde liegende SharePoint-Suche über den gesamten Tenant arbeitet, gibt es keine Freigabe „nur für diese eine Website“. Die Eingrenzung passiert über die Berechtigungen der Nutzer und über die Zuweisung der Anwendung an bestimmte Gruppen — nicht über eine Auswahl von Sites im Konnektor. Wer das im Sicherheitskonzept anders geplant hatte, sollte an dieser Stelle umplanen statt diskutieren. |
|---|
Schreibrechte: ein eigener Beschluss
Standardmäßig ist die Anbindung lesend. Schreibende Werkzeuge sind ein zusätzlicher Schritt: Sie müssen freigeschaltet werden, und im Verzeichnis müssen die entsprechenden Schreibberechtigungen erteilt sein. Organisationen, die den Konnektor schon vor der Einführung der Schreibfunktionen genutzt haben, bleiben ausdrücklich blockiert, bis jemand aktiv zustimmt. Ist das erledigt, kann Claude E-Mails senden und weiterleiten, Entwürfe und Kategorien verwalten, Kalendereinträge anlegen und beantworten, Abwesenheitsnotizen setzen sowie Dateien in OneDrive und SharePoint anlegen und ändern — immer im Rahmen der Rechte der jeweiligen Person. Teams bleibt auch dann lesend.
Bemerkenswert sind die eingebauten Bremsen. Von Claude versendete Mails tragen eine Kennzeichnung, die sie als von einem Agenten ausgelöst ausweist. Für die heikelsten Aktionen — senden, weiterleiten, Termine anlegen oder ändern — gibt es kein dauerhaftes „immer erlauben“, es wird also jedes Mal bestätigt. Anhänge unterstützt keines der Schreibwerkzeuge, und pro Nutzer greifen Mengenbegrenzungen für Schreibvorgänge und Empfänger. Das nimmt dem Thema viel von seinem Schrecken, ersetzt aber keine Entscheidung.
|
WARNUNG Schreibrechte sind kein Nebeneffekt der Anbindung Zwischen „Claude darf unsere Ablage durchsuchen“ und „Claude darf im Namen unserer Leute Mails verschicken und Dateien überschreiben“ liegt ein ganzer Freigabevorgang. Trefft diese Entscheidung getrennt, dokumentiert sie getrennt und startet ohne Schreibrechte. Wenn nach vier Wochen niemand sie vermisst hat, war die Antwort ohnehin klar — und wenn doch, habt ihr dann echte Anwendungsfälle statt Vermutungen. |
|---|
Steuerung im laufenden Betrieb
Vier Hebel zum Einfangen
Für den Notfall und für den Alltag gibt es vier Ebenen. Einzelne Personen trennen ihre Verbindung selbst in den eigenen Einstellungen. Ein Owner schaltet den Konnektor für die ganze Organisation ab, dann kann niemand mehr verbinden. Im Verzeichnis lassen sich einzelne Berechtigungen gezielt entziehen — etwa der Zugriff auf Postfächer oder Teams-Chats, während der Rest weiterläuft. Und wer alles stoppen will, widerruft im Verzeichnis sämtliche Berechtigungen der Anwendung. Die letzten beiden wirken unmittelbar für alle.
Was ihr zusätzlich anwenden könnt
Weil die Anmeldung über euer Verzeichnis läuft, greifen eure bestehenden Regeln automatisch mit: Mehrfaktor-Anmeldung, Anforderungen an verwaltete Geräte, Begrenzung auf Firmennetz oder VPN, Zuweisung an bestimmte Sicherheitsgruppen. Genau diese Gruppenzuweisung ist auch der empfohlene Weg für einen Pilotbetrieb — Anwendung nur einer Testgruppe zuweisen, Erfahrungen sammeln, Gruppe erweitern. Und für den Nachweis: Jeder Abruf, den der Konnektor auslöst, erscheint im Auditprotokoll von Microsoft 365 mit Zeitstempel, Nutzer, Vorgang und angefasster Ressource; die Aufbewahrung folgt eurer eigenen Richtlinie.
Was in der Praxis schiefgeht
Vier Meldungen landen erfahrungsgemäß im Servicedesk, und alle vier sind keine Fehler. Erstens: „Ich sehe den Konnektor gar nicht.“ Dann ist er in der Organisation nicht freigegeben oder die Person ist der Anwendung im Verzeichnis nicht zugewiesen. Zweitens: „Die Anmeldung schlägt fehl.“ Häufig versucht jemand, sein privates Microsoft-Konto zu verwenden — das ist ausgeschlossen. Drittens: „Claude findet unsere Preisliste nicht.“ In den meisten Fällen darf die fragende Person die Datei tatsächlich nicht öffnen; der Konnektor bildet nur ab, was ohnehin gilt. Und viertens die Erwartung, dass etwas automatisch passiert, sobald ein Dokument abgelegt wird: Der Konnektor antwortet auf Fragen, er überwacht keine Ablagen. Wer Ereignissteuerung braucht, baut sie über die Schnittstelle, nicht über den Chat.
Abb.: Vier Hebel zum Einfangen des Zugriffs — plus Pilotweg und Nachweisspur.
|
WARNUNG Was aus dem Konnektor kommt, bleibt im Chat Die Inhalte werden zwar nur zur Laufzeit geholt, aber Abrufergebnisse, die in einem gespeicherten Chat landen, bleiben dort auch stehen. Wer einen solchen Verlauf teilt, gibt zwar nicht die Rohtreffer weiter — die sieht nur die anfragende Person —, wohl aber Claudes Antwort mitsamt allem, was daraus übernommen wurde. Für eure Nutzungsregel heißt das: Chats mit vertraulichen Treffern sind selbst vertrauliche Dokumente und gehören in eure Aufbewahrungsregelung. |
|---|
Über Microsoft hinaus: eigene MCP-Server
Der Microsoft-365-Konnektor ist nur der bekannteste Eintrag in einem Katalog. Dasselbe Protokoll trägt Konnektoren zu anderen Systemen — und, für Unternehmen der eigentlich interessante Teil, zu euren eigenen. Ein selbst betriebener Server nach diesem Standard hängt Claude an das ERP, das Ticketsystem oder die Fachanwendung, für die es nie einen fertigen Konnektor geben wird. Freigegeben wird auf Organisationsebene durch einen Owner, verbunden anschließend von jedem Nutzer mit dem eigenen Konto.
Vor jeder Freigabe — fremd oder selbst gebaut — gehören drei Fragen beantwortet: Welche Daten verlassen dabei welchen Bereich? Bringt der Konnektor Schreibwerkzeuge mit, und braucht ihr sie? Und wer im Haus ist dafür zuständig, dass das in einem Jahr noch stimmt? Ein Konnektorenkatalog ohne Eigentümer ist nach zwölf Monaten dasselbe wie eine Berechtigungslandschaft ohne Eigentümer: gewachsen, unübersichtlich und niemandes Schuld.
Wann sich ein eigener Konnektor lohnt
Die Versuchung ist groß, für jedes System sofort einen eigenen Konnektor zu bauen. Nüchtern betrachtet lohnt sich das erst, wenn drei Bedingungen zusammenkommen: Die Daten liegen strukturiert genug vor, dass eine Suche darauf sinnvoll ist; es gibt mehr als eine Handvoll Menschen, die regelmäßig danach fragen; und es existiert jemand, der die Schnittstelle im Betrieb pflegt. Fehlt eine dieser Bedingungen, ist ein wöchentlicher Export in eine Ablage, die der vorhandene Konnektor ohnehin durchsucht, die ehrlichere Lösung — unspektakulär, aber in sechs Monaten noch funktionsfähig.
|
PRAXIS-TIPP Erst eine Gruppe, dann das Haus — und mit einer echten Frage testen Weist die Anwendung im Verzeichnis zunächst einer Sicherheitsgruppe aus zehn bis fünfzehn Leuten zu und lasst sie eine Woche lang echte Fragen stellen, nicht Demoszenarien. Zwei Dinge lernt ihr dabei zuverlässig: wie gut eure Ablage tatsächlich strukturiert ist und welche Bibliotheken zu weit geteilt sind. Beides erfahrt ihr lieber von der eigenen Testgruppe als vom Betriebsrat. |
|---|
Häufige Fragen (FAQ)
Kann Claude auf unser SharePoint zugreifen?
Ja — über den Microsoft-365-Konnektor kann Claude SharePoint, OneDrive, Outlook samt Kalender und Teams-Chats durchsuchen und lesen. Voraussetzung sind drei Freigaben: die Aktivierung in der Claude-Organisation durch einen Owner, die einmalige Zustimmung eines globalen Administrators im Verzeichnis und die persönliche Anmeldung jedes Nutzers. Was Claude dabei sieht, entspricht exakt den Berechtigungen der angemeldeten Person.
Wie richten wir den Microsoft-365-Konnektor ein?
In der Claude-Organisation unter den Konnektoren den Microsoft-365-Konnektor hinzufügen, anschließend die Zustimmung im Verzeichnis durch einen globalen Administrator erteilen lassen; danach verbinden die Nutzer ihre eigenen Konten. Für einen kontrollierten Start weist ihr die Anwendung im Verzeichnis zunächst nur einer Sicherheitsgruppe zu. Schreibende Werkzeuge sind ein separater Schritt und bleiben bis dahin abgeschaltet.
Sieht Claude mehr als der einzelne Mitarbeiter?
Nein — der Konnektor arbeitet ausschließlich mit delegierten Rechten, es gibt kein Dienstkonto mit erweitertem Zugriff. Claude sieht damit genau das, was die angemeldete Person ohnehin öffnen könnte. Der praktische Haken ist die Umkehrung dieses Satzes: Alles, was zu weit geteilt wurde, ist ab sofort per natürlicher Sprache auffindbar — deshalb gehört ein Berechtigungscheck vor die Freigabe.
Kann Claude E-Mails senden oder Dateien ändern?
Nur wenn ihr Schreibwerkzeuge ausdrücklich freischaltet und im Verzeichnis die entsprechenden Berechtigungen erteilt sind; ohne das ist die Anbindung rein lesend. Mit Schreibrechten kann Claude Mails senden und organisieren, Entwürfe und Termine verwalten sowie Dateien in OneDrive und SharePoint anlegen und ändern — Teams bleibt lesend. Versandte Mails sind als von einem Agenten ausgelöst gekennzeichnet, Anhänge sind ausgeschlossen, und für die kritischen Aktionen ist jedes Mal eine Bestätigung nötig.
Wie sehen wir, was Claude abgerufen hat?
Alle Abrufe des Konnektors erscheinen im Auditprotokoll von Microsoft 365 — mit Zeitstempel, Nutzer, Vorgang und angefasster Ressource, aufbewahrt nach eurer bestehenden Richtlinie. Zusätzlich protokolliert Anthropic Anmeldungen und Werkzeugaufrufe auf seiner Seite. Für die Revision heißt das: Die Nachweisspur liegt dort, wo eure Auditoren ohnehin hinschauen, und muss nicht separat aufgebaut werden.
Weiterlesen
Wie Claude im Unternehmen insgesamt aufgesetzt wird — Lizenzen, Identität, Datenschutz und das Zusammenspiel mit Microsoft — steht im Überblick Claude im Unternehmen. Wenn ihr die Anbindung sauber aufsetzen wollt — inklusive Berechtigungscheck vor der Freigabe: In der Beratung zu Claude und KI-Governance gehen wir Freigabekette, Pilotgruppe und Konnektorenkatalog gemeinsam durch.