Was ist das Model Context Protocol (MCP) – und warum ist es für die Datensicherheit von Unternehmen wichtig?

Wenn Ihr Unternehmen KI-Assistenten einsetzt – oder dies plant –, werden Sie auf das Model Context Protocol (MCP) stoßen. MCP ist der neue Standard, der festlegt, wie KI-Tools wie Claude und Microsoft Copilot mit Unternehmenssystemen wie Dateirepositorys, Wissensdatenbanken, Datenbanken und Geschäftsanwendungen verbunden werden.

Kurz gesagt: MCP ist die Infrastruktur, die KI im Unternehmenskontext nutzbar macht. Und wie bei jeder Infrastruktur bleibt sie unsichtbar, solange sie funktioniert – und wird zum Desaster, wenn nicht. Für CIOs, IT-Leiter und VP AI-Verantwortliche ist MCP kein Entwicklerdetail, sondern eine Entscheidung zur Daten-Governance, die bestimmt, ob die KI-Einführung im Unternehmen sicher, compliant und revisionssicher ist – oder eben keines davon.

Executive Summary

Kernaussage: Das Model Context Protocol entwickelt sich rasant zum Standard-Interface für die Anbindung von KI-Assistenten an Unternehmensdaten und -systeme. Wie ein Unternehmen MCP implementiert – und ob diese Implementierung Governance auf Enterprise-Niveau umfasst – entscheidet, ob KI-Einführung Mehrwert schafft oder Risiken erzeugt.

Warum das relevant ist: Die meisten MCP-Implementierungen am Markt sind auf Entwicklerfreundlichkeit ausgelegt, nicht auf Governance im Unternehmen. Unternehmen, die unkontrollierte MCP-Integrationen einsetzen, verbinden KI-Tools mit sensiblen Datenquellen – ohne Zugriffskontrollen, Audit-Trail oder Compliance-Dokumentation, wie sie regulierte Branchen verlangen. Die Entscheidung über Governance bei MCP muss vor der Einführung getroffen werden – nicht erst, wenn ein Sicherheitsvorfall oder eine Anfrage der Aufsicht die Notwendigkeit erzwingt.

5 Wichtige Erkenntnisse

1. MCP ist der neue Standard für die Integration von KI und Unternehmenssystemen und ermöglicht KI-Assistenten, über ein universelles Protokoll – statt individueller Punkt-zu-Punkt-Verbindungen – auf Unternehmensdaten zuzugreifen, Dateien hoch- und herunterzuladen, zu suchen und zu verwalten.
2. Das Protokoll selbst ist governance-neutral. Ein MCP-Server kann mit Zugriffskontrollen, Prüfprotokollen und Compliance-Mechanismen auf Enterprise-Niveau implementiert werden – oder ganz ohne diese Funktionen. Die Governance liegt nicht im Protokoll, sondern in der Umsetzung.
3. Unkontrollierte MCP-Implementierungen gewähren KI-Tools meist weitreichenden Zugriff auf verbundene Systeme über überprivilegierte Service-Accounts – ohne nutzerbezogene Autorisierung, ohne operationale Protokollierung und ohne Durchsetzung von Sensitivitätskennzeichnungen.
4. Enterprise-MCP-Governance erfordert mindestens sechs Kontrollen: OAuth 2.0-Authentifizierung mit außerhalb des KI-Kontexts gespeicherten Zugangsdaten, operationale RBAC- und ABAC-Autorisierung, Audit-Logging auf Attributionsniveau, Pfad- und Scope-Kontrollen, Rate Limiting und Sensitivitätslabel-Überprüfung.
5. Ein kontrollierter MCP-Server, der bestehende Data-Governance-Policies auf KI-Interaktionen ausweitet – statt eine separate KI-spezifische Governance-Infrastruktur zu verlangen – ist das Architekturmodell, das eine schnelle und gleichzeitig abgesicherte KI-Einführung im Unternehmen ermöglicht.

Was ist das Model Context Protocol und woher kommt es?

