~6 minutes
Les frontières de confiance dans une architecture A2A ne sont pas physiques, elles sont logiques. Et elles sont souvent inexistantes. Quand un agent externe est traité comme un agent interne de confiance, c’est toute l’architecture qui est compromise.
Partie de la série A2A Security
Description du risque
Ce dernier risque de la série est aussi le plus architectural : les violations de frontières de confiance dans les écosystèmes A2A. Dans une architecture multi-agents, tous les agents ne se valent pas en termes de confiance. On distingue typiquement :
- Agents internes : développés et maîtrisés par l’organisation, déployés sur son infrastructure
- Agents partenaires : agents de confiance partielle, développés par des tiers mais dans un cadre contractuel
- Agents externes : agents publics ou de tiers inconnus, avec lesquels la communication doit être traitée comme non fiable
Le problème est que A2A, par conception, ne définit pas de modèle de confiance entre agents. Tous les agents sont traités de manière uniforme par le protocole. C’est aux implémenteurs de définir et d’appliquer ces niveaux de confiance et dans la précipitation du développement, cette étape est souvent omise.
Le résultat : des agents externes se voient accorder les mêmes droits que des agents internes de confiance, créant des chemins d’accès non anticipés vers des ressources critiques.
Dans un écosystème A2A sans frontières de confiance explicites, un agent externe bien configuré peut avoir accès aux mêmes ressources qu’un agent interne d’administration.
Vecteurs d’attaque
1. Élévation de confiance via Agent Card légitime
Un agent externe présente une Agent Card valide et signée — mais cette carte n’indique pas son niveau de confiance réel. L’orchestrateur, qui ne dispose pas d’une politique de confiance par zone, lui accorde par défaut le même niveau d’accès qu’à ses agents internes. L’agent externe peut alors interagir avec des agents internes sensibles qu’il n’aurait pas dû pouvoir atteindre.
2. Traversée de zone de confiance via délégation
Un agent externe légitime (zone de confiance basse) reçoit une tâche d’un orchestrateur. Dans le cadre de cette tâche, il initie une sous-délégation vers un agent interne sensible (zone de confiance haute) — par exemple, un agent de base de données ou un agent d’administration. Si les frontières de confiance ne sont pas vérifiées à chaque niveau de délégation, cette traversée de zone passe inaperçue.
3. Usurpation de zone de confiance via métadonnées
Un agent malveillant modifie les métadonnées de son Agent Card pour se déclarer membre d’une zone de confiance interne (en ajoutant un champ trust_zone: "internal" ou équivalent). Si l’orchestrateur se fie à cette auto-déclaration sans vérification externe, l’agent malveillant accède à la zone de confiance haute.
Exemple concret
Une architecture de plateforme de données comprend trois zones de confiance : External (partenaires), Internal (agents métier) et Admin (agents d’infrastructure).
- Un partenaire déploie un agent A2A externe avec une Agent Card valide, déclaré dans la zone External.
- L’orchestrateur reçoit une tâche de l’agent partenaire et la traite sans vérifier les frontières de confiance.
- L’agent partenaire initie une sous-délégation vers l’agent de reporting interne, qui a accès à la totalité des données clients.
- L’agent de reporting interne fait confiance à toute requête A2A signée, quelle que soit sa zone d’origine.
- L’agent partenaire exfiltre l’intégralité des données clients via le reporting.
Analyse STRIDE
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d’identité) | Oui | Un agent externe peut se déclarer interne via ses métadonnées d’Agent Card si la zone de confiance est auto-déclarée. |
| Tampering (Falsification) | Modéré | Un agent en zone de confiance supérieure à sa zone réelle peut modifier des données qu’il n’aurait pas dû pouvoir toucher. |
| Repudiation (Répudiation) | Oui | Sans log de la zone de confiance de l’agent initiateur à chaque étape, impossible de retracer les violations de frontière. |
| Information Disclosure (Divulgation) | Oui (PRIMAIRE) | L’accès non autorisé à des ressources d’une zone de confiance supérieure expose des données sensibles protégées par cette classification. |
| Denial of Service (Déni de service) | Faible | Impact limité sur ce vecteur spécifique. |
| Elevation of Privilege (Élévation de privilèges) | Oui (PRIMAIRE) | La violation de frontière de confiance est par définition une élévation de privilèges d’une zone basse vers une zone haute. |
Analyse PASTA
Étape 4 — Analyse des menaces
Threat actors :
- Partenaire commercial malveillant ou dont l’agent a été compromis, qui exploite l’absence de contrôle de frontière pour accéder à des données hors de son périmètre
- Attaquant externe ayant réussi à enregistrer un agent dans l’écosystème (via spoofing ou injection dans le registre)
- Développeur interne qui configure mal les zones de confiance lors du déploiement d’un nouvel agent
Motivations : accès à des données de la zone Admin ou Internal, escalade de privilèges, exfiltration ciblée.
Étape 6 — Modélisation des attaques
graph TD
A["Trust Boundary Violation"] --> B["Accès direct non contrôlé"]
A --> C["Traversée de zone via délégation"]
B --> B1["Orchestrateur sans politique de routing par zone"]
B --> B2["Agent interne qui accepte toute requête A2A signée"]
C --> C1["Agent External délègue à agent Internal sans vérification"]
C --> C2["Auto-déclaration de zone dans l'Agent Card non vérifiée"]
Étape 7 — Analyse de risque/impact
| Scénario | Probabilité | Impact | Score |
|---|---|---|---|
| Agent partenaire accède à agent Internal via délégation | Élevée (absence de contrôle commune) | Critique | Critique |
| Auto-déclaration de zone de confiance dans Agent Card | Modérée | Critique | Critique |
| Agent externe atteint zone Admin | Faible | Critique | Critique |
Impact potentiel
| Impact | Niveau | Description de l'impact |
|---|---|---|
| Confidentialité | Critique | Un agent externe qui accède à la zone Admin peut exfiltrer l'intégralité des données protégées par cette classification, sans aucune détection si les logs ne tracent pas la zone de confiance de l'initiateur. |
| Intégrité | Critique | Un agent avec accès à une zone supérieure à sa zone réelle peut modifier des données d'infrastructure, des configurations et des règles de sécurité, avec des conséquences durables. |
| Disponibilité | Élevé | Un agent qui accède à la zone Admin peut interrompre des services en modifiant des configurations ou en déclenchant des actions destructrices sur l'infrastructure agentique. |
| Réputation | Sévère | Une violation de frontière de confiance par un partenaire commercial constitue un incident de sécurité majeur avec des implications contractuelles, réglementaires (RGPD, NIS2) et de réputation durables. |
Recommandations de mitigation
1. Définir et appliquer un modèle de confiance par zone
Avant de déployer la moindre architecture A2A en production, définir explicitement les zones de confiance (External, Partner, Internal, Admin) et les règles de communication autorisées entre zones. Ce modèle doit être documenté et implémenté dans chaque orchestrateur.
2. Appliquer le principe Zero Trust inter-agents
Ne jamais faire confiance implicitement à un agent, même interne, au-delà de sa zone de confiance déclarée. Chaque requête inter-agents doit être authentifiée et autorisée indépendamment, sans héritage de confiance basé sur la position dans le pipeline.
3. Zone de confiance définie dans le registre central, pas dans l’Agent Card
Ne jamais se fier à une zone de confiance auto-déclarée dans l’Agent Card de l’agent. La zone de confiance doit être définie dans un registre interne contrôlé par l’organisation, et vérifiée par l’orchestrateur à chaque échange.
4. Logging de la zone de confiance à chaque étape
Journaliser la zone de confiance de l’agent initiateur à chaque étape de délégation. Un changement de zone dans une chaîne de délégation (External → Internal) doit déclencher une alerte immédiate.
Quelques références pour aller plus loin
- OWASP Top 10 Agentic 2026 — ASI07
- Securing Agentic Applications Guide 1.0 (OWASP)
- Red Hat — How to enhance Agent2Agent (A2A) security
- ArXiv — Security Threat Modeling for AI-Agent Protocols
- Connexe sur ce blog : A2A04 - Unauthorized Delegation — la délégation transitive est le vecteur de traversée de zone le plus courant
À retenir
