Der blinde Fleck bei der schnellsten Adoption-Welle 2026
MCP-Server installiert man in Sekunden. Ein Copy-Paste-Befehl aus einem README, ein Neustart des Clients, fertig — der Agent hat jetzt Zugriff auf GitHub, die eigene Datenbank, das Dateisystem oder externe APIs. Bei klassischer Software prüfen die meisten zumindest kurz, wer der Autor ist, ob es Reviews gibt, welche Berechtigungen sie verlangt. Bei MCP-Servern fällt dieser Reflex oft komplett weg — der Befehl sieht harmlos aus, das Ergebnis wirkt sofort nützlich.
Das Problem: Ein MCP-Server bekommt nicht nur Zugriff auf Daten, er bekommt Einfluss auf das Modell selbst. Seine Tool-Beschreibungen sind Text, den das Modell als Anweisung liest — genau wie deinen Prompt. Die OWASP-Foundation hat das im Laufe von 2025 systematisiert und einen eigenen MCP-Top-10-Katalog veröffentlicht, unabhängig vom allgemeinen LLM-Top-10. Zehn Kategorien, hier als zehn selbst testbare Checkpunkte für dein eigenes Setup.
Wenn du noch nicht weißt, was MCP grundsätzlich ist: Dazu gibt es einen eigenen Einstiegs-Artikel in der Coding-Kategorie. Hier geht's direkt in die Sicherheitsseite.
Die zehn Checkpunkte
MCP01 — Token Mismanagement & Secret Exposure Test: Prüfe, wo OAuth-Tokens oder API-Keys landen, die ein MCP-Server für dich hält (Gmail-, GitHub-, Slack-Anbindung). Landen sie im Klartext in einer lokalen Config-Datei, in Logs oder in Prozess-Umgebungsvariablen, die andere lokale Prozesse auslesen können? Pass-Kriterium: Tokens liegen verschlüsselt oder in einem OS-Keychain, nicht als Plaintext-Datei im Repo- oder Home-Verzeichnis.
MCP02 — Privilege Escalation via Scope Creep Test: Vergleiche die angeforderten OAuth-Scopes mit dem, was der Server laut Beschreibung tatsächlich braucht. Ein "Kalender lesen"-Tool, das gleich Vollzugriff auf das ganze Google-Workspace-Konto verlangt, ist Scope Creep. Pass-Kriterium: Minimal-Scope, dokumentiert und nachvollziehbar begründet.
MCP03 — Tool Poisoning Test: Lies die vollständigen Tool-Beschreibungen als Rohtext (siehe HowTo oben), nicht nur die gekürzte Client-Ansicht. Suche nach Anweisungen, die sich an das Modell statt an dich richten. Pass-Kriterium: Keine versteckten Imperative, keine Anweisungen die zusätzliche, unbeschriebene Aktionen triggern.
MCP04 — Software Supply Chain Attacks & Dependency Tampering
Test: Prüfe, wie der MCP-Server selbst installiert wird — gepinnte Version oder latest? Signierte Releases? Wie viele transitive Dependencies zieht ein npx-Aufruf nach?
Pass-Kriterium: Gepinnte, verifizierbare Version. Kein npx paket@latest in produktiven Setups (RULE-17-Analogon: keine ungepinnten Dependencies, gilt auch hier).
MCP05 — Command Injection & Execution Test: Wenn ein Tool Shell-Befehle, Code oder Queries mit vom Modell generierten Parametern ausführt: Kannst du durch geschickt formulierten Chat-Input Sonderzeichen einschleusen, die die Befehlsgrenze durchbrechen? Pass-Kriterium: Parametrisierte Ausführung, keine String-Konkatenation in Shell- oder SQL-Kontext.
MCP06 — Intent Flow Subversion Test: Kann ein Tool-Output (z. B. der Inhalt einer abgerufenen Webseite oder Datei) die nächste Entscheidung des Agenten so umlenken, dass er von der ursprünglichen Nutzer-Absicht abweicht, ohne dass das auffällt? Pass-Kriterium: Tool-Outputs werden als nicht-vertrauenswürdiger Kontext markiert, nicht als gleichwertig zur System-Instruktion behandelt.
MCP07 — Insufficient Authentication & Authorization Test: Läuft der MCP-Server über HTTP/SSE statt stdio — ist der Endpunkt authentifiziert? Reicht ein erratener oder öffentlicher Endpunkt, um Tools aufzurufen? Pass-Kriterium: Auth-Pflicht auf Transport-Ebene, nicht nur auf Anwendungsebene.
MCP08 — Lack of Audit and Telemetry Test: Gibt es ein Log, welches Tool wann mit welchen Parametern aufgerufen wurde? Könntest du im Nachhinein rekonstruieren, was ein Agent in den letzten 24 Stunden über welchen Server getan hat? Pass-Kriterium: Mindestens lokales Aufruf-Log mit Zeitstempel, Tool-Name, Parametern.
MCP09 — Shadow MCP Servers Test: Läuft irgendwo ein MCP-Server, der nicht zentral erfasst ist — von einem Teammitglied testweise verbunden, nie wieder entfernt? Bei mehreren gleichzeitig verbundenen Servern: Kann einer die Tool-Beschreibungen eines anderen "überschreiben" oder in dessen Namen auftreten (Shadowing)? Pass-Kriterium: Zentrale Liste aller autorisierten Server, regelmäßiger Abgleich mit tatsächlich verbundenen.
MCP10 — Context Injection & Over-Sharing Test: Bekommt ein Tool mehr vom Konversationsverlauf oder Systemkontext übergeben, als es für seine Aufgabe braucht? Landen z. B. vorherige, unrelated sensible Nachrichten im Payload eines externen API-Aufrufs? Pass-Kriterium: Tools bekommen nur den Kontext, den ihre Funktion erfordert — kein pauschales "ganzer Chatverlauf mitschicken".
Der Rug-Pull-Sonderfall
MCP03 (Tool Poisoning) hat eine gemeine Variante, die eigene Erwähnung verdient: den Rug Pull. Ein Server verhält sich beim ersten Connect vollkommen sauber — du prüfst die Tool-Beschreibungen, gibst frei, alles gut. Das Protokoll erzwingt aber nirgendwo, dass diese Definitionen stabil bleiben. Der Server kann sie später, nach deiner Freigabe, serverseitig ändern und schädliche Anweisungen nachträglich einschleusen. Dein Client merkt das nur, wenn er aktiv gegen einen gespeicherten Stand prüft — die wenigsten tun das automatisch.
Praktische Konsequenz: Freigabe ist kein einmaliger Akt. Wer MCP-Server in einem Team oder produktiv einsetzt, sollte Tool-Definitionen versionieren (Hash oder vollständiger Text) und bei jedem Reconnect diffen, nicht nur beim ersten Mal hinschauen.
Vor der nächsten npx <mcp-server>-Installation
Kurzcheck, bevor ein neuer Server in einem Setup mit echtem Dateisystem- oder Netzwerkzugriff landet:
- Quellcode einsehbar und tatsächlich gelesen (nicht nur README überflogen)?
- Version gepinnt, nicht
@latest? - Tool-Beschreibungen vollständig gelesen, nicht nur die gekürzte UI-Ansicht?
- Angeforderte Scopes/Berechtigungen minimal für die beworbene Funktion?
- In einer isolierten Umgebung testweise verbunden, bevor er an ein Setup mit echten Zugangsdaten geht?
Fünf Punkte, die sich in fünf Minuten prüfen lassen und die klassische "Tool-Poisoning trifft ungeprüftes Setup"-Kombination zuverlässig verhindern.
Praktische Einordnung
Das ist kein Grund, MCP zu meiden — die Coding-Kategorie hier zeigt genug Beispiele, wo es echten Workflow-Wert bringt. Es ist ein Grund, MCP-Server mit derselben Skepsis zu behandeln wie jede andere Software, die volle Rechte auf deinem System bekommt — nicht mit der Sorglosigkeit, die ein einzeiliger Installationsbefehl suggeriert. Die zehn Punkte oben laufen in unter einer Stunde für ein typisches Setup mit drei bis fünf Servern durch.
Wer eigene MCP-Server baut oder produktiv gegen mehrere Server gleichzeitig testet: In der Zone "Hacking & Security" und in "Coding & Projekte" im Discord landen beide Perspektiven — die, die MCP-Server bauen, und die, die sie brechen wollen bevor es jemand anderes tut.