Das Model Context Protocol ist ein offener Standard, ursprünglich von Anthropic entwickelt, der definiert, wie KI-Assistenten mit externen Tools und Datenquellen kommunizieren. Vor MCP erforderte die Anbindung einer KI an ein Unternehmenssystem für jede Kombination aus KI-Tool und Datenquelle individuellen Integrationscode – ein fragmentierter, teurer Ansatz, der zu uneinheitlicher Sicherheit und hohem Wartungsaufwand führte.

MCP löst dieses Problem durch Standardisierung. Ein Unternehmen, das einen MCP-Server für ein Datenrepository bereitstellt, kann jedes MCP-kompatible KI-Tool ohne zusätzlichen Integrationsaufwand anbinden. Die KI fragt den MCP-Server nach verfügbaren Operationen, der Server beschreibt seine Fähigkeiten, und die KI nutzt diese, um mit den Daten zu interagieren. Aus architektonischer Sicht funktioniert MCP ähnlich wie USB die Geräteanbindung standardisiert hat – eine universelle Schnittstelle, die proprietäre Verbindungen zwischen jedem Gerätepaar überflüssig macht.

Das Protokoll wird in der KI-Branche schnell übernommen. Große KI-Plattformen wie Claude, Microsoft Copilot und ein wachsendes Ökosystem von Enterprise-KI-Tools unterstützen MCP bereits als native Integrationsmethode. Für IT-Verantwortliche im Unternehmen bedeutet diese Entwicklung: MCP ist kein aufkommendes Thema mehr, das man beobachten sollte – es ist ein Standard, den man jetzt steuern muss.

Wie MCP im Unternehmenskontext funktioniert

Eine MCP-Implementierung besteht in der Praxis aus drei Komponenten. Der KI-Client – etwa Claude, Copilot oder ein anderer MCP-kompatibler Assistent – ist die Schnittstelle, über die Nutzer mit ihren Daten interagieren. Der MCP-Server sitzt zwischen KI-Client und Datenrepository; er empfängt Anfragen der KI, prüft sie, führt erlaubte Operationen aus und liefert Ergebnisse zurück. Das Datenrepository ist das angebundene Unternehmenssystem – etwa ein Fileshare, eine Dokumentenmanagement-Plattform, eine Wissensdatenbank oder ein beliebiger Content Store.

Fordert ein Nutzer den KI-Assistenten auf, „den Henderson-Vertrag zu finden und mit der Rechtsabteilung zu teilen“, übersetzt die KI diese natürliche Sprache in eine Reihe von MCP-Operationen: Datei nach bestimmten Kriterien suchen, abrufen und eine Freigabeaktion initiieren. Jede dieser Operationen ist eine eigene Anfrage an den MCP-Server. Der MCP-Server entscheidet bei jeder Anfrage, ob sie ausgeführt wird – und genau hier entscheidet sich, ob Governance greift oder nicht.

Das ist der architektonische Knackpunkt, den IT-Leiter verstehen müssen: Die KI greift nicht direkt auf Unternehmensdaten zu. Sie bittet den MCP-Server, dies in ihrem Auftrag zu tun. Der MCP-Server ist der Kontrollpunkt. Ein MCP-Server mit starken Governance-Kontrollen – Authentifizierung, Autorisierung, Logging, Rate Limiting – ermöglicht eine sichere, revisionssichere KI-Integration. Ein MCP-Server ohne diese Kontrollen erlaubt der KI alles, was der Service-Account darf, unter dem sie läuft – ohne nutzerbezogene Einschränkungen, ohne Logging, ohne Compliance-Dokumentation. Das Risikoprofil einer MCP-Implementierung hängt vollständig davon ab, was an diesem Kontrollpunkt passiert.

Warum Standard-MCP-Implementierungen nicht unternehmensbereit sind

Die meisten heute verfügbaren MCP-Server wurden für einzelne Entwickler und kleine Teams konzipiert. Sie lösen das Konnektivitätsproblem effizient – sie machen es einfach, ein KI-Tool an ein Dateisystem oder eine API anzubinden. Das Governance-Problem im Unternehmen lösen sie jedoch nicht. Das Standard-MCP-Implementierungsmuster weist vier strukturelle Lücken auf, die es für regulierte Unternehmensumgebungen ungeeignet machen.

