Sicherheit und Berechtigungen bei MCP

Einen KI-Assistenten an das eigene ERP zu lassen, klingt zunächst nach einer weitreichenden Entscheidung. Sie ist es weniger, als sie klingt – weil MCP an keiner Stelle neue Zugriffsmöglichkeiten schafft. Dieser Artikel zeigt, wo die Kontrollpunkte liegen.

Drei Schranken, nicht eine

Ein Zugriff über MCP muss drei unabhängige Hürden nehmen. Fällt eine davon, passiert nichts.

Ist der Zugang freigegeben? Jede MCP-Konfiguration trägt eine autorisierte Gruppe oder Person. Wer nicht dazugehört, kommt an der Adresse nicht vorbei – auch wenn er sie kennt.
Hat der Benutzer die Berechtigung erteilt? Beim ersten Verbinden fragt teamspace per OAuth, was der Client darf. Ohne diese Zustimmung gibt es keinen Zugriff.
Darf der Benutzer die Daten überhaupt sehen? Bei jedem einzelnen Aufruf gilt sein normales Berechtigungsprofil.

Die dritte Schranke ist die wichtigste, und sie ist nicht abschaltbar:

Ein MCP-Zugang kann nie mehr als der Mensch, der ihn benutzt. Die Werkzeugliste beschreibt, was ein Zugang anbieten kann – nicht, wer damit was zu sehen bekommt. Das entscheidet allein das Berechtigungsprofil des angemeldeten Benutzers, exakt wie in der Oberfläche.

Konkret: Zwei Personen verbinden denselben Zugang, stellen dieselbe Frage – und bekommen unterschiedliche Antworten, wenn sie unterschiedliche Rechte haben. Das ist kein Fehler, sondern der Kern des Entwurfs. Es bedeutet auch, dass du Berechtigungen nicht doppelt pflegst: Was in Berechtigungen geregelt ist, gilt über MCP automatisch mit.

Was die Werkzeugauswahl leistet – und was nicht

Ein häufiges Missverständnis: Die Auswahl der Werkzeuge sei eine Sicherheitseinstellung. Ist sie nicht.

Was sie ist: ein Zuschnitt auf den Anwendungsfall. Weniger Werkzeuge heißt schneller und treffsicherer – siehe Wie MCP in teamspace funktioniert.
Was sie nicht ist: eine Zugriffsbeschränkung. Ein Werkzeug wegzulassen verhindert nicht, dass jemand die Daten sieht – er sieht sie eben in der Oberfläche oder über einen anderen Zugang.

Willst du wirklich verhindern, dass jemand etwas sieht, gehört das ins Berechtigungsprofil, nicht in die Werkzeugliste.

Trotzdem lohnt sich Sorgfalt bei der Auswahl, und zwar aus einem anderen Grund: Schreibende Werkzeuge. Ein Assistent kann sich vertun, und er hat kein Gefühl dafür, ob eine Änderung folgenreich war. Es ist deshalb üblich:

Der allgemeine Zugang für alle bekommt nur lesende Werkzeuge.
Schreibende Werkzeuge kommen in einen eigenen Zugang, der enger freigegeben ist.
Heikle Bereiche (Personal, Finanzen) bekommen ihren eigenen Zugang für ihre eigene Abteilung.

Die OAuth-Berechtigung verstehen

Beim ersten Verbinden zeigt teamspace eine Zustimmungsseite. Sie ist der Moment, in dem der Benutzer entscheidet – und der einzige, in dem er die Details zu Gesicht bekommt. Deshalb lohnt es, sie zu lesen statt wegzuklicken.

Sie nennt drei Berechtigungen:

Berechtigung	Kennzeichnung	Was sie erlaubt
MCP-Server lesen	`READ`	Die verfügbaren Werkzeuge und Ressourcen auflisten. Ohne dies weiß der Client nicht, was es gibt.
Tools aufrufen	`READ & EXECUTE`	Die konfigurierten Werkzeuge tatsächlich ausführen.
Daten schreiben	`WRITE`	Über den MCP-Server Daten schreiben.

