MCP Security: Authentifizierung, Zugriffskontrolle und Best Practices für Unternehmen

Das Model Context Protocol (MCP) öffnet KI-Systemen die Tür zu Unternehmensdaten und externen Diensten – und genau das macht es aus Sicherheitssicht so heikel. Wer MCP-Server an eine Datenbank, ein CRM oder eine E-Mail-Plattform anbindet, schafft potenzielle Angriffspunkte. Gleichzeitig bietet das Protokoll von sich aus solide Sicherheitsmechanismen, die bei korrekter Konfiguration viel abdecken. Was Unternehmen über MCP-Sicherheit wissen müssen, welche Risiken real sind und wie man sie minimiert.

Warum MCP Security überhaupt ein Thema ist

KI-Assistenten wie Claude, ChatGPT oder Gemini werden zunehmend in Unternehmensprozesse eingebunden. Ohne MCP bleibt ein KI-Assistent auf sein Trainingswissen beschränkt – eine interessante Spielerei, aber kein echter Business-Nutzen. Sobald ein KI-System jedoch auf echte Unternehmensdaten zugreifen kann – Kundenlisten, Projektpläne, E-Mails, Finanzdaten – wird jede Sicherheitslücke zur potentiellen Datenpanne.

Das Problem verschärft sich durch die Architektur von MCP: Ein MCP-Server gibt einem KI-Modell Werkzeuge an die Hand, die weit über eine einfache Konversation hinausgehen. Ein KI-Assistent mit angebundenem E-Mail-Server kann eigenständig E-Mails versenden. Mit angebundener Datenbank kann er Daten lesen, ändern oder löschen. Mit Dateisystem-Zugriff kann er Dateien lesen und schreiben. Jede dieser Fähigkeiten ist ein potentielles Risiko, wenn sie in falsche Hände gerät – sei es durch Prompt-Injection, kompromittierte Server oder fehlerhafte Zugriffskontrolle.

Die gute Nachricht: MCP wurde von Anfang an mit Sicherheitsüberlegungen entwickelt. Das Protokoll definiert Authentifizierungsmechanismen, Capabilities-Based Access Control und Transportverschlüsselung. Die schlechte Nachricht: Die Sicherheit steht und fällt mit der Implementierung – und in der Praxis wird vieles falsch gemacht.

Die Sicherheitsarchitektur von MCP im Detail

Authentifizierung: Wer darf zugreifen?

Bei lokalen MCP-Servern (Stdio-Transport) ist die Authentifizierung simplic: Client und Server laufen als Prozesse auf dem gleichen Rechner, und nur der lokale Nutzer hat Zugriff. Solange niemand sonst auf den Rechner zugreifen kann, ist das Risiko überschaubar.

Anders bei Remote-MCP-Servern (Streamable HTTP Transport). Hier muss sichergestellt werden, dass nur autorisierte Clients eine Verbindung aufbauen können. MCP unterstützt dafür:

• API-Keys: Einfachste Methode – ein geheimer Schlüssel wird bei jeder Anfrage mitgesendet. Geeignet für interne Server mit begrenztem Zugriff.
• OAuth 2.0: Enterprise-Standard für delegierte Autorisierung. Ein Client erhält einen Access Token mit begrenzten Rechten, der regelmäßig erneuert werden muss. Ideal für Multi-Tenant-Umgebungen und wenn ein Server mehrere Mandanten bedient.
• Bearer Tokens / JWT: Für Microservice-Architekturen. Ein signierter JSON Web Token enthält Claims über die Identität und Berechtigungen des Aufrufers.

Unternehmen sollten für Remote-Server grundsätzlich OAuth 2.0 oder JWT bevorzugen. API-Keys sind in Ordnung für Testumgebungen, aber als alleinige Absicherung im Produktivbetrieb zu riskant: Sie werden oft in Konfigurationsdateien gespeichert, rotieren selten und landen unverschlüsselt in Logs.

Authorization: Was darf der Client tun?

Authentication klärt die Frage „Wer bist du?“. Authorization klärt die Frage „Was darfst du tun?“. MCP unterstützt这两种 Arten der Autorisierung:

Scope-Based Access Control: Der MCP-Server definiert Scopes – abstrakte Berechtigungsbereiche wie

,

oder

. Der Client erhält bei der Authentifizierung einen Scope zugewiesen und darf nur Tools aufrufen, die in seinem Scope liegen.