Die erste Lücke ist die Zugriffskontrolle. Standard-MCP-Implementierungen verbinden die KI über einen Service-Account oder API-Key mit der Datenquelle und gewähren der KI damit Zugriff auf alles, was dieser Account erreichen kann. Es gibt keine nutzerbezogene Autorisierung – kann ein Nutzer über die MCP-Integration auf eine Datei zugreifen, können es faktisch alle, weil die KI immer unter demselben Service-Account agiert, unabhängig davon, wer fragt. Das widerspricht direkt den zero trust-Sicherheitsprinzipien und schafft das gleiche Risiko übermäßiger Berechtigungen, das Identity- und Access-Management-Programme eigentlich verhindern sollen.

Die zweite Lücke ist die Unvollständigkeit des Audit-Trails. Entwicklerorientierte MCP-Implementierungen protokollieren – wenn überhaupt – nur auf Anwendungsebene. Sie erfassen, dass die KI eine Anfrage gestellt hat – aber nicht, welcher Nutzer sie autorisiert hat, welche Daten konkret abgerufen wurden oder was damit geschah. Für Unternehmen, die HIPAA, DSGVO, SOX oder FedRAMP unterliegen, ist das kein Logging-Defizit, sondern ein Compliance-Defizit. Diese Frameworks verlangen eine Dokumentation des Datenzugriffs auf Attributionsniveau, die generisches MCP-Logging nicht liefert.

Die dritte Lücke betrifft die Sicherheit der Zugangsdaten. Viele schlanke MCP-Implementierungen speichern API-Keys oder Authentifizierungstokens in Konfigurationsdateien oder Umgebungsvariablen – zugänglich für jeden, der die Konfiguration lesen kann, teils sogar für das KI-Modell selbst über das Kontextfenster. Ein Prompt-Injection-Angriff auf eine KI mit Zugang zu eigenen Credentials ist ein Datenschutzverstoß in Wartestellung. Zero trust-Datenschutz verlangt, dass Credentials niemals über KI-Prompts zugänglich sind – unter keinen Umständen.

Die vierte Lücke ist das Fehlen von Exfiltrationskontrollen. Ohne Rate Limiting für MCP-Operationen kann ein kompromittiertes oder falsch konfiguriertes KI-System Daten in einem Umfang abrufen, der für normale Nutzer unmöglich wäre. Dieselben DLP-Prinzipien, die den Massenexport durch Menschen regulieren, gelten auch für KI-Agenten, die Tausende Operationen pro Minute ausführen – aber die meisten MCP-Implementierungen bieten dafür keine Kontrollen.

Direkte API vs. MCP: Was sich ändert – und was Governance weiterhin erfordert

Was Enterprise-MCP-Governance tatsächlich erfordert

Für IT-Entscheider bei MCP-Einführungen stellt sich nicht mehr die Frage, ob MCP eingesetzt werden soll – der Standard setzt sich durch. Die Frage ist, welche Governance-Kontrollen im MCP-Server vorhanden sein müssen, bevor er mit Unternehmensdaten verbunden wird. Für regulierte Umgebungen sind sechs Anforderungen unverzichtbar.

Zwei dieser Anforderungen verdienen besondere Aufmerksamkeit, weil sie in Standardimplementierungen meist fehlen und im Ernstfall entscheidend sind.

Operationale Autorisierung – nicht nur auf Sitzungsebene – ist der entscheidende Unterschied zwischen Enterprise- und Entwickler-MCP. Ein Check auf Sitzungsebene prüft, ob die KI grundsätzlich auf das System zugreifen darf. Ein Check auf Operationsebene prüft, ob der spezifische Nutzer diese konkrete Aktion auf diesen konkreten Daten ausführen darf – für jede einzelne MCP-Operation. Nur operationale Autorisierung setzt das Prinzip der minimalen Rechte in der Praxis durch. Sitzungsbasierte Autorisierung schafft ein Vertrauensfenster, das zero trust-Architekturen explizit ablehnen.

