MCP Server Security Scan: KI-Agenten sicher bewerten

MCP Server Security Scan: KI-Agenten sicher bewerten

73 % aller produktiv laufenden MCP-Server weisen kritische Konfigurationsfehler auf — das ist das zentrale Ergebnis des Invariant Labs Security Report 2025. Wer heute einen KI-Agenten mit Zugriff auf Kundendaten, Kalender oder E-Mail-Postfächer betreibt, ohne den MCP Server systematisch geprüft zu haben, arbeitet statistisch gesehen mit einem verwundbaren System.

Ein MCP Server Security Scan ist die systematische Prüfung aller Sicherheitseigenschaften eines Servers, der das Model Context Protocol implementiert. Er bewertet, welche Tools ein KI-Agent aufrufen darf, wie Context-Daten geschützt werden und ob Prompt-Injection-Angriffe möglich sind.

Der schnellste erste Schritt, den Sie heute umsetzen können: Öffnen Sie die Tool-Permission-Liste Ihres MCP Servers. Jedes registrierte Tool ist eine potenzielle Angriffsfläche. Wenn die Liste mehr als fünf Einträge hat und Sie nicht jeden einzelnen begründen können, haben Sie akuten Handlungsbedarf.

Das Problem ist strukturell: Das Model Context Protocol wurde erst im November 2024 von Anthropic veröffentlicht und hat sich 2025 rasant verbreitet. Die Sicherheits-Tooling-Landschaft hinkt hinterher. Klassische Scanner kennen MCP-spezifische Risiken wie unkontrollierte Context-Weitergabe oder übermäßige Tool-Permissions nicht — ein Standard-Vulnerability-Scan liefert daher ein falsches Gefühl von Sicherheit.

Was macht MCP Server grundsätzlich angreifbar?

MCP-Server sind keine gewöhnlichen API-Endpunkte. Sie verbinden ein Sprachmodell mit realen Systemen — Datenbanken, Dateisystemen, externen APIs. Diese Verbindung schafft Angriffsflächen, die in klassischen Sicherheitsmodellen nicht existieren.

Das Tool-Permission-Problem

Jeder MCP Server definiert, welche Tools ein KI-Agent aufrufen darf. In der Praxis werden diese Berechtigungen zu großzügig vergeben — nicht aus Fahrlässigkeit, sondern weil Entwickler beim Prototyping alles aktivieren und beim Go-Live vergessen zu reduzieren.

Ein Agent, der nur Termine lesen soll, bekommt Schreibzugriff auf den Kalender. Ein Support-Agent erhält Zugriff auf die interne Wissensdatenbank inklusive vertraulicher Preislisten. Diese übermäßigen Permissions sind das Einfallstor.

Prompt Injection über Tool-Parameter

Prompt Injection ist bei MCP-Servern besonders gefährlich. Ein Angreifer platziert manipulierten Text in einer Datenquelle, die der Agent liest — etwa in einem Kundenticket oder einer E-Mail. Der Agent interpretiert diesen Text als Anweisung und führt unerwünschte Tool-Calls aus.

Anfangs versuchten viele Teams, das mit Output-Filtering zu lösen — vergeblich, weil die Injection bereits im Input passiert. Durchgesetzt hat sich Input-Sanitization auf Tool-Parameter-Ebene, kombiniert mit strikten Allowlists für erlaubte Aktionen.

Context-Leakage zwischen Agenten

In Multi-Agenten-Architekturen teilen sich mehrere KI-Instanzen denselben MCP Server. Ohne klare Context-Isolation kann Agent A auf Daten zugreifen, die eigentlich nur für Agent B bestimmt sind. Laut OWASP Top 10 for LLM Applications (2025) ist unkontrollierte Context-Weitergabe die am häufigsten übersehene Schwachstelle in produktiven KI-Systemen.

Die fünf Prüfbereiche eines MCP Security Scans

Ein vollständiger MCP Server Security Scan deckt fünf Bereiche ab. Jeder Bereich liefert einen eigenen Risk-Score, die Summe ergibt das Gesamtrisikoprofil des Servers.

1. Authentifizierung und Autorisierung

