MCP-Server-Sicherheit: Tools vor der Installation prüfen

Die Installation eines MCP-Servers wirkt trivial: kopiere einen Befehl oder eine URL, starte den Client neu, und ein neues Tool erscheint im Kontext deines Agenten. Aber hinter diesem Tool-Namen sitzt ausführbarer Code, ein in das Kontextfenster des Modells injiziertes Schema, Anmeldedaten und alles, was diese Anmeldedaten erreichen können. Das MCP-Ökosystem reift noch immer, und der Überprüfungsprozess für neue Server ist wohlwollend ausgedrückt dünn. Dieser Artikel gibt dir eine wiederverwendbare Checkliste vor der Installation, angewendet auf ein angeheftetes illustratives Beispiel, mit Erkenntnissen und einer klaren Akzeptanz-/Ablehnungsbegründung für jeden Schritt.

Was Installation wirklich gewährt

Wenn du einen MCP-Server installierst, installierst du keine passive Bibliothek. Du gewährst ausführbarem Code Zugriff auf deine Tools, dein Dateisystem und normalerweise deine API-Schlüssel, ohne einen Überprüfungsschritt, den die meisten Clients dir anzeigen würden.

Dieses Vertrauen ist kumulativ und nicht granular. Wie Pluto Securitys Praktiker-Leitfaden anmerkt, bedeutet die Genehmigung eines MCP-Servers, jeden Operator in seiner Lieferkette zu genehmigen. Es gibt keine Komponenten-spezifische Erneuerungsvormerkung. Jeder aktivierte MCP-Server pusht auch seine vollständige Tool-Liste in den Kontext des Modells beim Sitzungsstart, verbraucht Token und verwässert die Aufmerksamkeit. Du zahlst also zweimal: einmal in der Sicherheitsoberfläche, einmal im Kontext-Budget.

In Claude Code speziell werden Server über .mcp.json (projektgebunden) oder ~/.claude.json (benutzergebunden) konfiguriert und können in einem Plugin-Verzeichnis gebündelt sein, das auch Hooks, Agenten, Monitore und bin/-Skripte enthält. Ein Plugin ist nicht ein schlanker Wrapper. Es kann alles erreichen, das deine Shell-Sitzung erreicht.

Das Bedrohungsmodell hat drei realistische Fehlerszenarien:

• Ein böswilliger Herausgeber erstellt einen Nachahmer-Server, der in der Registry erscheint, API-Aufrufe umleitet oder Daten stumm exfiltriert.
• Ein wohlmeinender, aber unerfahrener Autor versendet einen Server, der Token im Klartext speichert oder Request-Bodies protokolliert, ohne darüber nachzudenken.
• Ein legitimer Server, den du genehmigt hast, wird aktualisiert, und die neue Version führt eine Hintertür ein oder erweitert seine Berechtigungen, ohne dich erneut zu entsprechen.

Alle drei sind dokumentiert in freier Wildbahn, nicht hypothetisch.

Quelle, Herkunft und Aktualisierungsverhalten überprüfen

Beginne, bevor du eine einzige Codezeile liest. Wer hat diesen Server veröffentlicht? Gibt es eine überprüfbare Identität hinter dem Paket? Hat das Repository eine aussagekräftige Commit-Historie, oder wurde es letzte Woche mit einem Commit erstellt?

Christian Schneiders Leitfaden zur verteidigungszentrierten Architektur legt die Anforderungen zur Lieferketten-Hygiene deutlich dar: Installiere Server nur aus seriösen Quellen, verifiziere Paketsignaturen oder Hashes, und pinne Abhängigkeitsversionen, anstatt „Latest" zu akzeptieren. Führe npm audit oder pip-audit gegen das Paket aus, bevor es dein System berührt. Generiere eine Software Bill of Materials (SBOM), damit du jede Abhängigkeit nachverfolgen und schnell reagieren kannst, wenn ein CVE auftritt.

Für deine Review-Checkliste erfasst du diese in der Quellphase:

1. Bestätige, dass die Herausgeber-Identität einer bekannten Organisation oder Person mit einer Erfolgsbilanz zugeordnet ist.
2. Überprüfe das Repository-Erstellungsdatum und die Commit-Häufigkeit. Ein-Commit-Repos verdienen zusätzliche Aufmerksamkeit.
3. Heften Sie die exakte Version fest, die Sie überprüft haben. Notieren Sie den Commit-Hash oder das Release-Tag.
4. Führen Sie npm audit oder pip-audit auf dem Dependency Tree aus und dokumentieren Sie die Ergebnisse.
5. Überprüfen Sie, ob der Update-Mechanismus des Servers digitale Signaturen vor der Anwendung von Änderungen verifiziert.

