Sécurité des agents A2A et MCP : identité, délégation et traçabilité

L’injection de prompt attire la majeure partie de l’attention en matière de sécurité dans les systèmes de LLM, et cela est justifié, mais ce n’est pas le seul problème une fois que les agents commencent à utiliser des outils et à déléguer du travail à d’autres agents.

MCP donne à un agent un accès structuré aux fichiers, aux API, aux bases de données et aux systèmes de ticketing. A2A permet à un agent d’envoyer des tâches, des messages et des artefacts à un autre agent qui peut appartenir à une autre équipe, un autre vendeur ou un autre runtime. Ces protocoles sont utiles précisément parce qu’ils traversent les limites de confiance, ce qui signifie que l’identité, l’autorisation, les limites de délégation et les traces d’audit deviennent une architecture de premier plan plutôt qu’un durcissement optionnel.

Cet article est le guide canonique pour la sécurité des protocoles d’agents dans le cluster [Architecture LLM](https://www.glukhov.org/fr/llm-architecture/ “Décisions de conception système pour les systèmes LLM de production : routage de modèles, optimisation des coûts, garde-fous, orchestration multi-modèles et ingénierie de prompt. Il couvre les modèles de menace, l’identité, les passerelles, les registres, la délégation et les listes de contrôle de production. Pour la validation des entrées, le filtrage des sorties et les modèles de sécurité des prompts, consultez plutôt Garde-fous LLM en pratique.

Garde-fous vs Sécurité des protocoles vs Politique d’exécution

Ces trois couches résolvent des problèmes différents et échouent de différentes manières lorsqu’elles sont confondues.

Les garde-fous LLM opèrent sur les entrées et sorties du modèle : blocage des schémas d’injection, filtrage du contenu nocif, validation de la forme JSON et application de règles de ton ou de conformité sur le texte généré. Ils protègent la couche de conversation.

La sécurité des protocoles opère sur les limites des agents : qui peut appeler quel outil MCP, quel agent peut déléguer à quel pair, quels champs OAuth sont attachés à une tâche et si un agent en aval peut agir au nom d’un utilisateur. Elle protège la couche d’action.

La politique d’exécution se situe entre les deux : un moteur de politique qui évalue les requêtes par rapport aux règles, indépendamment du fait que le déclencheur ait été du langage naturel ou un appel de protocole structuré. Elle peut exiger l’approbation humaine avant l’exécution d’un outil, bloquer l’accès sortant vers des domaines inconnus ou refuser la délégation lorsque le champ d’application dépasse celui de l’utilisateur d’origine.

Mon opinion est brutale : les garde-fous sans sécurité de protocole produisent des chatbots polis qui exfiltraient quand même des données via un appel d’outil. La sécurité de protocole sans garde-fous produit des agents bien authentifiés qui suivent quand même des instructions malveillantes intégrées dans un artefact. Vous avez besoin des deux, plus d’une politique d’exécution pour les actions à haut risque.

Modèle de menace pour les systèmes d’agents A2A et MCP

Commencez par les actifs et les adversaires, pas par une liste de courses de contrôles.

Actifs à protéger : données utilisateur dans les prompts et artefacts, identifiants pour les serveurs MCP, systèmes de production accessibles via les outils, réputation des agents, comptes de facturation liés à l’utilisation des jetons et intégrité de l’audit.

Adversaires réalistes : utilisateurs externes abusant des points de terminaison d’agent publics, serveurs MCP compromis retournant des résultats d’outils empoisonnés, agents malveillants faussant les compétences dans les cartes d’agent, initiés déléguant excessivement l’autorité et manipulation de la chaîne d’approvisionnement des métadonnées d’outils qui manipulent le comportement du modèle.

Outils malveillants ou compromis (MCP)

Un serveur MCP est du code et des données exposés au modèle. Un serveur hostile peut retourner des descriptions d’outils trompeuses, exfiltrer les arguments passés par le modèle ou effectuer des actions au-delà de ce que l’utilisateur a prévu lorsque l’hôte exécute des appels d’outils sans identifiants limités.

Agents malveillants ou usurpés (A2A)

Un agent qui accepte des tâches peut être malveillant, compromis ou simplement sur-dérogé. Les cartes d’agent décrivent les capacités ; elles ne prouvent pas l’identité à moins que vous ne vérifiiez les signatures, le TLS et la confiance de l’émetteur.

Confused deputy (délégation confuse)

L’agent B détient la permission d’accéder à une API financière. L’agent A, avec des privilèges inférieurs, demande à B de “résumer cette facture” tout en cachant une instruction de transfert dans un artefact. B exécute en utilisant ses propres identifiants à moins que le champ de délégation ne soit appliqué de bout en bout.

Permissions trop larges et chaînes de délégation cachées

L’utilisateur approuve une étape. L’orchestrateur enchaîne silencieusement trois sauts A2A et cinq appels MCP. L’utilisateur ne voit jamais le graphe complet, mais l’organisation est toujours responsable du résultat.

Injection de prompt via les artefacts et les messages inter-agents

L’injection n’est pas seulement un problème de message utilisateur. Un artefact PDF, une page web récupérée par un outil ou un message de l’Agent C peut transporter des instructions destinées au modèle de l’Agent D. Traitez tout contenu transporté par protocole comme une entrée non fiable à la limite du modèle.

Cartes d’agent empoisonnées ou trompeuses

Les descriptions et les noms de compétences sont une surface de prompt. Une carte qui publie safe_read_only_analysis (analyse en lecture seule sécurisée) tout en acceptant des backends capables d’écriture est une couche d’ingénierie sociale, pas une garantie technique.

Modèle d’identité pour les systèmes multi-agents

La sécurité du protocole commence par des types d’identité clairs et ce que chacun est autorisé à prouver.

La carte d’agent A2A publie les schémas d’authentification pris en charge (OAuth 2.0, clés API, mTLS et des modèles similaires alignés avec les pratiques OpenAPI) et les compétences avec des exigences de sécurité facultatives. La carte est une métadonnée de découverte, pas une ancre de confiance. Les clients obtiennent les identifiants hors bande et les envoient dans les en-têtes HTTP standard à chaque requête ; les serveurs doivent valider à chaque appel et retourner 401 ou 403 lorsque l’authentification ou le champ échoue.

Vues internes vs externes du même agent

Les agents de production publient souvent une carte d’agent publique avec une liste de compétences limitée et une carte authentifiée plus riche pour les appelants internes. La spécification A2A permet des cartes étendues pour les clients authentifiés. Utilisez cette séparation délibérément : les partenaires ne devraient pas voir les compétences internes, et les orchestrateurs internes ne devraient pas s’appuyer uniquement sur la découverte publique pour l’autorisation.

Authentification et autorisation pour MCP et A2A

L’authentification répond à qui appelle. L’autorisation répond à ce qu’ils peuvent faire.

Accès aux outils MCP

Pour chaque connexion MCP, définissez :

• quel hôte d’agent peut se connecter
• quels outils sont activés pour cet hôte
• quel utilisateur OS ou compte de service exécute les effets secondaires
• si l’utilisateur humain doit approuver chaque appel mutateur

Privilégiez les listes blanches d’outils par rapport aux configurations MCP “connecter tout”. Un agent de codage n’a pas besoin de serveurs MCP de paie sur le même profil qu’un bot de support public.

Accès aux agents A2A

Pour chaque relation entre pairs d’agents, définissez :

• quels IDs d’agents appelants peuvent invoquer quelles compétences
• profondeur maximale de délégation
• quels types d’artefacts peuvent traverser la limite
• si le contexte utilisateur doit se propager comme des revendications signées

Mappez les champs OAuth (ou équivalents) aux compétences, pas à l’administration générale de l’agent. Le moindre privilège au niveau du jeton bat l’espoir au niveau du prompt.

Politique appliquée par la passerelle vs par agent

La politique par agent fonctionne lorsqu’une équipe possède tout le graphe et que les versions sont coordonnées. La politique appliquée par la passerelle fonctionne lorsque plusieurs équipes, locataires ou vendeurs partagent un réseau d’agents et que vous avez besoin d’un endroit pour appliquer les listes blanches, les limites de taux et l’audit.

Passerelle A2A comme plan de contrôle

Une passerelle A2A n’est pas strictement requise par le protocole, mais elle devient nécessaire lorsque le trafic d’agents a besoin d’une gouvernance centralisée.

Une passerelle gère typiquement :

• terminaison d’authentification et échange de jetons
• routage vers le service d’agent correct par compétence ou locataire
• vérifications de politique avant que les tâches soient acceptées ou transférées
• négociation de version de protocole
• limitation de taux et détection d’abus
• émission d’audit structurée à chaque transition de tâche

Quand une passerelle est excessive vs nécessaire

Une passerelle est souvent excessive pour un seul orchestrateur et deux agents spécialistes dans un espace de noms Kubernetes maintenu par une seule équipe. Elle devient nécessaire lorsque des partenaires invoquent vos agents, lorsque plusieurs unités commerciales partagent l’infrastructure, lorsque la conformité exige une journalisation uniforme, ou lorsque vous ne pouvez pas faire confiance à chaque implémentation d’agent pour appliquer correctement la politique.

Associez une passerelle A2A avec une passerelle MCP (ou proxy MCP) afin que l’accès aux outils reçoive le même traitement : identité, listes blanches, contrôles de sortie et audit à la limite de l’outil plutôt qu’au niveau de l’interface utilisateur de chat uniquement.

Cartes d’agent pour les partenaires vs internes

Publiez des métadonnées de découverte différentes pour les appelants externes et internes. Les cartes externes exposent des compétences étroites et une authentification plus stricte. Les cartes internes peuvent lister des compétences de maintenance ou d’administration mais ne doivent jamais être accessibles sans une authentification plus forte que celle impliquée par la carte publique.

Sécurité du registre et de la découverte d’agents

La découverte fait partie de la surface d’attaque. Quiconque contrôle ce qui apparaît comme “disponible” contrôle où les orchestrateurs envoient le travail.

Registre vs URLs de cartes d’agent bien connues

Les petits déploiements utilisent des URLs bien connues par agent (/.well-known/agent-card.json). Les déploiements d’entreprise ajoutent un registre qui indexe les IDs d’agent, les versions, les points de terminaison, les propriétaires et les étiquettes de politique. Le registre est un objet de politique : les entrées devraient enregistrer quels locataires peuvent découvrir quels agents, pas seulement où ils résident.

Versionning, dépréciation et propriété

Les enregistrements du registre ont besoin de propriétaires, d’historique des changements et de dates de dépréciation. Un orchestrateur qui met en cache les cartes d’agent doit actualiser sur le TTL et vérifier les signatures là où c’est supporté. Les cartes périmées sont la façon dont les compétences retirées continuent de recevoir du trafic longtemps après qu’une vulnérabilité a été corrigée.

Réseaux internes d’entreprise vs partenaires externes

Les maillages d’agents internes peuvent s’appuyer sur mTLS et DNS privé. Les agents partenaires ont besoin de règles de fédération explicites, de compétences limitées contractuellement et d’une inspection d’artefacts plus forte car vous ne contrôlez pas leur runtime.

Délégation à travers les limites des agents

La délégation est là où la sécurité A2A est gagnée ou perdue. Lorsque l’Agent A envoie une tâche à l’Agent B, trois questions doivent avoir des réponses précises :

1. De quelle autorité est exercée ? Celle de l’utilisateur, du compte de service de A, ou un jeton délégué mélangé ?
2. Ce que B est autorisé à faire avec cette autorité ? Analyse en lecture seule, ou outils mutateurs au nom de A ?
3. Qui est responsable si B dépasse le champ ? A, B, la politique de la passerelle, ou l’humain qui a approuvé un prompt ambigu ?

Propager l’intention utilisateur vs sur-délégation

Transmettez des revendications de délégation signées qui incluent l’ID utilisateur, l’ID de tâche original, les compétences autorisées, l’expiration et le nombre maximal de sauts. Les agents en aval doivent rejeter les tâches qui étendent le champ silencieusement. Si B a besoin de privilèges plus élevés que ceux détenus par A, passez à input_required et obtenez l’approbation humaine explicite plutôt que de mettre à niveau les jetons invisiblement.

Les flux d’approbation humaine dans la boucle pour la délégation risquée sont couverts dans A2A Streaming et tâches asynchrones pour les workflows d’agents longue durée où input_required est un état de tâche de premier plan plutôt qu’une erreur.

Séparer le raisonnement des permissions d’exécution

Un agent peut avoir besoin d’un large accès en lecture pour planifier tandis que les outils en écriture sont derrière une approbation. Divisez les identifiants ou utilisez des profils MCP distincts pour la planification vs l’exécution afin qu’une erreur de modèle ne puisse pas muter immédiatement la production.

Traces d’audit et provenance des réponses

Si vous ne pouvez pas reconstruire une chaîne de délégation, vous ne pouvez pas expliquer un incident, passer un audit ou contester une anomalie de facturation.

Journalisez à trois couches :

Passerelle : résultat d’authentification, décision de politique, ID d’agent routé, ID de tâche, ID de tâche parent, événements de limitation de taux.

Agent : transitions d’état de tâche, messages envoyés/reçus, invocations de modèle/outils (arguments masqués si nécessaire), artefacts créés, délégation sortante.

Serveur MCP : nom de l’outil, ID de l’agent appelant, contexte utilisateur, succès/échec, latence, lignes affectées ou IDs de ressources (si la politique le permet).

Corrélez avec un ID de traçage à travers toutes les couches. Observabilité pour les systèmes LLM couvre les backends d’instrumentation ; cet article définit ce qui doit être capturé afin que ces backends aient un signal significatif.

La provenance de la réponse finale devrait répondre à : quel utilisateur, quelle tâche d’orchestrateur, quels agents spécialistes, quels outils, quels artefacts ont influencé le texte que l’utilisateur a vu, et quelles portes de politique ont été déclenchées en cours de route.

Politique d’exécution, sortie et secrets

Les moteurs de politique d’exécution (OPA, Cedar, services de règles personnalisés) évaluent des événements structurés : “outil X avec args Y pour utilisateur Z”. Ils complètent les garde-fous car ils ne dépendent pas du fait que le modèle se comporte bien.

L’approbation humaine appartient à la politique d’exécution pour les actions irréversibles ou à haut coût : paiements, e-mail externe, changements de configuration de production, attributions de privilèges.

Les contrôles de sortie limitent les domaines que les serveurs MCP et les agents peuvent appeler. Un agent qui peut à la fois lire des secrets et POST vers des URLs arbitraires est une perte de données en attente de se produire.

Les secrets n’appartiennent jamais dans les cartes d’agent ou les prompts. Les hôtes MCP devraient injecter des identifiants à courte durée de vie au moment de l’exécution depuis un gestionnaire de secrets. Pour le chiffrement du transport, la gestion des clés et les modèles de sécurité d’infrastructure de base, consultez Modèles architecturaux pour sécuriser les données.

Les webhooks de notification push dans les flux A2A asynchrones ont besoin de la même rigueur : vérifier l’identité de l’expéditeur, rejeter les événements périmés et ne jamais traiter une charge utile de webhook comme une autorisation à elle seule.

Architecture de sécurité de référence

Le diagramme suivant résume une orientation de production pour les déploiements A2A à l’extérieur, MCP à l’intérieur à grande échelle.

L’orchestrateur voit les agents spécialistes via A2A. Les spécialistes voient les outils via MCP. Les utilisateurs ne reçoivent jamais d’identifiants MCP bruts, et les partenaires ne reçoivent jamais de surfaces de compétences internes sans revue de politique.

Pour les concepts de protocole (cartes d’agent, tâches, artefacts), consultez Qu’est-ce que le protocole A2A ?. Pour l’adoption et le cadre d’entreprise, consultez Protocole A2A de Google en 2026. Pour la topologie lorsque de nombreux agents coordonnent, consultez Modèles d’orchestration multi-agents.

Liste de contrôle de production pour la sécurité A2A et MCP

Avant d’exposer les protocoles d’agents au-delà d’un bac à sable de confiance, vérifiez :

Identité et auth

• Pas d’agents anonymes dans les chemins de production
• Chaque appel MCP et A2A authentifié à chaque requête
• Champs OAuth ou équivalents mappés aux compétences/outils, pas à l’administration générale
• Vues de cartes d’agent publiques vs authentifiées définies intentionnellement

Délégation et politique

• Les jetons de délégation portent l’ID utilisateur, l’ID de tâche, le champ, l’expiration, la limite de sauts
• Les agents en aval rejettent l’extension de champ sans approbation explicite
• Les outils à haut risque nécessitent une politique d’exécution ou une approbation humaine
• Le raisonnement et l’exécution utilisent des identifiants séparés lorsque possible

Découverte et registre

• Les entrées du registre d’agents ont des propriétaires et un historique de version
• Les cartes d’agent actualisées sur le TTL ; signatures vérifiées là où supporté
• Les agents partenaires fédérés avec des listes blanches de compétences explicites

Audit et observabilité

• Les couches passerelle, agent et MCP émettent des événements d’audit corrélés
• Les chaînes de délégation journalisées avec les IDs de tâche parent et enfant
• La provenance des artefacts enregistrée pour les réponses finales
• Les IDs de traçage connectés aux backends d’observabilité

Abus et résilience

• Limites de taux par utilisateur, agent et locataire
• Politiques de délai d’attente sur les tâches déléguées
• Listes blanches de sortie sur les serveurs d’outils
• Secrets dans un gestionnaire, pas dans les cartes, les prompts ou les dépôts

Conclusion

L’interopérabilité A2A et MCP est puissante car les agents et les outils peuvent composer à travers les limites des équipes et des vendeurs, mais cette puissance est dangereuse sans conception d’identité, d’autorisation, de limites de délégation et d’audit. Les garde-fous protègent la conversation du modèle ; la sécurité du protocole protège les actions que les agents prennent au nom des utilisateurs.

Traitez les cartes d’agent comme des publicités, la délégation comme un contrat signé, les outils MCP comme une exécution de code privilégiée, et les journaux d’audit comme la chaîne de preuves dont vous aurez besoin lorsque quelque chose d’intéressant se passe à 2 heures du matin.

Construisez la passerelle lorsque la gouvernance a besoin d’une seule gorge à étrangler. Séparez les identifiants avant de séparer les agents. Journalisez chaque saut afin que la réponse “le modèle a décidé” ne soit jamais le rapport d’incident final.

Questions fréquemment posées

Quelle est la différence entre les garde-fous LLM et la sécurité des agents A2A MCP ? Les garde-fous contraignent les entrées et sorties du modèle. La sécurité du protocole contraint qui peut invoquer des outils, déléguer des tâches et agir au nom de qui à travers MCP et A2A avec identité, autorisation et traces d’audit.

Comment l’identité des agents devrait-elle fonctionner dans un déploiement A2A ? Séparez les identités humaines, de service d’agent et de tâche. Validez les identifiants à chaque requête, utilisez des jetons limités et traitez les cartes d’agent comme des métadonnées de découverte plutôt que comme une preuve de confiance.

Quel est le problème du “confused deputy” dans les systèmes multi-agents ? Il se produit lorsqu’un agent ou outil privilégié effectue une action sensible parce qu’un appelant moins privilégié a caché des instructions via la délégation ou les artefacts. Appliquez le champ à chaque saut.

Avez-vous besoin d’une passerelle A2A en production ? Les déploiements internes d’une seule équipe peuvent appliquer la politique par agent. Les réseaux multi-locataires, multi-vendeurs ou face aux partenaires ont généralement besoin d’une passerelle pour l’auth centralisée, le routage, les limites de taux et l’audit.

Que devrait contenir un journal d’audit A2A MCP ? ID utilisateur, ID agent, ID tâche, ID tâche parent, appels d’outils, décisions de politique, artefacts et horodatages corrélés avec les IDs de traçage à travers les couches passerelle, agent et MCP.

Sources

• Protocole A2A – Sujets de sécurité prêts pour l’entreprise : https://github.com/a2aproject/A2A/blob/main/docs/topics/enterprise-ready.md
• Protocole A2A – Aperçu de la spécification : https://a2a-protocol.org/latest/specification/
• Protocole A2A – Streaming et sécurité des notifications push : https://a2a-protocol.org/latest/topics/streaming-and-async/