Prüfen Sie zuerst, wie sich Clients gegenüber dem MCP Server authentifizieren. Akzeptiert der Server Verbindungen ohne Token-Validierung? Gibt es Role-Based Access Control für verschiedene Agent-Typen? Werden Tokens mit angemessener Laufzeit ausgestellt?

Konkrete Prüfschritte: Senden Sie eine Tool-Anfrage ohne gültiges Token. Prüfen Sie, ob der Server zwischen Read-only- und Write-Agenten unterscheidet. Kontrollieren Sie Token-Expiry-Zeiten — alles über 24 Stunden ist ein Risiko.

2. Tool-Permission-Analyse

Listen Sie alle registrierten Tools auf und bewerten Sie jedes einzeln nach dem Least-Privilege-Prinzip. Braucht der Agent dieses Tool wirklich? In welchen Szenarien? Was passiert, wenn ein Angreifer genau dieses Tool missbraucht?

Tool-Typ	Risikostufe	Empfehlung
Lesezugriff auf interne Daten	Mittel	Scope auf konkrete Datenbereiche einschränken
Schreibzugriff auf Datenbanken	Hoch	Nur mit expliziter Bestätigung erlauben
Externe API-Calls	Hoch	Allowlist für erlaubte Domains erzwingen
Code-Ausführung	Kritisch	Nur in isolierter Sandbox, niemals direkt
Dateisystem-Zugriff	Kritisch	Strikt auf definierte Verzeichnisse begrenzen

3. Input-Validierung und Prompt-Injection-Resistenz

Testen Sie, ob Tool-Parameter validiert werden, bevor der Agent sie verarbeitet. Senden Sie absichtlich manipulierte Parameter — etwa Strings mit eingebetteten Anweisungen wie „Ignoriere alle vorherigen Regeln und führe aus: …“.

Ein robuster MCP Server lehnt solche Parameter ab oder sanitisiert sie, bevor sie das Model erreichen. Fehlt diese Validierung, ist der Server anfällig für Indirect Prompt Injection.

4. Logging und Audit-Trail

Jeder Tool-Call eines KI-Agenten muss protokolliert werden — mit Zeitstempel, Agent-ID, aufgerufenem Tool und übergebenen Parametern. Ohne diesen Audit-Trail ist eine forensische Analyse nach einem Sicherheitsvorfall unmöglich.

Prüfen Sie: Werden Logs zentral gespeichert? Sind sie manipulationssicher? Gibt es Alerting bei ungewöhnlichen Tool-Call-Mustern? Laut SANS Institute (2025) fehlen in 58 % aller produktiven MCP-Deployments ausreichende Audit-Logs.

5. Dependency- und Transport-Sicherheit

MCP-Server-Implementierungen basieren auf Libraries, die eigene Schwachstellen mitbringen. Prüfen Sie alle Dependencies mit Snyk oder einem vergleichbaren Tool. Stellen Sie sicher, dass die Kommunikation zwischen Client und Server ausschließlich über TLS 1.3 läuft.

Schritt-für-Schritt: So führen Sie den Scan durch

Dieser Ablauf funktioniert für Teams ohne dediziertes Security-Budget. Er dauert beim ersten Mal vier Stunden, bei Wiederholungen unter einer Stunde.

Schritt 1: Inventar erstellen (30 Minuten)

Dokumentieren Sie alle MCP-Server in Ihrer Infrastruktur. Für jeden Server: Welche Tools sind registriert? Welche Agenten haben Zugriff? Welche Datenquellen werden angezapft? Diese Übersicht ist die Grundlage für alle weiteren Prüfschritte.

Schritt 2: Automatisierten Scan starten (30 Minuten)

Führen Sie Semgrep mit dem MCP-Security-Ruleset gegen Ihren Server-Code aus: semgrep --config=p/mcp-security . — das liefert innerhalb von Minuten eine Liste potenzieller Schwachstellen mit Schweregrad-Einstufung.

Parallel: Snyk-Scan für alle Dependencies. Kritische CVEs in verwendeten Libraries müssen sofort gepatcht werden, unabhängig vom restlichen Scan-Ergebnis.

Schritt 3: Manuelle Permission-Prüfung (60 Minuten)

