AWS relie trois agents d'IA dans deux comptes via le protocole A2A

Vous avez créé un assistant d'IA d'entreprise avec LangChain, alors que le fournisseur du service de contrôle de sécurité utilise Strands. Il faut maintenant les relier : transmettre la tâche, vérifier l'accès et expliquer au service externe quelles règles internes s'appliquent chez le client. Généralement, une couche d'intégration distincte apparaît alors, que les deux équipes doivent maintenir.

AWS a publié un exemple de ce type de liaison via Agent-to-Agent, ou A2A. Trois agents y fonctionnent dans deux comptes AWS, échangent des tâches et se demandent mutuellement du contexte. L'intérêt pratique de ce document tient à un schéma concret d'interaction entre entreprises : des frameworks différents, des systèmes d'identité distincts et un rappel vers le client.

Comment l'agent externe découvre les règles de l'entreprise

Imaginez la demande d'un responsable : vérifier si les comptes de travail enfreignent les exigences de sécurité internes. L'agent d'entreprise reçoit la question et confie la vérification à l'agent du fournisseur SaaS. Mais le fournisseur ignore de lui-même quels comptes relèvent de la production, quelles données sont considérées comme confidentielles et qui prévenir en cas de problème.

L'agent externe se tourne donc vers un troisième participant : l'agent interne de contexte. Celui-ci fournit des informations sur les comptes, les politiques applicables et les contacts d'escalade. Une fois le contexte obtenu, l'agent SaaS termine la vérification et renvoie le résultat à l'orchestrateur de l'entreprise, qui prépare la réponse destinée à l'utilisateur.

Par exemple, un compte de production peut être soumis à l'interdiction du stockage public, et les données confidentielles à l'obligation de chiffrement au repos. Ces règles sont définies par l'entreprise. Le fournisseur obtient les informations nécessaires via une interface convenue et les utilise dans sa tâche.

Dans la démonstration, les données sur les violations sont synthétiques. Les auteurs décrivent la connexion réelle à AWS Config, Security Hub ou GuardDuty comme la prochaine étape pour un système de production. L'exemple montre donc l'organisation de l'interaction, mais ne prouve pas la qualité d'un audit de sécurité automatique.

Ce que A2A standardise exactement

Au démarrage, l'orchestrateur charge l'Agent Card de l'agent externe, une description de ses capacités. À partir des compétences publiées, il crée des outils LangChain, et le modèle choisit l'outil adapté à la question de l'utilisateur. Dans ce schéma, il n'est pas nécessaire de définir une route distincte pour chaque question.

La carte de l'agent SaaS publie une seule capacité applicative : la vérification de conformité aux exigences. Les outils internes, le prompt système et le choix du modèle restent côté fournisseur. Celui-ci peut modifier l'implémentation tant qu'il préserve la compatibilité de la carte et de l'interface A2A externe.

Pour une équipe produit, c'est une frontière de responsabilité utile : le client s'intègre à la capacité du service, tandis que le fournisseur fait évoluer seul sa structure interne. Il faut toutefois maintenir la compatibilité de l'interface : le protocole n'annule pas les accords sur le comportement et le résultat de la tâche.

Dans cette architecture, A2A joue aussi un rôle distinct de MCP. Avec MCP, un agent peut connecter ses propres outils et sources de données. Avec A2A, il confie du travail à un autre agent. Un même service peut utiliser les deux protocoles : MCP en interne, A2A pour l'interaction avec le client.

Où s'arrête l'exemple prêt à l'emploi

Chaque partie utilise son propre pool d'utilisateurs Amazon Cognito. Lors de la connexion, les entreprises échangent des paramètres publics : adresses, identifiants de clients et périmètres d'accès. Aucun secret n'est transmis entre elles, même si, au sein de chaque partie, des secrets servent à obtenir les jetons et sont stockés dans Secrets Manager.

Le rappel n'est autorisé que vers l'adresse enregistrée lors de la connexion du client. Avant l'appel, l'agent SaaS vérifie la carte de l'agent interne. C'est un détail important : l'adresse de destination est définie par la configuration de l'intégration, et non par un texte arbitraire de la tâche entrante.

Le déploiement est découpé en trois notebooks Jupyter. Les durées indiquées par les auteurs pour les étapes sont d'environ 3, 5 et 20 minutes ; la préparation des comptes et des autorisations demandera du temps supplémentaire. L'infrastructure est payante, et une partie des ressources fonctionne en permanence, notamment la passerelle NAT, les tâches Fargate et l'équilibreur de charge.

Le développeur gagnera à étudier cet exemple si son agent doit travailler avec des services de partenaires ou de différentes équipes internes. On peut commencer par un seul scénario : transmettre une tâche à l'agent externe, autoriser une demande de contexte limitée et tester tout le trajet avec les jetons des deux parties. C'est précisément ce segment qu'AWS a détaillé assez concrètement pour servir de base à un prototype.