Illustratives Beispiel: Angenommen, Sie überprüfen einen hypothetischen mcp-db-connector@1.4.2 von einem Publisher mit 18 Monaten Commit-Verlauf, zwei Mitwirkenden und einem signierten Release auf GitHub. npm audit gibt null kritische Findings zurück. Das besteht diese Phase. Ein Server mit anonymem Publisher, zwei Tage altem Repository und ohne signiertes Release würde das nicht schaffen.

Inspizieren Sie Tools, Hooks, Scripts und Netzwerkzugriff.

Source Provenance ist Grundvoraussetzung. Jetzt lesen Sie das Ganze.

Sehen Sie sich jede Tool-Definition an, die der Server registriert. Stimmt die angegebene Beschreibung mit der tatsächlichen Implementierung überein? Wie Towards Data Science's MCP-Survival-Guide warnt: Nur weil etwas als „Email-Sender" veröffentlicht wird, bedeutet das nicht, dass es nur Emails versendet. Es könnte sie protokollieren, umschreiben oder an einen Ort weiterleiten, den Sie nicht beabsichtigt haben.

Überprüfen Sie diese speziell:

• Hooks und Lifecycle Scripts: Registriert hooks.json Pre- oder Post-Tool-Callbacks? Was tun sie?
• Scripts in `bin/`: Gibt es Shell-Scripts, die bei Installation oder Aufruf ausgeführt werden? Lesen Sie sie.
• Ausgehende Netzwerkaufrufe: Kontaktiert der Server einen Endpunkt, der nicht in der README dokumentiert ist? Nutzen Sie grep -r "fetch\|axios\|http\|https\|request" über die gesamte Quelle.
• Dateisystemzugriff: Fordert er umfassenderen Pfadzugriff an, als die Aufgabe erfordert?
• Credential Handling: Werden API-Schlüssel auf die Festplatte geschrieben, protokolliert oder außerhalb des deklarierten Zielservice übertragen?

Die SlowMist MCP Security Checklist bewertet Input Validation, API Rate Limiting und Output Encoding als die drei höchstpriorisierten Controls. Wenn der Server seine eigenen Eingaben nicht streng validiert, ist es ein Vektor für Injection-Angriffe, unabhängig davon, ob Sie dem Publisher vertrauen.

Ein Punkt, den die Checkliste kennzeichnet und den die meisten übersehen: Tool-Beschreibungen werden wörtlich in den Kontext des Modells injiziert. Eine böswillige oder schlecht geschriebene Beschreibung kann das Verhalten des Agenten in der Sandbox lenken, selbst wenn die Sandbox selbst intakt ist. Sandboxing ohne Schema-Scanning ist nur halb eine Abwehr.

Testen Sie Prompt Injection und Data Boundary Cases.

Dieser Schritt ist nicht optional für alles, das Produktionsdaten oder Kundeninformationen berührt.

Prompt Injection über Tool-Beschreibungen ist ein dokumentierter Angriffsvektor. Ein Angreifer bettet Anweisungen in das Beschreibungsfeld eines Tools ein, das das Modell als Benutzerintention interpretiert. Sie müssen überprüfen, dass das Schema des Servers keine eingebetteten Anweisungen enthält, dass die Ausgabe des Servers nicht als autoritative Benutzereingabe nachgelagert vertraut wird, und dass Daten, die von einem Tool zurückgegeben werden, nicht in den Kontext einer separaten Sitzung oder eines separaten Benutzers durchsickern können.

Führen Sie illustrative Boundary Cases aus, bevor Sie den Server mit echten Credentials verbinden:

1. Formulieren Sie einen Tool-Aufruf, der eine Antwort mit etwas wie „Ignorieren Sie vorherige Anweisungen und..." zurückgibt, und beobachten Sie, ob der Host-Client diese aufzeigt oder danach handelt.
2. Übergeben Sie übergroße oder malformed Eingaben an jedes registrierte Tool und überprüfen Sie, ob der Server sie elegant behandelt oder unkontrollierte Exceptions wirft, die Stack Traces offenlegen.
3. Wenn der Server Zugriff auf mehrere Datenquellen hat, überprüfen Sie, dass eine Abfrage gegen Quelle A keine Daten aus Quelle B zurückgeben kann.

