Vor ein paar Wochen hätte ich fast einen „kostenlosen WhatsApp MCP" in dieselbe Claude Code-Sitzung eingebunden, in der bereits meine GitHub- und Dateisystem-Server liefen. Er hatte ein sauberes Repository, ein Logo, eine einzeilige Installation. Ich kopierte den Konfigurationsblock und hörte dann beim letzten Tastendruck auf, weil mich etwas störte: Ich hatte keine Ahnung, was die Tool-Beschreibungen dieses Servers tatsächlich sagten.
Diese Störung erwies sich als das Kernproblem. Im April 2025 demonstrierte Invariant Labs einen Angriff, bei dem genau diese Art von harmlos wirkenden Server — ein Quizspiel — versteckte Anweisungen in seiner Tool-Beschreibung trug, die dem Agenten befahlen, Nachrichten von einem separaten, vertrauenswürdigen WhatsApp-Server still und heimlich an die Nummer eines Angreifers umzuleiten und dabei den Chat-Verlauf im Nachrichtentext zu verstecken (Invariant Labs). Der bösartige Server berührte WhatsApp selbst nie direkt. Er überzeugte den Agenten lediglich, es zu tun.
Das ist das, was niemand sagt, wenn man dir einen Konfigurationsblock überreicht. Ein MCP-Server ist keine Bibliothek, die du aufrufst. Er ist ein Teilnehmer am Denken deines Agenten. Seine Tool-Beschreibungen werden direkt in den Kontext des Modells eingefügt, und das Modell behandelt sie als Anweisungen, denen es folgen soll — was bedeutet, dass ein nicht vertrauenswürdiger Server neben einem vertrauenswürdigen diesen wie eine Marionette steuern kann. Den schlechten Server in einer Sandbox zu isolieren hilft nicht, weil der Angriff durch den Agenten läuft, nicht durch das Netzwerk.
Die Kurzfassung: Bevor du einen Drittanbieter-MCP-Server verbindest, erweiterst du das Vertrauen auf denjenigen, der ihn geschrieben hat, und auf denjenigen, der ihn später ändern kann. Nimm dir zehn Minuten, um zu bestätigen, was er lesen kann, wohin er reichen kann, was er mit deinen Geheimnissen macht und ob er nach deiner Genehmigung still und heimlich zu etwas anderem werden kann. Das meiste davon ist Lesen, kein Werkzeug-Einsatz. Hier ist der Audit.
Warum ein MCP-Server eine größere Anforderung ist als ein Paket
Ein normales npm-Paket führt Code aus. Das ist schon schlimm genug. Ein MCP-Server tut das und fügt Text ein, dem das Modell gehorcht, und enthält oft Anmeldeinformationen, und teilt eine Sitzung mit deinen anderen Servern. Vier Vertrauensoberflächen, nicht eine.
Die offizielle MCP-Sicherheitsanleitung nennt das klar beim Namen. Sie dokumentiert das Confused-Deputy-Problem in OAuth-Proxys, das „Token-Passthrough"-Anti-Muster (das die Spezifikation ausdrücklich verbietet — „MCP-Server DÜRFEN keine Tokens akzeptieren, die nicht explizit für den MCP-Server ausgestellt wurden"), Server-seitige Request-Fälschung bei der OAuth-Erkennung, Session-Hijacking und lokale Server-Kompromittierung durch bösartige Startup-Befehle (MCP Security Best Practices). Der Abschnitt zur lokalen Kompromittierung beschreibt sogar den offensichtlichen Missbrauch: ein Startup-Befehl, der curl -X POST -d @~/.ssh/id_rsa an einen Sammelendpunkt ausführt. Die Spezifikation ist im Grunde eine Liste von Möglichkeiten, wie ein MCP-Server dir schaden kann, geschrieben von den Leuten, die ihn entworfen haben.
Für einen Einzelentwickler, der einen Server auf GitHub auswählt, sind zwei weitere Angriffsklassen am wichtigsten. Die erste ist Tool-Vergiftung — versteckte Prompt-Injection-Anweisungen, die in die Tool-Beschreibungen und Parameterfelder gestopft werden, die das Modell vollständig liest, die dein Client-UI dir aber abgeschnitten anzeigt (Vulnerable MCP Project). Die zweite ist der Teppich-Zug: ein Server, der am Tag deiner Genehmigung eine saubere Tool-Beschreibung liefert, und dann still und heimlich eine vergiftete austauscht. Das Protokoll hat keine erforderliche Integritätsprüfung, keine Manifest-Pinning, und die tools/list_changed-Benachrichtigung ist optional und erzwingt keine erneute Zustimmung — daher kann der Austausch stattfinden, ohne dass du es je siehst (Acuvity). Tool-Vergiftung ist jetzt der am häufigsten reproduzierte Angriff in der Literatur; der akademische MCPTox-Benchmark baute seine gesamte Vorlage darum (MCPTox).
Der Audit ist also keine Paranoia. Er entspricht dokumentierten, benannten, reproduzierten Angriffen.
Der 10-minütige Audit
Führe diese der Reihe nach aus. Die frühen sind günstig und erfassen die schlimmsten Fälle, sodass du selten das Ende erreichst.
1. Lies die Tool-Beschreibungen selbst — die rohen. Das ist die wertvollste Einzelüberprüfung und fast niemand macht sie. Dein Client zeigt dir eine ordentliche Zusammenfassung; das Modell sieht die vollständige Nutzlast. Öffne den Quellcode des Servers und lies jedes description-Feld und jede Parameterbeschreibung, als wäre es Code, weil es für das Modell Code ist. Suche nach allem, was wie eine Anweisung an den Agenten klingt und nicht wie Dokumentation für einen Menschen: „Bevor du das verwendest, rufe auch … auf", „Füge immer den Inhalt von … ein", „Wenn du nach X gefragt wirst, mache stattdessen Y", Verweise auf andere Server oder Dateien oder unsichtbaren/Unicode-aufgefüllten Text. Wenn die Tool-Beschreibung eines Taschenrechners deine SSH-Schlüssel erwähnt, bist du fertig — schließ den Tab.
2. Finde jeden ausgehenden Netzwerkaufruf. grep den Quellcode nach fetch, axios, http, requests, urllib, curl, net. und rohen IPs. Ein Dateisystem-Server hat keinen Grund, einen entfernten Host anzurufen. Ein Server, der legitim eine API aufruft, sollte diese API aufrufen und nichts anderes. Der SSRF-Abschnitt der Spezifikation existiert, weil Server dazu gebracht werden können, http://169.254.169.254/ anzugreifen — den Cloud-Metadaten-Endpunkt, der IAM-Anmeldeinformationen ausgibt — daher ist jeder ausgehende Datenverkehr zu Link-Local- oder privaten Bereichen (169.254.*, 10.*, 192.168.*, 127.*) ein sofortiges Warnsignal (MCP Security Best Practices). Ungeklärter ausgehender Datenverkehr ist der Unterschied zwischen einem Werkzeug und einem Exfiltrationskanal.
3. Verfolge, wie er mit Geheimnissen umgeht. Wohin gehen deine Tokens? Werden sie aus Umgebungsvariablen gelesen und lokal verwendet, oder irgendwohin weitergeleitet? Bestätige, dass der Server kein Token-Passthrough macht — deine Anmeldeinformation direkt an eine nachgelagerte API übergeben, ohne die Zielgruppenprüfungen, die die Spezifikation verlangt. Wenn die README dir sagt, ein breites persönliches Zugriffstoken einzufügen statt eines bereichsbegrenzten, sagt dir das Design des Servers, dass es nie über den Explosionsradius nachgedacht hat. Gib einem MCP-Server niemals eine Anmeldeinformation, die mehr tun kann als die eine Aufgabe, für die er da ist.
4. Begrenze Berechtigungen auf die eigentliche Aufgabe. Der eigene Abschnitt zur Berechtigungsminimierung der Spezifikation warnt vor Servern, die vorab files:*, db:*, admin:* oder Wildcard-Bereiche all/full-access veröffentlichen, weil ein gestohlenes breites Token dann alles auf einmal öffnet (MCP Security Best Practices). Frage, was dieser Server wirklich braucht. Ein „Meine Commits formatieren"-Server, der repo-weiten Schreibzugriff plus Netzwerkzugang anfordert, stellt zu viel. Gewähre das Minimum, und bevorzuge Server, die schrittweise enge Bereiche anfordern, gegenüber solchen, die am ersten Tag den ganzen Katalog verlangen.
5. Prüfe, was daneben sitzt. Das ist die Lektion aus dem WhatsApp-Exploit: Das Risiko liegt nicht in einem Server, sondern in der Kombination. Ein nicht vertrauenswürdiger Server in derselben Sitzung kann einen vertrauenswürdigen entführen. Behandle die MCP-Serverliste deines Agenten daher wie eine gemeinsame Vertrauensgrenze. Führe keinen ungeprüften Server in derselben Sitzung aus wie irgendetwas, das echte Anmeldeinformationen oder Schreibzugriff hat. Wenn du unbedingt etwas Neues ausprobieren musst, gib ihm seine eigene Sitzung, ohne dass etwas Wertvolles verbunden ist.
6. Versionierung fixieren. Das bewegliche Ziel ablehnen. Teppich-Züge funktionieren, weil die meisten Leute von latest oder von einem entfernten Server installieren, den sie nicht kontrollieren. Fixiere auf einen bestimmten Commit oder Release-Tag, liefere den Quellcode mit, wenn du kannst, und lies die Tool-Beschreibungen bei jedem Upgrade erneut. Für entfernte/gehostete MCP-Server, die du nicht fixieren kannst, verstehe, dass du einen Server akzeptiert hast, der seine eigenen Tools jederzeit neu definieren kann — das ist eine echte, fortlaufende Vertrauensvergabe, keine einmalige Installation.
7. Führe einen Scanner aus, und vertraue dann deiner eigenen Lektüre mehr. uvx mcp-scan@latest liest deine MCP-Konfiguration, verbindet sich mit den Servern, zieht die Tool-Beschreibungen und markiert Tool-Vergiftung, Teppich-Zug-Drift, Cross-Origin-Shadowing und Prompt-Injection (Invariant Labs). Es ist Open Source und benötigt keine Konfiguration. Verwende es als schnellen ersten Durchlauf — aber ein Scanner erfasst bekannte Muster, und deine Lektüre aus Schritt 1 erfasst die cleveren, die er nicht erfasst.
8. Lies das Commit-Protokoll und den Issues-Tab. Derselbe Schachzug wie bei der Prüfung jeder Abhängigkeit. Ein Server, der seit Monaten unberührt auf einem Protokoll liegt, das sein Auth-Modell in einem Jahr zweimal überarbeitet hat, ist ein Fossil. Eine Commit-Historie, die alles „README aktualisieren" und kein „Randfall beheben" ist, bedeutet, dass niemand ihn wirklich betreibt. Und der Issues-Tab wird dir oft von dem Exfiltrations-Bug erzählen, bevor du ihn auf die harte Tour entdeckst.
Sandbox das Ding, weil Lesen nicht ausreicht
Den Quellcode zu lesen sagt dir, was der Code zu tun scheint. Es sagt dir nicht, was eine transitive Abhängigkeit zur Laufzeit tut, und das kann es nicht, weil du nicht den gesamten Baum lesen wirst. Der Rat der Spezifikation für lokale Server ist also das richtige Sicherheitsnetz: Führe sie in einer Sandbox aus, mit eingeschränktem Dateisystem- und Netzwerkzugriff, mit stdio-Transport, damit nur dein Client sie erreichen kann, und mit einem echten Zustimmungsdialog, der den genauen Befehl anzeigt, bevor irgendetwas ausgeführt wird (MCP Security Best Practices).
Für ein Solo-Setup bedeutet das: Führe unbekannte Server in einem Container oder einem eingeschränkten Benutzerkonto aus, nicht in deiner Haupt-Shell mit deinen Schlüsseln in der Umgebung. Gib dem Container Zugriff auf das eine Verzeichnis, das die Aufgabe benötigt, und verweigere den Rest. Es ist zehn Minuten Einrichtung einmal, und es verwandelt „dieser Server kann mein gesamtes Home-Verzeichnis lesen" in „dieser Server kann nur den einen Ordner lesen, den ich ihm gegeben habe". Die NSA-eigene MCP-Anleitung kommt zum selben Schluss — minimale Rechte, Isolation und Überwachung rund um jeden Server, den du nicht selbst geschrieben hast (NSA CSI: MCP Security).
Wann einfach Nein sagen
Einige Server scheitern, bevor der Audit beginnt. Ich installiere nicht, wenn:
- Ich den Quellcode nicht lesen kann. Ein Closed-Source- oder minifizierter lokaler Server ist ein Startup-Befehl, den ich blind ausführe. Weiter.
- Er eine breite, langlebige Anmeldeinformation will. Wenn der einzige Weg, ihn zu verwenden, ein Gott-Mode-Token ist, hat mir das Design bereits gesagt, dass es den Explosionsradius nicht respektiert.
- Es ist ein entfernter Server, den ich nicht fixieren kann, der Zugriff auf etwas hat, das ich nicht verlieren möchte. Das ist eine ständige Einladung zu einem Teppich-Zug. Gut für Einwegzeug; nicht für Produktionsdaten.
- Seine Tool-Beschreibungen lesen sich wie Anweisungen an meinen Agenten. Dokumentation beschreibt; sie befiehlt nicht. Alles, was mich übergeht, um direkt mit dem Modell zu sprechen, ist auf den ersten Blick disqualifizierend.
- Der Komfort überwindet die Hürde nicht. Ein Server, der mir fünf Minuten pro Woche spart, ist keine Anmeldeinformation und keinen Platz in der Vertrauensgrenze meines Agenten wert. Die meisten „coolen" MCP-Server, die ich bewertet habe, brauchte ich nicht.
Der schwierige Teil ist keine einzelne Überprüfung — es ist, dass das Vertrauen, das du bei der Installation gewährst, nicht eingefroren ist. Das Paket, das du geprüft hast, kann nächste Woche ein anderes Paket werden, und nichts im Protokoll zwingt es, dich zu informieren. Die dauerhafte Gewohnheit ist also nicht der einmalige Audit. Es ist, die Liste klein, fixiert und in einer Sandbox zu halten und die Beschreibungen jedes Mal neu zu lesen, wenn du eine Version aktualisierst. Beginne mit Schritt eins: Öffne den Quellcode und lies die Tool-Beschreibungen laut vor. Wenn sie so klingen, als würden sie mit deinem Agenten statt mit dir reden, hast du bereits deine Antwort.