MCP erklärt: wie Claude sicher an deine Firmensysteme andockt

Ein Vertriebsleiter tippt in Claude: “Zeig mir alle Deals aus dem CRM, die diese Woche verfallen, und trag die Nachfass-Termine gleich in den Kalender ein.” Damit das ohne Copy-paste zwischen drei Programmen funktioniert, muss Claude wissen, wie es mit dem CRM und dem Kalender spricht. Genau dafür wurde das Model Context Protocol gebaut, kurz MCP. Wer 2026 über KI-Einführung im Unternehmen entscheidet, stolpert über die drei Buchstaben ständig, oft ohne dass jemand erklärt, was dahintersteckt und wo die Stolperfallen liegen.

Jede Anbindung braucht einen definierten Port, keinen wilden Kabelsalat. Genau das leistet MCP auf der Protokoll-Ebene für Claude. Foto: Brett Sayles auf Pexels

Das Grundproblem, das MCP löst

Wer sich generell erst noch einen Überblick über Claude im Unternehmenseinsatz verschaffen will, findet dort den Einstieg, dieser Artikel geht gezielt auf die Anbindungsschicht ein. Vor MCP musste jede Verbindung zwischen einem KI-Modell und einem externen System einzeln programmiert werden. Ein Entwickler, der Claude an Salesforce anbinden wollte, schrieb eine Integration. Ein anderer, der Claude an eine interne PostgreSQL-Datenbank anbinden wollte, schrieb eine zweite, komplett andere Integration. Bei zehn Systemen und drei KI-Anbietern ergab das schnell dreißig Einzellösungen, die alle gepflegt werden mussten, sobald sich eine API änderte.

MCP löst das, indem es die Schnittstelle standardisiert, nicht das System dahinter. Ein MCP-Server für Salesforce spricht dieselbe Protokollsprache wie ein MCP-Server für eine interne Datenbank. Claude muss dadurch nicht für jedes System neu lernen, wie eine Anfrage aussieht, sondern versteht das Protokoll einmal und kann es auf beliebige angebundene Systeme anwenden. Wer schon mit No-Code-Automatisierungstools wie n8n oder Make gearbeitet hat, kennt das Prinzip aus einer anderen Ecke: eine gemeinsame Verbindungsschicht statt hundert Einzelintegrationen.

Wie die Verbindung technisch abläuft

MCP arbeitet mit drei Rollen: dem Host, also der Anwendung, in der Claude läuft, dem Client, der die eigentliche Verbindung hält, und dem Server, der Zugriff auf ein konkretes System wie ein CRM oder eine Dateiablage bereitstellt. Wenn du in Claude nach offenen Rechnungen fragst, schickt der Client eine strukturierte Anfrage an den passenden MCP-Server, der Server holt die Daten aus dem angebundenen System und schickt eine strukturierte Antwort zurück. Claude selbst hat zu keinem Zeitpunkt einen direkten, ungefilterten Zugriff auf die Datenbank dahinter, es sieht nur das, was der Server ihm bewusst zur Verfügung stellt.

Bei der eigentlichen Übertragung unterscheidet MCP zwei Wege. Lokale Server laufen über den sogenannten STDIO-Transportweg direkt auf dem Rechner oder Server, auf dem auch der Client läuft, die Kommunikation passiert über simple Ein- und Ausgabe-Kanäle. Remote-Server laufen dagegen als eigenständiger Dienst irgendwo im Netz und werden über HTTP angesprochen, meist zusätzlich abgesichert über eine Streaming-Verbindung für laufende Antworten. Für Unternehmen ist genau diese Unterscheidung der wichtigste technische Punkt, denn sie entscheidet über das Sicherheitsmodell.

Auth ist der Bereich von MCP, der sich am stärksten weiterentwickelt hat, und er ist die zentrale Sorge jeder Organisation, die das Protokoll einführt.

— WorkOS, Analyse zu MCP-Authentifizierungsanbietern, 2026

Remote-MCP-Server, die über das Internet erreichbar sind, müssen laut Protokoll-Spezifikation OAuth 2.1 mit PKCE implementieren, dem heute üblichen Standard für sichere Autorisierung ohne fest hinterlegte Passwörter. Praktisch bedeutet das: Statt eines geteilten API-Schlüssels bekommt jede Nutzerin und jeder Nutzer einen kurzlebigen, eng begrenzten Zugriffstoken, der sich jederzeit widerrufen lässt, ohne dass gleich das ganze System neu konfiguriert werden muss.

