Jeder MCP-Server, mit dem Sie sich verbinden, liefert eine tools/list-Antwort — ein JSON-Dokument, geschrieben von wem auch immer den Server gebaut hat — direkt und ungeprüft in den Kontext Ihres Modells. Fügen Sie diese Antwort in den Scanner von VeriSwarm ein und erhalten Sie in Sekunden 11 deterministische Prüfungen zurück: Tool-Poisoning, Typosquatting, Schema-Manipulation, Rug-Pull-Muster, Prompt-Injection, übermäßige Berechtigungen, Model Misbinding, Context Spoofing, verdeckte Kanäle, unsichere Speicherreferenzen und Header-Injection. Kein LLM, das über Ihre Tools urteilt — Muster- und Strukturanalyse, die jedes Mal dasselbe Urteil liefert.
MCP-Tool-Metadaten sind tragend. Das Modell entscheidet anhand des Beschreibungstexts, was und wie es aufgerufen wird — nicht anhand des dahinterliegenden Codes. Eine vergiftete Beschreibung muss nichts kompromittieren; der Angriff läuft vollständig im Reasoning des Modells ab. Der MCPTox-Benchmark hat dies gegen 45 reale MCP-Server und 353 echte Tools getestet und Angriffserfolgsraten von über 60 % gemessen, mit einem Höchstwert von 72 %. Tool-Beschreibungen mit bloßem Auge zu lesen, skaliert nicht über den ersten Server hinaus und übersteht keinen Rug Pull — einen Server, der sich während Ihrer Prüfung sauber verhält und beim nächsten Versionssprung etwas anderes ausliefert.
Sie decken die ursprünglichen Risikokategorien ab, für die der Scanner gebaut wurde — diejenigen, die am ehesten in einer vergifteten oder nachlässigen Tool-Definition auftauchen.
Versteckte Anweisungen in Beschreibungen und Parametertext — „ignoriere die vorherigen Anweisungen“, Verschleierungsanweisungen, Persona-Hijacks. Der Scanner durchläuft den gesamten Schemabaum, einschließlich Eigenschaften, die innerhalb von oneOf/anyOf-Zweigen verschachtelt sind, sodass eine vier Ebenen tief vergrabene Payload trotzdem auftaucht.
Tool-Namen, die verdächtig nah an bekannten Tools liegen — einschließlich Nachahmungen, die sich nur in Groß-/Kleinschreibung unterscheiden, wie READ_FILE, das sich als read_file ausgibt — etwas, das ein naiver Exact-Match-Vergleich vollständig übersieht.
Leere Objekt-Schemas, die beliebige Eingaben akzeptieren, additionalProperties: true, die versteckte Felder durchschlüpfen lässt, sowie Schema-Verschachtelungen von mehr als 4 Ebenen — ein gängiger Ort, um einen bösartigen Parameter zu verstecken.
Formulierungen, die Zugangsdaten, Tokens oder Zugriff auf sensible Dateien und interne Netzwerk-Endpunkte verlangen, den der angegebene Zweck des Tools nicht rechtfertigt — die Vorbereitung für eine spätere Umdefinition, sobald dem Tool vertraut wird.
Base64-Blobs, die sich zu lesbarem Text dekodieren lassen — Payload-Schmuggel — und Unicode-Homoglyphen, etwa ein kyrillisches а, das Ihr lateinisches a ersetzt, um Anweisungen an einer visuellen Prüfung vorbeizuschmuggeln.
Ein Tool, das als schreibgeschützt benannt oder beschrieben ist, aber die Parameter command, script oder sql akzeptiert, gibt eine Fähigkeit an und liefert eine andere.
Protokollspezifische Risiken, die die ursprünglichen sechs nicht abdecken. Über alle elf Prüfungen hinweg deckt der Scanner 9 der 10 Risiken der OWASP MCP Top 10 v0.1-beta (2025) ab. Das zehnte — MCP08, Lack of Audit and Telemetry — ist etwas, das eine statische Tool-Definition nicht zeigen kann; es ist eine Lücke im Laufzeit-Logging, keine Schema-Lücke.
Tools, die fest an ein bestimmtes Modell gebunden sind — „funktioniert nur mit GPT-4“ oder eine Kopplungspflicht an einen bestimmten System-Prompt. Erzeugt eine Routing-Abhängigkeit und eine modellspezifische Angriffsfläche.
Ein Tool, das behauptet, den Gesprächsverlauf umschreiben, gefälschte Turns einschleusen oder sich als Nutzer oder Assistent ausgeben zu können — Fähigkeiten, die Sicherheitsfilter und Audit-Trails gleichzeitig aushebeln können.
Nicht standardisierte Top-Level-Schlüssel, Vendor-Extension-Schemafelder (x-) und lange, in Beschreibungen eingebettete Base64-Blobs — Stellen, an denen ein Prüfer, der nach Fließtext sucht, nicht hinschaut.
Formulierungen, die globalen, geteilten oder sitzungsübergreifenden Zustandszugriff beanspruchen, oder ein session_id-Parameter, der standardmäßig auf einen Platzhalter zeigt — das Muster hinter einem Bruch der Mandantenisolation.
Ein Parameter, der wie ein Header-Name aussieht — darunter authorization, cookie oder host — oder einer, der über die x-mcp-header-Erweiterung der MCP-Spezifikation in eine ausgehende Anfrage verdrahtet ist. Beide können einen Vertrauensgrenzen-Header überschreiben, den der Aufrufer nie zu Gesicht bekommt.
Dieselben 11 Prüfungen, dasselbe Berichtsformat, drei Wege dorthin:
POST /v1/suite/guard/scan-mcp mit den Tool-Definitionen im Body. Liefert ein Urteil (pass / warn / fail), einen Risiko-Score von 0–1 und ein Findings-Array — jeder Fund enthält den Tool-Namen, die ausgelöste Prüfung, den Schweregrad, Belege und eine Empfehlung.scanMcpTools() im Node-SDK, scan_mcp_tools() im Python-SDK — beide kapseln denselben Endpunkt mit typisierten Request-/Response-Formen.scan_mcp_tools auf dem eigenen MCP-Server von VeriSwarm die Tools eines anderen Servers scannen, bevor er sie jemals aufruft — kein separater HTTP-Client nötig.Funde mit kritischem oder hohem Schweregrad werden als Guard-Scan-Findings in Ihrem Tenant gespeichert, sodass ein Scan-Ergebnis kein einmaliger Konsolen-Ausdruck ist — sondern ein Datensatz, den Sie im Zeitverlauf prüfen, priorisieren und abschließen können.
Eine heute sauber gescannte Tool-Definition kann morgen etwas anderes ausliefern — das definierende Merkmal eines Rug Pulls ist genau, dass die geprüfte Version nicht die Version ist, die Sie nächste Woche ausführen. Führen Sie den Scan bei jedem Versionssprung des MCP-Servers durch, oder nach einem Zeitplan, nicht nur bei der ersten Verbindung. Der Scanner ist die Hälfte der Geschichte vor dem Deployment; die Laufzeit-Hälfte — die live eingehende Tool-Aufrufe filtert, nachdem der Server bereits einen Scan bestanden hat — ist Guard Proxy. Keines ersetzt das andere: Der Scanner erfasst, was ein Tool behauptet, Guard Proxy erfasst, was es tatsächlich tut.
Tool-Poisoning ist die Prüfung, die es am meisten lohnt, im Detail zu verstehen — es ist diejenige, bei der der Angriff vollständig im Reasoning des Modells abläuft, ohne dass auf der Netzwerkebene etwas abzufangen wäre. Die Mechanik des Angriffs, die realen Erfolgsraten und wie der Scanner ihn erkennt, werden aufgeschlüsselt in MCP Tool Poisoning: Wie der Angriff funktioniert und wie man ihn erkennt.
Rufen Sie dessen tools/list-Methode auf, um die Tool-Definitionen zu erhalten, und senden Sie dieses Array an den Scanner von VeriSwarm — POST /v1/suite/guard/scan-mcp, das scanMcpTools() des Node-SDK, das scan_mcp_tools() des Python-SDK oder das scan_mcp_tools-Tool des gehosteten MCP-Servers. Alle vier rufen dieselbe Engine mit 11 Prüfungen auf und liefern denselben strukturierten Bericht: ein Urteil (pass/warn/fail), einen Risiko-Score von 0-1 sowie pro Fund Schweregrad, Belege und eine Empfehlung.
Elf deterministische Prüfungen: Tool-Poisoning, Typosquatting, Schema-Manipulation, Rug-Pull-Muster, Prompt-Injection und übermäßige Berechtigungen decken die ursprünglichen sechs Risikokategorien ab; Model Misbinding, Context Spoofing, verdeckte Kanäle, unsichere Speicherreferenzen und Header-Injection bilden den Scanner auf 9 der 10 Risiken der OWASP MCP Top 10 v0.1-beta (2025) ab — jedes Risiko außer MCP08 (Lack of Audit and Telemetry), das eine statische Tool-Definition nicht zeigen kann; dafür braucht es Laufzeit-Logging, keinen Schema-Scan. Jede Prüfung ist muster- und strukturbasiert — kein LLM in der Schleife, sodass eine gegebene Tool-Definition bei jedem Scan dieselben Funde liefert.
Nein. Es ist ein statischer Analysator — Regex-Muster, Schemabaum-Durchläufe und Unicode-Normalisierung, kein Modellaufruf. Das ist ein bewusster Kompromiss: Probabilistische Richter sind der Grund, warum mindestens ein unabhängiges Audit eines YARA-basierten MCP-Scanners eine False-Positive-Rate von rund 78 % gemeldet hat. Deterministische Prüfungen tauschen etwas Recall gegen etwas, worauf eine CI-Pipeline tatsächlich gaten kann — dieselbe Eingabe erzeugt zweimal dasselbe Urteil.
Beides. Speichern Sie in CI die tools/list-Antwort eines Servers in einer Datei und scannen Sie sie als Pipeline-Schritt — ein kritischer Fund ist ein fehlgeschlagener Build, kein Slack-Thread im Nachhinein. In Produktion rufen Sie den API-Endpunkt nach einem Zeitplan oder bei jedem Versionssprung des MCP-Servers auf, denn ein Tool, das einmal sauber gescannt wurde, gilt nur einmal als bekanntermaßen gut. Erneutes Scannen ist der Weg, wie ein Rug-Pull — ein Server, der sich während der Prüfung wohlverhält und danach bösartig wird — erwischt statt übersehen wird.
Der Scanner ist die Hälfte vor dem Deployment: Er liest deklarierte Tool-Definitionen, bevor Ihr Agent den Server jemals aufruft. Guard Proxy ist die Laufzeit-Hälfte: Er sitzt zwischen Ihrem Agenten und seinen Tools und filtert jeden Live-Aufruf, während er geschieht. Keines ersetzt das andere. Der Scanner erfasst, was ein Tool zu tun behauptet; Guard Proxy erfasst, was es zum Zeitpunkt des Aufrufs tatsächlich tut.
Es ist gemessen, nicht theoretisch. Der MCPTox-Benchmark hat Tool-Poisoning gegen 45 reale MCP-Server und 353 echte Tools getestet und Angriffserfolgsraten von über 60 %, mit einem Höchstwert von 72 %, gefunden — wobei leistungsfähigere Modelle häufiger befolgen, weil besseres Befolgen von Anweisungen auch bessere Befolgung einer bösartigen Anweisung bedeutet. Eine vollständige Aufschlüsselung der Angriffsmechanik und wie die tool_poisoning-Prüfung des Scanners sie erkennt, finden Sie im dedizierten Erklärartikel.
Senden Sie eine tools/list-Antwort an Guard und sehen Sie, was Ihre Agenten bisher gelesen haben. Der kostenlose Plan von Gate gibt Ihnen zuerst die Trust-Scoring- und Event-Pipeline; der Scanner von Guard baut darauf auf.