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 gegen ein instrumentiertes Backend auf einer einzigen Maschine getestet und dabei zusätzliche Latenz, toolbezogene Autorisierung, Inhaltsschutz und Audit-Vollständigkeit gemessen.
MCP Gateway-Benchmark-Ergebnisse
Ein Produkt erscheint nur dann gegenüber einer Kontrolle, wenn es eine solche mitliefert und diese Kontrolle ausgeführt wurde, sodass niemand für eine Funktion, die es nicht verkauft, null Punkte erhält.
Zwei der sechs getesteten Gateways führten in den uns verfügbaren Konfigurationen einen Injektionsdetektor aus. Cortx stoppte alle 60 injizierten Anweisungen und TrueFoundry 55 von 60. Bei den anderen vier erreichte eine in einer Tool-Antwort platzierte Anweisung den Client.
ContextForge liefert 44 Plugins.1 Die drei, deren Namen „inject“ enthalten, fügen einen HTTP-Header, einen Datenschutzhinweis und einen Lizenzheader hinzu, und keiner der übrigen erkennt eine Injektion.
Das Scannen von Zugangsdaten ist die besser abgedeckte Dimension. Fünf Gateways stoppten alle drei mustererkennbaren Formate. Cortx, Lasso und TrueFoundry schwärzen das erkannte Geheimnis und geben den Rest der Antwort zurück. ContextForge und Docker halten die gesamte Tool-Ausgabe zurück, sodass der Aufrufer auch die Fehlermeldung verliert.
Drei Produkte liefern ihre Inhaltsschutzmaßnahmen standardmäßig deaktiviert aus – der Zustand, in dem die meisten Leser sie vorfinden. ContextForge erkennt Zugangsdaten erst, wenn ein Betreiber seine Plugins aktiviert. Cortx scannt Tool-Antworten erst, nachdem ein Organisationsadministrator dies einschaltet.
Injizierte Anweisungen in Tool-Antworten
Die Sonde gibt eine Tool-Antwort zurück, die eine an das Modell gerichtete Anweisung in zwei Formen enthält: als Element in 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-Textform, indem es seinen integrierten Prompt-Injektions-Detektor mit der standardmäßigen Durchsetzungs-Einstellung verwendet. Die Ablehnung nennt die ausgelöste Regel.
Fünf von 60 Versuchen erreichten dennoch den Client, und die Standardstrategie lässt eine Anfrage durch, wenn der Detektor selbst einen Fehler meldet.
Cortx blockiert 30 von 30 bei beiden Formen mit seinem Indirekt-Injektions-Detektor im Durchsetzungsmodus. Anstelle der Tool-Ausgabe erhält der Client eine Meldung, die benennt, was der Detektor erkannt hat. Seine Einstellungen lassen ebenfalls eine Antwort durch, wenn ein Detektor ausfällt.
Wir haben beide Detektoren mit einer Anweisung in zwei Formen getestet. Das Ergebnis deckt keine anderen Anweisungen ab und stellt kein Ranking der beiden Produkte dar.
Die Sonde 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 zurück, der vier Zugangsdaten enthält: ein GitHub-Token, eine AWS-Zugriffsschlüssel-ID, ein JWT und eine beliebige Anbieterzeichenfolge.
Keiner der getesteten Scanner erkannte die beliebige Anbieterzeichenfolge, da keiner eine für diese Form geschriebene Regel enthielt. ContextForge und Docker stoppten sie nur, weil sie die gesamte Antwort zurückhielten, nachdem sie die anderen drei erkannt hatten.
Das Secret-Scanning von Docker ist standardmäßig aktiviert, und es ist die einzige Zugangsdatenkontrolle in dieser Tabelle, die ein Betreiber ohne jegliche Konfiguration erhält.
Toolbezogene Autorisierung
Die Sonde beschränkt eine Zugangsberechtigung so, dass ein Tool ausgeschlossen wird, und ruft dieses Tool dann direkt beim Namen auf.
Vier der sechs setzen durch, und keiner von ihnen gibt die zurückgehaltenen Daten zurück. Dockers Open-Source-Build läuft ohne eine Aufrufer-Berechtigung, daher kann sie ein Tool global verstecken, aber nicht zwei Aufrufern unterschiedliche Tool-Sets geben. Lassos Plugin-Oberfläche besteht aus Guardrails und Tracing, ohne jeglichen Autorisierungsschritt.
Bifrost misst 840 Mikrosekunden mit einem bereichsbezogenen Schlüssel und 866 mit einem nicht bereichsbezogenen – eine Differenz, die kleiner ist als die Schwankung zwischen Wiederholungen. Das Einschränken einer Berechtigung verursachte keine auflösbare Latenzstrafe.
Cortx und TrueFoundry benennen die Einschränkung, wobei Cortx „Tool für diese Sitzung nicht zugelassen“ zurückgibt. 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 Protokoll und einer Datenbank auf.
TrueFoundry und Cortx protokollieren Autorisierungsablehnungen. 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 DENIED-Ergebnis mit dem Grund.
Bifrost und ContextForge blockieren beide einen nicht autorisierten Aufruf, und keiner von beiden zeichnet ihn auf. Ihre Speicher wiesen vor und nach dem Versuch dieselbe Zeilenanzahl auf.
ContextForge hat in unserer Bereitstellung keinen fehlgeschlagenen Aufruf aufgezeichnet, und seine 26-spaltige Tabelle audit_trails blieb durchgehend leer.
Docker ist das einzige selbst gehostete Gateway, das eine Spur eines blockierten Aufrufs hinterlässt, und die Spur liest sich wie ein Erfolg. Die Zeile enthält den Tool-Namen und eine plausible Dauer von zwei Millisekunden ohne Ergebnisfeld, sodass ein Betreiber, der nach Sicherheitsereignissen sucht, 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 unsere Aufrufe von vor sechs Wochen, mit ihren Argumenten.
Zusätzliche Latenz
Bifrost fügt pro Aufruf 840 Mikrosekunden hinzu, Docker 1.134 und ContextForge 23.058. ContextForge fügt 27-mal so viel Latenz hinzu wie Bifrost.
Der eigene Wert von Bifrost liegt unter 100 Mikrosekunden pro Anfrage, gemessen bei 5.000 Anfragen pro Sekunde.2 Unser Test sendete eine Anfrage nach der anderen 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 läuft. 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 ein Gateway auf einem eigenen Host nicht betreffen, daher wird er getrennt von den obigen Werten für geroutete Aufrufe ausgewiesen.
Kosten der Governance
Bei zwei Produkten konnte mit deaktivierter und aktivierter Inhaltsschutzmaßnahme 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 deaktivierten und 73 bei aktivierten Detektoren. Diese Baseline ist nicht mit dem Latenzdiagramm vergleichbar: Das Plugin-Framework und die Tool-Anzahl unterschieden sich beide, daher zählt nur die Änderung innerhalb des Paares.
Die zwei Guardrails von TrueFoundry bringen es von 55.5 auf 172.1 Millisekunden, ungefähr das Dreifache. Seine drei Wiederholungen maßen 152.6, 163.4 und 200.3 Millisekunden. Bei deaktivierten Detektoren betrug die Standardabweichung zwischen den Wiederholungen 1.5 Millisekunden.
Die beiden Detektortypen verursachten unterschiedlich hohe Kosten. Das Musterabgleichen von ContextForge fügte 11,5 % hinzu, während die Injektions- und Geheimniserkennung von TrueFoundry zusammen den Wert ungefähr verdreifachte und über Wiederholungen zwischen 152.6 und 200.3 Millisekunden schwankte, sodass ein einzelner Lauf diese Spanne nicht gezeigt hätte.
Was ist eine KI-Steuerungsebene?
Wir haben Cortx und TrueFoundry als gehostete Dienste getestet. Sie sind KI-Steuerungsebenen: eine gehostete Schicht, die Richtlinien, Identität und Audit-Protokoll für den KI-Datenverkehr eines Unternehmens bereithält und Tool-Aufrufe durch sich selbst leitet, sodass überall dieselben Regeln gelten.
Das Gateway leitet den Datenverkehr. Die Steuerungsebene entscheidet, was erlaubt ist, und protokolliert, was geschehen ist. Anbieter verkaufen Letzteres als Grund, Ersteres zu kaufen.
Beide Werte werden von der Netzwerkentfernung dominiert. Cortx fügt von derselben Maschine 211.1 Millisekunden hinzu und TrueFoundry 55.5, und allein die Round-Trip-Zeit beträgt ungefähr 100 Millisekunden zur Region von Cortx gegenüber 14.1 zu der von TrueFoundry. Zwei Überquerungen machen ungefähr 200 der 211 Millisekunden von Cortx aus. Wir bewerten die beiden niemals gegeneinander.
Eine Steuerungsebene behauptet, dass eine Richtlinie überall gilt; genau das haben wir getestet. Cortx liefert das Antwort-Scanning für MCP-Tool-Aufrufe deaktiviert aus, und nur ein Organisationsadministrator kann es aktivieren. Bei aktiviertem Scanning, dem Injektionsdetektor im Durchsetzungsmodus und einer Richtlinie, die zwei integrierte Kategorien auf Block setzt, hielt Cortx jede Antwort zurück, die injizierte Anweisung trug, und maskierte die drei Standard-Zugangsdatenformate, wobei der restliche Fehlertext zurückgegeben wurde.
Bei aktiver Richtlinie und deaktiviertem Organisationsschalter erreichten jedes Zugangsdatenformat und beide Anweisungsformen den Client. Cortx erkennt Injection mit einem separaten Detektor statt mit einer Richtlinienkategorie. Der Detektor blockiert nur im Durchsetzungsmodus. Im Überwachungsmodus markiert er die Anweisung und lässt die Antwort durch.
Eine Steuerungsebene kann daher eine aktive Richtlinie anzeigen und dennoch den Pfad, der Ihnen wichtig ist, nicht scannen. Fragen Sie einen Anbieter, welche Einstellung seine Engine auf den Tool-Antwort-Pfad setzt und in welchem Modus seine Detektoren laufen. Cortx und TrueFoundry sind zwei der 12 Steuerungsebenen, die wir hinsichtlich der 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 sich außerhalb davon befinden, wie etwa einen Datenbankabfragedienst oder eine interne API. Ein Gateway ist ein Proxy, durch den all diese Aufrufe laufen, sodass ein Betreiber viele Agenten auf eine Adresse verweisen kann, statt jeden Agenten 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.
Was der Pfad abdeckt und nicht abdeckt
Ein Gateway sieht Tool-Aufrufe und Tool-Antworten. Es sieht weder die privaten Überlegungen des Modells noch den vollständigen Chat-Kontext; daher testet dieser Benchmark Injektionskontrollen nur bei Tool-Antworten.
Außerdem schützt es nur Datenverkehr, der über es läuft. Wir haben das Backend direkt erreichbar gelassen und den Schutz vor Umgehungen nicht bewertet, 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 Ursprungsprotokoll null Verbindungen aufzeichnete, und das von uns getestete free-Tarif-Konto besaß nicht die Schlüsselklasse, die eine Integration auf Organisationsebene erfordert.
Messzeitpunkte: Latenz eigenständiger MCP-Tools 2026-08-13, Richtlinien- und Audit-Sweep 2026-08-21, gehostete Latenz von TrueFoundry 2026-08-17, gehostete Latenz von Cortx 2026-08-19.
Umgebung: eine Maschine mit 8 vCPUs, Gateway und Mock-Backend kolokalisiert, Caddy über TLS. Gehostete Gateways werden über das WAN aufgerufen, daher enthalten ihre Werte Netzwerklatenz, die diese Konfiguration nicht sauber von der Gateway-Verarbeitung trennen kann. Cortx sendet aus 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 leakt auf Anfrage 4 Zugangsdatenformate (GitHub-Token, AWS-Schlüssel-ID, JWT, beliebige Anbieterzeichenfolge), gibt injizierte Anweisungen in 2 Formen zurück (strukturierte Liste, free-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 Sekunden an Varianz zu einer Mikrosekundenmessung hinzufügen, ohne zu ändern, was das Gateway tut.
Latenz: mediane zusätzliche Latenz bei Parallelität 1, der über das Gateway geroutete Aufruf minus einem passenden direkten Aufruf an das Backend, wobei die beiden Pfade verschachtelt wurden, um Driftverzerrungen zu reduzieren. Bifrost 5 Wiederholungen, Docker und ContextForge 3, bei 200 Aufrufen pro Aufgabe und Wiederholung. Sequenzielle Probenahme wurde verworfen: Sie übertraf Docker um 89 % und Bifrost um 54 %. Lasso läuft über stdio statt über einen Socket und hat daher keinen vergleichbaren Wert.
Richtlinien-Sonden (n=30 jeweils): eine injizierte Anweisung in 2 Formen, ein Zugangsdaten-Leak in 4 Formaten und ein Aufruf eines Tools, für das die Berechtigung nicht freigegeben ist. Die direkte Baseline zum Backend gab jede Nutzlast zurück, sodass eine Null durch ein Gateway anzeigt, dass das Gateway gehandelt hat, und nicht, dass die Sonde fehlgeschlagen ist.
Konfiguration: jedes Produkt wurde mit den stärksten uns verfügbaren Inhaltsschutzmaßnahmen gemessen, wobei die ausgelieferten Detektorparameter beibehalten wurden. Wir haben kein Muster geschrieben, das zur Testnutzlast passt. Wenn ein Produkt über eine Standard- und eine verwaltete Konfiguration verfügt, veröffentlichen wir beide. TrueFoundry, ContextForge und Cortx lieferten ihre Inhaltsschutzmaßnahme jeweils deaktiviert aus und wurden mit aktivierter Maßnahme erneut gemessen, und alle drei protokollierten die Durchsetzung auf dem getesteten Pfad. Bei Cortx legte dessen Anbieter xnode den Schalter auf Organisationsebene und den Detektormodus fest, die unser Konto nicht ändern kann, und fügte der Musterbibliothek unseres Workspace Standard-Tokenformate von Anbietern hinzu, einschließlich der von GitHub.
Audit: Wir haben jede identifizierte Audit-Oberfläche gelesen, einschließlich stdout, Datenbankspeicher, Aktivitätsprotokolle und gehosteter Trace-Ansichten. Wir haben Datenbankspeicher 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 20. Oktober 2026}
}Ergebnisse und Zeitstempel von 35 Datenpunkten. Laden Sie die Zusammenfassungsdaten aus den Diagrammen und Tabellen dieses Artikels als ZIP-Datei herunter, die 7 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
Als nächstes lesen
Top 8 Atera-Alternativen: MSP-Funktionen und Preise im Vergleich
MSP-Automatisierung: NinjaOne, Acronis & ConnectWise
Codeausführung mit MCP: Ein neuer Ansatz für die Effizienz von KI-Agenten
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.