Die Isolierung der Credentials vom KI-Modell ist ebenso kritisch. OAuth 2.0-Tokens müssen im sicheren Credential Store des Betriebssystems gespeichert werden – nicht in Konfigurationsdateien, nicht in Umgebungsvariablen, die über den KI-Kontext zugänglich sind, und niemals über Prompts an die KI weitergegeben werden. Das Bedrohungsszenario ist Prompt Injection: Ein Angreifer, der Anweisungen in den Input-Stream der KI einschleusen kann, könnte eine schlecht gesicherte KI anweisen, ihre Credentials preiszugeben. Die Speicherung im OS Keychain eliminiert diese Angriffsfläche vollständig. Das ist eine zero trust-Anforderung für den Datenaustausch, kein optionales Hardening.

MCP und Compliance: Was Aufsichtsbehörden künftig verlangen werden

IT-Verantwortliche in regulierten Branchen – Finanzdienstleister, Gesundheitswesen, Rechtswesen, Behörden – sollten davon ausgehen, dass Aufsichtsbehörden künftig nach Governance für KI-Datenzugriffe fragen werden. Die regulatorischen Signale sind eindeutig: Die DSGVO-Anforderungen an Datenzugriffe gelten auch für KI-Retrievals; das HIPAA-Minimalprinzip gilt für KI-Abfragen auf Patientendaten; FedRAMP verlangt Audit-Logging für alle Operationen in autorisierten Informationssystemen, auch für KI-Operationen. Keines dieser Frameworks wurde speziell für MCP angepasst – das ist aber nicht nötig, da die bestehenden Anforderungen bereits greifen.

Praktisch heißt das: Unternehmen, die heute MCP-Integrationen einführen, müssen künftig nachweisen können, dass jeder KI-Datenzugriff über MCP authentifiziert, gegen RBAC-Policies autorisiert, mit vollständiger Attribution geloggt und entsprechend der Sensitivitätsklassifizierung erfolgt ist. Wer diesen Nachweis nicht führen kann, ist regulatorisch genauso exponiert wie bei jedem anderen unkontrollierten Datenzugriff – dass die Anfrage von einer KI und nicht von einem Menschen kam, ändert daran nichts.

Hinzu kommt eine Datenhoheits-Komponente für Unternehmen, die in mehreren Jurisdiktionen tätig sind. Ein MCP-Server, der KI-Datenanfragen über Cloud-Infrastruktur in einer anderen Jurisdiktion leitet, kann DSGVO-Anforderungen an grenzüberschreitende Datentransfers auslösen oder mit Data-Residency-Vorgaben kollidieren. Kontrollierte MCP-Implementierungen, die innerhalb der eigenen Dateninfrastruktur laufen – statt über externe KI-Anbieter – adressieren dieses Risiko von vornherein.

Das Shadow-AI-Problem, das MCP lösen sollte – und verschärfen kann

Eines der stärksten Argumente für standardisierte MCP-Einführung ist die Eindämmung von Schatten-KI. Mitarbeitende, die KI-Unterstützung wollen, werden Wege finden – ob mit oder ohne IT. Konsumenten-KI-Tools – persönliche ChatGPT-Accounts, browserbasierte KI-Assistenten, Drittanbieter-Plugins – sind bereits in den meisten Unternehmen im Einsatz. Diese Tools sind völlig losgelöst von Governance: keine Zugriffskontrollen, kein Audit-Trail, keine Durchsetzung von Datenklassifizierungen.

Eine kontrollierte MCP-Implementierung löst dieses Problem, indem sie Mitarbeitenden eine legitime, von der IT freigegebene KI-Schnittstelle bietet, die den Schatten-Alternativen sogar überlegen ist – weil sie auf autoritative Unternehmensdaten zugreifen kann – und dabei vollständige Transparenz für das Security-Team ermöglicht. Produktivitäts- und Governance-Argument laufen hier in dieselbe Richtung: Ein gut kontrollierter MCP-Server ist für Nutzer attraktiver und für Sicherheitsteams besser als die unkontrollierten Alternativen, die ohnehin schon genutzt werden.

