Agentgateway réunit le trafic LLM, MCP et A2A dans un seul proxy open source

Ivan, architecte système chez RED Security, a publié sur Habr une analyse d'Agentgateway, un gateway open source capable de faire transiter trois types de trafic d'IA à la fois : les requêtes vers les modèles de langage, les appels d'outils via MCP et les échanges entre agents via A2A. L'idée parlera à quiconque a vu l'IA se diffuser dans une entreprise : au lieu d'une dizaine de connexions directes, avec des clés dans le code et sans journal centralisé, on obtient un seul point de contrôle.

Précision : seule l'annonce de l'article est disponible dans le flux ; le texte complet se trouve sur Habr. Ce qui suit s'appuie donc sur la documentation publique du projet, et non sur un résumé des détails de l'analyse de l'auteur.

Quel problème le gateway résout-il

Tant que les équipes branchent les LLM un par un, tout semble anodin. Un service appelle OpenAI, un autre Anthropic, un troisième Gemini. Puis arrivent les agents, qui appellent des API internes via des serveurs MCP, et qui s'appellent entre eux. Chaque connexion a ses propres clés, ses propres limites, ses propres logs. Ou n'en a aucun.

Le scénario est classique : le responsable sécurité demande quelles données ont quitté l'entreprise la semaine dernière, et personne ne peut répondre. Le gateway règle ce problème par l'architecture : tout le trafic passe par le proxy, et les règles sont décrites en un seul endroit. Pour une entreprise soumise à des certifications et aux exigences des régulateurs, ce n'est pas un confort, mais une condition pour passer l'IA en production.

Ce que l'on sait du projet

Agentgateway a été créé par la société Solo.io, puis le projet a été confié à la Linux Foundation. Le point compte pour ceux qui redoutent la dépendance à un seul éditeur : le code est ouvert et la gouvernance dépasse le cadre d'une seule entreprise. Le cœur est écrit en Rust, ce qui signifie généralement une faible consommation de mémoire et une latence prévisible sur le chemin critique.

Principales fonctionnalités d'après la documentation :

• trois types de trafic dans un seul proxy : requêtes LLM, MCP, A2A ;
• routage vers plusieurs fournisseurs de modèles, y compris des plateformes cloud et des API compatibles OpenAI ;
• authentification et politiques d'accès, notamment à partir de JWT et d'expressions CEL ;
• limites et suivi de consommation fondés sur les tokens, et pas seulement sur le nombre de requêtes ;
• filtres de protection pour les prompts et les réponses ;
• métriques et traçage via OpenTelemetry ;
• intégration avec l'API Kubernetes Gateway et interface intégrée de débogage.

Où est le piège

Le gateway devient un point de défaillance unique et une cible d'attaque unique. Il faut le redonder, le mettre à jour et le superviser avec la même rigueur qu'un load balancer exposé en frontal. Autre point : les protocoles MCP et A2A sont jeunes, leurs spécifications évoluent encore, et la compatibilité devra être vérifiée sur de vrais serveurs et de vrais agents, pas sur un banc de démonstration.

Il existe aussi un risque organisationnel. Si les équipes continuent de contourner le gateway pour appeler les modèles avec des clés personnelles, la centralisation restera théorique. Techniquement, on y remédie avec des politiques réseau et en ne confiant les clés qu'au gateway, mais cette décision relève de l'infrastructure, pas d'un projet isolé.

Par où commencer le déploiement

Voici une démarche pragmatique. Commencez par déployer le gateway dans un environnement de test et faites-y passer un service non critique utilisant un LLM. Comparez la latence et vérifiez que les logs contiennent ce dont l'audit a besoin. Transférez ensuite les clés des fournisseurs, des applications vers la configuration du gateway, et coupez l'accès direct à Internet pour les services qui appellent les modèles.

Étape suivante : définissez les politiques pour les outils MCP. Partez d'une interdiction par défaut et n'autorisez que les outils dont l'agent a réellement besoin. Enfin, configurez des limites par tokens pour chaque équipe : les dépenses d'IA cesseront ainsi d'être une surprise en fin de mois. Pour les détails de configuration et les exemples, mieux vaut consulter l'article original de l'auteur sur Habr et la documentation du projet.