Agentgateway reúne tráfego de LLM, MCP e A2A em um único proxy open source

Ivan, arquiteto de sistemas da RED Security, publicou no Habr uma análise do Agentgateway, um gateway open source capaz de processar três tipos de tráfego de IA ao mesmo tempo: requisições a modelos de linguagem, chamadas de ferramentas via MCP e a comunicação dos agentes entre si por A2A. A ideia é familiar para quem já viu a IA se espalhar por uma empresa: em vez de dezenas de conexões diretas, com chaves no código e sem um registro unificado, passa a existir um único ponto de controle.

Ressalva: o feed traz apenas o anúncio do artigo; o texto completo está no Habr. Por isso, o contexto abaixo vem da documentação pública do projeto e não é um resumo dos detalhes da análise do autor.

Que problema o gateway resolve

Quando as equipes conectam LLMs uma a uma, tudo parece inofensivo. Um serviço acessa a OpenAI, outro a Anthropic, um terceiro o Gemini. Depois surgem agentes que chamam APIs internas por servidores MCP e também chamam uns aos outros. Cada conexão tem suas próprias chaves, seus próprios limites e seus próprios logs. Ou nenhum deles.

É comum o time de segurança perguntar quais dados saíram da empresa na semana passada e ninguém ter como responder. O gateway resolve isso na arquitetura: todo o tráfego passa pelo proxy, e as regras ficam descritas em um único lugar. Para uma empresa com certificações e exigências de reguladores, isso não é questão de conveniência, e sim condição para colocar a IA em produção.

O que se sabe sobre o projeto

O Agentgateway foi criado pela Solo.io e depois transferido para a Linux Foundation. Isso importa para quem teme ficar preso a um único fornecedor: o código é aberto e a governança vai além de uma só empresa. O núcleo é escrito em Rust, o que costuma significar baixo consumo de memória e latência previsível no caminho crítico.

Principais recursos, segundo a documentação:

• três tipos de tráfego em um só proxy: requisições a LLMs, MCP e A2A;
• roteamento para vários provedores de modelos, incluindo plataformas de nuvem e APIs compatíveis com a OpenAI;
• autorização e políticas de acesso, inclusive baseadas em JWT e expressões CEL;
• limites e controle de consumo vinculados a tokens, e não apenas ao número de requisições;
• filtros de proteção para prompts e respostas;
• métricas e tracing via OpenTelemetry;
• integração com o Kubernetes Gateway API e uma interface embutida para depuração.

Onde está o problema

O gateway se torna um ponto único de falha e um ponto único de ataque. Ele precisa de redundância, atualizações e monitoramento tão rigorosos quanto os de um balanceador de carga externo. Outro ponto: os protocolos MCP e A2A são jovens, as especificações ainda mudam, e a compatibilidade terá de ser testada em servidores e agentes reais, não em um ambiente de demonstração.

Há também um risco organizacional. Se as equipes continuarem acessando os modelos por fora do gateway, com chaves pessoais, a centralização fica só no papel. Tecnicamente, isso se resolve com políticas de rede e entregando as chaves apenas ao gateway, mas essa já é uma decisão no nível da infraestrutura, não de um único projeto.

Por onde começar a adoção

O caminho prático é este. Primeiro, suba o gateway em um ambiente de testes e passe por ele um serviço não crítico que use LLM. Compare a latência e confirme que os logs trazem o que a auditoria precisa. Depois, mova as chaves dos provedores dos aplicativos para a configuração do gateway e bloqueie o acesso direto à internet dos serviços que consultam os modelos.

O passo seguinte é definir as políticas para as ferramentas MCP. Comece com a negação por padrão e libere apenas as ferramentas de que o agente realmente precisa. Por fim, configure limites de tokens para cada equipe: assim, o gasto com IA deixa de ser surpresa no fim do mês. Detalhes de configuração e exemplos estão no artigo original do autor no Habr e na documentação do projeto.