MoEngage ouvre 400 API privées à ses agents IA via AgentCore Gateway, sans serveurs MCP maison

MoEngage édite une plateforme par laquelle plus de 1350 marques grand public envoient des messages personnalisés : push, email, SMS, WhatsApp et RCS. Lorsque l'entreprise s'est lancée dans les agents IA, elle a constaté que tout le nécessaire fonctionnait déjà : création de campagnes, requêtes sur les segments, statistiques de livraison. Cela représente environ 400 API REST internes, écrites par 25 équipes et hébergées dans des réseaux cloud privés (VPC) répartis sur sept régions AWS.

Elles ne sont pas exposées sur Internet en raison des exigences de conservation des données dans la région. Le défi : laisser les agents y accéder en toute sécurité. La solution : la passerelle managée Amazon Bedrock AgentCore Gateway.

D'après MoEngage, elle a permis d'économiser environ six mois de développement de plateforme. Il s'agit d'une estimation interne à l'entreprise, que personne n'a vérifiée de manière indépendante.

Pourquoi 20 serveurs MCP sont une mauvaise idée

MCP (Model Context Protocol) est le standard par lequel un agent découvre les outils dont il dispose et les appelle. La voie évidente : chaque équipe monte son propre serveur MCP. MoEngage a chiffré ce que cela impliquerait :

• plus de 20 déploiements à surveiller, à patcher et à adapter à l'évolution du protocole ; • les agents qui ont besoin de données issues de plusieurs domaines (une campagne, son segment, ses statistiques de livraison) devraient se connecter à plusieurs serveurs et fusionner les réponses ; • chaque équipe produit aurait besoin d'une expertise MCP sans rapport avec son vrai métier.

La règle est donc la suivante : les équipes n'écrivent pas de MCP. Elles développent leur API REST et indiquent quelles opérations doivent être considérées comme des outils. Toute la couche MCP est pilotée par l'équipe AI Platform. La responsabilité de l'équipe produit s'arrête à une spécification OpenAPI bien écrite.

De cette règle, l'entreprise a tiré quatre conditions strictes, à remplir simultanément :

• aucune adresse publique : ni passerelles NAT, ni proxys, ni VPN pour chaque intégration, faute de quoi il faudrait tout multiplier par sept régions ; • l'identité de l'appel n'est pas une décision du modèle : le tenant, l'utilisateur, le rôle et le contexte de base de données ne peuvent pas être des paramètres que le modèle risque de modifier par erreur ou qu'on pourrait le convaincre de changer ; • le catalogue de 400 outils ne doit pas peser sur le contexte : avec environ 50 tokens de schéma par outil, la liste complète dépasse 20 000 tokens à chaque connexion ; • un filtre côté client ne constitue pas une protection : si le catalogue a déjà été transmis, l'agent a vu ce qu'il n'aurait pas dû voir.

Comment AgentCore Gateway répond à ces conditions

La passerelle fonctionne comme un serveur MCP entièrement managé. On enregistre les spécifications OpenAPI comme cibles, et elle génère elle-même les outils et route les appels. Chaque opération reçoit un nom de la forme Target___operationId, par exemple CampaignsAPI___searchCampaigns. Un endpoint ajouté à la spécification fait apparaître l'outil, un endpoint retiré le fait disparaître. Ni déploiement, ni validation par l'équipe plateforme.

L'accès est encadré par des politiques écrites en langage Cedar. Chaque agent s'authentifie avec son propre rôle IAM. Le moteur de politiques sélectionne les outils avant même la construction de la réponse à tools/list. Un bot de vérification de campagnes, par exemple, reçoit le groupe d'outils campaigns-read et une interdiction explicite sur le groupe write-actions. Les outils d'écriture ne figurent tout simplement pas dans sa liste : ils n'ont pas été envoyés, et non masqués côté client.

La connectivité repose sur une sortie managée (egress) via Amazon VPC Lattice. Le trafic entrant passe uniquement par un point de terminaison d'interface VPC avec DNS privé. Pour une nouvelle API, il suffit d'ajouter une cible à la passerelle, sans toucher à la topologie réseau. Le réseau se configure une seule fois.

Trois autres choix méritent d'être repris :

• SigV4 plutôt que JWT : les agents internes sont déjà des services dotés de rôles IAM. Ils signent donc leurs requêtes avec les clés existantes, sans rien avoir à émettre ni à renouveler. Le serveur MCP public de MoEngage, destiné aux utilisateurs de Claude et d'autres clients, fonctionne quant à lui séparément avec OIDC JWT ; • l'identité dans les en-têtes : la bibliothèque cliente convertit un petit objet Identity en en-têtes X-MOE-*.

Le modèle ne les voit pas. Comme SigV4 occupe l'en-tête Authorization, le jeton bearer d'un tiers est transmis dans un en-tête distinct, préfixé MoEngage ; • la recherche plutôt que la liste : le modèle ne voit qu'un seul méta-outil, search_tools. L'agent décrit sa tâche, la recherche sémantique de la passerelle renvoie des candidats, et seuls ceux-ci deviennent appelables jusqu'à la fin du tour.

Si get_segment_user_count est renommé en get_segment_size, la recherche par le sens le retrouvera quand même.

Un API branché en quelques heures et trois mois de production

L'équipe ajoute à sa spécification un bloc x-moe-mcp. L'exposition est un consentement explicite : pas de bloc, pas d'outil, et la CI ne le signale pas. Les agents n'ont besoin ni de préchauffage de cache ni de migrations. Les drapeaux internal et external ouvrent indépendamment l'opération aux agents internes, au serveur MCP public, ou aux deux.

Premier enseignement : une description d'API écrite pour un développeur fonctionne mal comme description d'outil pour un modèle. Lorsque MoEngage insérait telle quelle la mention « Returns a paginated list », les modèles choisissaient l'outil d'après des détails d'implémentation plutôt que d'après l'intention. Désormais, les champs tool_description et param_overrides permettent de rédiger un texte destiné au modèle sans toucher à la documentation pour les humains. Le reste est géré par la CI : elle valide le bloc, enregistre la cible dans la passerelle et applique la politique Cedar.

Le système tourne aujourd'hui dans sept régions et dessert environ 400 opérations pour 10 agents internes. Parmi eux figurent un agent de vérification de campagnes (règles de ciblage et contenu avant lancement), un agent de santé de la livraison (vitesse d'envoi et pics de bounce par canal) et un générateur de segments (qui transforme une description d'audience en langage naturel en requête). Chacun a son propre rôle et son propre jeu d'outils.

Les nouveaux agents démarrent sans noms d'outils codés en dur : ils décrivent leur intention, obtiennent des candidats, puis appellent. Un renommage ou une nouvelle opération est pris en compte sans modifier le code. Selon l'entreprise, le branchement d'une nouvelle API prend désormais quelques heures au lieu de plusieurs jours.

La leçon pour les ingénieurs : si vous disposez de nombreuses API internes, ne donnez pas un serveur MCP à chaque équipe. Conservez une couche unique, restreignez l'accès côté serveur et n'exposez pas l'identité dans des paramètres visibles par le modèle. Une réserve : il s'agit d'un billet de blog d'AWS sur un produit d'AWS, rédigé avec un client, et AgentCore n'est pas disponible dans toutes les régions.