~6 minutes
Dans une architecture A2A, les tokens voyagent entre agents. Un token mal géré ne compromet pas un service , il compromet toute la chaîne de délégation.
Partie de la série A2A Security
Description du risque
On constate que la gestion des tokens dans les architectures A2A souffre des mêmes mauvaises pratiques que les APIs REST classiques, mais avec une surface d’exposition démultipliée. Dans un pipeline multi-agents, un token d’authentification ne sert plus à sécuriser un seul appel API : il est potentiellement transmis, relayé, mis en cache et utilisé par plusieurs agents successifs dans la chaîne de délégation.
La spécification A2A ne définit pas de mécanisme d’autorisation standardisé entre agents. Chaque implémentation doit donc construire ses propres conventions, ce qui produit inévitablement des disparités : certains agents transmettent le token de l’agent appelant tel quel, d’autres en génèrent un nouveau, d’autres encore n’authentifient pas du tout les agents workers.
Le résultat : des tokens avec des privilèges élevés qui transitent en clair dans des pipelines inter-agents, sans expiration stricte, sans scoping précis, et sans audit trail de leur utilisation.
Un token A2A à durée de vie longue dans une architecture multi-agents, c’est une clé maîtresse qui passe de main en main dans un couloir sans caméra.
Vecteurs d’attaque
1. Token Passthrough non scopé
L’agent orchestrateur transmet son propre token d’accès à l’agent worker pour lui permettre d’agir en son nom. L’agent worker reçoit ainsi un token avec tous les droits de l’orchestrateur bien au-delà de ce dont il a besoin pour sa tâche spécifique. Si cet agent worker est compromis ou malveillant, il dispose d’un accès privilégié non anticipé.
2. Token sans expiration dans les tâches longues
A2A supporte des tâches longues avec streaming. Un token émis au début d’une tâche qui dure plusieurs heures reste valide tout au long de son exécution. Sans mécanisme de renouvellement, un token intercepté en cours de route reste utilisable bien après la fin de la tâche légitime.
3. Absence d’invalidation après délégation
Quand un agent worker sous-délègue une tâche à un troisième agent, le token original peut continuer de circuler dans la chaîne sans que l’agent émetteur initial puisse l’invalider. Une fois le token sorti du périmètre de contrôle direct, sa révocation devient impossible sans mécanisme de token introspection côté serveur.
Exemple concret
Un pipeline de traitement de données RH implique trois agents : un orchestrateur RH, un agent d’analyse de CV et un agent d’export vers un SIRH.
- L’orchestrateur RH s’authentifie avec un token OAuth 2.0 portant les scopes
hr:read,hr:write,admin:export. - Pour déléguer l’analyse d’un CV, il transmet ce token complet à l’agent d’analyse, qui en a seulement besoin pour lire le fichier.
- L’agent d’analyse, développé par un prestataire tiers, stocke les tokens reçus dans un cache Redis sans TTL pour optimiser les performances.
- Un attaquant qui compromet le cache Redis récupère le token complet avec le scope
admin:export. - Avec ce token, l’attaquant exporte l’intégralité de la base RH vers un serveur externe via l’endpoint d’export.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Oui | Un token volé dans la chaîne de délégation permet d’usurper l’identité de l’agent légitime auprès des services en aval. |
| Tampering (Falsification) | Modéré | Avec un token d’écriture récupéré, l’attaquant peut modifier des données dans les systèmes accessibles par l’agent. |
| Repudiation (Répudiation) | Oui | Sans audit trail de l’usage des tokens par agent, impossible de distinguer les actions légitimes des actions malveillantes réalisées avec un token volé. |
| Information Disclosure (Divulgation) | Oui (PRIMAIRE) | Le token exposé donne accès à toutes les ressources dans son scope potentiellement bien plus que nécessaire pour la tâche A2A spécifique. |
| Denial of Service (Déni de service) | Modéré | Un attaquant avec un token valide peut saturer les quotas API des services en aval, bloquant le pipeline légitime. |
| Elevation of Privilege (Élévation de privilèges) | Oui | Le passthrough d’un token admin à un agent worker peu privilégié constitue une élévation de privilèges de facto. |
Analyse PASTA
Étape 4 — Analyse des menaces
Threat actors :
- Agent worker compromis (supply chain) : reçoit des tokens trop permissifs par design
- Attaquant avec accès au réseau interne : intercepte les tokens dans les échanges inter-agents non chiffrés ou mal configurés
- Prestataire tiers malveillant : exploite les tokens reçus dans le cadre d’une délégation légitime
Motivations : accès persistant aux systèmes, exfiltration de données, sabotage.
Étape 6 — Modélisation des attaques
graph TD
A["⚠️ Compromission token A2A"]
A --> B["🔓 Vol du token en transit"]
A --> C["🔁 Exploitation du passthrough"]
B --> D["Interception réseau<br/>(TLS mal configuré)"]
B --> E["Exfiltration depuis le cache<br/>de l'agent worker"]
C --> F["Agent worker compromis<br/>utilise le token admin reçu"]
C --> G["Token transmis dans la chaîne<br/>sans downscoping"]
Étape 7 — Analyse de risque/impact
| Scénario | Probabilité | Impact | Score |
|---|---|---|---|
| Token admin passthrough vers agent tiers | Élevée | Critique | Critique |
| Token sans TTL dans un cache non sécurisé | Élevée | Élevé | Critique |
| Interception en transit (TLS misconfiguration) | Faible | Critique | Élevé |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Critique | Un token trop permissif donne accès à l'ensemble du périmètre couvert par son scope, bien au-delà de la tâche A2A initiale. Exfiltration de données sensibles à grande échelle. |
| Intégrité | Élevé | Avec un token d'écriture, l'attaquant peut modifier des données de production, injecter des entrées malveillantes dans des systèmes de référence, ou altérer des workflows en cours. |
| Disponibilité | Modéré | Saturation des quotas API, révocation d'urgence des tokens compromis qui interrompt les workflows légitimes, temps de remédiation élevé. |
| Réputation | Sévère | Une fuite de données RH ou financières issue d'une mauvaise gestion des tokens dans un pipeline IA génère des obligations de notification RGPD et une couverture médiatique significative. |
Recommandations de mitigation
1. Downscoping systématique (Token Exchange)
Ne jamais transmettre le token de l’orchestrateur tel quel. Utiliser le mécanisme de Token Exchange (OAuth 2.0 Token Exchange) pour émettre un token fils avec seulement les scopes nécessaires à la tâche déléguée.
2. Tokens à courte durée de vie obligatoires
Tout token émis pour une délégation A2A doit avoir une durée de vie maximale de 15 minutes, non renouvelable automatiquement. Pour les tâches longues, implémenter un mécanisme de renouvellement explicite côté orchestrateur.
3. Token introspection côté agents workers
Chaque agent worker doit valider le token reçu auprès du serveur d’autorisation (introspection endpoint RFC 7662) avant de l’utiliser, et ne jamais le mettre en cache sans TTL aligné sur son expiration.
4. Audit trail des usages par agent
Chaque utilisation d’un token dans le pipeline doit être loggée avec l’identifiant de l’agent, la tâche associée et le timestamp. Cela permet de détecter les utilisations anormales et de retracer précisément l’origine d’une compromission.
{
"timestamp": "2042-02-01T04:21:11.421Z",
"event": "token.used",
"agent_id": "worker-invoice-processor-v2",
"task_id": "task-8f3a2c1d",
"parent_agent_id": "orchestrator-finance",
"token_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
"token_scope": "invoices:read payments:validate",
"action": "GET /api/payments/validate",
"source_ip": "42.42.42.42",
"status": "success",
}
Un
token_idunique par token permet de corréler tous les appels d’un même credential à travers le pipeline ; dès qu’un ID réapparaît sur un agent non prévu, c’est une anomalie détectable.
Quelques références pour aller plus loin
- RFC 8693 — OAuth 2.0 Token Exchange
- RFC 7662 — OAuth 2.0 Token Introspection
- OWASP Top 10 Agentic 2026 : ASI07
- Red Hat : How to enhance Agent2Agent (A2A) security
- Connexe sur ce blog : MCP01 - Token Mismanagement => même problématique appliquée aux outils MCP
À retenir