Was Claude Team- und Enterprise-Admins konkret einstellen

Für Unternehmen, die Claude über Team oder Enterprise nutzen, ist MCP keine Bastelaufgabe für einzelne Mitarbeitende, sondern eine Admin-Entscheidung. Im offiziellen Connector-Verzeichnis stehen inzwischen über 75 vorgeprüfte Anbindungen, von Google Workspace über Microsoft 365 bis zu spezialisierten Business-Tools. Organisations-Admins legen unter Organisationseinstellungen fest, welche dieser Connectoren für die gesamte Organisation überhaupt sichtbar und nutzbar sind, einzelne Mitarbeitende können nicht auf eigene Faust einen neuen Connector aktivieren.

Wer schon Claude Team gegen Claude Enterprise abgewogen hat, kennt das Muster: Auch bei den Connector-Rechten liegt der Unterschied nicht im Kernfunktionsumfang, sondern in der Verwaltungstiefe. Mit Enterprise-verwalteter Authentifizierung, aktuell im Beta-Status, autorisiert ein Admin einen Connector einmal zentral für die gesamte Organisation, und neue Teammitglieder erben den Zugriff automatisch bei der ersten Anmeldung, ohne dass jeder Einzelne seinen eigenen OAuth-Flow durchlaufen muss. Bei verifizierten Domain-Connectoren lässt sich der Zugriff zusätzlich auf die eigene Unternehmensdomain beschränken, sodass ein Connector nicht versehentlich mit einem privaten Konto verknüpft wird.

Die Sicherheitslücke, über die 2026 gesprochen wurde

Im April 2026 veröffentlichten Sicherheitsforscher von OX Security eine Untersuchung, die in der Branche für Aufsehen sorgte. Ihr Befund: Der STDIO-Transportweg von MCP, also die lokale Variante ohne Netzwerk-Autorisierung, reicht in vielen Implementierungen Eingaben ungeprüft an die Kommandozeile durch. Wird ein Server so aufgerufen, dass Nutzereingaben direkt in einen Kommandozeilen-Befehl eingebettet werden, lässt sich darüber unter Umständen beliebiger Code ausführen. Die Forscher fanden mehr als 7.000 öffentlich erreichbare Server mit aktivem STDIO-Transport und schätzten die Gesamtzahl potenziell betroffener Installationen auf bis zu 200.000, verteilt über ein Ökosystem mit über 150 Millionen SDK-Downloads. Aus der Untersuchung gingen über zehn CVE-Einträge für konkrete Projekte wie LiteLLM, LangFlow und Flowise hervor.

Anthropic selbst hat auf die Untersuchung reagiert, aber nicht mit einer Protokolländerung. Das Unternehmen stuft das Verhalten des STDIO-Transports als bewusste Design-Entscheidung ein, vergleichbar mit einem lokalen Kommandozeilenprogramm, und sieht die Pflicht zur Eingabe-Bereinigung bei den Entwicklern der jeweiligen Server, nicht im Protokoll selbst. Für Unternehmen heißt das praktisch: Wer einen MCP-Server aus einer offiziellen, geprüften Quelle wie dem Claude-Connector-Verzeichnis nutzt, bewegt sich in einem kontrollierten Rahmen. Wer dagegen einen selbst gebauten oder aus einem unbekannten GitHub-Repository heruntergeladenen MCP-Server lokal auf einem Firmenrechner startet, importiert damit potenziell auch dessen Schwachstellen, ganz ohne dass Claude selbst daran etwas ändert.

Praktische Einordnung für die eigene IT-Entscheidung

Für ein mittelständisches Unternehmen, das MCP-Connectoren einführen will, lohnt sich eine klare Reihenfolge. Zuerst das offizielle Verzeichnis prüfen, ob der gewünschte Anbieter schon einen geprüften Connector anbietet, wie es etwa bei NetSuite mit seinen ERP-Anbindungen bereits umgesetzt hat. Erst wenn dort nichts Passendes existiert, kommt ein selbst betriebener MCP-Server infrage, und dann idealerweise als Remote-Server mit eigener OAuth-Registrierung statt als lokaler STDIO-Prozess auf einem Mitarbeitendenrechner. Für jedes angebundene System empfiehlt sich außerdem ein eigener, eng begrenzter Zugriffstoken statt eines gemeinsamen Zugangs für mehrere Systeme gleichzeitig, damit ein kompromittierter Connector nicht automatisch die Tür zu allen anderen aufstößt.