Capabilities Negotiation: Während des Handshakes tauschen Client und Server ihre Fähigkeiten aus. Der Server teilt mit, welche Tools, Resources und Prompts er anbietet. Der Client teilt mit, welche er nutzen darf. Ein gut konfigurierter Server gibt einem breiten Client nur Zugriff auf die Ressourcen, die dieser tatsächlich braucht.

Das Prinzip dahinter: Least Privilege. Jeder MCP-Server und jeder Client sollte nur die Mindestberechtigungen erhalten, die für seine Aufgabe erforderlich sind. Ein MCP-Server für den E-Mail-Versand sollte keine Datenbankabfragen erlauben. Ein Read-only-Client sollte keine Schreibrechte bekommen.

Transportverschlüsselung

Remote-MCP-Server nutzen HTTPS für die Transportverschlüsselung. Das ist selbstverständlich, aber nicht selbsterklärend: Wer einen MCP-Server selbst betreibt, muss ein gültiges TLS-Zertifikat konfigurieren. Selbstsignierte Zertifikate sind für Tests in Ordnung, im Produktivbetrieb sind sie ein Ausschlusskriterium – besonders wenn das Unternehmen DSGVO-pflichtige Daten verarbeitet.

Wichtig: HTTPS verschlüsselt nur die Übertragung. Die Daten liegen auf dem Server entschlüsselt vor. Das ist normal, aber man sollte sich bewusst sein, dass ein kompromittierter Server Zugriff auf alle weitergeleiteten Daten bedeutet.

Reale Bedrohungsszenarien

Prompt Injection über MCP

Prompt Injection ist eine Angriffstechnik, bei der ein Angreifer bösartige Eingaben in Daten einschleust, die das KI-System verarbeitet. Bei MCP wird das Problem besonders greifbar: Wenn ein MCP-Server Daten aus einer Datenbank oder einer Webseite liefert, könnte ein Angreifer dort präparierte Prompts einbetten.

Beispiel: Ein MCP-Server liefert Produktbeschreibungen aus einer Datenbank. Ein Angreifer, der Schreibzugriff auf diese Datenbank hat (durch einen anderen Server oder eine Sicherheitslücke), könnte in eine Produktbeschreibung einen Prompt-Injection-Angriff einbetten. Das KI-Modell interpretiert diese Eingabe als Anweisung und führt Befehle aus, die es normalerweise nicht ausführen würde.

Gegenmaßnahmen:

• Eingaben von MCP-Servern niemals ungefiltert als Prompts verwenden
• Sanitization-Schicht zwischen Server-Daten und Modell-Eingabe
• Separate Kontexte für System-Anweisungen und externen Content

Datenexfiltration über kompromittierte Server

Ein MCP-Server, der Zugriff auf sensitive Daten hat – etwa Kundenstammdaten oder Finanzberichte – ist ein attraktives Ziel. Wenn ein Server kompromittiert wird, hat der Angreifer Zugriff auf alle Daten, die dieser Server der KI bereitstellt.

Das Risiko wird grösser, je mehr Server ein Unternehmen betreibt: Jeder Server ist eine potenzielle Angriffsfläche. Ein gut konzipiertes MCP-Gateway kann hier helfen, indem es alle Server-Verbindungen über einen zentralen Kontrollpunkt führt.

Escalation of Privileges

Ein weiteres Risiko: Wenn ein MCP-Client kompromittiert wird – etwa durch einen malware-infizierten KI-Assistenten – kann er alle Berechtigungen ausnutzen, die ihm seine Servers erteilt hat. Ein Client, der Zugriff auf E-Mail, Datenbank und Kalender hat, könnte bei einer Kompromittierung alle drei Systeme gleichzeitig angreifen.

Gegenmaßnahme: Separate Clients für separate Aufgaben. Ein KI-Agent für E-Mail-Verarbeitung sollte keinen Zugriff auf die Finanzdatenbank haben, auch wenn technisch möglich.

Best Practices für den Unternehmenseinsatz

1. Authentifizierung immer aktivieren

Kein Remote-MCP-Server ohne Authentifizierung. Auch wenn der Server „nur intern“ läuft: Firewall-Regeln können fehlerhaft sein, und ein versehen offen gelassener Port reicht für einen Angriff. OAuth 2.0 mit kurzlebigen Tokens ist der Goldstandard. Falls das nicht möglich ist, mindestens API-Keys mit regelmäßiger Rotation.

