~5 minutes
Les agents A2A sont bavards par nature : ils partagent contexte, résultats et métadonnées à chaque étape. Sans contrôle de ce qui transite, les données sensibles fuient à chaque délégation.
Partie de la série A2A Security
Description du risque
Dans une architecture A2A, chaque délégation de tâche implique une transmission de données entre agents : le payload de la tâche, le contexte de traitement, les résultats intermédiaires, les métadonnées de la session. Ces données transitent souvent sans classification, sans filtrage, et sans contrôle sur ce qui est strictement nécessaire pour l’agent destinataire.
Le résultat est prévisible : des données personnelles (PII), des informations médicales, des données financières, des secrets métier se retrouvent transmises à des agents qui n’en ont pas besoin, stockées dans des logs sans TTL, exposées dans des réponses non filtrées, ou exfiltrées vers des systèmes tiers via des délégations non contrôlées.
C’est une fuite de données silencieuse et distribuée, beaucoup plus difficile à détecter qu’une fuite classique sur une API REST, parce qu’elle se produit à l’intérieur du pipeline agentique, entre des composants qui se font confiance par défaut.
Ce qui entre dans le contexte d’un agent A2A peut ressortir dans n’importe quelle réponse, log ou sous-délégation ultérieure.
Vecteurs d’attaque
1. Transmission de contexte excessif
L’orchestrateur inclut dans le payload de la tâche beaucoup plus de contexte que nécessaire pour l’agent destinataire : le profil complet de l’utilisateur, l’historique complet de la session, des données d’autres utilisateurs stockées en mémoire. L’agent worker reçoit ainsi des informations sensibles qu’il n’a pas besoin de connaître, et les intègre potentiellement dans ses propres délégations ou dans ses logs.
2. Fuite dans les Artifacts de résultat
Un agent qui traite des données sensibles inclut dans son Artifact de résultat plus d’informations que ce que l’orchestrateur attendait : numéros de sécurité sociale visibles dans un rapport d’analyse, données médicales dans un résumé, coordonnées bancaires dans un rapport de traitement. L’orchestrateur transmet cet Artifact à d’autres agents sans vérification de son contenu.
3. Persistance dans les logs inter-agents
Les échanges A2A sont loggés par les frameworks d’orchestration pour le debugging. Sans politique de rétention et sans masquage des données sensibles dans ces logs, les données personnelles qui ont transité dans le pipeline restent accessibles indéfiniment dans les systèmes de log, accessibles à quiconque a accès à l’infrastructure de logging.
Exemple concret
Un pipeline de traitement de dossiers médicaux implique un agent de lecture de dossiers, un agent de résumé et un agent de facturation.
- L’agent de lecture extrait le dossier médical complet : nom, date de naissance, numéro de sécurité sociale, diagnostic, traitement, résultats d’analyses.
- Il transmet l’intégralité du dossier en contexte à l’agent de résumé, alors que cet agent n’a besoin que du diagnostic et du traitement pour générer son résumé.
- L’agent de résumé génère son Artifact et l’inclut dans son propre payload de délégation vers l’agent de facturation, avec les données médicales complètes en contexte.
- L’agent de facturation n’a besoin que du code acte et du montant. Il reçoit pourtant l’intégralité du dossier médical.
- Tous ces échanges sont loggés par le framework d’orchestration. Un mois plus tard, un prestataire externe qui a accès aux logs pour du debugging y trouve des milliers de dossiers médicaux complets.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Faible | Ce risque ne porte pas directement sur l’identité. |
| Tampering (Falsification) | Faible | La fuite de données n’implique pas leur modification. |
| Repudiation (Répudiation) | Oui | Sans audit du contenu des payloads inter-agents, impossible de prouver quelles données ont transité vers quel agent. |
| Information Disclosure (Divulgation) | Oui (PRIMAIRE) | La transmission de données sensibles à des agents non autorisés à les traiter constitue une divulgation non autorisée, avec des implications RGPD directes. |
| Denial of Service (Déni de service) | Faible | Impact limité sur ce vecteur. |
| Elevation of Privilege (Élévation de privilèges) | Modéré | Un agent qui reçoit des données hors de son périmètre peut les utiliser pour initier des actions qu’il n’aurait pas pu effectuer autrement. |
Analyse PASTA
Étape 4 — Analyse des menaces
Threat actors :
- Prestataire tiers avec accès aux logs de l’infrastructure d’orchestration
- Agent worker tiers qui reçoit plus de données que nécessaire et les exploite ou les exfiltre
- Auditeur externe qui découvre des données personnelles dans des logs d’infrastructure lors d’un audit
Motivations : espionnage industriel, vol de données médicales ou financières, conformité RGPD non respectée.
Étape 6 — Modélisation des attaques
graph TD
A["Data Leakage A2A"] --> B["Transmission de contexte excessif"]
A --> C["Persistance dans les logs"]
B --> B1["Payload sans filtrage des champs sensibles"]
B --> B2["Contexte complet transmis à chaque niveau de délégation"]
C --> C1["Logs sans masquage des PII"]
C --> C2["Pas de politique de rétention (TTL des logs)"]
Étape 7 — Analyse de risque/impact
| Scénario | Probabilité | Impact | Score |
|---|---|---|---|
| Données médicales dans les logs d’orchestration | Élevée | Critique | Critique |
| PII transmis à un agent tiers sans nécessité | Élevée | Critique | Critique |
| Artifact contenant des données hors périmètre | Modérée | Élevé | Élevé |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Critique | Des données personnelles, médicales ou financières transmises à des agents non autorisés constituent une violation de données au sens du RGPD, avec obligation de notification à la CNIL dans les 72h. |
| Intégrité | Modéré | Impact limité sur l'intégrité, la fuite ne modifie pas les données, mais peut conduire à des utilisations frauduleuses secondaires. |
| Disponibilité | Faible | Impact marginal sur la disponibilité du service. |
| Réputation | Sévère | Une violation de données médicales ou financières via un pipeline IA génère une pression réglementaire (RGPD, HIPAA, NIS2) et une couverture médiatique très négative sur la gestion des données par IA. |
Recommandations de mitigation
1. Principe de minimisation des données entre agents
Chaque agent ne doit recevoir que les champs strictement nécessaires à sa tâche. Définir explicitement le schéma de données autorisé pour chaque type de délégation et filtrer le payload avant transmission.
2. Pseudonymisation et anonymisation des données sensibles
Pseudonymiser les données personnelles avant de les transmettre dans les payloads inter-agents. L’agent worker travaille sur des identifiants pseudonymisés ; seul l’orchestrateur maintient la table de correspondance.
3. Politique de rétention et masquage dans les logs
Configurer les frameworks d’orchestration pour masquer les champs sensibles dans les logs (numéros de sécurité sociale, coordonnées bancaires, données médicales). Définir une politique de rétention automatique des logs inter-agents (maximum 30 jours pour les logs contenant des données personnelles).
4. Audit des flux de données inter-agents
Cartographier systématiquement quelles données transitent entre quels agents. Cet audit de flux (équivalent d’un Data Flow Diagram pour les pipelines A2A) est indispensable pour respecter les obligations RGPD et détecter les fuites potentielles avant qu’elles ne se produisent.
Quelques références pour aller plus loin
- Microsoft Presidio — Détection et anonymisation PII
- OWASP Top 10 Agentic 2026
- OWASP LLM Top 10 2025 — LLM02 Sensitive Information Disclosure
- Connexe sur ce blog : A2A05 - Context Poisoning
À retenir
