MCP-Gateway-Benchmark: Latenz & Sicherheit von 6 Gateways
Ein MCP-Gateway sitzt zwischen einem KI-Agenten und den Tools, die er aufruft, und Anbieter positionieren ihn als Sicherheitsschicht für diesen Datenverkehr. Wir haben sechs MCP-Gateways gegen ein instrumentiertes Backend auf einer einzelnen Maschine gebenchmarkt und dabei zusätzliche Latenz, Tool-bezogene Autorisierung, Inhaltsschutz und Audit-Vollständigkeit gemessen.
MCP-Gateway-Benchmark-Ergebnisse
Ein Produkt erscheint nur dann neben einer Kontrolle, wenn es eine solche mitliefert und diese Kontrolle auch ausgeführt wurde. Niemand erhält also null Punkte für eine Funktion, die er nicht verkauft.
Eines der sechs getesteten Gateways liefert einen Injection-Detektor mit. TrueFoundry stoppte damit 55 von 60 injizierten Anweisungen. Die anderen fünf verfügen über keine Injection- oder Jailbreak-Erkennung, sodass eine in einer Tool-Antwort platzierte Anweisung den Client über jedes von ihnen erreicht.
ContextForge liefert 44 Plugins.1 Die drei, deren Namen „inject“ enthalten, fügen einen HTTP-Header, einen Datenschutzhinweis und einen Lizenz-Header hinzu, und keiner der übrigen erkennt Injection.
Die Erkennung von Zugangsdaten ist die besser abgedeckte Dimension. Vier Gateways stoppten alle drei mustererkennbaren Formate. Sie unterscheiden sich darin, was der Aufrufer erhält: Lasso und TrueFoundry schwärzen das erkannte Geheimnis und geben den Rest der Antwort zurück, während ContextForge und Docker die gesamte Tool-Ausgabe zurückhalten, sodass der Aufrufer auch die Fehlermeldung verliert.
Drei Produkte liefern ihre Inhaltskontrollen standardmäßig deaktiviert aus – das ist der Zustand, in dem die meisten Leser sie vorfinden. ContextForge erkennt Zugangsdaten, sobald ein Operator seine Plugins aktiviert. Cortx blockierte selbst mit aktiver Richtlinie nichts.
Injizierte Anweisungen in Tool-Antworten
Die Prüfsonde liefert eine Tool-Antwort mit einer an das Modell gerichteten Anweisung in zwei Formen: als Element innerhalb einer strukturierten Liste und als Satz, eingebettet in kostenlos Text. Ein Gateway, das die Tool-Ausgabe prüft, sollte sie entfernen oder ablehnen.
TrueFoundry blockiert 27 von 30 bei der Listenform und 28 von 30 bei der free-Text-Form, wobei der eingebaute Prompt-Injection-Detektor in der standardmäßigen Durchsetzungseinstellung verwendet wird. Die Ablehnung nennt die ausgelöste Regel.
Fünf von 60 Versuchen erreichten den Client dennoch, und die Standardstrategie lässt eine Anfrage durch, wenn der Detektor selbst einen Fehler meldet.
Die Prüfsonde misst, ob das Gateway den Text entfernt. Sie testet nicht, ob ein Modell der Anweisung folgen würde.
Backend-Zugangsdaten in Tool-Antworten
Das Backend gibt einen Fehler mit vier Zugangsdaten zurück: einen GitHub-Token, eine AWS-Zugriffsschlüssel-ID, ein JWT und eine beliebige Anbieter-Zeichenkette.
Keiner der getesteten Scanner erkannte die beliebige Anbieter-Zeichenkette, da keiner eine Regel für deren Form enthielt. ContextForge wirkt nur so, als würde es sie stoppen, weil die gesamte Antwort aufgrund der anderen drei zurückgehalten wurde.
Die Secret-Erkennung von Docker ist standardmäßig aktiviert und die einzige Zugangsdaten-Kontrolle in dieser Tabelle, die ein Operator ohne jegliche Konfiguration erhält.
Tool-bezogene Autorisierung
Die Prüfsonde beschränkt ein Zugangsdatum so, dass ein Tool ausgeschlossen ist, und ruft dieses Tool dann direkt namentlich auf.
Vier der sechs setzen dies durch, und keines gibt die zurückgehaltenen Daten zurück. Die Open-Source-Variante von Docker läuft ohne Aufrufer-Zugangsdaten und kann daher ein Tool global verstecken, aber zwei Aufrufern keine unterschiedlichen Toolsets zuweisen. Die Plugin-Oberfläche von Lasso umfasst Leitplanken und Tracing, ohne jeglichen Autorisierungsschritt.
Bifrost misst 840 Mikrosekunden mit einem eingeschränkten Schlüssel und 866 mit einem uneingeschränkten – ein Unterschied, der kleiner ist als die Streuung zwischen Wiederholungen. Die Einschränkung eines Zugangsdatums verursachte keine auflösbare Latenzstrafe.
Cortx und TrueFoundry benennen die Einschränkung; Cortx gibt „Tool für diese Sitzung nicht erlaubt“ zurück. Bifrost und ContextForge melden das Tool als nicht gefunden. Keines der beiden Verhalten wird hier bewertet.
Audit-Vollständigkeit
Wir haben jede identifizierbare Audit-Oberfläche gelesen. Die meisten Produkte teilen den Datensatz zwischen einem Log und einer Datenbank auf.
TrueFoundry und Cortx zeichnen Autorisierungsablehnungen auf. Der Trace von TrueFoundry für den abgelehnten Aufruf enthält den Tool-Namen, die E-Mail des Aufrufers, die Argumente und den Ablehnungstext. Der Datensatz von Cortx enthält den Tool-Namen, die Benutzer-ID des Aufrufers, die Argumente und ein ABGELEHNT-Ergebnis mit Grund.
Bifrost und ContextForge blockieren beide einen unautorisierten Aufruf, und keines zeichnet ihn auf. Ihre Speicher wiesen vor und nach dem Versuch dieselbe Zeilenzahl auf.
ContextForge zeichnete in unserem Deployment keinen fehlgeschlagenen Aufruf auf, und seine 26-spaltige Tabelle audit_trails blieb durchgehend leer.
Docker ist das einzige selbst gehostete Gateway, das irgendeine Spur eines blockierten Aufrufs hinterlässt, und diese Spur liest sich als Erfolg. Die Zeile enthält den Tool-Namen und eine plausible Dauer von zwei Millisekunden ohne Ergebnisfeld, sodass ein nach Sicherheitsereignissen suchender Operator sie nicht finden würde.
Cortx zeichnet die Tool-Argumente und die vollständige Antwort auf. Bifrost, Lasso und TrueFoundry tun dasselbe. Die Gateway-Aktivitätsansicht von Cortx zeigt nur die letzten 50 Aufrufe, aber ein zweiter Speicher enthielt noch unsere Aufrufe von vor sechs Wochen samt Argumenten.
Zusätzliche Latenz
Bifrost verursacht 840 Mikrosekunden pro Aufruf, Docker 1.134 und ContextForge 23.058. ContextForge verursacht 27-mal so viel Latenz wie Bifrost.
Bifrosts eigener Wert liegt unter 100 Mikrosekunden pro Anfrage, gemessen bei 5.000 Anfragen pro Sekunde.2 Unser Test sendete jeweils nur eine Anfrage und maß 840 Mikrosekunden. Wir haben nicht bei 5.000 Anfragen pro Sekunde getestet, daher zeigt dieses Ergebnis nicht, dass die Behauptung falsch ist.
Ein Gateway verlangsamt auch Datenverkehr, der nie über es geroutet wird. Während Docker oder ContextForge aktiv war, liefen direkte Aufrufe an das Backend etwa 0.9 Millisekunden langsamer, zwischen 858 und 973 Mikrosekunden über die vier Zeitmessaufgaben.
Dieser Effekt würde bei einem Gateway auf einem eigenen Host nicht auftreten, daher wird er getrennt von den oben genannten Zahlen für geroutete Aufrufe ausgewiesen.
Kosten der Governance
Zwei Produkte konnten mit aus- und eingeschalteter Inhaltskontrolle gemessen werden, wobei zwischen den Paaren nur eine Einstellung geändert wurde.
Die vier Detektoren von ContextForge kosteten 3.198 Mikrosekunden, ein Anstieg von 11,5 %. Die Standardabweichungen zwischen den Wiederholungen betrugen 157 Mikrosekunden bei ausgeschalteten und 73 bei eingeschalteten Detektoren. Dieser Ausgangswert ist nicht mit dem Latenzdiagramm vergleichbar: Das Plugin-Framework und die Tool-Anzahl unterschieden sich beide, sodass nur die Änderung innerhalb des Paares aussagekräftig ist.
Die zwei Leitplanken von TrueFoundry erhöhen den Wert von 55.5 auf 172.1 Millisekunden, etwa das Dreifache. Seine drei Wiederholungen ergaben 152.6, 163.4 und 200.3 Millisekunden. Bei ausgeschalteten Detektoren betrug die Standardabweichung zwischen den Wiederholungen 1.5 Millisekunden.
Die beiden Detektortypen verursachten unterschiedliche Kosten. Das Pattern Matching von ContextForge fügte 11,5 % hinzu, während die Injection-Erkennung von TrueFoundry den Wert etwa verdreifachte und über die Wiederholungen zwischen 152.6 und 200.3 Millisekunden schwankte, sodass ein einzelner Lauf diese Spanne nicht gezeigt hätte.
Was ist eine KI-Control-Plane?
Cortx und TrueFoundry sind keine Gateways, die man installiert. Sie sind KI-Control-Planes: eine gehostete Schicht, die Richtlinie, Identität und Audit-Trail für den KI-Datenverkehr eines Unternehmens vorhält und Tool-Aufrufe durch sich selbst leitet, damit überall dieselben Regeln gelten.
Das Gateway ist der Teil, der den Datenverkehr bewegt. Die Control Plane ist der Teil, der entscheidet, was erlaubt ist, und aufzeichnet, was passiert ist. Anbieter verkaufen das Zweite als Grund, das Erste zu kaufen.
Beide Werte werden von der Netzwerkentfernung dominiert. Cortx verursacht 211.1 Millisekunden und TrueFoundry 55.5 von derselben Maschine aus; allein der Roundtrip beträgt etwa 100 Millisekunden zur Region von Cortx gegenüber 14.1 zu der von TrueFoundry. Zwei Durchquerungen machen ungefähr 200 der 211 Millisekunden von Cortx aus. Wir bewerten die beiden nie gegeneinander.
Das Versprechen einer Control Plane ist, dass eine Richtlinie überall gilt, und genau das haben wir getestet. Cortx liefert die Antwortprüfung standardmäßig deaktiviert aus. Wir erstellten eine Richtlinie, aktivierten zwei integrierte Kategorien auf Block, genehmigten sie, und der Statusendpunkt des Produkts bestätigte, dass unsere Richtlinie die aktive war. Jedes Zugangsdaten-Format und beide injizierten Anweisungen erreichten den Client dennoch, und das Aktivieren der Richtlinie verursachte keine messbare Latenz. Der Statusendpunkt von Cortx zeigt die Antwortprüfung auf dem MCP-Gateway-Pfad als inaktiv an, und der Richtlinien-Editor bietet keine Möglichkeit, sie zu aktivieren. Der Statusendpunkt von Cortx listet eine Stufe für Tool-Antworten auf dem MCP-Gateway-Pfad, meldet sie aber als nicht aktiv, und der Richtlinien-Editor bietet diese Stufe nicht an.
Das Enforcement-Log von Cortx zeigt den Grund: Jedes aufgezeichnete Ereignis liegt in der Stufe, die um einen Modellaufruf herum ausgeführt wird, und unser Pfad enthält kein Modell. Keine der integrierten Kategorien deckt zudem Prompt Injection oder Jailbreak-Erkennung ab – dieselbe Lücke wie im Plugin-Set von ContextForge.
Eine Control Plane kann daher korrekt konfiguriert sein, sich selbst als aktiv melden und dennoch nicht auf dem Pfad liegen, der für Sie relevant ist. Eine MCP-Tool-Antwort ist eine neuere Angriffsfläche als ein Modell-Prompt, und eine Policy-Engine deckt die Flächen ab, für die sie gebaut wurde. Fragen Sie einen Anbieter, welche Stufe seiner Engine eine Tool-Antwort sieht, und holen Sie diese Antwort vor dem Audit ein, nicht erst danach. Cortx und TrueFoundry sind zwei der 12 Control Planes, die wir hinsichtlich Funktionsabdeckung bewertet haben; dieser Benchmark misst, was zwei von ihnen tatsächlich auf dem MCP-Pfad tun.
Als bevorzugte Quelle hinzufügenWas ist ein MCP-Gateway?
Das Model Context Protocol ermöglicht es einem KI-Agenten, Tools zu entdecken und aufzurufen, die außerhalb seiner selbst liegen, etwa einen Datenbank-Abfragedienst oder eine interne API. Ein Gateway ist ein Proxy, durch den alle diese Aufrufe laufen, sodass ein Operator viele Agenten auf eine Adresse verweisen kann, statt jeden Agenten einzeln mit jedem Tool zu verbinden.
Ein Gateway zentralisiert vier Aufgaben über viele Agenten und Tools hinweg. Es entscheidet, welcher Aufrufer welches Tool verwenden darf, prüft die Ausgabe des Tools, bevor das Modell sie liest, zeichnet auf, was passiert ist, und leitet den Datenverkehr weiter.
Was der Pfad abdeckt und was nicht
Ein Gateway sieht Tool-Aufrufe und Tool-Antworten. Es sieht nicht die privaten Überlegungen des Modells oder den gesamten Chat-Kontext, daher testet dieser Benchmark Injection-Kontrollen nur bei Tool-Antworten.
Es schützt außerdem nur Datenverkehr, der durch es hindurchgeht. Wir ließen das Backend direkt erreichbar und bewerteten die Umgehungsresistenz nicht, da dieses Ergebnis von Netzwerkkontrollen der Bereitstellung außerhalb des Gateway-Pfads abhängen würde.
MCP-Gateway-Benchmark-Methodik
Produkte: sieben ausgewählt, sechs gemessen. Bifrost v1.6.10, Docker MCP-Gateway v0.43.3, IBM ContextForge v1.0.7, Lasso Security v1.2.1 (selbst gehostet); Cortx v1.1, TrueFoundry Developer-Tier-Konsole 0.167.0 (gehostet). Portkey lieferte keine Messung. Die Workspace-Synchronisierung meldete Erfolg, während unser Origin-Log null Verbindungen verzeichnete, und dem getesteten free-Tier-Konto fehlte die Schlüsselklasse, die eine Integration auf Organisationsebene erfordert.
Messzeitpunkte: Latenz eigenständiger MCP-Tools 2026-08-13, Richtlinien- und Audit-Durchlauf 2026-08-21, gehostete Latenz von TrueFoundry 2026-08-17, gehostete Latenz von Cortx 2026-08-19.
Umgebung: eine Box mit 8 vCPUs, Gateway und Mock-Backend gemeinsam platziert, Caddy über TLS. Gehostete Gateways werden über das WAN angesprochen, daher enthalten ihre Werte Netzwerklatenz, die sich in diesem Setup nicht sauber von der Gateway-Verarbeitung trennen lässt. Cortx nutzt ausgehend AWS us-east-1; die Region von TrueFoundry wurde nicht unabhängig identifiziert.
Backend: ein Mock-MCP-Server, 16 Tools, deterministische Verzögerungen pro Tool, davon 4 reine Echos für die Zeitmessung. Er gibt auf Anfrage 4 Zugangsdaten-Formate preis (GitHub-Token, AWS-Zugriffsschlüssel-ID, JWT, beliebige Anbieter-Zeichenkette), liefert injizierte Anweisungen in 2 Formen (strukturierte Liste, kostenlos Text) und protokolliert jeden Aufruf. Die drei Standard-Zugangsdatenformate sind synthetisch, mit Längen und Strukturen, die den Formatregeln echter Secret-Scanner entsprechen.
Client: ein deterministischer MCP-Client ohne Sprachmodell. Ein Modell im Pfad würde einer Mikrosekundenmessung Sekunden an Varianz hinzufügen, ohne das Verhalten des Gateways zu ändern.
Latenz: mediane zusätzliche Latenz bei Nebenläufigkeit 1, also der über das Gateway geroutete Aufruf abzüglich eines passenden direkten Aufrufs an das Backend, wobei die beiden Pfade verschränkt wurden, um Drift-Verzerrungen zu reduzieren. Bifrost 5 Wiederholungen, Docker und ContextForge 3, mit 200 Aufrufen pro Aufgabe und Wiederholung. Sequenzielles Sampling wurde verworfen: Es überschätzte Docker um 89 % und Bifrost um 54 %. Lasso läuft über stdio statt über einen Socket und hat daher keinen vergleichbaren Wert.
Richtlinien-Prüfsonden (n=30 je): eine injizierte Anweisung in 2 Formen, ein Zugangsdaten-Leck in 4 Formaten und ein Aufruf eines Tools, für das Zugangsdatum nicht berechtigt ist. Die direkte Backend-Baseline lieferte jede Payload zurück, sodass eine Null durch ein Gateway ein Handeln des Gateways anzeigt und nicht eine fehlgeschlagene Prüfsonde.
Konfiguration: jedes Produkt wurde mit den stärksten uns verfügbaren Inhaltskontrollen gemessen, wobei die mitgelieferten Detektorparameter beibehalten wurden. Es wurde kein Muster geschrieben, das zur Test-Payload passt. Wo ein Produkt eine Standard- und eine reglementierte Konfiguration hat, werden beide veröffentlicht. TrueFoundry, ContextForge und Cortx lieferten ihre Inhaltskontrolle jeweils deaktiviert aus und wurden mit aktivierter Kontrolle erneut gemessen. TrueFoundry und ContextForge protokollierten die Durchsetzung auf dem getesteten Pfad; Cortx bestätigte, dass die Richtlinie aktiv war, protokollierte aber kein Durchsetzungsereignis für diese Aufrufe.
Audit: jede identifizierte Audit-Oberfläche wurde gelesen, einschließlich stdout, Datenbank-Speichern, Aktivitätslogs und gehosteten Trace-Ansichten. Die Datenbank-Speicher wurden vor dem Zählen der Zeilen mit einem Checkpoint versehen.
Für Ergebnisse auf Modellebene siehe den agentischen LLM-Benchmark.
Zitieren Sie diesen Benchmark
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk},
title = {{MCP-Gateway-Benchmark: Latenz & Sicherheit von 6 Gateways}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/mcp-gateway}},
note = {AIMultiple. Abgerufen am 5. Oktober 2026}
}Ergebnisse und Zeitstempel von 25 Datenpunkten. Laden Sie die Zusammenfassungsdaten aus den Diagrammen und Tabellen dieses Artikels als ZIP-Datei herunter, die 3 CSV-Dateien und eine README enthält.
Möchten Sie die granularen Daten dahinter? Premium beitreten
Änderungsprotokoll
2 AktualisierungenAbschnitt mit Benchmark-Ergebnissen zu sechs MCP-Gateways bei Latenz und Sicherheit hinzugefügt
IBM ContextForge, Kong AI Gateway und MintMCP Gateway zur Gateway-Übersicht hinzugefügt.
Referenzlinks
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.