mcp-fence – Ein Sicherheits-Proxy, der Anfragen und Antworten von MCP-Servern in beide Richtungen prüft

Wenn ein KI-Agent über einen MCP-Server Dateien liest oder Tools aufruft, gelangen die vom Server zurückgegebenen Antworten ohne gesonderte Validierung in den Kontext. mcp-fence ist ein Sicherheits-Proxy, der sowohl diese Anfragen als auch die Antworten in Echtzeit prüft.

Beim Erstellen von nworks (dem NAVER WORKS MCP-Server) habe ich diese Struktur selbst erlebt. Auf GitHub habe ich 28 MCP-Sicherheitsprojekte geprüft, doch die meisten untersuchten nur die ausgehende Richtung und betrachteten die Rückrichtung nicht. Deshalb habe ich es selbst gebaut.

Nach der Entwicklung habe ich selbst ein Sicherheitsaudit durchgeführt. Ich konnte sämtliche Erkennungen umgehen, indem ich Zeichen verwendete, die für Menschen gleich aussehen, vom Computer aber als andere Zeichen erkannt werden. Ich konnte alle Prüfungen bestehen, indem ich unsichtbare transparente Zeichen einfügte, und fand sogar einen Bug, durch den sich die Sicherheitsprüfung selbst mit speziellen Eingaben stoppen ließ. Alles wurde noch vor dem Release behoben. Von 1.426 Tests sind 630 adversariale Sicherheitstests, und bei 13 bekannten MCP-Schwachstellen liegt die Erkennungsrate bei 86 %. Nach OWASP MCP Top 10 deckt das Projekt 9 von 10 Punkten ab.

Erkannt werden Injection, Secrets, PII und Command Injection, und auch ein Rug Pull, bei dem Tool-Beschreibungen heimlich verändert werden, wird per Hash-Pinning erkannt. Die Erkennung basiert auf regulären Ausdrücken, daher kann man sie umgehen, wenn man dieselbe Bedeutung anders formuliert. ML-basierte semantische Erkennung ist für v1.x geplant.

Wenn man zum Beispiel einen filesystem-MCP-Server verwendet, setzt man es einfach davor.

npx mcp-fence start -- npx @modelcontextprotocol/server-filesystem /tmp  

Ohne Änderungen am bestehenden Server-Code funktioniert es mit dieser einen Zeile. Standardmäßig werden nur Logs geschrieben, aber nichts blockiert. Man kann zuerst prüfen, welcher Traffic tatsächlich fließt, und dann bei Bedarf in den Blocking-Modus wechseln.

Da es ein Projekt ist, das ein Mobile-Security-Ingenieur mit 9 Jahren Erfahrung in 10 Wochen allein gebaut hat, kann es noch Schwachstellen geben. Über Feedback würde ich mich freuen.