MCP-Server-Sicherheit: Der essentielle CISO-Leitfaden

Ihre Entwickler installieren MCP-Server in Minuten — per Kopieren und Einfügen. Ihr Sicherheitsteam hat davon wahrscheinlich kein Inventar. Das muss sich ändern.

Was ein MCP-Server ist — und warum er sich von allem anderen unterscheidet

MCP (Model Context Protocol) ist der USB-C-Standard für KI-Agenten. Er erlaubt Sprachmodellen — Claude, GPT, Gemini oder was auch immer in Ihrem Rechenzentrum läuft — sich ohne spezifischen Integrationscode mit Werkzeugen und Datenquellen zu verbinden.

Die häufigsten Ziele: Code-Repositories (GitHub, GitLab), Datenbanken (Postgres, MySQL, Snowflake), Cloud-Anbieter (AWS, Azure, GCP), Ticketsysteme (Jira, Linear), Observability-Plattformen (Grafana, Datadog), Zahlungssysteme (Stripe) und interne Dateisysteme. Ein einziger MCP-Server kann mehrere dieser Systeme gleichzeitig verbinden.

Was ihn grundlegend von jedem SaaS-Anbieter unterscheidet, den Sie bisher bewertet haben: Ein MCP-Server ist keine passive Datenquelle, sondern eine Aktionsfläche. Wenn ein Entwickler einen MCP-Server installiert, gibt er einem Sprachmodell direkten Zugriff auf ein System — mit der Möglichkeit zu lesen, zu schreiben, APIs aufzurufen und Aktionen zu verketten, ohne bei jedem Schritt um Bestätigung zu fragen.

Drei Eigenschaften machen das besonders risikoreich:

• Direkter Systemzugriff. MCP-Server laufen mit der Identität und den Anmeldedaten des Nutzers, der sie gestartet hat — oft ein Entwickler mit weitreichendem Produktionszugriff. Standardmäßig kein Mittler, kein Rate-Limiting, keine menschliche Genehmigung.
• Dynamische Werkzeugdefinitionen. Fähigkeiten können sich nach der Installation ändern. Ein harmloses Werkzeug am Tag 1 kann am Tag 7 still und leise eine E-Mail_senden-Funktion hinzufügen. Ihre quartalsweisen Lieferantenbewertungen werden diese Drift nicht erkennen.
• LLM-vermittelte Ausführung. Das Modell entscheidet anhand natürlichsprachiger Anweisungen, wann und wie es jedes Werkzeug aufruft — und diese Anweisungen können aus nicht vertrauenswürdigen Dokumenten stammen. Werkzeugbeschreibungen sind für das Modell sichtbar, aber für den Endnutzer unsichtbar — ein ideales Versteck für Prompt-Injection-Angriffe.

Drei Risiken für den Vorstand

Datenexfiltration. Ein KI-Agent kann angewiesen werden — durch ein Dokument, das er liest, ein Ticket, das er bearbeitet, ein Repository, das er indexiert — Daten stillschweigend dorthin zu kopieren, wo sie nicht hingehören. Im Mai 2025 dokumentierte Invariant Labs einen Prompt-Injection-Angriff über den GitHub MCP-Server: Schädliche Inhalte in einem öffentlichen Issue überzeugten einen Agenten, private Repository-Inhalte einschließlich Gehaltsdaten in einem neuen öffentlichen Pull Request preiszugeben. Auswirkung: hoch. Erkennung: schwierig.

Supply-Chain-Substitution. Sie haben ein Werkzeug am Montag genehmigt. Am Freitag hat es still und leise geändert, was es tut — und niemand in Ihrem Team wurde informiert. Forscher von Knostic fanden Ende 2025 über 1.862 MCP-Server im öffentlichen Internet ohne jegliche Authentifizierung. Astrix Security berichtete, dass 43 % der Open-Source-MCP-Server Command-Injection-Schwachstellen enthalten. CVE-2025-6514 allein betraf über 437.000 Entwicklungsumgebungen.

Regulatorisches Risiko. DORA, NIS2 und der EU AI Act verlangen alle den Nachweis von Kontrolle über Drittanbieter-Tools, die mit kritischen Geschäftsprozessen verbunden sind. Ein unkontrollierter MCP-Server ist per Definition ein unkontrollierter IKT-Drittanbieter — ein Befund, den kein Prüfer übersehen wird. Der IBM Cost of a Data Breach Report 2025 beziffert den Aufpreis durch „Shadow-KI” auf 670.000 US-Dollar. Derzeit überwachen nur 17 % der Organisationen Agenten-zu-Agenten-Interaktionen.

Das gemeinsame Muster in allen drei Fällen: Der Angreifer muss Ihren Perimeter nicht durchbrechen. Schädliche Anweisungen kommen als gewöhnliche Inhalte über legitime Kanäle herein und werden von Werkzeugen ausgeführt, die Ihre Organisation freiwillig installiert hat. Der Schadensradius wird ausschließlich durch die vergebenen Privilegien bestimmt.

