Kong AI Gateway 2.0 intègre la gouvernance des agents au travail de passerelle

Kong a rendu Kong AI Gateway 2.0 largement disponible, marquant une nouvelle étape dans la transition du simple proxy LLM vers un plan de contrôle plus large pour les modèles, les agents, les outils et les dépenses en IA.

La version du 1er septembre apporte plusieurs fonctionnalités importantes pour les équipes qui exécutent déjà des charges de travail d'IA en production : le regroupement de serveurs MCP pour un accès aux outils gouverné, une gestion dynamique des coûts qui prend en compte différentes modalités, une couverture plus large des modèles et des fournisseurs, des politiques d'IA prenant en compte l'identité et une authentification IAM native pour Amazon Bedrock AgentCore. Kong indique également que le produit est désormais disponible dans Kong Konnect sans activation bêta.

Cette combinaison fait la une. La catégorie des passerelles AI ne consiste plus seulement à accepter une requête de type OpenAI, à la transmettre à un fournisseur et à enregistrer la réponse. Les acheteurs d'entreprise souhaitent de plus en plus que la passerelle décide qui peut appeler quel modèle, quels outils un agent peut atteindre, comment les dépenses doivent être mesurées et comment ces décisions sont mappées aux systèmes d'identité déjà utilisés par l'entreprise.

Ce qui a changé dans Kong AI Gateway 2.0

L'ajout le plus notable est le regroupement de serveurs MCP. MCP, ou Model Context Protocol, est devenu un moyen courant d'exposer des outils et des ressources aux agents d'IA. Le regroupement des serveurs MCP au niveau de la couche passerelle donne aux équipes de plate-forme un endroit pour regrouper et gouverner ces connexions d'outils plutôt que de laisser chaque équipe d'application câbler et contrôler ses propres intégrations d'agents.

Il s'agit d'une orientation produit significative. À mesure que les agents passent des démonstrations aux flux de travail internes, le risque réside moins dans le fait qu'un modèle réponde mal à une question que dans le fait qu'un modèle soit connecté à trop d'outils avec trop peu de surveillance. Une passerelle capable de regrouper et de contrôler l'accès MCP est plus proche du problème opérationnel : quels agents peuvent atteindre quels systèmes, sous quelle identité et avec quelles limites politiques.

Kong a également ajouté une gestion dynamique des coûts tenant compte des modalités. C’est important car la tarification de l’IA n’est plus un compteur à jeton unique. Le texte, l’image, l’audio, la vidéo, les appels d’outils, le contexte mis en cache et les modes de raisonnement peuvent chacun avoir des conséquences économiques différentes selon le fournisseur. Une couche de contrôle des coûts qui comprend les modalités peut donner aux équipes des limites et des règles de routage plus précises qu'un compteur de requêtes générique.

La version étend également la couverture des modèles et des fournisseurs et ajoute des politiques d'IA prenant en compte l'identité. L'authentification IAM native de Kong pour Amazon Bedrock AgentCore est particulièrement pertinente car Bedrock AgentCore est en train de devenir l'un des endroits où les entreprises exécutent et gèrent des agents. La connexion de la politique de passerelle à l'identité cloud réduit l'écart entre les contrôles spécifiques à l'IA et les systèmes d'accès que les entreprises auditent déjà.

Pourquoi est-ce important pour les développeurs et les équipes de plateforme

Pour les développeurs, l'effet pratique est que la passerelle devient une partie de l'architecture de l'application, et non seulement un module complémentaire d'infrastructure. Une équipe qui crée un agent de support interne, un assistant de codage ou un workflow d'analyse de données peut désormais avoir besoin de règles de passerelle pour l'accès aux modèles, l'accès aux outils, les seuils budgétaires et la propagation des identités avant que l'application n'atteigne la production.

