Microsoft 365 Copilot Cowork mit internen Daten: Warum MCP-Plugins der fehlende Baustein sind

Ich habe Microsoft 365 Copilot Cowork in den letzten Monaten intensiv im Frontier-Modus verwendet. Mein Eindruck ist klar: Cowork verschiebt Copilot von einem Antwortsystem hin zu einem Arbeitsmodus. Man gibt nicht nur eine Frage ein. Man delegiert eine Aufgabe, lässt Zwischenschritte ausführen, Ergebnisse strukturieren und Zusammenhänge interpretieren.

Was mir dabei lange gefehlt hat, war der direkte Zugriff auf interne Systeme. In Microsoft 365 liegen viele Dokumente, Mails, Termine und Dateien. Aber die wirklich operative Wahrheit eines Unternehmens liegt oft woanders: in proprietären Anwendungen, Datenbanken, Fachsystemen, ERP-nahen Tabellen, Rechnungsdaten, Projektständen oder internen Auswertungen. Genau dort wird Cowork interessant, aber ohne Erweiterung auch begrenzt.

Der Mechanismus dafür sind Plugins. Cowork-Plugins können Skills, Connectors oder beides enthalten. Skills geben Cowork fachliche Arbeitsweisen und Spezialisierungen. Connectors verbinden Cowork mit externen Datenquellen und Diensten. In meinem Fall war der entscheidende Schritt ein Plugin, das aus einem Model-Context-Protocol-Server und einigen Skills besteht. Damit kann Cowork auf interne Daten zugreifen und diese in Aufgaben, Analysen und Auswertungen verwenden.

Architekturdiagramm eines Cowork Plugins mit Skills, Connector, MCP Server, Microsoft Entra OAuth und interner Datenbank. — Das Plugin ist die fachliche Brücke. Der MCP-Server ist die technische Brücke. Microsoft Entra ist die Sicherheitsgrenze.

Warum MCP hier so gut passt

MCP ist für diesen Anwendungsfall fast ideal, weil es nicht voraussetzt, dass interne Daten zuerst in einen globalen Index kopiert werden. Ein MCP-Server kann gezielte Tools bereitstellen: suchen, abrufen, zusammenfassen, filtern, berechnen oder eine fachliche Abfrage ausführen. Cowork kann diese Werkzeuge dann im richtigen Moment nutzen.

Das ist ein anderer Ansatz als „wir machen alle Daten irgendwie verfügbar“. Ein guter MCP-Server stellt nicht die Datenbank bloß. Er stellt fachliche Fähigkeiten bereit. Statt einer generischen SQL-Schnittstelle gibt es zum Beispiel ein Tool, das offene Vorgänge sucht, eine Kundenhistorie zusammenfasst, Belege nach Kriterien abruft oder Kennzahlen für einen Zeitraum aggregiert.

Der entscheidende Punkt: Cowork braucht keine Rohdatenflut. Cowork braucht gut beschriebene, sichere und fachlich sinnvolle Werkzeuge.

Der Knackpunkt war Authentifizierung

Der technische Teil eines MCP-Servers ist nicht das Schwerste. Tools definieren, Daten abrufen, JSON zurückgeben, Fehler behandeln: Das ist Arbeit, aber beherrschbar. Der Knackpunkt war für mich lange die Absicherung. Ein MCP-Server, der interne Daten verfügbar macht, darf nicht nur „irgendwie erreichbar“ sein. Er muss sauber prüfen, wer anfragt, welche Berechtigungen diese Person hat und welche Daten sie sehen darf.

Genau dort war die Dokumentation aus meiner Sicht lange nicht ausreichend konkret. Inzwischen ist das deutlich besser. Microsoft dokumentiert heute explizit, wie Authentifizierung für MCP- und API-Plugins in Microsoft 365 Copilot funktioniert. Für meinen Anwendungsfall war die entscheidende Variante OAuth 2.0 beziehungsweise Microsoft Entra als Identitäts- und Zugriffsschicht.

Praktisch bedeutet das: Cowork ruft den Connector nicht anonym auf. Der Zugriff läuft über einen Token-Kontext. Der MCP-Server validiert diesen Token, prüft Audience, Issuer, Benutzeridentität und gegebenenfalls Rollen oder Scopes. Danach entscheidet der Server, welche Tools ausgeführt werden dürfen und welche Daten zurückgegeben werden.

Wie ich ein solches Plugin denken würde

Die Implementierung besteht nicht aus einem einzelnen Baustein. Es sind mehrere Schichten, die sauber zusammenpassen müssen.

1. Fachliche Tool-Grenzen definieren Vor dem ersten Code muss klar sein, welche Fragen Cowork beantworten soll. Gute Tools sind fachlich geschnitten: suchen, abrufen, aggregieren, vergleichen, erklären. Schlechte Tools sind technische Rohzugriffe.

