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 kennt MCP genau zwei offizielle Wege, daran hat auch die neue Fassung nichts geändert. 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 Streamable HTTP angesprochen, bei dem jede Nachricht als HTTP-Anfrage an einen einzigen Endpunkt geht. Der ältere Weg über eine dauerhaft offene SSE-Verbindung gilt seit der Juli-Fassung als überholt und läuft aus. Für Unternehmen ist die Unterscheidung lokal gegen remote der wichtigste technische Punkt überhaupt, denn sie entscheidet über das Sicherheitsmodell.

Die Spezifikation vom 28. Juli 2026 hat den Kern des Protokolls dabei spürbar umgebaut, und zwar in eine Richtung, die für Firmennetze praktisch ist. Früher meldete sich ein Client mit einem initialize-Handshake an und bekam eine Sitzungs-ID, die jede weitere Anfrage mitschleppen musste. Das ist entfallen: Jede Anfrage steht jetzt für sich und trägt Protokollversion und Rechte selbst mit sich. Dadurch kann ein beliebiger Server hinter einem Lastverteiler antworten, ohne dass die Beteiligten sich einen gemeinsamen Sitzungsspeicher teilen. Für eure IT noch wichtiger: Streamable HTTP spiegelt die wichtigsten Angaben zusätzlich in HTTP-Header, damit Gateways und Web Application Firewalls den Verkehr steuern, zählen und protokollieren können, ohne den Nachrichteninhalt auszupacken. Wer MCP-Zugriffe bisher nicht sauber ins Monitoring bekommen hat, hat damit einen Ansatzpunkt.

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.

Genau an dieser Stelle hat die Juli-Fassung nachgeschärft. Der Autorisierungsserver muss jetzt seine eigene Kennung mitschicken, und der Client prüft sie, bevor er einen Code einlöst. Das schließt eine Angriffsvariante, bei der ein untergeschobener Server den Berechtigungsnachweis eines anderen abfängt. Zusätzlich sind Zugangsdaten fest an den ausstellenden Autorisierungsserver gebunden, und die frühere dynamische Client-Registrierung ist abgekündigt, an ihre Stelle treten hinterlegte Client-Metadaten. Der praktische Nutzen für ein Unternehmen: Der Autorisierungsweg von MCP nähert sich dem an, was eure Identitätsverwaltung für andere Anwendungen längst tut, und muss weniger als Sonderfall behandelt werden.

Was Claude Team- und Enterprise-Admins konkret einstellen

Für Unternehmen, die Claude über Team oder Enterprise nutzen, gehört MCP auf den Tisch der Administration. Organisations-Admins legen unter Organisationseinstellungen fest, welche Connectoren für die gesamte Organisation überhaupt sichtbar und nutzbar sind, einzelne Mitarbeitende können nicht auf eigene Faust einen neuen Connector aktivieren. Wer im Team-Plan keine Berechtigung dafür hat, sieht im Verzeichnis statt der Verbinden-Schaltfläche eine Anfrage-Schaltfläche. Die Anfrage landet bei den Admins, sichtbar sowohl in den Connector-Einstellungen als auch im Benachrichtigungsbereich mit Zähler, und wird dort freigegeben oder abgelehnt. Damit habt ihr einen dokumentierten Weg statt eines Zurufs im Flur.

Ein Punkt daran wird in der Praxis regelmäßig falsch verstanden, und er ist wichtiger als jede Zahl im Verzeichnis. Das Verzeichnis ist kein Gütesiegel für alle Einträge. Anthropic vergibt zwei Labels: Geprüfte Connectoren hat das Unternehmen selbst auf Qualität und Sicherheit durchgesehen, sie tragen ein Häkchen. Community-Connectoren stammen von Drittentwicklern, haben nur die automatisierten Prüfungen durchlaufen und sind ausdrücklich nicht im Detail begutachtet worden. Claude blendet vor dem Verbinden einen entsprechenden Hinweis ein. Technisch verhalten sich beide identisch, sobald sie einmal verbunden sind, das Label sagt also nur etwas über die Prüftiefe aus. Wer eine Freigabeliste aufsetzt, sollte deshalb nach dem Label filtern und nicht nach der Verzeichnis-Zugehörigkeit. Eine belastbare Gesamtzahl der Einträge veröffentlicht Anthropic übrigens nicht, kursierende Angaben von einigen hundert bis über tausend zählen unterschiedliche Bestände zusammen, deshalb steht hier keine.