Cela peut ajouter des coûts de configuration, mais cela résout également un véritable mode d'échec. Sans couche de passerelle partagée, la sélection du modèle, les informations d'identification du fournisseur, les autorisations des outils et les contrôles des dépenses ont tendance à se propager dans le code d'application, les secrets CI, les wrappers SDK et les tableaux de bord spécifiques à l'équipe. Cette fragmentation rend les incidents plus difficiles à enquêter et les migrations de modèles plus difficiles à exécuter.

La sortie de Kong est également un signal pour les fournisseurs qui créent des couches d'API compatibles OpenAI et des produits API multimodèles. La compatibilité à elle seule devient un enjeu de table. Les clients attendent de plus en plus une gouvernance autour de la demande : application des politiques, analyses d'utilisation, accès au niveau de l'équipe, contrôles budgétaires, routage de secours et visibilité du modèle/fournisseur.

Pour les utilisateurs de Model Gate, la connexion est directe. La facturation unifiée, la gestion des clés API, l'analyse de l'utilisation et les contrôles d'équipe deviennent tous plus précieux lorsque l'accès au modèle ne constitue qu'une partie du flux de travail. À mesure que les agents accèdent aux outils via des interfaces de type MCP, les passerelles devront représenter non seulement le modèle appelé, mais également l'équipe, la clé, l'ensemble d'outils et le contexte politique impliqués.

La référence concurrentielle évolue

Kong n'est pas le seul dans cette direction. Les évolutions récentes sur le marché montrent que les fournisseurs d’infrastructures d’IA convergent vers un même problème plus vaste : l’IA d’entreprise a besoin d’un chemin gouverné entre les utilisateurs, les modèles, les agents, les outils et les dépenses. Les produits Gateway sont moins jugés en fonction de leur capacité à normaliser les formats de demande et davantage en fonction de leur capacité à prendre en charge les contrôles de production.

Cela pousse les acheteurs à poser des questions plus précises. La passerelle comprend-elle les tarifs et les modalités spécifiques au fournisseur ? Les administrateurs peuvent-ils définir une politique par équipe ou par identité ? Peut-il transiter entre fournisseurs sans perdre en auditabilité ?Peut-il régir les outils des agents, et pas seulement les modèles de points de terminaison ? Peut-il exposer les données d'utilisation et de coût d'une manière que la finance, la sécurité et l'ingénierie peuvent toutes utiliser ?

Ces questions ne sont plus théoriques. Les modèles à contexte long, les appels aux outils d'agent et les charges de travail multimodales peuvent modifier rapidement les profils de coûts. Un flux de travail qui semble bon marché lors des tests peut devenir coûteux lorsque des contextes répétés, des entrées d'images ou des boucles d'agents gourmandes en outils entrent en production. Une passerelle qui ne peut pas distinguer ces modèles peut quand même centraliser l'accès, mais elle ne donnera pas suffisamment de contrôle aux opérateurs.

Ce qui reste incertain

L'annonce établit la disponibilité générale et nomme les fonctionnalités clés, mais l'adoption dans le monde réel dépendra des détails de mise en œuvre : la façon dont les équipes configurent les offres groupées MCP, le degré de granularité des politiques de reconnaissance de l'identité, le comportement des contrôles de coûts entre les fournisseurs mixtes et la visibilité opérationnelle dont bénéficient les clients dans la pratique.

Il est également trop tôt pour savoir si les entreprises standardiseront les agents. gouvernance dans une passerelle d’IA unique ou répartissez la responsabilité entre les plates-formes cloud, les outils de sécurité, les plates-formes de développement et les fournisseurs d’observabilité. AWS, les plateformes d'hébergement, les fournisseurs d'IDE et les fournisseurs de passerelles autonomes tentent tous de posséder des parties de la même surface de contrôle.

Pourtant, la direction est claire. Kong AI Gateway 2.0 traite le trafic IA comme un système d'entreprise gouverné plutôt que comme un flux d'appels de modèles. Pour les développeurs et les entreprises qui s'appuient sur des modèles d'API, cela signifie que les décisions en matière de passerelle deviennent des décisions d'architecture : elles affectent le coût, la sécurité, le choix du modèle, l'accès aux outils et la fiabilité des flux de travail des agents.