2. MCP-Server implementieren Der Server stellt Tools mit klaren Namen, Beschreibungen, Eingabeschemas und Rückgabeformaten bereit. Diese Beschreibungen sind wichtig, weil der Orchestrator daraus ableitet, wann ein Tool sinnvoll ist.

3. Microsoft Entra absichern Der Server akzeptiert nur gültige Tokens, prüft den erwarteten Empfänger und arbeitet mit Benutzerkontext. Gerade bei internen Daten ist das keine Zusatzfunktion, sondern die Voraussetzung.

4. Plugin und Skills beschreiben Die Skills erklären Cowork, welche Arbeitsweise das Plugin unterstützt. Der Connector liefert die Daten. Erst beides zusammen macht aus einem technischen Zugriff eine nutzbare Arbeitsfähigkeit.

5. Betrieb ernst nehmen Logging, Auditierbarkeit, Rate Limits, Fehlermeldungen und Datenminimierung sind Teil der Architektur. Ein produktiver MCP-Server ist keine Demo-API.

Implementierungspfad für ein Cowork MCP Plugin: Domäne, MCP Tools, Entra Auth, Skills, Tests, Betrieb und Nutzen. — Die Implementierung ist ein Zusammenspiel aus fachlicher Modellierung, sicherem Transport, Plugin-Beschreibung und Betrieb.

Was dadurch möglich wird

Der Effekt ist größer als „Copilot kann jetzt Daten nachschlagen“. Ein gut angebundenes Cowork-Plugin ermöglicht echte Arbeitsabläufe. Man kann Cowork zum Beispiel bitten, interne Daten für einen Zeitraum auszuwerten, Auffälligkeiten zu erklären, offene Punkte zu gruppieren, Abweichungen zu interpretieren oder eine Management-Zusammenfassung vorzubereiten.

Der Mehrwert entsteht dabei aus der Kombination: Der MCP-Server liefert verlässliche, aktuelle und berechtigte Daten. Cowork bringt die Stärken in Strukturierung, Interpretation, Formulierung und Aufgabenbearbeitung ein. Das Ergebnis ist nicht nur eine Tabelle, sondern eine verwertbare Einschätzung.

Ohne Plugin Cowork arbeitet hauptsächlich mit Microsoft-365-Kontext und dem, was im Gespräch bereitgestellt wird. Interne Fachsysteme bleiben außerhalb des Arbeitskontexts.

Mit MCP-Plugin Cowork kann gezielt interne Daten abfragen und diese in seine Arbeit einbeziehen. Die Abfrage bleibt kontrolliert, protokollierbar und benutzerbezogen.

Mit Skills Cowork versteht besser, wann und wie die Daten fachlich zu verwenden sind. Aus technischem Zugriff wird eine wiederholbare Arbeitsweise.

Was ich dabei nicht unterschätzen würde

Ein solches Plugin ist mächtig. Genau deshalb muss es eng gebaut werden. Ich würde keine generische Datenbankabfrage nach außen geben. Ich würde auch keine Werkzeuge bauen, deren Wirkung oder Datenumfang unklar ist. Gute Tools haben schmale Eingaben, klare Ergebnisformen und eine fachliche Begrenzung.

Wichtig ist außerdem, dass der MCP-Server die Sicherheit nicht an Cowork delegiert. Cowork ist der Nutzer des Werkzeugs, aber der Server bleibt verantwortlich für Zugriffskontrolle. Wenn ein Benutzer eine bestimmte Information im Fachsystem nicht sehen darf, darf sie auch über Cowork nicht sichtbar werden.

Mein Fazit

Für mich ist diese Kombination aus Cowork, Plugins, MCP und Microsoft Entra ein sehr konkreter Schritt in Richtung produktiver Unternehmensagenten. Es geht nicht mehr nur darum, dass KI Texte zusammenfasst oder Dokumente findet. Es geht darum, interne Systeme kontrolliert als Arbeitsfähigkeiten verfügbar zu machen.

Der MCP-Server ist dabei nicht einfach eine Schnittstelle. Er ist eine Sicherheits- und Fachlichkeitsgrenze. Die Skills machen daraus eine nutzbare Cowork-Erweiterung. Und Microsoft Entra sorgt dafür, dass interne Daten nicht aus dem Governance-Modell herausfallen.

Wenn das sauber umgesetzt ist, verändert sich der Nutzen von Cowork deutlich. Aus einem starken Assistenten wird ein Arbeitskollege, der interne Daten abfragen, auswerten, interpretieren und in konkrete Arbeitsergebnisse überführen kann. Genau an dieser Stelle wird das Konzept für mich richtig spannend.

Weiterführende Quellen

Microsoft 365 Copilot Cowork Model Context Protocol MCP Microsoft Entra OAuth2 Agentenarchitektur