Das Risiko kehrt sich um, wenn eine unkontrollierte MCP-Implementierung zur offiziellen Alternative für Schatten-KI wird. Ersetzt ein Unternehmen ein Konsumenten-KI-Tool ohne Unternehmensdatenzugriff durch eine MCP-Integration mit breitem Datenzugriff – aber ohne nutzerbezogene Autorisierung, Logging oder Compliance-Kontrollen –, wird das Risiko nicht reduziert, sondern konzentriert und legitimiert. Die Governance-Kontrollen machen den Unterschied zwischen MCP als Sicherheitsgewinn und MCP als Sicherheitsrisiko.

Wie der Kiteworks Secure MCP Server Enterprise-Governance für MCP liefert

MCP-Governance ist kein Problem, das man nach der Einführung löst – es ist eine Architekturentscheidung, die vor dem ersten KI-Zugriff auf Unternehmensdaten getroffen werden muss. Wer das richtig macht, erhält einen Vorteil, den Wettbewerber nicht haben: KI-Produktivität im großen Stil, ohne das Compliance- und Sicherheitsrisiko, das andere Unternehmen zur Verlangsamung oder zum Verbot von KI zwingt. Die kontrollierte MCP-Implementierung trennt KI-Einführungen mit Wettbewerbsvorteil von solchen mit regulatorischem Risiko.

Kiteworks Secure MCP Server wurde gezielt entwickelt, um die sechs Governance-Anforderungen im Unternehmenskontext zu erfüllen. Die Authentifizierung erfolgt über OAuth 2.0 mit PKCE – Tokens werden im OS Keychain gespeichert, nie an das KI-Modell weitergegeben und sind nie über KI-Prompts zugänglich. Die Autorisierung wird für jede Operation durch die Kiteworks Data Policy Engine geprüft, sodass die KI exakt die Rechte des anfragenden Nutzers erbt und diese für keine Aktion überschreiten kann. Jede MCP-Operation wird mit vollständiger Attribution geloggt – KI-System, Nutzer, abgerufene Daten, Zeitstempel, Ergebnis – und in Echtzeit in das Kiteworks-Audit-Log und SIEM integriert.

Path-Traversal-Schutz und absolute Pfadbeschränkungen sind standardmäßig aktiviert und verhindern, dass die KI auf Systemdateien oder Verzeichnisse außerhalb des vorgesehenen Bereichs zugreift. Rate Limiting verhindert Massenausleitung auf Sitzungs- und Nutzerebene. Und da der Kiteworks Secure MCP Server innerhalb des Private Data Network sitzt, gelten für jede KI-Interaktion dieselben Data-Governance-Policies, Compliance-Dokumentationen und Sicherheitskontrollen wie für alle anderen Datenbewegungen über die Kiteworks-Plattform – sicheres Filesharing, Managed File Transfer, sichere E-Mail und mehr. Keine parallele Governance-Infrastruktur. Kein separates KI-Policy-Management. Die gleiche kontrollierte Datenebene – erweitert für MCP.

Für CIOs und IT-Leiter, die KI-Produktivität ermöglichen wollen, ohne neue Governance-Blindspots zu schaffen, bietet der Kiteworks Secure MCP Server die Lösung. Mehr erfahren? Jetzt individuelle Demo vereinbaren.

Weitere Ressourcen

• Blogbeitrag
  Zero‑Trust-Strategien für erschwinglichen KI-Datenschutz
• Blogbeitrag
  Wie 77 % der Unternehmen bei KI-Datensicherheit versagen
• eBook
  AI Governance Gap: Warum 91 % der kleinen Unternehmen 2025 russisches Roulette mit Datensicherheit spielen
• Blogbeitrag
  Für Ihre Daten gibt es kein „–dangerously-skip-permissions“
• Blogbeitrag
  Aufsichtsbehörden fragen nicht mehr, ob Sie eine KI-Policy haben. Sie wollen den Nachweis, dass sie funktioniert.