Was Sie vor der Genehmigung eines MCP-Servers fragen sollten

Ihr bestehendes Drittanbieter-Risikoprogramm setzt einen SaaS-Anbieter, einen Vertrag und einen vierteljährlichen Prüfzyklus voraus. MCP bricht alle drei Annahmen. Hier ist, was wirklich zählt:

Herkunft und Lieferkette

• Wer pflegt den Server, und ist jede Version an einen kryptografischen Hash gebunden?
• Wurde er unabhängig analysiert — SAST, Taint-Analyse, Supply-Chain-Scan?
• Was sind die Schwachstellen-Offenlegungsrichtlinie und das Patch-SLA?

Zugriff und Berechtigungen

• Auf welche Systeme hat er Zugriff? Zählen Sie sie auf. „Hängt von der Konfiguration ab” ist keine akzeptable Antwort.
• Benötigt er persistente Anmeldedaten, oder kann er kurzlebige, bereichsbegrenzte Token verwenden?
• Kann der Zugriff pro Nutzer oder pro Sitzung eingeschränkt werden?

Laufzeitverhalten

• Können sich Werkzeugdefinitionen nach der Installation ändern? Wenn ja, gibt es eine automatische Drift-Erkennung?
• Führt er ausgehende Netzwerkanfragen durch, und an welche spezifischen Endpunkte?
• Kann er Schreib- oder destruktive Aktionen ohne explizite Nutzerbestätigung auslösen?

Governance und Compliance

• Erzeugt er strukturierte Audit-Protokolle, die für DORA-Berichte geeignet sind?
• Ist der Datenspeicherort für EU-Datenflüsse dokumentiert?
• Gibt es einen benannten Sicherheitsansprechpartner mit einer öffentlichen security.txt?

Ein Server, der all das nicht beantworten kann, sollte für kein System genehmigt werden, das regulierte Daten, Produktionsanmeldedaten oder Kundenkommunikation verarbeitet. Und diese Liste hat kein Ablaufdatum — wiederholen Sie sie bei jedem wesentlichen Versions-Update.

90 Tage von null zu verteidigbarer Kontrolle

Derzeit überwacht nur 38 % der Organisationen KI-Traffic lückenlos. Hier ist ein konkretes Programm, um die Kontrolle zurückzugewinnen.

Tage 1-30 — Bestandsaufnahme. Verabschieden Sie eine schriftliche Richtlinie: Während dieser Phase werden keine neuen MCP-Server mit Produktionssystemen verbunden. Untersuchen Sie Entwickler-Tools (Cursor, Claude Desktop, VS Code Copilot, Cline, benutzerdefinierte Agenten). Fügen Sie MCP-Server als neue Asset-Klasse in Ihr CMDB ein, verknüpft mit dem installierenden Nutzer und dem Geschäftsprozess. Gleichen Sie die Daten mit Netzwerk-Egress-Protokollen ab, um nicht registrierte Server zu entdecken. Ergebnis: eine freigegebene Bestandsliste mit Eigentümer, Herausgeber, Version und Datenklassifizierungskennung pro Eintrag.

Tage 31-60 — Analyse. Führen Sie eine Zertifizierungspipeline für jeden Server durch: SAST, Taint-Analyse, Supply-Chain-Scan, Secrets-Scan. Bewerten Sie jeden einzelnen. Klassifizieren Sie nach Schadensradius — Stufe 1 (Produktion + regulierte Daten), Stufe 2 (Produktion), Stufe 3 (nur Sandbox). Ergebnis: risikobewerteter Katalog mit Sanierungsplan für alles unterhalb einer Basis-Sicherheitszertifizierung.

Tage 61-90 — Durchsetzung. Stellen Sie eine Ausführungsschicht bereit, die kryptografische Hashes und Zertifizierungsstufe prüft, bevor ein Werkzeug einem Modell ausgesetzt wird. Verbinden Sie Ausführungsereignisse mit Ihrem SIEM für DORA-konforme Vorfallmeldungen. Definieren Sie Alarmschwellen für neue Endpunkte, neue Werkzeugdefinitionen und Anomalien beim ausgehenden Datenvolumen. Ergebnis: Richtliniendokument + Runtime-Enforcement + 90-Tage-Bericht für den Vorstand mit Nachweis der Kontrollabdeckung.

Das Wesentliche auf einen Blick

Der Kernpunkt beim MCP-Risiko ist nicht die Netzwerksicherheit — es sind Least-Privilege-Enforcement, Herkunftsnachveis und Laufzeit-Attestierung. Eine Organisation, die diese drei Bereiche beherrscht, kann den Rest bewältigen. Eine, die einen davon vernachlässigt, wird einem Regulierer schwer erklären können, warum sie nicht wusste, was ihre KI-Agenten taten.