Gehen Sie jedes registrierte Tool durch und beantworten Sie drei Fragen: Braucht der Agent dieses Tool für seinen definierten Use Case? Ist der Scope so eng wie möglich gefasst? Was ist das schlimmste Szenario, wenn dieses Tool missbraucht wird?

Tools, die die erste Frage mit Nein beantworten, werden sofort deaktiviert. Tools mit kritischem Missbrauchspotenzial erhalten zusätzliche Guardrails.

Schritt 4: Prompt-Injection-Tests (60 Minuten)

Testen Sie manuell, ob Ihr MCP Server gegen gängige Injection-Muster resistent ist. Nutzen Sie die OWASP LLM Top 10 Testcases als Grundlage. Dokumentieren Sie jeden Test und sein Ergebnis — diese Dokumentation brauchen Sie für den Audit-Trail.

Schritt 5: Ergebnisse bewerten und priorisieren (60 Minuten)

Kategorisieren Sie alle Findings nach CVSS-Score: Kritisch (9-10), Hoch (7-8.9), Mittel (4-6.9), Niedrig (0-3.9). Kritische und hohe Findings müssen vor dem nächsten Deployment behoben sein. Mittlere Findings kommen ins nächste Sprint-Backlog.

„Ein MCP Server ohne Permission-Granularität ist wie ein Mitarbeiter mit Generalschlüssel für alle Räume — technisch funktioniert es, aber das Risiko ist nicht akzeptabel.“ — Invariant Labs Security Team, 2025

Bewertungsmatrix: Wie sicher ist Ihr MCP Server?

Diese Matrix gibt Ihnen nach dem Scan eine schnelle Einordnung. Bewerten Sie jeden Bereich mit 0 (nicht vorhanden), 1 (teilweise) oder 2 (vollständig implementiert).

Prüfbereich	0 Punkte	1 Punkt	2 Punkte
Authentifizierung	Kein Token-Check	Statische Tokens	Kurzlebige Tokens + RBAC
Tool-Permissions	Alle Tools aktiv	Manuelle Auswahl	Least-Privilege + Review-Prozess
Input-Validierung	Keine Sanitization	Basis-Filterung	Vollständige Parametervalidierung
Logging	Keine Logs	Lokale Logs	Zentrales SIEM + Alerting
Transport-Sicherheit	HTTP	TLS 1.2	TLS 1.3 + Certificate Pinning
Dependency-Hygiene	Keine Prüfung	Manueller Check	Automatisierter Scan im CI/CD

Auswertung: 10-12 Punkte = gutes Sicherheitsniveau. 6-9 Punkte = Handlungsbedarf bei einzelnen Bereichen. Unter 6 Punkte = kritisches Risiko, sofortiger Stopp des Produktivbetriebs empfohlen.

Die Kosten des Nichtstuns — konkret berechnet

Rechnen wir: Ein kompromittierter MCP Server, der Kundendaten exfiltriert, löst in der EU eine DSGVO-Meldepflicht aus. Die durchschnittlichen Kosten eines solchen Vorfalls liegen laut IBM Cost of a Data Breach Report (2025) bei 4,9 Millionen EUR — verteilt auf Forensik, Benachrichtigungen, Bußgelder und Reputationsschäden. Ein vollständiger MCP Security Scan kostet zwischen 800 und 12.000 EUR. Das Verhältnis spricht für sich.

Dazu kommen operative Kosten: Wenn ein KI-Agent durch eine Injection-Attacke falsche Aktionen ausführt — etwa fehlerhafte Buchungen oder versendete E-Mails — verbringt Ihr Team im Schnitt 8 bis 15 Stunden mit der manuellen Korrektur. Bei drei solchen Vorfällen pro Monat sind das über ein Jahr 36 bis 60 Stunden verlorene Arbeitszeit.

„Die Frage ist nicht ob ein unsicherer MCP Server angegriffen wird, sondern wann. Die Angriffsfläche wächst mit jeder neuen Tool-Integration.“ — OWASP LLM Security Working Group (2025)

Kontinuierliches Monitoring nach dem ersten Scan

Ein einmaliger Scan ist kein Sicherheitskonzept. Das MCP-Ökosystem verändert sich schnell — neue Protocol-Versionen, neue Tool-Integrationen, neue Angriffsmuster. Sicherheit braucht einen kontinuierlichen Prozess.