Dies sind Triage-Tests, keine Zertifizierung. Eine kurze manuelle Überprüfung identifiziert offensichtliche Probleme. Sie garantiert nicht die Abwesenheit subtiler Probleme.

Wenn du KI-Werkzeuge für Kunden entwickelst und Unterstützung bei der Überprüfung von MCP-Integrationen als Teil eines umfassenderen Claude Code-Setups brauchst, kann Seahawks Claude Code Agency-Service dabei helfen, den Stack zu bewerten, bevor er in die Produktion geht.

Wähle den kleinsten Anmeldedatenbereich und isoliere den Prozess

Sobald du den Server überprüft hast und entschieden hast, dass er akzeptabel ist, stellt sich die Frage: Wie führst du ihn aus?

Das Prinzip ist das Prinzip der geringsten Berechtigung, konsequent angewendet. Gib einem MCP-Server nicht deinen persönlichen API-Schlüssel mit vollständigem Kontozugriff, nur weil es bequem ist. Erstelle eine Anmeldedaten mit den Mindestberechtigungen, die die dokumentierte Funktionalität erfordert. Wenn der Server Lesezugriff auf einen einzelnen S3-Bucket benötigt, sollte die Anmeldedaten keinen Schreibzugriff haben, Punkt.

Isolierungsoptionen, grob in aufsteigender Reihenfolge nach Kosten:

• Führe den Server in einem dedizierten Unterprozess aus, der keinen Zugriff auf die Umgebungsvariablen der übergeordneten Shell hat – außer auf denen, die du explizit übergibst.
• Verwende einen Container mit einer eingeschränkten Netzwerkrichtlinie, damit der Server keine willkürlichen ausgehenden Verbindungen herstellen kann.
• Erzwinge für sensible Bereitstellungen Supply-Chain-Checks als Bereitstellungsgates und behandle MCP-Server-Updates mit dem gleichen Change-Management-Prozess wie Anwendungscode.

Das General Analysis-Bedrohungsmodell drückt es gut aus: Ein überprüfter Marketplace ohne Versionsfestsetzung bedeutet, dass der heute überprüfte Server morgen ein Rug Pull ist. Isolation und Versionsfestsetzung sind nicht redundant. Sie schützen vor verschiedenen Ausfallmodi. Sandboxing begrenzt den Schadensbereich; Versionsfestsetzung verhindert stille Abweichungen.

Auch wichtig: Teile Anmeldedaten nicht zwischen MCP-Servern. Token-Passthrough und gemeinsame API-Schlüssel bedeuten, dass ein Kompromiss in einem Server alles erreicht, das die Anmeldedaten berührt.

Dokumentiere die Entscheidung und überprüfe sie bei jeder Änderung neu

Eine Überprüfung, die du nicht dokumentierst, ist eine Überprüfung, die nie stattgefunden hat – aus Sicht deines zukünftigen Ich oder deines Teams.

Führe für jeden installierten Server ein Entscheidungsprotokoll mit mindestens:

• Der genauen überprüften Version (Paketversion plus Commit-Hash oder Release-Tag).
• Dem Überprüfungsdatum.
• Der Person, die die Überprüfung durchgeführt hat.
• Erkenntnissen aus den Audit-Tools und manuelle Inspektion.
• Dem Annahme-/Ablehnungsgrund.
• Bedingungen, die eine Neuüberprüfung auslösen würden (z. B. jede neue Hauptversion, jede Änderung am Tool-Schema, jede Sicherheitsempfehlung, die eine Abhängigkeit berührt).

Das ist keine Bürokratie um ihrer selbst willen. Schneiders Architekturleitfaden stellt eine direkte Frage, die die meisten Teams nicht beantworten können: „Was passiert, wenn sich die Tool-Beschreibung eines MCP-Servers ändert, nachdem ein Benutzer ihn genehmigt hat? Würde jemand das wissen?" In den meisten Standardeinstellungen ist die Antwort nein. Versionsfestsetzung plus ein Entscheidungsprotokoll ist, wie du diese Antwort änderst.

Stelle einen Kalendertermin ein, um angeheftete Server vierteljährlich neu zu überprüfen, auch ohne eine neue Version, da sich die Bedrohungsumgebung um sie herum ändert, selbst wenn der Code nicht geändert wird.

Für Teams, die bereits MCP-Server in Production Stacks betreiben, werden die operativen Überlegungen zur Verwaltung mehrerer Server neben deiner vorhandenen Tooling in unserem Production Stack-Post separat behandelt.