2. Minimalprinzip konsequent umsetzen

Jeder MCP-Server sollte nur die Berechtigungen bekommen, die er tatsächlich braucht. Das klingt banal, wird aber in der Praxis oft missachtet. Ein Filesystem-Server für einen bestimmten Projektordner braucht keinen Zugriff auf das gesamte Home-Verzeichnis. Ein E-Mail-Server braucht keinen Zugriff auf Dateien.

Im Umkehrschluss: Wer einen MCP-Server entwickelt, sollte Tools und Resources so granular wie möglich definieren. Statt eines generischen

-Tools lieber ein spezifisches

-Tool, das nur auf einen definierten Ordner zugreifen darf.

3. Audit-Logs aktivieren und überwachen

Jeder Tool-Aufruf über MCP sollte geloggt werden: Welcher Client hat welches Tool aufgerufen, wann, mit welchen Parametern, und was war das Ergebnis? Diese Logs sind Gold wert für die forensische Analyse nach einem Vorfall und gleichzeitig ein Abschreckungsmittel – wenn bekannt ist, dass alles geloggt wird, denken Angreifer zweimal nach.

Idealerweise werden Audit-Logs an ein zentrales SIEM-System (Security Information and Event Management) weitergeleitet, wo sie mit anderen Sicherheitsereignissen korreliert werden können.

4. Regelmäßige Sicherheits-Audits der Server

MCP-Server sind Software – und Software hat Sicherheitslücken. Server regelmäßig auf bekannte CVEs prüfen (Common Vulnerabilities and Exposures), Abhängigkeiten aktuell halten, Pen-Tests durchführen. Gerade weil MCP-Server oft als schnell gebaute Prototypen starten, schleichen sich hier technische Schulden ein.

5. Network Segmentation

MCP-Server sollten nicht ungehindert auf das gesamte Netzwerk zugreifen können. Idealerweise sind sie in einem isolierten Netzwerksegment, das nur über dedizierte Firewalls mit anderen Systemen kommuniziert. Das Prinzip: Even if one server is compromised, the blast radius should be limited.

6. Input Validation auf Serverseite

Jeder MCP-Server sollte alle eingehenden Parameter validieren, bevor er sie an die Zielanwendung weitergibt. Das betrifft besonders:

• Dateipfade: Niemals beliebige Pfade zulassen – nur vorgegebene, verifizierte Verzeichnisse
• SQL-Queries: Parameterized Queries verwenden, niemals String-Concatenation
• E-Mail-Adressen: Regex-Validierung gegen gängige Spam-Muster
• URLs: Nur erlaubte Domains zulassen, Blacklist für bekannte Phishing-Domains

7. User Consent und Data Governance

Wenn MCP-Server auf personenbezogene Daten zugreifen, muss klar sein, wer die Verantwortung trägt. Nach DSGVO ist derjenige datenverantwortlich, der über Zweck und Mittel der Verarbeitung entscheidet. Wenn ein KI-Agent automatisch auf CRM-Daten zugreift, ist das eine automatisierte Entscheidungsfindung – und unter Umständen meldepflichtig.

Unternehmen sollten klare Data-Governance-Richtlinien für MCP-Integrationen haben: Welche Daten darf ein KI-System lesen? Welche Aktionen darf es ausführen? Wer hat das autorisiert? Und vor allem: Wie wird sichergestellt, dass diese Richtlinien eingehalten werden?

DSGVO und MCP: Was Unternehmen beachten müssen

Das Model Context Protocol ist ein technisches Protokoll – aber seine Verwendung hat rechtliche Implikationen, besonders wenn personenbezogene Daten verarbeitet werden.

Rechtsgrundlage: KI-Systeme, die auf personenbezogene Daten zugreifen, brauchen eine Rechtsgrundlage nach Art. 6 DSGVO. Das kann eine Einwilligung sein, ein Vertrag, oder ein berechtigtes Interesse. Für den Unternehmenseinsatz ist meist ein Vertrag (Auftragsverarbeitung nach Art. 28 DSGVO) oder ein berechtigtes Interesse die richtige Grundlage.

Auftragsverarbeitung: Wenn ein MCP-Server auf Daten zugreift, die ein anderes Unternehmen kontrolliert – etwa wenn ein SaaS-Anbieter MCP-Zugriff auf Kundendaten gewährt – liegt unter Umständen eine Auftragsverarbeitung vor. Dann braucht es einen AV-Vertrag.

