MCP Gateway Benchmark: Latência e Segurança de 6 Gateways
Um MCP gateway fica entre um agente de IA e as ferramentas que ele chama, e os fornecedores o posicionam como a camada de segurança para esse tráfego. Avaliamos seis MCP gateways em relação a um backend instrumentado em uma única máquina, medindo latência adicionada, autorização por ferramenta, proteção de conteúdo e completude de auditoria.
MCP resultados do benchmark de gateway
Um produto aparece em relação a um controle somente se ele o oferece e se esse controle foi executado, portanto ninguém recebe pontuação zero por um recurso que não vende.
Dois dos seis gateways medidos executaram um detector de injeção nas configurações disponíveis para nós. O Cortx bloqueou todas as 60 instruções injetadas e o TrueFoundry bloqueou 55 de 60. Nos outros quatro, uma instrução inserida em uma resposta de ferramenta chegou ao cliente.
O ContextForge oferece 44 plugins.1 Os três cujos nomes contêm “inject” adicionam um cabeçalho HTTP, um aviso de privacidade e um cabeçalho de licença, e nenhum dos demais detecta injeção.
A varredura de credenciais é a dimensão mais bem atendida. Cinco gateways bloquearam todos os três formatos detectáveis por padrão. Cortx, Lasso e TrueFoundry ocultam o segredo identificado e retornam o restante da resposta. ContextForge e Docker retêm toda a saída ferramenta, de modo que o chamador também perde a mensagem de erro.
Três produtos são fornecidos com os controles de conteúdo desativados, que é o estado em que a maioria dos leitores os encontrará. O ContextForge detecta credenciais quando um operador ativa seus plugins. O Cortx examina as respostas das ferramentas somente depois que um administrador da organização ativa essa opção.
Instruções injetadas nas respostas das ferramentas
A sonda retorna uma resposta de ferramenta contendo uma instrução dirigida ao modelo em duas formas: um item dentro de uma lista estruturada e uma frase inserida em texto gratuito. Um gateway que inspeciona a saída ferramenta deve removê-la ou recusá-la.
O TrueFoundry bloqueia 27 de 30 na forma de lista e 28 de 30 na forma de texto gratuito, usando seu detector de injeção de prompt integrado na configuração padrão de aplicação. A recusa nomeia a regra que foi acionada.
Cinco de 60 tentativas ainda chegaram ao cliente, e a estratégia padrão permite a passagem de uma solicitação quando o próprio detector apresenta erro.
O Cortx bloqueia 30 de 30 em ambas as formas com seu detector de injeção indireta em modo de aplicação. No lugar da saída ferramenta, o cliente recebe um aviso nomeando o que o detector identificou. Suas configurações também permitem a passagem de uma resposta quando um detector falha.
Testamos ambos os detectores em uma instrução em duas formas. O resultado não abrange outras instruções e não classifica os dois produtos.
A sonda mede se o gateway remove o texto. Ela não testa se um modelo seguiria a instrução.
Credenciais de backend nas respostas das ferramentas
O backend retorna um erro contendo quatro credenciais: um token do GitHub, um ID de chave de acesso da AWS, um JWT e uma string arbitrária de fornecedor.
Nenhum dos scanners testados capturou a string arbitrária de fornecedor, pois nenhum possuía uma regra escrita para esse formato. O ContextForge e o Docker a bloquearam apenas porque retiveram toda a resposta após detectar as outras três.
A varredura de segredos do Docker é ativada por padrão e é o único controle de credenciais nesta tabela que um operador obtém sem configurar nada.
Autorização por ferramenta
A sonda restringe uma credencial para excluir uma ferramenta e, em seguida, chama essa ferramenta diretamente pelo nome.
Quatro dos seis aplicam a restrição, e nenhum deles retorna os dados retidos. A versão de código aberto do Docker é executada sem uma credencial de chamador, portanto pode ocultar uma ferramenta globalmente, mas não pode fornecer a dois chamadores conjuntos de ferramentas diferentes. A superfície de plugins do Lasso é composta por guardrails e rastreamento, sem nenhuma etapa de autorização.
O Bifrost registra 840 microssegundos com uma chave com escopo e 866 com uma sem escopo, uma diferença menor que a variação entre repetições. Restringir o escopo de uma credencial não acarretou penalidade de latência que pudéssemos detectar.
O Cortx e o TrueFoundry nomeiam a restrição; o Cortx retorna “Tool not permitted for this session”. O Bifrost e o ContextForge relatam a ferramenta como não encontrada. Nenhum dos comportamentos é pontuado aqui.
Completude da auditoria
Lemos todas as superfícies de auditoria que conseguimos identificar. A maioria dos produtos divide o registro entre um log e um banco de dados.
O TrueFoundry e o Cortx registram as negativas de autorização. O rastreamento do TrueFoundry para a chamada recusada contém o nome da ferramenta, o e-mail do chamador, os argumentos e o texto da recusa. O registro do Cortx contém o nome da ferramenta, o ID de usuário do chamador, os argumentos e um resultado NEGADO com o motivo.
O Bifrost e o ContextForge bloqueiam uma chamada não autorizada, e nenhum deles a registra. Seus repositórios mantiveram a mesma contagem de linhas antes e depois da tentativa.
O ContextForge não registrou nenhuma invocação com falha em nossa implantação, e sua tabela audit_trails de 26 colunas permaneceu vazia o tempo todo.
O Docker é o único gateway auto-hospedado que deixa algum rastro de uma chamada bloqueada, e o rastro aparece como sucesso. A linha contém o nome da ferramenta e uma duração plausível de dois milissegundos, sem campo de resultado, de modo que um operador que procura eventos de segurança não a encontraria.
O Cortx registra os argumentos da ferramenta e a resposta completa. O Bifrost, o Lasso e o TrueFoundry fazem o mesmo. A visualização de atividade do gateway do Cortx mostra apenas as últimas 50 chamadas, mas um segundo repositório ainda mantinha nossas chamadas de seis semanas antes, com seus argumentos.
Latência adicionada
O Bifrost adiciona 840 microssegundos por chamada, o Docker 1.134 e o ContextForge 23.058. O ContextForge adiciona 27 vezes mais latência do que o Bifrost.
O número informado pelo Bifrost é inferior a 100 microssegundos por solicitação, medido a 5.000 solicitações por segundo.2 Nosso teste enviou uma solicitação por vez e mediu 840 microssegundos. Não testamos a 5.000 solicitações por segundo, portanto esse resultado não mostra que a afirmação está errada.
Um gateway também deixa mais lento o tráfego que nunca passa por ele. Enquanto o Docker ou o ContextForge estava em operação, as chamadas feitas diretamente ao backend foram executadas cerca de 0.9 milissegundos mais lentas, entre 858 e 973 microssegundos nas quatro tarefas de medição de tempo.
Esse efeito não se aplicaria a um gateway em seu próprio host, portanto é relatado separadamente dos números de chamadas roteadas acima.
Custo da governança
Dois produtos puderam ser medidos com o controle de conteúdo desativado e ativado, alterando uma configuração entre os pares.
Os quatro detectores do ContextForge custaram 3.198 microssegundos, um aumento de 11,5%. Os desvios-padrão entre repetições foram de 157 microssegundos com eles desativados e de 73 com eles ativados. Esta linha de base não é comparável ao gráfico de latência: o framework de plugins e a contagem de ferramentas eram diferentes, portanto apenas a mudança dentro do par é válida.
Os dois guardrails do TrueFoundry elevam o tempo de 55.5 para 172.1 milissegundos, aproximadamente o triplo. Suas três repetições mediram 152.6, 163.4 e 200.3 milissegundos. Com os detectores desativados, o desvio-padrão entre repetições foi de 1.5 milissegundos.
Os dois tipos de detector tiveram custos diferentes. A correspondência de padrões do ContextForge adicionou 11,5%, enquanto a detecção de injeção e de segredos do TrueFoundry em conjunto aproximadamente triplicou o valor e variou de 152.6 a 200.3 milissegundos entre repetições, de modo que uma única execução não teria mostrado essa faixa.
O que é um plano de controle de IA?
Testamos o Cortx e o TrueFoundry como serviços hospedados. Eles são planos de controle de IA: uma camada hospedada que mantém a política, a identidade e a trilha de auditoria do tráfego de IA de uma organização e roteia as chamadas de ferramentas por meio de si mesma para que um único conjunto de regras se aplique em todos os lugares.
O gateway movimenta o tráfego. O plano de controle decide o que é permitido e registra o que aconteceu. Os fornecedores vendem o segundo como o motivo para comprar o primeiro.
Ambos os números são dominados pela distância de rede. O Cortx adiciona 211.1 milissegundos e o TrueFoundry 55.5 a partir da mesma máquina, e somente o tempo de ida e volta é de cerca de 100 milissegundos para a região do Cortx, contra 14.1 para a do TrueFoundry. Dois cruzamentos representam aproximadamente 200 dos 211 milissegundos do Cortx. Nunca classificamos os dois um contra o outro.
Um plano de controle afirma que uma política se aplica em todos os lugares, então foi isso que testamos. O Cortx fornece a varredura de respostas para chamadas de ferramentas MCP desativada, e somente um administrador da organização pode ativá-la. Com a varredura ativada, o detector de injeção no modo de aplicação e uma política que habilita duas categorias integradas em Block, o Cortx reteve todas as respostas que continham a instrução injetada e mascarou os três formatos de credencial padrão, retornando o restante do texto de erro.
Com a política ativa e o interruptor da organização desativado, todos os formatos de credencial e ambas as formas de instrução chegaram ao cliente. O Cortx detecta injeção com um detector separado, e não com uma categoria de política. O detector bloqueia apenas no modo de aplicação. No modo de monitoramento, ele sinaliza a instrução e permite a passagem da resposta.
Um plano de controle pode, portanto, exibir uma política ativa e ainda assim não examinar o caminho que importa para você. Pergunte a um fornecedor qual configuração coloca o mecanismo dele no caminho da resposta da ferramenta e em qual modo seus detectores são executados. O Cortx e o TrueFoundry são dois dos 12 planos de controle que pontuamos quanto à cobertura de recursos; este benchmark mede o que dois deles realmente fazem no caminho MCP.
Adicionar como fonte preferencialO que é um MCP gateway?
O Model Context Protocol permite que um agente de IA descubra e chame ferramentas que residem fora dele, como um serviço de consulta a banco de dados ou uma API interna. Um gateway é um proxy pelo qual todas essas chamadas passam, de modo que um operador pode apontar muitos agentes para um único endereço em vez de conectar cada agente a cada ferramenta.
Um gateway centraliza quatro tarefas entre muitos agentes e ferramentas. Ele decide qual chamador pode usar qual ferramenta, inspeciona a saída ferramenta antes que o modelo a leia, registra o que aconteceu e roteia o tráfego.
O que o caminho cobre e não cobre
Um gateway vê as chamadas e as respostas das ferramentas. Ele não vê o raciocínio privado do modelo nem o contexto completo do chat, portanto este benchmark testa os controles de injeção somente nas respostas das ferramentas.
Ele também protege apenas o tráfego que passa por ele. Deixamos o backend diretamente acessível e não pontuamos a resistência a bypass, porque esse resultado dependeria de controles de rede de implantação fora do caminho do gateway.
MCP metodologia do benchmark de gateway
Produtos: sete selecionados, seis medidos. Bifrost v1.6.10, Docker MCP Gateway v0.43.3, IBM ContextForge v1.0.7, Lasso Security v1.2.1 (auto-hospedados); Cortx v1.1, console TrueFoundry Developer tier 0.167.0 (hospedado). O Portkey não produziu nenhuma medição. A sincronização do workspace relatou sucesso enquanto nosso log de origem registrou zero conexões, e a conta de nível gratuito que testamos não possuía a classe de chave que uma integração de nível organizacional exige.
Datas de medição: Latência de ferramentas MCP autônomas 2026-08-13, varredura de política e auditoria 2026-08-21, latência hospedada do TrueFoundry 2026-08-17, latência hospedada do Cortx 2026-08-19.
Ambiente: uma máquina de 8 vCPUs, gateway e backend simulado colocados no mesmo local, Caddy sobre TLS. Os gateways hospedados são acessados pela WAN, portanto seus números incluem latência de rede que esta configuração não consegue separar de forma clara do processamento do gateway. O Cortx origina de AWS us-east-1; a região do TrueFoundry não foi identificada de forma independente.
Backend: um servidor MCP simulado, 16 ferramentas, atrasos determinísticos por ferramenta, 4 delas ecos puros para medição de tempo. Ele vaza 4 formatos de credencial sob solicitação (token do GitHub, ID de chave da AWS, JWT, string arbitrária de fornecedor), retorna instruções injetadas em 2 formas (lista estruturada, texto gratuito) e registra cada chamada. Os três formatos de credencial padrão são sintéticos, com comprimentos e estruturas que atendem às regras de formato usadas por scanners reais de segredos.
Cliente: um cliente MCP determinístico sem modelo de linguagem. Um modelo no caminho adicionaria segundos de variação a uma medição em microssegundos sem mudar o que o gateway faz.
Latência: latência adicionada mediana em concorrência 1, a chamada roteada pelo gateway menos uma chamada correspondente direta ao backend, com os dois caminhos intercalados para reduzir o viés de deriva. Bifrost 5 repetições, Docker e ContextForge 3, a 200 chamadas por tarefa por repetição. A amostragem sequencial foi rejeitada: superestimou o Docker em 89% e o Bifrost em 54%. O Lasso é executado por stdio em vez de um socket, portanto não tem um número comparável.
Sondas de política (n=30 cada): uma instrução injetada em 2 formas, um vazamento de credencial em 4 formatos e uma chamada a uma ferramenta para a qual a credencial não tem escopo. A linha de base direta ao backend retornou todos os payloads, portanto um zero através de um gateway indica que o gateway agiu, não uma sonda com falha.
Configuração: cada produto medido com os controles de conteúdo mais fortes disponíveis para nós, mantendo os parâmetros padrão de detector. Não escrevemos nenhum padrão para corresponder ao payload de teste. Quando um produto tem uma configuração padrão e uma configuração governada, publicamos ambas. O TrueFoundry, o ContextForge e o Cortx forneceram seus controles de conteúdo desativados e foram medidos novamente com eles ativados, e os três registraram a aplicação no caminho testado. No Cortx, o xnode do fornecedor definiu o interruptor no nível da organização e o modo do detector, os quais nossa conta não pode alterar, e adicionou formatos padrão de token de fornecedor, incluindo o do GitHub, à biblioteca de padrões do nosso workspace.
Auditoria: Lemos todas as superfícies de auditoria que identificamos, incluindo stdout, repositórios de banco de dados, logs de atividade e visualizações de rastreamento hospedadas. Fizemos checkpoints nos repositórios de banco de dados antes de contar as linhas.
Para resultados em nível de modelo, consulte o benchmark de LLM agêntico.
Cite este benchmark
Escolha o formato adequado ao local onde você vai publicar. Colar a versão com link no seu CMS preserva o backlink.
@misc{kalelioglu2026,
author = {Kalelioğlu, Berk},
title = {{MCP Gateway Benchmark: Latência e Segurança de 6 Gateways}},
year = {2026},
month = oct,
howpublished = {\url{https://aimultiple.com/mcp-gateway}},
note = {AIMultiple. Acessado em 5 outubro 2026}
}Resultados e carimbos de data/hora de 35 pontos de dados. Baixe os dados resumidos exibidos nos gráficos e tabelas deste artigo como um arquivo ZIP contendo 7 arquivos CSV e um README.
Quer os dados granulares por trás disso? Assine o Premium
Registro de alterações
2 atualizaçõesAdicionada seção de resultados de benchmark comparando seis gateways MCP em latência e segurança
Adicionados IBM ContextForge, Kong AI Gateway e MintMCP Gateway à cobertura de gateways.
Links de referência
A seguir, leia
Automação de MSP: NinjaOne, Acronis & ConnectWise
Execução de código com MCP: uma nova abordagem para a eficiência de agentes de IA
MCP Benchmark: Principais Servidores MCP para Acesso à Web
Seja o primeiro a comentar
Seu endereço de e-mail não será publicado. Todos os campos são obrigatórios. Os comentários são deixados em seu idioma original.