Kong disponibilizou o Kong AI Gateway 2.0 para o público geral, marcando mais um passo na mudança do proxy LLM simples para um plano de controle mais amplo para modelos, agentes, ferramentas e gastos com IA.

A versão de 1º de setembro traz vários recursos importantes para equipes que já executam cargas de trabalho de IA de produção: pacote de servidores MCP para acesso governado a ferramentas, gerenciamento dinâmico de custos que leva em conta diferentes modalidades, modelo mais amplo e cobertura de provedor, políticas de IA com reconhecimento de identidade e autenticação IAM nativa para Amazon Bedrock AgentCore. Kong também diz que o produto agora está disponível no Kong Konnect sem habilitação beta.

Essa combinação é a novidade. A categoria de gateway de IA não trata mais apenas de receber uma solicitação no estilo OpenAI, encaminhá-la para um provedor e registrar a resposta. Os compradores corporativos desejam cada vez mais que o gateway decida quem pode ligar para qual modelo, quais ferramentas um agente pode usar, como os gastos devem ser medidos e como essas decisões são mapeadas para os sistemas de identidade já usados ​​pela empresa.

O que mudou no Kong AI Gateway 2.0

A adição mais notável é o MCP Server Bundling. MCP, ou Model Context Protocol, tornou-se uma forma comum de expor ferramentas e recursos a agentes de IA. O agrupamento de servidores MCP na camada de gateway oferece às equipes de plataforma um local para agregar e controlar essas conexões de ferramentas, em vez de deixar que cada equipe de aplicação conecte e policie suas próprias integrações de agentes.

Essa é uma direção de produto significativa. À medida que os agentes passam de demonstrações para fluxos de trabalho internos, o risco é menor de um modelo responder mal a uma pergunta e mais de um modelo estar conectado a muitas ferramentas com pouca supervisão. Um gateway que possa empacotar e controlar o acesso MCP está mais próximo do problema operacional: quais agentes podem alcançar quais sistemas, sob cuja identidade e com quais limites de política.

Kong também adicionou gerenciamento de custos dinâmico com reconhecimento de modalidade. Isso é importante porque o preço da IA ​​não é mais um medidor de token único. Texto, imagem, áudio, vídeo, chamadas de ferramentas, contexto em cache e modos de raciocínio podem trazer economias diferentes dependendo do provedor. Uma camada de controle de custos que entende a modalidade pode fornecer às equipes limites e regras de roteamento mais precisos do que um contador de solicitações genérico.

A versão também expande a cobertura de modelos e provedores e adiciona políticas de IA com reconhecimento de identidade. A autenticação IAM nativa do Kong para Amazon Bedrock AgentCore é especialmente relevante porque o Bedrock AgentCore está se tornando um dos locais onde as empresas executam e gerenciam agentes. Conectar a política de gateway à identidade na nuvem reduz a lacuna entre os controles específicos de IA e os sistemas de acesso que as empresas já auditam.

Por que isso é importante para desenvolvedores e equipes de plataforma

Para os desenvolvedores, o efeito prático é que o gateway está se tornando parte da arquitetura do aplicativo, e não apenas um complemento de infraestrutura. Uma equipe que cria um agente de suporte interno, um assistente de codificação ou um fluxo de trabalho de análise de dados pode agora precisar de regras de gateway para acesso a modelos, acesso a ferramentas, limites de orçamento e propagação de identidade antes que o aplicativo chegue à produção.

Isso pode adicionar alguns custos de configuração, mas também resolve um modo de falha real. Sem uma camada de gateway compartilhada, a seleção de modelos, as credenciais do provedor, as permissões de ferramentas e os controles de gastos tendem a se espalhar pelo código do aplicativo, pelos segredos do CI, pelos wrappers do SDK e pelos painéis específicos da equipe. Essa fragmentação torna os incidentes mais difíceis de investigar e as migrações de modelos mais difíceis de executar.

O lançamento de Kong também é um sinal para os fornecedores que criam camadas de API compatíveis com OpenAI e produtos de API multimodelos. A compatibilidade por si só está se tornando uma aposta de mesa. Os clientes esperam cada vez mais governança em torno da solicitação: aplicação de políticas, análise de uso, acesso em nível de equipe, controles de orçamento, roteamento alternativo e visibilidade de modelo/provedor.

Para usuários do Model Gate, a conexão é direta. Faturamento unificado, gerenciamento de chaves de API, análise de uso e controles de equipe tornam-se mais valiosos quando o acesso ao modelo é apenas uma parte do fluxo de trabalho. À medida que os agentes obtêm acesso às ferramentas por meio de interfaces estilo MCP, os gateways precisarão representar não apenas qual modelo foi chamado, mas também qual equipe, chave, pacote de ferramentas e contexto de política estavam envolvidos.

A referência competitiva está mudando

Kong não está sozinho nessa direção. Movimentos recentes no mercado mostram que os fornecedores de infraestrutura de IA estão convergindo para o mesmo problema mais amplo: a IA empresarial precisa de um caminho governado entre usuários, modelos, agentes, ferramentas e gastos. Os produtos da Gateway estão sendo julgados menos pela capacidade de normalizar os formatos de solicitação e mais pela capacidade de suportar controles de produção.

Isso pressiona os compradores a fazerem perguntas mais precisas. O gateway compreende preços e modalidades específicas do fornecedor? Os administradores podem definir políticas por equipe ou identidade? Ele pode rotear entre provedores sem perder a auditabilidade?Ele pode governar as ferramentas do agente, e não apenas modelar endpoints? Ele pode expor dados de uso e custo de uma forma que finanças, segurança e engenharia possam usar?

Essas questões não são mais teóricas. Modelos de contexto longo, chamadas de ferramentas de agentes e cargas de trabalho multimodais podem alterar rapidamente os perfis de custos. Um fluxo de trabalho que parece barato durante o teste pode se tornar caro quando contextos repetidos, entradas de imagens ou loops de agentes com muitas ferramentas entram em produção. Um gateway que não consegue distinguir esses padrões ainda pode centralizar o acesso, mas não dará aos operadores controle suficiente.

O que permanece incerto

O anúncio estabelece a disponibilidade geral e nomeia os principais recursos, mas a adoção no mundo real dependerá dos detalhes da implementação: como as equipes configuram os pacotes MCP, quão granulares são as políticas de reconhecimento de identidade, como os controles de custos se comportam em provedores mistos e quanta visibilidade operacional os clientes obtêm na prática.

Também é muito cedo para saber se as empresas padronizarão a governança dos agentes em um único gateway de IA ou divida a responsabilidade entre plataformas de nuvem, ferramentas de segurança, plataformas de desenvolvedores e fornecedores de observabilidade. AWS, plataformas de hospedagem, fornecedores de IDE e provedores de gateway independentes estão todos tentando possuir partes da mesma superfície de controle.

Ainda assim, a direção é clara. Kong AI Gateway 2.0 trata o tráfego de IA como um sistema empresarial governado, em vez de um fluxo de chamadas de modelo. Para desenvolvedores e empresas que desenvolvem APIs de modelo, isso significa que as decisões de gateway estão se tornando decisões de arquitetura: elas afetam o custo, a segurança, a escolha do modelo, o acesso às ferramentas e a confiabilidade dos fluxos de trabalho dos agentes.