Wer schon Claude Team gegen Claude Enterprise abgewogen hat, kennt das Muster: Bei den Connector-Rechten unterscheiden sich die Pläne vor allem in der Verwaltungstiefe. Mit Enterprise-verwalteter Authentifizierung 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. Auf Protokollebene ist dieses Verfahren seit Juni 2026 als stabile Erweiterung verabschiedet und in der Juli-Spezifikation offiziell verankert, getragen unter anderem von Anthropic, Microsoft und Okta.

In Claude selbst steckt die Funktion allerdings weiterhin im Beta-Status für Team- und Enterprise-Pläne, und sie deckt bisher nur einen kleinen Kreis ab: bereitstellen lassen sich damit derzeit Asana, Atlassian, Canva, Figma, Granola, Linear und Supabase, Slack ist angekündigt. Als Identitätsanbieter wird zum Start Okta unterstützt, weitere sollen folgen. Für die Planung heißt das: Rechnet für alles außerhalb dieser Liste vorerst weiter mit einer Anmeldung je Mitarbeitendem. 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.

Was die Messungen im Sommer 2026 ergeben haben

Seit dem Frühjahr ist aus der Einzelbeobachtung eine Datenlage geworden, und die fällt unangenehm aus. Eine Erhebung mehrerer Forschungsgruppen vom 31. Juli 2026 hat das offene Internet nach MCP-Servern abgesucht und über 21.000 erreichbare Instanzen gefunden. 640 davon haben die Forscher aktiv durchgetestet. Das Ergebnis: 91,8 Prozent dieser Server hatten überhaupt keine OAuth-Authentifizierung vorgeschaltet, jeder konnte also einfach anfragen. In 687 Fällen boten die Server ein Werkzeug zur Ausführung von Shell-Befehlen an, ohne jede Zugriffsbeschränkung. Dazu kamen 68 meldepflichtige Schwachstellen, von SQL-Injection über Angriffe auf Cloud-Metadaten bis zu Pfad-Manipulationen.

Eine Zahl aus derselben Erhebung sagt mehr über den Umgang mit MCP als jede Schwachstellenliste: 41,6 Prozent der bestätigten Server waren binnen drei Tagen wieder verschwunden. Da laufen also massenhaft kurzlebige Installationen, die jemand schnell hochzieht und wieder vergisst. Genau dieses Muster produziert die Schatten-IT, die ihr später niemandem zuordnen könnt. Wenn in eurem Haus jemand experimentiert, gehört das auf einen von der IT verwalteten Server, mit Ablaufdatum und Eintrag in einer Liste.

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 steckte 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. An dieser Stelle scheitern die meisten Einführungen: Die Technik läuft, aber niemand hat vorher festgelegt, 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 statt über den Laptop einer einzelnen Fachabteilung. Denselben Governance-Reflex braucht jede neue SaaS-Anbindung ohnehin, hier trifft er nur eine neue Protokoll-Ebene.

Der konkrete nächste Schritt, wenn ihr Claude bereits im Team- oder Enterprise-Plan nutzt: Öffnet die Organisationseinstellungen unter Connectors und geht die aktuell freigegebene Liste einmal durch. Prüft bei jedem Eintrag, ob er das Prüfsiegel trägt oder als Community-Connector läuft, und ob die vergebenen Berechtigungen für den tatsächlichen Zweck nötig sind. Was niemand mehr benutzt, fliegt raus. Das ist eine halbe Stunde Arbeit und beantwortet die Frage, die im Ernstfall zuerst gestellt wird: Wer hatte über welchen Connector Zugriff auf welche Daten.

Celina Finger

Content Strategist, Collective Brain GmbH · Hamburg

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

Beratung anfragen