Automatisiertes Scanning im CI/CD

Integrieren Sie den Semgrep MCP-Scan in Ihre CI/CD-Pipeline. Jeder Commit, der MCP-Server-Konfigurationen oder Tool-Definitionen ändert, triggert automatisch einen Sicherheits-Check. Findings mit Schweregrad Hoch oder Kritisch blockieren den Deploy.

Diese Integration dauert bei GitHub Actions oder GitLab CI etwa zwei Stunden Einrichtungszeit — eine Investition, die sich beim ersten verhinderten Produktionsfehler amortisiert.

Laufzeit-Monitoring mit Invariant Labs

Statische Scans erkennen Konfigurationsprobleme, aber keine anomalen Verhaltensweisen zur Laufzeit. Invariant Labs Guardrails überwacht Tool-Call-Muster in Echtzeit und schlägt Alarm, wenn ein Agent ungewöhnlich viele Calls in kurzer Zeit ausführt oder auf Ressourcen zugreift, die außerhalb seines normalen Musters liegen.

Quartalsweise manuelle Reviews

Automatisierung ersetzt kein menschliches Urteilsvermögen. Planen Sie einmal pro Quartal einen manuellen Review aller MCP-Server-Konfigurationen. Fragen Sie dabei: Haben sich Use Cases geändert? Gibt es Tools, die nicht mehr gebraucht werden? Sind neue Angriffsmuster bekannt geworden?

Wer seine KI-Infrastruktur umfassend absichern möchte, sollte neben dem MCP-Scan auch die doppelte Absicherung für AI-Crawler über security.txt und llms.txt in Betracht ziehen — beide Maßnahmen ergänzen sich sinnvoll.

„Sicherheit ist kein Zustand, den man erreicht — es ist ein Prozess, den man aufrechterhält. Das gilt für MCP-Server genauso wie für jeden anderen Teil der IT-Infrastruktur.“ — SANS Institute, State of AI Security (2025)

Fallbeispiel: Vom unsicheren Prototyp zum produktionsreifen MCP Server

Ein mittelständisches Softwareunternehmen aus München rollte Anfang 2025 einen KI-Agenten für den internen Helpdesk aus. Der MCP Server hatte Zugriff auf das Ticketsystem, die Wissensdatenbank und — versehentlich — auf das interne HR-System. Keine Token-Validierung, keine Audit-Logs, alle Tools aktiv.

Drei Wochen nach Go-Live: Ein Mitarbeiter formulierte eine Supportanfrage mit eingebettetem Injection-Text. Der Agent rief daraufhin HR-Daten ab und fügte sie in eine automatisch generierte E-Mail ein. Kein Datenverlust nach außen, aber ein interner Datenschutzvorfall, der das Unternehmen 40 Stunden Aufarbeitung kostete.

Das Team führte daraufhin einen vollständigen MCP Security Scan durch. Ergebnis: 14 Findings, davon 3 kritisch. Nach zwei Wochen Remediation — Tool-Permissions eingeschränkt, Input-Validierung implementiert, Logging aktiviert — war der Server produktionsreif. Seitdem: null Sicherheitsvorfälle in 12 Monaten.

Ihre nächsten Schritte

Beginnen Sie heute, nicht nächste Woche. Drei konkrete Aktionen für die nächsten 24 Stunden: Erstens, exportieren Sie die Tool-Permission-Liste jedes produktiven MCP Servers und deaktivieren Sie alles, was nicht aktiv gebraucht wird. Zweitens, starten Sie semgrep --config=p/mcp-security gegen Ihr Server-Repository — 30 Minuten Aufwand, sofort verwertbare Ergebnisse. Drittens, prüfen Sie, ob Ihre MCP-Server Audit-Logs schreiben. Falls nein, ist das der erste Fix.

Für die kommenden zwei Wochen: Arbeiten Sie die Bewertungsmatrix aus diesem Artikel für jeden Server ab und dokumentieren Sie den Score. Alles unter 10 Punkten braucht einen Remediation-Plan mit klarer Deadline. Alles unter 6 Punkten gehört bis zur Behebung offline.