Außerdem zeigt die Seite:

Anwendungsidentität – wer sich da registriert hat und wann er erstmals gesehen wurde. Bei einem Client wie Claude ist das ein dynamisch registrierter Client: Er hat sich automatisch angemeldet, ohne dass ein Administrator ihn vorher eingetragen hat. Der gelbe Hinweis auf der Seite fordert genau deshalb dazu auf, die angeforderten Berechtigungen und die Redirect-URI zu prüfen.
Die Weiterleitungsadresse – wohin der Benutzer nach der Zustimmung geschickt wird, z. B. https://claude.ai/api/mcp/auth_callback. Das ist der wichtigste Prüfpunkt der ganzen Seite: Die Domain muss zu dem Dienst passen, den du gerade berechtigen willst. Steht dort etwas anderes als erwartet, brich ab.
Die MCP-Konfiguration, die berechtigt wird – so siehst du, welchen Zugang du gerade freigibst.
Eine Bestätigungs-Checkbox, die aktiv angehakt werden muss, bevor „Erlauben” greift.

Erkläre deinen Anwendern diese Seite. Sie ist der einzige Punkt, an dem ein Mensch prüft, ob die Weiterleitung stimmt – technisch lässt sich das nicht abnehmen. Ein Satz in der Einführungsmail spart später Ärger.

Was ein Administrator im Blick behält

Konfiguration → Schnittstellen

Diese Kategorie enthält neben den MCP Konfigurationen mehrere Kacheln, die zusammengehören:

OAuth-Clients – welche Anwendungen sich registriert haben.
OAuth-Berechtigungen (Audit) – wer wann welchem Client was erlaubt hat. Der erste Ort, an dem du nachsiehst, wenn du wissen willst, wer teamspace mit welchem Assistenten verbunden hat.
Mandanten-Client-Policies – die Vorgaben, welche Clients im Mandanten überhaupt zulässig sind.
OAuth-Servereinstellungen – die Grundeinstellungen des OAuth-Servers.

In der Liste der OAuth-Clients siehst du je Eintrag den Anzeigenamen des Clients, seinen Typ, den Verifikationsstatus und die Scopes – also welche der drei Berechtigungen tatsächlich erteilt wurden. Dass dort mehrere Einträge desselben Assistenten stehen, ist normal: Jede neue Verbindung registriert sich einzeln.

Der Reiter OAuth-Clients mit einer Liste selbst registrierter Clients – Codex, Kilo, ChatGPT, MCP Inspector und Claude – je mit Typ (Public oder Confidential), Verifikationsstatus und den erteilten Scopes wie mcp:read, mcp:tool und mcp:write. Die Spalte Client-ID ist unkenntlich gemacht, weil sie Kennungen des Mandanten enthält. — Der Reiter „OAuth-Clients" mit den selbst registrierten Clients, ihrem Typ und den erteilten Scopes

Hinweise

Der Notausschalter ist das Feld „Aktiv”. Eine deaktivierte MCP-Konfiguration antwortet sofort nicht mehr – unabhängig davon, wer sie schon verbunden hat.
Rechte ändern wirkt sofort. Nimmst du jemandem in teamspace eine Berechtigung, ist sie auch über MCP weg. Der Konnektor muss dafür nicht angefasst werden.
Die Adresse ist kein Geheimnis, aber auch keine Einladung. Sie enthält eine lange Kennung, doch der Schutz liegt in der Freigabe und im Berechtigungsprofil – nicht in der Unkenntnis der URL.
Anderes OAuth, gleicher Name. teamspace nutzt OAuth auch für Microsoft-365-Mailkonten und Single Sign-on. Das sind eigene Einstellungen und haben mit MCP nichts zu tun – siehe Weitere Konfigurationen und Microsoft App-Registrierung.