MCP Gateway Benchmark: Latency & Security of 6 Gateways
An MCP gateway sits between an AI agent and the tools it calls, and vendors position it as the security layer for that traffic. We benchmarked six MCP gateways against one instrumented backend on a single box, measuring added latency, per-tool authorization, content protection, and audit completeness.
MCP gateway benchmark results
A product appears against a control only if it ships one and that control ran, so nobody is scored zero for a feature they do not sell.
One of the six measured gateways ships an injection detector. TrueFoundry stopped 55 of 60 injected instructions with it. The other five carry no injection or jailbreak detection, so an instruction planted in a tool response reaches the client through each of them.
ContextForge ships 44 plugins.1 The three whose names contain “inject” add an HTTP header, a privacy notice, and a license header, and none of the rest detects injection.
Credential scanning is the better-served dimension. Four gateways stopped all three pattern-matchable formats. They differ in what the caller receives: Lasso and TrueFoundry redact the matched secret and return the rest of the response, while ContextForge and Docker withhold the entire tool output, so the caller also loses the error message.
Three products ship their content controls switched off, which is the state most readers will find them in. ContextForge catches credentials once an operator enables its plugins. Cortx blocked nothing even with a policy active.
Injected instructions in tool responses
The probe returns a tool response carrying an instruction addressed to the model in two forms: an item within a structured list and a sentence embedded in free text. A gateway that inspects tool output should strip or refuse it.
TrueFoundry blocks 27 of 30 on the list shape and 28 of 30 on the free-text shape, using its built-in prompt-injection detector at the default enforcing setting. The refusal names the rule that fired.
Five of 60 attempts still reached the client, and the default strategy lets a request through when the detector itself errors.
The probe measures whether the gateway removes the text. It does not test whether a model would follow the instruction.
Backend credentials in tool responses
The backend returns an error containing four credentials: a GitHub token, an AWS access key id, a JWT, and an arbitrary vendor string.
None of the tested scanners caught the arbitrary vendor string, because none carried a rule written for its shape. ContextForge reads as stopping it only because the whole response was withheld on the strength of the other three.
Docker’s secret scanning is on by default, and it is the only credential control in this table that an operator gets without configuring anything.
Per-tool authorization
The probe scopes a credential to exclude one tool, then calls that tool directly by name.
Four of the six enforce, and none of them returns the withheld data. Docker’s open-source build runs without a caller credential, so it can hide a tool globally but cannot give two callers different tool sets. Lasso’s plugin surface is guardrails and tracing, with no authorization step at all.
Bifrost measures 840 microseconds with a scoped key and 866 with an unscoped one, a gap smaller than the variation between repetitions. Scoping a credential carried no latency penalty we could resolve.
Cortx and TrueFoundry name the restriction, Cortx returning “Tool not permitted for this session”. Bifrost and ContextForge report the tool as not found. Neither behavior is scored here.
Audit completeness
We read every audit surface we could identify. Most products split the record between a log and a database.
TrueFoundry is the only participant that records an authorization denial. Its trace for the refused call carries the tool name, the caller’s email, the arguments, and the refusal text.
Bifrost, ContextForge and Cortx all block an unauthorized call and none records that it happened. Their stores held the same row count before and after the attempt.
ContextForge recorded no failed invocation in our deployment, and its 26-column audit_trails table stayed empty throughout.
Docker is the only self-hosted gateway that leaves any trace of a blocked call, and the trace reads as a success. The line carries the tool name and a plausible two-millisecond duration with no outcome field, so an operator scanning for security events would not find it.
Cortx records the tool arguments and the full response, which only Lasso and TrueFoundry also do, but keeps 50 rows whatever limit is requested. That window covered 11 seconds of our 2,400-call run.
Added latency
Bifrost adds 840 microseconds per call, Docker 1,134, and ContextForge 23,058. ContextForge adds 27 times as much latency as Bifrost.
Bifrost’s own sub-100-microsecond figure is a throughput claim at high concurrency.2 At concurrency 1 it adds roughly ten times that, and the claim should be tested as a throughput number rather than treated as refuted here.
A gateway also slows traffic that never routes through it. While Docker or ContextForge was serving, calls made straight to the backend ran about 0.9 milliseconds slower, between 858 and 973 microseconds across the four timing tasks.
That effect would not apply to a gateway on its own host, so it is reported separately from the routed-call figures above.
Cost of governance
Two products could be measured with their content control off and on, changing one setting between the pairs.
ContextForge’s four detectors cost 3,198 microseconds, an 11.5% increase. Between-repetition standard deviations were 157 microseconds with them off and 73 with them on. This baseline is not comparable with the latency chart: the plugin framework and the tool count both differed, so only the change within the pair holds.
TrueFoundry’s two guardrails take it from 55.5 to 172.1 milliseconds, roughly triple. Its three repetitions measured 152.6, 163.4 and 200.3 milliseconds. With the detectors off, the between-repetition standard deviation was 1.5 milliseconds.
The two detector types cost different amounts. ContextForge’s pattern matching added 11.5%, while TrueFoundry’s injection detection roughly tripled the figure and varied from 152.6 to 200.3 milliseconds across repetitions, so a single run would not have shown that range.
What is an AI control plane?
Cortx and TrueFoundry are not gateways you install. They are AI control planes: a hosted layer that holds the policy, the identity and the audit trail for an organization’s AI traffic, and routes tool calls through itself so one set of rules applies everywhere.
The gateway is the part that moves traffic. The control plane is the part that decides what is allowed and writes down what happened. Vendors sell the second as the reason to buy the first.
Both figures are dominated by network distance. Cortx adds 211.1 milliseconds and TrueFoundry 55.5 from the same box, and the round trip alone is about 100 milliseconds to Cortx’s region against 14.1 to TrueFoundry’s. Two crossings account for roughly 200 of Cortx’s 211 milliseconds. We never rank the two against each other.
A control plane’s claim is that one policy applies everywhere, so that is what we tested. Cortx ships response scanning off. We created a policy, enabled two of its built-in categories at Block, approved it, and the product’s own status endpoint confirmed ours was the live policy. Every credential format and both injected instructions still reached the client, and turning the policy on cost no measurable latency.
Its enforcement log shows why: every event it records sits at the stage that runs around a model call, and our path has no model in it. None of its built-in categories covers prompt injection or jailbreak detection either, the same gap as ContextForge’s plugin set.
A control plane can therefore be correctly configured, report itself as active, and still not sit on the path you care about. An MCP tool response is a newer surface than a model prompt, and a policy engine covers the surfaces it was built for. Ask a vendor which stage of their engine sees a tool response, and get that answer before the audit rather than after. Cortx and TrueFoundry are two of the 12 control planes we scored on feature coverage; this benchmark measures what two of them actually do on the MCP path.
Add as preferred sourceWhat is an MCP gateway?
The Model Context Protocol enables an AI agent to discover and call tools that reside outside it, such as a database query service or an internal API. A gateway is a proxy that all those calls pass through, so an operator can point many agents to one address instead of wiring each agent to each tool.
A gateway centralizes four jobs across many agents and tools. It decides which caller may use which tool, inspects the tool’s output before the model reads it, records what happened, and routes traffic.
What the path does and does not cover
A gateway sees tool calls and tool responses. It does not see the model’s private reasoning or the full chat context, so this benchmark tests injection controls on tool responses only.
It also only protects traffic that goes through it. We left the backend directly reachable and did not score bypass resistance because that result would depend on deployment-network controls outside the gateway path.
MCP gateway benchmark methodology
Products: seven selected, six measured. Bifrost v1.6.10, Docker MCP Gateway v0.43.3, IBM ContextForge v1.0.7, Lasso Security v1.2.1 (self-hosted); Cortx v1.1, TrueFoundry Developer tier console 0.167.0 (hosted). Portkey produced no measurement. Its workspace sync reported success while our origin log recorded zero connections, and the free-tier account we tested lacked the key class an organization-level integration requires.
Measurement dates: Standalone MCP tools latency 2026-08-13, policy and audit sweep 2026-08-21, TrueFoundry hosted latency 2026-08-17, Cortx hosted latency 2026-08-19.
Environment: one 8-vCPU box, gateway and mock backend co-located, Caddy over TLS. osted gateways are accessed over the WAN, so their figures include network latency that this setup cannot cleanly separate from gateway processing. Cortx egresses from AWS us-east-1; TrueFoundry’s region was not independently identified.
Backend: one mock MCP server, 16 tools, deterministic per-tool delays, 4 of them pure echoes for timing. It leaks 4 credential formats on request (GitHub token, AWS key id, JWT, arbitrary vendor string), returns injected instructions in 2 shapes (structured list, free text), and logs every call. The three standard credential formats are synthetic, with lengths and structures that satisfy the format rules real secret scanners use.
Client: a deterministic MCP client with no language model. A model in the path would add seconds of variance to a microsecond measurement without changing what the gateway does.
Latency: median added latency at concurrency 1, the gateway-routed call minus a matched direct-to-backend call, with the two paths interleaved to reduce drift bias. Bifrost 5 repetitions, Docker and ContextForge 3, at 200 calls per task per repetition. Sequential sampling was rejected: it overstated Docker by 89% and Bifrost by 54%. Lasso runs over stdio rather than a socket, so it has no comparable figure.
Policy probes (n=30 each): an injected instruction on 2 shapes, a credential leak on 4 formats, and a call to a tool the credential is not scoped for. The direct-to-backend baseline returned every payload, so a zero through a gateway indicates the gateway acting, not a failed probe.
Configuration: every product measured with the strongest content controls available to us, keeping the shipped detector parameters. No pattern was written to match the test payload. Where a product has a default and a governed configuration, both are published. TrueFoundry, ContextForge and Cortx each shipped their content control off and were re-measured with it on. TrueFoundry and ContextForge logged enforcement on the tested path; Cortx confirmed the policy was active but logged no enforcement event for these calls.
Audit: every audit surface we identified was read, including stdout, database stores, activity logs, and hosted trace views. Database stores were checkpointed before counting rows.
For model-level results, see the agentic LLM benchmark.
Cite this benchmark
Pick the format that matches where you're publishing. Pasting the link version into your CMS preserves the backlink.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk},
title = {{MCP Gateway Benchmark: Latency & Security of 6 Gateways}},
year = {2026},
month = aug,
howpublished = {\url{https://aimultiple.com/mcp-gateway}},
note = {AIMultiple. Retrieved August 24, 2026}
}Changelog
2 updates- 2026
Added benchmark results section comparing six MCP gateways on latency and security
Added IBM ContextForge, Kong AI Gateway and MintMCP Gateway to the gateway coverage.
Reference Links
Be the first to comment
Your email address will not be published. All fields are required. Comments are left in their original language.