~6 minutes
Une tâche A2A interceptée peut être modifiée, rejouée ou détournée. Sans protection d’intégrité des messages, chaque échange inter-agents est une cible.
Partie de la série A2A Security
Description du risque
On constate que le protocole A2A structure les échanges entre agents sous forme de tâches JSON-RPC contenant un task_id, un payload d’entrée et un contexte. La spécification v2 a introduit HTTP Message Signatures pour protéger l’intégrité de ces messages, mais l’adoption est encore incomplète, et de nombreuses implémentations ne valident ni la signature ni l’unicité du task_id.
Cette lacune ouvre la porte à deux catégories d’attaques distinctes :
- Task Hijacking : interception et modification du payload d’une tâche en transit (attaque Man-in-the-Middle dans le réseau interne)
- Replay Attack : capture d’une tâche légitime et renvoi identique ou légèrement modifié à l’agent destination, pour répéter une action déjà exécutée (virement, approbation, envoi de message)
Dans un pipeline de décision automatisée, rejouer une tâche d’approbation de crédit ou de virement bancaire peut avoir des conséquences financières directes et immédiates.
Sans nonce et sans timestamp validé, une tâche A2A capturée est une tâche réutilisable à volonté.
Vecteurs d’attaque
1. Man-in-the-Middle sur réseau interne
Un attaquant ayant un pied dans le réseau interne (via un mouvement latéral, un container compromis, ou un accès VPN) peut intercepter les échanges HTTP entre agents. Si TLS n’est pas configuré avec vérification de certificat côté client (mTLS), ou si les agents communiquent en HTTP sur le réseau de containers, le payload JSON-RPC de la tâche est lisible et modifiable.
2. Replay Attack sur tâche d’action
L’attaquant capture une tâche légitime (par exemple, une approbation de transaction) et la réenvoie ultérieurement à l’agent destination. Sans vérification de l’unicité du task_id et sans validation du timestamp, l’agent exécute la tâche une seconde fois, produisant un double paiement, une double approbation ou un double envoi.
3. Manipulation de payload intermédiaire
Dans les architectures avec des agents proxy ou des passerelles A2A, un composant intermédiaire compromis peut modifier le payload de la tâche avant de le transmettre à l’agent destination. Par exemple, modifier l’IBAN d’un virement dans la tâche d’un agent de paiement, tout en conservant un task_id valide.
Exemple concret
Un pipeline de validation de virements implique un agent orchestrateur financier et un agent d’exécution de paiements.
- L’orchestrateur envoie une tâche d’exécution de virement de 5 000 € vers le fournisseur A.
- Un attaquant présent sur le réseau interne intercepte le message JSON-RPC (pas de mTLS configuré sur le réseau de containers).
- L’attaquant modifie l’IBAN et retransmet le message à l’agent de paiement.
- L’agent de paiement n’a pas de mécanisme de vérification de signature du payload => il exécute le virement modifié.
- Conséquence : 5 000 € virés vers le compte de l’attaquant. La modification est indétectable sans audit trail des payloads.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Modéré | Un replay avec task_id réutilisé peut faire croire à l’agent destination qu’il reçoit une nouvelle instruction légitime de l’orchestrateur. |
| Tampering (Falsification) | Oui (PRIMAIRE) | La modification du payload en transit (MitM) est le vecteur central de ce risque. Sans signature, n’importe quel intermédiaire peut altérer le contenu d’une tâche. |
| Repudiation (Répudiation) | Oui | Sans audit trail des payloads reçus et sans signature, impossible de prouver qu’un message a été altéré entre l’envoi et la réception. |
| Information Disclosure (Divulgation) | Modéré | L’interception en transit expose le contenu des tâches — données métier, montants, identifiants, contexte. |
| Denial of Service (Déni de service) | Modéré | Des replays massifs d’une même tâche peuvent saturer un agent ou déclencher des effets de bord répétés (envois d’emails, appels API externes). |
| Elevation of Privilege (Élévation de privilèges) | Faible | Limité , sauf si le payload modifié contient des paramètres qui influencent les droits de la tâche exécutée. |
Analyse PASTA
Étape 4 — Analyse des menaces
Threat actors :
- Attaquant réseau interne : mouvement latéral depuis un container ou service compromis, accès au trafic inter-agents
- Agent proxy ou passerelle compromis : composant intermédiaire modifiant les tâches avant transmission
- Script automatisé : replay bot qui rejoue des tâches capturées de manière répétée
Motivations : fraude financière (replay de virements), sabotage de workflow, exfiltration de données de tâches.
Étape 6 — Modélisation des attaques
graph TD
A["Task Hijacking / Replay"]
A --> B["Interception en transit"]
B --> C["Réseau de containers sans mTLS"]
B --> D["Agent proxy compromis (MitM interne)"]
A --> E["Replay d'une tâche capturée"]
E --> F["task_id réutilisable (pas de vérification d'unicité)"]
E --> G["Timestamp non validé (fenêtre de replay longue)"]
Étape 7 — Analyse de risque/impact
| Scénario | Probabilité | Impact | Score |
|---|---|---|---|
| Modification d’IBAN dans tâche de paiement | Modérée | Critique | Critique |
| Replay d’approbation de transaction | Modérée | Critique | Critique |
| Replay massif (DoS applicatif) | Faible | Élevé | Élevé |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Élevé | L'interception en transit expose le contenu complet des tâches : montants, données métier, IBAN, références, contextes de traitement. |
| Intégrité | Critique | La modification du payload en transit produit des effets réels dans les systèmes en aval (virements falsifiés, approbations détournées, données corrompues) sans aucun signal d'alerte immédiat. |
| Disponibilité | Modéré | Le replay massif peut saturer les files de traitement d'un agent, produire des doublons dans les systèmes downstream et nécessiter une remédiation manuelle coûteuse. |
| Réputation | Sévère | Une fraude financière réalisée via la manipulation d'un pipeline A2A expose l'organisation à des poursuites judiciaires et à une remise en question de la fiabilité de son architecture IA. |
Recommandations de mitigation
1. HTTP Message Signatures sur tous les échanges A2A
Activer et rendre obligatoire la signature des messages A2A avec HTTP Message Signatures (RFC 9421). Chaque agent doit signer ses messages sortants et rejeter tout message entrant sans signature valide.
2. Nonce + timestamp pour anti-replay
Inclure un nonce aléatoire unique et un timestamp dans chaque tâche. L’agent destination valide que le nonce n’a pas déjà été utilisé (dans une fenêtre de temps définie) et que le timestamp est dans une fenêtre acceptable (ex. ±5 minutes).
3. mTLS obligatoire
Configurer le mutual TLS entre tous les agents A2A, y compris sur le réseau de containers interne. Un agent sans certificat valide ne doit pas pouvoir établir de connexion avec un autre agent.
4. Ne déclencher qu’une seule fois les tâches à effet de bord
Chaque agent qui exécute des actions à effet de bord (paiements, envois, modifications) doit implémenter une logique d’idempotence basée sur le task_id : une même tâche ne peut être exécutée qu’une seule fois, même si le message est reçu plusieurs fois.
Quelques références pour aller plus loin
- RFC 9421 — HTTP Message Signatures
- OWASP Top 10 Agentic 2026 — ASI07
- Spécification A2A v2 — Security
- ArXiv — Security Threat Modeling for AI-Agent Protocols
À retenir