Ein Beispiel aus der Praxis: von der Tabelle zur Anbindung

Ein Beispiel macht den Unterschied greifbar. Ein Steuerberatungsbüro mit vierzig Beschäftigten nutzte Claude zunächst nur im Browser, für Textentwürfe und Recherche, während Mandantendaten weiter in DATEV lagen und für jede Auswertung manuell exportiert wurden. Nach der Einführung eines geprüften DATEV-Connectors aus dem offiziellen Verzeichnis konnte ein Sachbearbeiter Claude direkt fragen, welche Fristen in den nächsten zwei Wochen anstehen, ohne vorher eine Exportdatei zu erzeugen und wieder hochzuladen. Der Wechsel selbst dauerte einen Nachmittag: Ein Admin gab den Connector in den Organisationseinstellungen frei, das Team meldete sich beim ersten Aufruf einmal über den hinterlegten Identity Provider an, und ab da lief die Anbindung, ohne dass jemand Code schreiben musste.

Der eigentliche Aufwand lag nicht in der technischen Einrichtung, sondern in der Entscheidung davor: Welche Mandantendaten darf Claude überhaupt sehen, und welche Auswertungen bleiben bewusst außen vor. Diese Frage beantwortet kein Connector automatisch, sie gehört in die interne Richtlinie, bevor der erste Zugriff freigeschaltet wird. Genau an dieser Stelle scheitern viele Einführungen in der Praxis nicht an der Technik, sondern daran, dass niemand vorher festgelegt hat, wer die Freigabe verantwortet.

Was IT-Teams vor der Einführung klären sollten

Vier Fragen tauchen in nahezu jedem Einführungsprojekt auf, unabhängig von der Unternehmensgröße. Welche Systeme sollen überhaupt angebunden werden, und gibt es dafür bereits einen geprüften Connector im offiziellen Verzeichnis, oder muss ein Anbieter erst einen eigenen MCP-Server bereitstellen? Wer in der Organisation darf neue Connectoren freigeben, und ist das an eine Person gebunden oder an eine Rolle, damit die Freigabe auch bei Urlaub oder Kündigung weiterläuft? Welche Rechte braucht der Zugriff tatsächlich, reines Lesen oder auch Schreiben, und lässt sich das im jeweiligen Connector überhaupt getrennt einstellen? Und schließlich: Wo laufen selbst gehostete MCP-Server, falls kein offizieller Connector existiert, auf einem von der IT verwalteten Server oder auf dem Rechner einer einzelnen Fachabteilung?

Die letzte Frage ist in der Praxis die häufigste Fehlerquelle. Fachabteilungen, die schnell eine Anbindung brauchen, greifen gerne zu einem selbst gehosteten MCP-Server aus einer Anleitung oder einem GitHub-Repository, weil das offizielle Verzeichnis das gewünschte System noch nicht abdeckt. Genau das ist die Konstellation, in der die STDIO-Schwachstelle aus dem vorigen Abschnitt relevant wird, weil ein unbeaufsichtigt installierter lokaler Server selten dieselbe Sorgfalt bei der Eingabeprüfung erhält wie ein von einem etablierten Anbieter gepflegter Connector.

Die Datenschutz-Seite bleibt davon unberührt und läuft parallel: Wie wir bei der DSGVO-konformen Claude-Einführung eingeordnet haben, regelt ein MCP-Connector nicht automatisch, welche Daten wie lange gespeichert werden. Das bleibt Sache des jeweiligen Auftragsverarbeitungsvertrags mit Anthropic und, falls der Connector ein Drittsystem anbindet, zusätzlich Sache des Vertrags mit diesem Anbieter. MCP regelt den technischen Zugriffsweg, nicht die rechtliche Verantwortung dahinter.

Für die IT-Abteilung heißt das in der Praxis: eine kurze, aber verbindliche interne Richtlinie, welche Connectoren aus dem offiziellen Verzeichnis freigegeben sind, wer neue Anfragen prüft, und dass selbst gehostete MCP-Server grundsätzlich über die IT laufen, nicht über den Laptop einer einzelnen Fachabteilung. Das ist kein Sonderaufwand, den MCP verursacht, sondern derselbe Governance-Reflex, den jede neue SaaS-Anbindung ohnehin braucht, nur eben auf eine neue Protokoll-Ebene angewendet.

Celina Finger

Content Strategist, Collective Brain GmbH · Hamburg

Content Strategist bei Collective Brain. Spezialisiert auf B2B-Content für den Mittelstand.

Beratung anfragen