MCP Gateway Benchmark: Latência e Segurança de 6 Gateways
Um gateway MCP 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 gateways MCP 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.
Resultados do benchmark de gateway MCP
Um produto aparece em relação a um controle apenas se ele o oferece e esse controle foi executado, então ninguém recebe nota zero por um recurso que não vende.
Um dos seis gateways medidos oferece um detector de injeção. TrueFoundry interrompeu 55 de 60 instruções injetadas com ele. Os outros cinco não possuem detecção de injeção ou jailbreak, então uma instrução plantada em uma resposta de ferramenta chega ao cliente por meio de cada um deles.
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 melhor atendida. Quatro gateways bloquearam todos os três formatos detectáveis por correspondência de padrão. Eles diferem no que o chamador recebe: Lasso e TrueFoundry ocultam o segredo correspondente e devolvem o restante da resposta, enquanto 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 vêm com seus controles de conteúdo desativados, que é o estado em que a maioria dos leitores os encontrará. O ContextForge captura credenciais uma vez que um operador ativa seus plugins. O Cortx não bloqueou nada, mesmo com uma política ativa.
Instruções injetadas em respostas de ferramentas
A sonda retorna uma resposta de ferramenta contendo uma instrução dirigida ao model em duas formas: um item dentro de uma lista estruturada e uma frase incorporada 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 integrado de prompt-injection na configuração de imposição padrão. A recusa informa a regra que disparou.
Cinco de 60 tentativas ainda chegaram ao cliente, e a estratégia padrão deixa uma solicitação passar quando o próprio detector falha.
A sonda mede se o gateway remove o texto. Ela não testa se um model seguiria a instrução.
Credenciais de backend em respostas de 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, porque nenhum tinha uma regra escrita para seu formato. O ContextForge parece bloqueá-la apenas porque toda a resposta foi retida com base nas outras três.
A varredura de segredos do Docker está 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 define o escopo de uma credencial para excluir uma ferramenta e, em seguida, chama essa ferramenta diretamente pelo nome.
Quatro dos seis aplicam, 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 oferecer a dois chamadores conjuntos de ferramentas diferentes. A superfície de plugins do Lasso é de guardrails e tracing, sem nenhuma etapa de autorização.
O Bifrost mede 840 microssegundos com uma chave com escopo e 866 com uma sem escopo, uma diferença menor que a variação entre repetições. Definir escopo em uma credencial não acarretou penalidade de latência que pudéssemos detectar.
Cortx e TrueFoundry nomeiam a restrição; o Cortx retorna “Ferramenta não permitida para esta sessão”. Bifrost e ContextForge relatam a ferramenta como não encontrada. Nenhum desses comportamentos é pontuado aqui.
Completude de 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.
TrueFoundry é o único participante que registra uma negação de autorização. O trace da chamada recusada contém o nome da ferramenta, o e-mail do chamador, os argumentos e o texto da recusa.
Bifrost, ContextForge e Cortx bloqueiam uma chamada não autorizada, e nenhum deles registra que ela ocorreu. Seus armazenamentos 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 durante todo o período.
O Docker é o único gateway auto-hospedado que deixa algum rastro de uma chamada bloqueada, e o trace aparece como um 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 procurando eventos de segurança não a encontraria.
O Cortx registra os argumentos da ferramenta e a resposta completa, o que apenas Lasso e TrueFoundry também fazem, mas mantém 50 linhas independentemente do limite solicitado. Essa janela cobriu 11 segundos da nossa execução de 2.400 chamadas.
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 que o Bifrost.
O valor do próprio Bifrost de sub-100 microssegundos é uma alegação de vazão em alta concorrência.2 Em concorrência 1, ele adiciona aproximadamente dez vezes esse valor, e a alegação deve ser testada como um número de vazão em vez de ser tratada como refutada aqui.
Um gateway também deixa mais lento o tráfego que nunca passa por ele. Enquanto o Docker ou o ContextForge estava servindo, as chamadas feitas diretamente ao backend rodaram 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 custam 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. Essa linha de base não é comparável ao gráfico de latência: o framework de plugins e o número de ferramentas diferiram, portanto apenas a mudança dentro do par é válida.
Os dois guardrails do TrueFoundry levam 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 custam valores diferentes. A correspondência de padrões do ContextForge adicionou 11.5%, enquanto a detecção de injeção do TrueFoundry praticamente triplicou o número 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?
Cortx e TrueFoundry não são gateways que você instala. 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 si mesma para que um conjunto de regras se aplique em todos os lugares.
O gateway é a parte que movimenta o tráfego. O plano de controle é a parte que 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 apenas o tempo de ida e volta é de cerca de 100 milissegundos para a região do Cortx, contra 14.1 para a do TrueFoundry. Duas travessias representam aproximadamente 200 dos 211 milissegundos do Cortx. Nunca classificamos os dois um contra o outro.
A alegação de um plano de controle é que uma política se aplica em todos os lugares, então foi isso que testamos. O Cortx vem com a varredura de respostas desativada. Criamos uma política, ativamos duas de suas categorias integradas em Block, a aprovamos, e o endpoint de status do próprio produto confirmou que a nossa era a política ativa. Todos os formatos de credenciais e ambas as instruções injetadas ainda chegaram ao cliente, e ativar a política não custou latência mensurável.
O log de imposição mostra o motivo: cada evento que ele registra fica na etapa que roda em torno de uma chamada de model, e nosso caminho não contém nenhum model. Nenhuma de suas categorias integradas cobre injeção de prompt ou detecção de jailbreak, a mesma lacuna do conjunto de plugins do ContextForge.
Um plano de controle pode, portanto, estar configurado corretamente, relatar-se como ativo e ainda assim não estar no caminho que importa para você. Uma resposta de ferramenta MCP é uma superfície mais nova do que um prompt de model, e um engine de políticas cobre as superfícies para as quais foi criado. Pergunte a um fornecedor em qual estágio do engine dele uma resposta de ferramenta é vista e obtenha essa resposta antes da auditoria, e não depois.
Adicionar como fonte preferencialO que é um gateway MCP?
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, para que um operador possa apontar muitos agentes para um único endereço em vez de conectar cada agente a cada ferramenta.
Um gateway centraliza quatro tarefas em muitos agentes e ferramentas. Ele decide qual chamador pode usar qual ferramenta, inspeciona a saída ferramenta antes que o model a leia, registra o que aconteceu e roteia o tráfego.
O que o caminho cobre e o que não cobre
Um gateway vê chamadas de ferramentas e respostas de ferramentas. Ele não vê o raciocínio privado do model nem o contexto completo do chat, portanto este benchmark testa controles de injeção apenas em respostas de 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.
Metodologia do benchmark de gateway MCP
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-hospedado); Cortx v1.1, console do tier Developer da TrueFoundry 0.167.0 (hospedado). O Portkey não produziu nenhuma medição. A sincronização do espaço de trabalho relatou sucesso enquanto nosso log de origem registrou zero conexões, e a conta do tier gratuito que testamos não tinha a classe de chave exigida por uma integração em nível organizacional.
Datas de medição: Latência de ferramentas MCP autônomas em 2026-08-13, varredura de políticas e auditoria em 2026-08-21, latência hospedada do TrueFoundry em 2026-08-17, latência hospedada do Cortx em 2026-08-19.
Ambiente: uma máquina de 8 vCPUs, gateway e backend simulado co-localizados, 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 limpa do processamento do gateway. O Cortx faz egresso da 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 cronometragem. Ele vaza 4 formatos de credenciais sob solicitação (token do GitHub, ID de chave 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 credenciais padrão são sintéticos, com comprimentos e estruturas que satisfazem as regras de formato usadas por scanners de segredos reais.
Cliente: um cliente MCP determinístico sem language model. Um model 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 direta ao backend correspondente, 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 roda sobre 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 todas as cargas, portanto um zero através de um gateway indica que o gateway agiu, e não uma sonda com falha.
Configuração: todos os produtos foram medidos com os controles de conteúdo mais fortes disponíveis para nós, mantendo os parâmetros dos detectores fornecidos. Nenhum padrão foi escrito para corresponder à carga de teste. Quando um produto tem uma configuração padrão e uma governada, ambas são publicadas. TrueFoundry, ContextForge e Cortx vieram com o controle de conteúdo desativado e foram medidos novamente com ele ativado. TrueFoundry e ContextForge registraram imposição no caminho testado; o Cortx confirmou que a política estava ativa, mas não registrou nenhum evento de imposição para essas chamadas.
Auditoria: todas as superfícies de auditoria que identificamos foram lidas, incluindo stdout, armazenamentos de banco de dados, logs de atividade e visualizações de trace hospedadas. Os armazenamentos de banco de dados foram submetidos a checkpoint antes da contagem de linhas.
Para resultados em nível de model, 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 = aug,
howpublished = {\url{https://aimultiple.com/mcp-gateway}},
note = {AIMultiple. Acessado em 24 Agosto 2026}
}Registro de alterações
2 atualizações- 2026
Adicionada 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
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.