Transparenz: Mitarbeiter müssen wissen, dass ein KI-System Zugriff auf bestimmte Daten hat. Das klingt selbstverständlich, wird aber oft vernachlässigt, wenn KI-Agenten „im Hintergrund“ arbeiten.

Speicherbegrenzung: Das KI-Modell speichert Kontext aus MCP-Sitzungen unter Umständen. Wenn dieser Kontext personenbezogene Daten enthält, gelten die Grundsätze der Speicherbegrenzung: Nur so lange speichern wie nötig, dann löschen.

Monitoring und Observability für MCP

Sicherheit ohne Monitoring ist unvollständig. Für MCP-Umgebungen empfehlen sich:

• Metriken: Anzahl der Verbindungen, Tool-Aufrufe pro Minute, Fehlerraten, Latenz. Ungewöhnliche Spitzen können auf einen Angriff hindeuten.
• Tracing: Jeder MCP-Request sollte eine Trace-ID haben, mit der sich der vollständige Aufrufpfad rekonstruieren lässt.
• Alerts: Automatische Benachrichtigungen bei verdächtigen Mustern – etwa hunderte Datenbankabfragen in kurzer Zeit, Zugriffe ausserhalb der Geschäftszeiten, oder fehlgeschlagene Authentifizierungsversuche.

Ein MCP-Gateway, das als zentraler Proxy fungiert, ist hier besonders wertvoll: Es kann alle Verbindungen protokollieren, aggregieren und an Monitoring-Systeme weiterleiten – ohne dass jeder einzelne Server selbst observabel sein muss.

Open-Source-MCP-Server: Vertrauenswürdig oder Risiko?

Das MCP-Ökosystem lebt von Open-Source-Servern. Auf GitHub gibt es hunderte von Community-Servern für Slack, Jira, PostgreSQL, AWS und mehr. Das ist eine Stärke des Protokolls – aber auch ein Sicherheitsrisiko.

Bevor ein MCP-Server in eine Produktivumgebung integriert wird, sollte man sich fragen:

• Wer entwickelt den Server? Ist das ein verifizierter Account mit aktivem Projekt?
• Wann wurde der Server zuletzt aktualisiert? Veraltete Server haben mehr Sicherheitslücken.
• Gibt es bekannte CVEs? Ein Blick auf GitHub Advisories lohnt sich.
• Welche Berechtigungen fordert der Server? Ein E-Mail-Server, der Zugriff auf das Dateisystem will, ist verdächtig.

Im Zweifel: Server selbst betreiben, anstatt einen Drittanbieter-Server zu nutzen. Das offizielle MCP-SDK macht das Entwickeln eines eigenen Servers einfach. Für sicherheitskritische Umgebungen ist der Kontrollverlust durch fremde Server den potenziellen Schaden nicht wert.

Fazit: Sicherheit ist kein Nachgedanke

MCP ist ein mächtiges Protokoll – und jedes mächtige Werkzeug braucht einen sicheren Rahmen. Das fängt bei der Authentifizierung an und hört bei der Data Governance auf. Unternehmen, die MCP-Integrationen planen, sollten Security von Anfang an mitdenken – nicht als nachträgliche Absicherung, sondern als integralen Bestandteil der Architektur.

Die Investition in sichere MCP-Infrastruktur – ein MCP-Gateway, OAuth-Authentifizierung, Audit-Logs, Network Segmentation – amortisiert sich schnell: Sie verhindert Datenpannen, die nicht nur peinlich, sondern auch teuer sind. Ein DSGVO-Bußgeld kann bis zu 20 Millionen Euro oder 4% des Jahresumsatzes betragen.

Wer MCP versteht und sicher implementiert, hat einen deutlichen Vorteil: Er kann die Vorteile des Protokolls voll ausschöpfen, ohne die Risiken einzugehen.

Mehr Links zum Thema

• Offizielle MCP-Dokumentation (modelcontextprotocol.io)
• MCP auf GitHub – Spezifikation, SDKs und Referenz-Server
• MCP Server: Was ist das Model Context Protocol?
• MCP Gateway: Was ist das und wozu braucht man es?

Sie möchten MCP sicher in Ihrem Unternehmen einsetzen?
Wir unterstützen Sie bei der Planung, Implementierung und Absicherung Ihrer MCP-Integration. Kontaktieren Sie uns über unser Kontaktformular – wir melden uns innerhalb von 24 Stunden bei Ihnen.