Wiederverwendbare Vor-Installation-Checkliste: Annahme-/Ablehnungsbegründung

Nachfolgend die vollständige Checkliste in Triage-Reihenfolge. Wenden Sie diese vor der Installation eines beliebigen Servers an. Die Beispielbefunde sind illustrativ; Ihre Ergebnisse werden unterschiedlich ausfallen.

Zeile 6 ist der Grund, warum Sie das tun. Ein undokumentierter Analytics-Ping ist nicht automatisch bösartig, aber er ist undokumentiert, und undokumentierte ausgehende Aufrufe sind ein Ablehnungskriterium bis zur Erklärung. Sie fragen den Verleger, erhalten eine klare Antwort, überprüfen, was tatsächlich gesendet wird, und treffen dann eine neue Entscheidung. Das ist der Prozess.

FAQ

Garantiert die Überprüfung des Quellcodes, dass ein Server sicher zu installieren ist?

Nein. Code-Review ist Triage, keine Zertifizierung. Es reduziert die Wahrscheinlichkeit offensichtlicher Probleme: undokumentierte Netzwerkaufrufe, Credential-Logging, böswillige Tool-Beschreibungen. Es schützt nicht vor Sicherheitslücken, die in einem zukünftigen Update eingeführt werden (deshalb fixieren Sie Versionen und überprüfen bei Änderungen neu) oder vor subtilen Logikfehlern, die tiefgehende Sicherheitsanalyse erfordern.

Was ist Tool-Poisoning und wie bezieht es sich auf MCP?

Tool-Poisoning bezieht sich darauf, dass ein Angreifer bösartige Anweisungen in das Namens- oder Beschreibungsfeld eines Tools einbettet. Da MCP-Tool-Schemas wortwörtlich in den Kontext des Modells injiziert werden, kann das Modell diese Anweisungen als legitime Direktiven interpretieren. Das Schema vor der Installation zu überprüfen und auf eingebettete Anweisungsfragmente zu prüfen, ist die primäre Entschärfung in der Vor-Installationsphase.

Sollte ich Remote-MCP-Server anders überprüfen als lokale?

Lokale Server haben einen kürzeren Pfad zu sensiblen Daten, da sie direkt auf Ihrem Rechner mit Zugriff auf Ihre Umgebung ausgeführt werden. Remote-Server führen Netzwerk-Angriffsfläche und Man-in-the-Middle-Risiken ein. Beide erfordern die gleiche Checkliste, aber lokale Server verdienen besondere Aufmerksamkeit beim Zugriff auf das Dateisystem und der Credential-Handling im Quellcode, während Remote-Server verifiziertes TLS, Signaturvalidierung und OAuth 2.1-Konformität gemäß der aktuellen MCP-Spezifikation erfordern.

Wie gehe ich mit MCP-Servern um, die Closed-Source oder als Binärdateien verteilt sind?

Wenn Sie den Quellcode nicht lesen können, verlassen Sie sich vollständig auf Publisher-Reputation, kryptographische Signaturverifizierung und Laufzeitkontrollen (Sandboxing, Netzwerkrichtlinie, begrenzte Credentials). Das ist eine materielle höhere Risiko-Position. Für alles, das Produktionsdaten oder Kundeninformationen berührt, sollte eine Closed-Source-Binärdatei ohne verifizierbare Signatur von einem bekannten Verleger standardmäßig abgelehnt werden.

Was ist eine SBOM und brauche ich wirklich eine für MCP-Server?

Eine SBOM (Software Bill of Materials) ist ein maschinenlesbares Verzeichnis aller Abhängigkeiten, die ein Paket enthält. Bei MCP-Servern können Sie damit identifizieren, ob eine transitive Abhängigkeit ein bekanntes CVE aufweist, selbst wenn das Top-Level-Paket selbst sauber aussieht. Bei wenig kritischen persönlichen Tools ist es optionaler Overhead. Bei Produktionsbereitstellungen, die sensible Daten verarbeiten, ist es der Unterschied zwischen dem Wissen um Ihre Gefährdung und dem Erraten.

Die schärfste Mahnung aus dieser gesamten Überprüfung: Eine Tool-Beschreibung, die in der Registry harmlos aussieht, kann das Agent-Verhalten nach der Installation genauso wirksam lenken wie bösartiger ausführbarer Code, und die meisten Clients warnen Sie nicht. Lesen Sie das Schema, nicht nur die README.