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 es als Sicherheitsschicht für diesen Datenverkehr. Wir haben sechs MCP Gateways mit einem instrumentierten Backend auf einer einzigen Maschine verglichen und dabei die zusätzliche Latenz, die Berechtigung pro Tool, den Inhaltsschutz und die Vollständigkeit der Prüfung gemessen.
MCP Gateway-Benchmark-Ergebnisse
Ein Produkt erscheint in einer Kontrollzeile nur dann, wenn es diese Kontrolle mitliefert und diese Kontrolle ausgeführt wurde; deshalb erhält niemand null Punkte für eine Funktion, die es nicht verkauft.
Eines der sechs gemessenen Gateways liefert einen Injektionsdetektor aus. TrueFoundry stoppte damit 55 von 60 eingeschleusten Anweisungen. Die anderen fünf verfügen über keine Injektions- oder Jailbreak-Erkennung; daher erreicht eine in einer Tool-Antwort platzierte Anweisung den Client durch jedes von ihnen.
ContextForge liefert 44 Plugins aus.1 Die drei, deren Namen „inject“ enthalten, fügen einen HTTP-Header, einen Datenschutzhinweis und einen Lizenz-Header hinzu, und keiner der übrigen erkennt eine Injektion.
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 maskieren 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 Inhaltsschutzfunktionen standardmäßig deaktiviert aus – der Zustand, in dem die meisten Leser sie vorfinden werden. ContextForge erkennt Zugangsdaten, sobald ein Operator seine Plugins aktiviert. Cortx blockierte selbst bei aktiver Richtlinie nichts.
Eingeschleuste Anweisungen in Tool-Antworten
Die Sonde liefert eine Tool-Antwort zurück, die eine an das Model gerichtete Anweisung in zwei Formen enthält: als Element innerhalb einer strukturierten Liste und als Satz, der in kostenlos Text eingebettet ist. 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äßig durchsetzenden Einstellung verwendet wird. Die Ablehnung nennt die Regel, die ausgelöst hat.
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 Sonde misst, ob das Gateway den Text entfernt. Sie testet nicht, ob ein Model der Anweisung folgen würde.
Backend-Zugangsdaten in Tool-Antworten
Das Backend gibt einen Fehler zurück, der vier Zugangsdaten enthält: ein GitHub-Token, eine AWS-Zugriffsschlüssel-ID, ein JWT und eine beliebige Anbieter-Zeichenfolge.
Keiner der getesteten Scanner fing die beliebige Anbieter-Zeichenfolge ab, weil keiner eine Regel für deren Form enthielt. ContextForge scheint sie nur zu stoppen, weil die gesamte Antwort aufgrund der anderen drei zurückgehalten wurde.
Das Secret-Scanning von Docker ist standardmäßig aktiviert und die einzige Zugangsdatenkontrolle in dieser Tabelle, die ein Operator ohne jegliche Konfiguration erhält.
Berechtigung pro Tool
Die Sonde beschränkt eine Zugangsberechtigung so, dass sie ein Tool ausschließt, und ruft dieses Tool dann direkt über seinen Namen auf.
Vier der sechs setzen dies durch, und keiner von ihnen gibt die zurückgehaltenen Daten zurück. Der Open-Source-Build von Docker läuft ohne eine Aufrufer-Berechtigung, sodass er ein Tool global ausblenden, aber zwei Aufrufern keine unterschiedlichen Tool-Sets bieten kann. Die Plugin-Oberfläche von Lasso umfasst Guardrails und Tracing, ohne jeglichen Berechtigungsschritt.
Bifrost misst 840 Mikrosekunden mit einem eingeschränkten Schlüssel und 866 mit einem uneingeschränkten; ein Unterschied, der kleiner ist als die Schwankung zwischen den Wiederholungen. Die Bereichsbeschränkung einer Berechtigung verursachte keinen für uns auflösbaren Latenznachteil.
Cortx und TrueFoundry nennen 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 Verhaltensweisen wird hier bewertet.
Audit-Vollständigkeit
Wir haben jede Audit-Oberfläche gelesen, die wir identifizieren konnten. Die meisten Produkte teilen den Datensatz zwischen einem Log und einer Datenbank auf.
TrueFoundry ist der einzige Teilnehmer, der eine Berechtigungsverweigerung aufzeichnet. Sein Trace für den abgelehnten Aufruf enthält den Tool-Namen, die E-Mail des Aufrufers, die Argumente und den Verweigerungstext.
Bifrost, ContextForge und Cortx blockieren alle einen nicht autorisierten Aufruf, und keiner zeichnet auf, dass er stattgefunden hat. Ihre Datenspeicher wiesen vor und nach dem Versuch dieselbe Zeilenzahl auf.
ContextForge zeichnete in unserer Bereitstellung keinen fehlgeschlagenen Aufruf auf, und seine 26-spaltige audit_trails-Tabelle blieb durchgehend leer.
Docker ist das einzige selbst gehostete Gateway, das eine Spur eines blockierten Aufrufs hinterlässt, und der Trace liest sich als Erfolg. Die Zeile enthält den Tool-Namen und eine plausible Dauer von zwei Millisekunden ohne Ergebnisfeld, sodass ein Operator, der nach Sicherheitsereignissen sucht, sie nicht finden würde.
Cortx zeichnet die Tool-Argumente und die vollständige Antwort auf, was nur Lasso und TrueFoundry ebenfalls tun, behält aber 50 Zeilen, unabhängig vom angeforderten Limit. Dieses Fenster deckte 11 Sekunden unseres 2.400-Aufruf-Laufs ab.
Zusätzliche Latenz
Bifrost fügt 840 Mikrosekunden pro Aufruf hinzu, Docker 1.134 und ContextForge 23.058. ContextForge fügt 27-mal so viel Latenz hinzu wie Bifrost.
Bifrosts eigene Angabe von unter 100 Mikrosekunden ist ein Durchsatzanspruch bei hoher Nebenläufigkeit.2 Bei Nebenläufigkeit 1 fügt es ungefähr das Zehnfache davon hinzu, und die Behauptung sollte als Durchsatzgröße getestet und hier nicht als widerlegt behandelt werden.
Ein Gateway verlangsamt auch Datenverkehr, der nie über es geleitet 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 Zeitmessungsaufgaben.
Dieser Effekt würde für ein Gateway auf einem eigenen Host nicht gelten; daher wird er getrennt von den oben genannten Zahlen für geroutete Aufrufe ausgewiesen.
Kosten der Governance
Zwei Produkte konnten mit deaktivierter und aktivierter Inhaltskontrolle gemessen werden, wobei zwischen den Paaren nur eine Einstellung geändert wurde.
Die vier Detektoren von ContextForge kosteten 3.198 Mikrosekunden, eine Steigerung von 11.5 %. Die Standardabweichungen zwischen den Wiederholungen betrugen 157 Mikrosekunden bei ausgeschalteten und 73 bei eingeschalteten Detektoren. Diese Baseline ist nicht mit dem Latenzdiagramm vergleichbar: Sowohl das Plugin-Framework als auch die Anzahl der Tools unterschieden sich, sodass nur die Änderung innerhalb des Paares aussagekräftig ist.
Die zwei Guardrails von TrueFoundry bringen es von 55.5 auf 172.1 Millisekunden, also ungefähr das Dreifache. Seine drei Wiederholungen maßen 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. ContextForges Musterabgleich fügte 11.5 % hinzu, während TrueFoundrys Injektionserkennung den Wert ungefähr verdreifachte und über die Wiederholungen zwischen 152.6 und 200.3 Millisekunden schwankte; ein einzelner Lauf hätte diese Spanne nicht gezeigt.
Was ist eine KI-Steuerungsebene?
Cortx und TrueFoundry sind keine Gateways, die man installiert. Sie sind KI-Steuerungsebenen: eine gehostete Schicht, die Richtlinie, Identität und Audit-Trail für den KI-Datenverkehr einer Organisation vorhält und Tool-Aufrufe über sich selbst leitet, sodass überall dieselben Regeln gelten.
Das Gateway ist der Teil, der den Datenverkehr bewegt. Die Steuerungsebene ist der Teil, der entscheidet, was erlaubt ist, und aufzeichnet, was passiert ist. Anbieter verkaufen Letzteres als Grund, Ersteres zu kaufen.
Beide Werte sind von der Netzwerkentfernung dominiert. Cortx fügt 211.1 Millisekunden hinzu und TrueFoundry 55.5, gemessen von derselben Maschine; allein der Roundtrip beträgt etwa 100 Millisekunden zur Region von Cortx gegenüber 14.1 zu TrueFoundry. Zwei Überquerungen machen ungefähr 200 der 211 Millisekunden von Cortx aus. Wir stufen die beiden nie gegeneinander ein.
Die Behauptung einer Steuerungsebene ist, dass eine Richtlinie überall gilt; genau das haben wir getestet. Cortx liefert das Response-Scanning deaktiviert aus. Wir erstellten eine Richtlinie, aktivierten zwei seiner integrierten Kategorien auf Block, genehmigten sie, und der eigene Status-Endpunkt des Produkts bestätigte, dass unsere Richtlinie live war. Jedes Zugangsdatenformat und beide eingeschleusten Anweisungen erreichten den Client dennoch, und das Aktivieren der Richtlinie verursachte keine messbare Latenz.
Sein Enforcement-Log zeigt, warum: Jedes aufgezeichnete Ereignis befindet sich in der Phase, die um einen Model-Aufruf herum läuft, und unser Pfad enthält kein Model. Keine seiner integrierten Kategorien deckt außerdem Prompt-Injection oder Jailbreak-Erkennung ab – dieselbe Lücke wie im Plugin-Set von ContextForge.
Eine Steuerungsebene kann daher korrekt konfiguriert sein, sich als aktiv melden und dennoch nicht auf dem Pfad liegen, der einen interessiert. Eine MCP-Tool-Antwort ist eine neuere Angriffsfläche als ein Model-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 danach.
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 sich außerhalb von ihm befinden, etwa einen Datenbankabfragedienst oder eine interne API. Ein Gateway ist ein Proxy, den all diese Aufrufe durchlaufen, sodass ein Operator viele Agenten auf eine Adresse verweisen kann, statt jeden Agenten mit jedem Tool zu verdrahten.
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 Model 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 weder die privaten Überlegungen des Models noch den vollständigen Chat-Kontext; daher testet dieser Benchmark Injektionskontrollen nur auf Tool-Antworten.
Es schützt außerdem nur den Datenverkehr, der über es läuft. Wir ließen das Backend direkt erreichbar und bewerteten die Umgehungsresistenz nicht, da dieses Ergebnis von Netzwerkkontrollen 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 aufzeichnete, und das von uns getestete free-Tier-Konto verfügte nicht über die Schlüsselklasse, die eine Integration auf Organisationsebene erfordert.
Messzeitpunkte: Latenz der eigenständigen 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 untergebracht, Caddy über TLS. Gehostete Gateways werden über das WAN erreicht; daher enthalten ihre Werte Netzwerklatenz, die dieses Setup nicht sauber von der Gateway-Verarbeitung trennen kann. Cortx nutzt 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, 4 davon reine Echos für Zeitmessungen. Er gibt auf Anfrage 4 Zugangsdatenformate preis (GitHub-Token, AWS-Schlüssel-ID, JWT, beliebige Anbieter-Zeichenfolge), liefert eingeschleuste Anweisungen in 2 Formen (strukturierte Liste, kostenlos Text) und protokolliert jeden Aufruf. Die drei Standard-Zugangsdatenformate sind synthetisch, mit Längen und Strukturen, die Formatregeln echter Secret-Scanner erfüllen.
Client: ein deterministischer MCP-Client ohne Language Model. Ein Model im Pfad würde einer Mikrosekundenmessung Sekunden an Varianz hinzufügen, ohne zu ändern, was das Gateway tut.
Latenz: mediane zusätzliche Latenz bei Nebenläufigkeit 1; der über das Gateway geleitete Aufruf abzüglich eines passenden Direktaufrufs an das Backend, wobei die beiden Pfade verschränkt wurden, um Drift zu reduzieren. Bifrost 5 Wiederholungen, Docker und ContextForge 3, bei 200 Aufrufen pro Aufgabe pro Wiederholung. Sequenzielles Sampling wurde verworfen: Es überschätzte Docker um 89 % und Bifrost um 54 %. Lasso läuft über stdio und nicht über einen Socket und hat daher keinen vergleichbaren Wert.
Richtlinien-Sonden (n=30 jeweils): eine eingeschleuste Anweisung in 2 Formen, ein Zugangsdatenleck in 4 Formaten und ein Aufruf eines Tools, für das die Berechtigung nicht freigegeben ist. Die Direkt-zum-Backend-Basislinie lieferte jede Nutzlast zurück; daher zeigt eine Null durch ein Gateway an, dass das Gateway gehandelt hat, und nicht, dass die Sonde fehlgeschlagen ist.
Konfiguration: jedes Produkt wurde mit den stärksten uns verfügbaren Inhaltskontrollen gemessen, wobei die ausgelieferten Detektorparameter beibehalten wurden. Es wurde kein Muster geschrieben, das zur Testnutzlast passt. Wo ein Produkt eine Standard- und eine gesteuerte 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 für diese Aufrufe jedoch kein Durchsetzungsereignis.
Audit: Jede identifizierte Audit-Oberfläche wurde gelesen, einschließlich stdout, Datenbankspeicher, Aktivitätsprotokollen und gehosteten Trace-Ansichten. Datenbankspeicher wurden vor dem Zählen der Zeilen mit einem Checkpoint versehen.
Für Ergebnisse auf Model-Ebene 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 = aug,
howpublished = {\url{https://aimultiple.com/mcp-gateway}},
note = {AIMultiple. Abgerufen am 24. August 2026}
}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.