Délégation entre agents IA : architecture défensive et patterns à connaître

La majorité des agents IA en production en 2026 sont des systèmes multi-agents déguisés : un agent principal qui en orchestre d'autres pour découper le travail. Claude Agent SDK avec sub-agents, LangGraph supervisor, AutoGen team, CrewAI crew — tous matérialisent un pattern de délégation. La façon dont vous structurez cette délégation a un impact direct sur votre exposition aux attaques.

Voici les 4 patterns principaux, et leurs propriétés défensives respectives.

Pattern 1 — Délégation hiérarchique (supervisor / workers)

Un supervisor central reçoit la demande, planifie, délègue à des workers spécialisés, agrège les résultats, décide.

`` supervisor (capabilities sensibles) / \ \ worker_1 worker_2 worker_3 (lecture) (analyse) (synthèse) ``

Propriétés défensives

• + Capabilities concentrées sur le supervisor → surface d'attaque externe réduite.
• + Workers peuvent être stateless et jetables (un worker compromis = perte limitée à une tâche).
• + Audit centralisé naturellement (toutes les décisions passent par le supervisor).
• − Le supervisor est un single point of failure. S'il est compromis, tout l'est.
• − Latence accrue (allers-retours).

Quand l'utiliser

C'est le pattern par défaut recommandé pour les agents qui agissent sur le SI en 2026. C'est aussi ce que matérialise par défaut le Claude Agent SDK et LangGraph.

Pattern 2 — Délégation pair-à-pair (mesh)

Plusieurs agents collaborent sans hiérarchie, en se passant des messages.

`` agent_A ⇄ agent_B ⇅ ⇅ agent_C ⇄ agent_D ``

Propriétés défensives

• + Pas de single point of failure.
• + Résilience accrue à la panne d'un agent.
• − Risque de collusion (cf. Multi-agent collusion) — instructions injectées qui se propagent.
• − Risque de boucles d'auto-amplification entre agents.
• − Audit difficile (pas de point central qui voit tout).
• − Modèle de menace difficile à raisonner.

Quand l'utiliser

Rarement, et avec beaucoup de précaution. Convient à des environnements de recherche plus qu'à de la prod. Si vous l'utilisez en prod, prévoir :

• Timeout strict sur les conversations multi-agents.
• Audit log centralisé hors-bande.
• Detection automatique de boucles.

Pattern 3 — Pipeline séquentiel

Les agents s'enchaînent linéairement, chaque agent prenant la sortie du précédent.

`` agent_input → agent_process → agent_validate → agent_output ``

Propriétés défensives

• + Chaque étape est claire et auditable.
• + On peut placer des gates entre étapes (validation structurée).
• + Permet le cloisonnement de confiance (l'étape 1 lit du contenu non fiable, transforme en structuré, les étapes suivantes ne voient que du structuré).
• − Performance : latence cumulative.
• − Si une étape se trompe silencieusement, l'erreur se propage.

Quand l'utiliser

Excellent pour les workflows déterministes où chaque étape a un rôle clair : ingestion → extraction → validation → action. Pattern recommandé quand vous avez des entrées externes (emails, documents, web) qui doivent être "nettoyées" avant de toucher la couche action.

Pattern 4 — Planner / Executor avec validateur tiers

Variante du supervisor où la décision est explicitement séparée de l'exécution, avec un troisième agent comme garde-fou.

`` planner (décide le plan) ↓ validator (vérifie le plan contre la politique) ↓ executor (exécute le plan validé, n'a aucune liberté d'interprétation) ``

Propriétés défensives

• + Séparation explicite entre raisonnement et exécution.
• + Le validator peut être un système non-IA (règles déterministes) ou un LLM avec un prompt sécurité dédié.
• + L'executor ne fait que ce qui est dans le plan validé — pas d'improvisation.
• + Très bonne propriété d'auditabilité : on peut rejouer le plan validé.
• − Lourdeur de mise en œuvre.
• − Latence à 3 étapes minimum.

Quand l'utiliser

Pour les agents qui prennent des décisions à fort impact (finance, juridique, RH). Modèle de référence en environnements régulés.

Comparaison synthétique

| Pattern | Auditabilité | Résilience | Risque collusion | Coût | |---|---|---|---|---| | Supervisor / workers | Élevée | Moyenne | Faible | Moyen | | Mesh | Faible | Élevée | Élevé | Faible | | Pipeline | Élevée | Faible | Faible | Faible | | Planner / Validator / Executor | Très élevée | Moyenne | Très faible | Élevé |

Les choix qui restent valables quel que soit le pattern

Indépendamment du pattern choisi, plusieurs principes s'appliquent toujours :

1. Identités séparées par agent

Chaque agent a son propre token / identité au niveau du broker de capabilities. Pas de credential partagé. Si l'agent C est compromis, ses permissions sont coupées sans toucher A et B.

2. Messages typés, pas en texte libre

Quand les agents se passent des informations, le format doit être structuré (JSON avec schéma), pas du texte libre. Limite la prompt injection entre agents.

3. Audit log croisé

Les logs des différents agents doivent partager :

• Un trace_id qui suit la requête utilisateur d'un bout à l'autre.
• Un span_id par étape (héritage OpenTelemetry).
• Une référence à l'agent qui a appelé l'agent courant.

C'est ce qui permet, en cas d'incident, de tracer l'instruction d'origine à travers la chaîne.

4. Tests par scénario inter-agent

Le red team d'un système multi-agent doit inclure des scénarios qui simulent un agent compromis et vérifient que la compromission ne se propage pas. Pas juste tester chaque agent isolément.

Le choix d'architecture est un choix de sécurité

C'est la conclusion qu'il faut retenir. Beaucoup d'équipes choisissent leur pattern d'orchestration pour des raisons purement fonctionnelles ("LangGraph est plus flexible", "AutoGen permet la conversation libre entre agents"). C'est aussi un choix qui détermine la posture de sécurité résiduelle. À considérer dès la phase de conception, pas après le premier incident.

Pour les risques de collusion détaillés, Multi-agent collusion. Pour les 7 surfaces de threat model single-agent, Threat model d'un agent.