Architecture multi-agents en production : trois patterns d'erreur d'autorisation observés en mission

Note de transparence. Cet article est rédigé conformément à la politique éditoriale d'IgnitionAI. Les références au framework OWASP LLM Top 10 for LLM Applications & AI Agents renvoient à la documentation officielle avec lien et date de consultation. Les patterns d'erreur décrits sont des cas reconstitués à partir de missions IgnitionAI 2024-2025 ; aucun client n'est identifiable. Les recommandations d'architecture sont des estimations expert taguées comme telles.

Le scénario type

Une organisation déploie un système multi-agents en production pour automatiser un processus métier composite. L'architecture choisie suit le pattern supervisor-worker devenu standard depuis 2024 : un agent orchestrateur reçoit la demande utilisateur, la décompose en sous-tâches, et délègue chaque sous-tâche à un agent spécialisé. Selon la mission, le pool de sub-agents comprend typiquement un agent recherche documentaire, un agent analyse de données, un agent rédaction, un agent extraction d'information sur un système métier précis, et parfois un agent appel d'API externes.

Le système a été conçu par une équipe technique compétente, testé sur des cas d'usage représentatifs, déployé après validation. Il fonctionne. Les utilisateurs sont satisfaits du gain de productivité. Et il expose à certains d'entre eux des informations qu'ils n'auraient jamais dû recevoir.

L'audit pointe vers une décision d'architecture initiale. L'orchestrateur a été conçu avec un modèle d'accès global aux données et aux outils de l'organisation. Le développeur considérait que l'orchestrateur étant « interne », exécuté côté serveur et non exposé directement aux utilisateurs, il pouvait disposer d'un périmètre de capacités large. Conséquence : les sub-agents que l'orchestrateur invoque héritent de fait de ce périmètre large via le contexte d'exécution.

L'un des sub-agents a accès à des données particulièrement sensibles dans le cadre nominal de son travail, typiquement, dans les missions observées, données RH nominatives, données financières non publiques, dossiers juridiques en cours, ou résultats commerciaux pré-publication. Quand un utilisateur final formule une requête qui amène l'orchestrateur à mobiliser ce sub-agent, il reçoit en retour des éléments dépassant ses droits d'accès individuels.

L'utilisateur n'a rien fait d'illégitime. Sa requête est métier, normale, conforme à son rôle. La réponse a franchi une frontière d'autorisation qu'elle n'aurait jamais dû franchir. Aucun système de log applicatif ne signale d'anomalie : pour les composants techniques, tout s'est passé selon les règles configurées.

C'est précisément ce type de risque que le framework OWASP a catégorisé.

OWASP a un nom pour cette catégorie : LLM06 Excessive Agency

Le projet OWASP Top 10 for LLM Applications & AI Agents publie depuis 2023 un référentiel des risques de sécurité spécifiques aux systèmes basés sur des grands modèles de langage. La version 2025 (OWASP Top 10 for LLM Applications 2025, consultée le 24 mai 2026) compte dix entrées dont une est explicitement consacrée aux agents : LLM06:2025 Excessive Agency.

La définition officielle pose le cadre : « An LLM-based system is often granted a degree of agency by its developer, the ability to call functions or interface with other systems via extensions » (OWASP LLM06:2025 Excessive Agency, consultée le 24 mai 2026). Le risque survient quand cette agency est accordée sans garde-fous proportionnés.

Le framework identifie trois racines à la vulnérabilité Excessive Agency.

Excessive Functionality, le système dispose de plus de capacités que ce dont il a besoin pour sa tâche. Une extension « read-only » qui inclut aussi la capacité de suppression. Un plugin hérité de la phase développement qui reste accessible en production.

Excessive Permissions, le système hérite de droits plus larges que ceux requis par son usage légitime. Une connexion base de données avec capacités INSERT/UPDATE/DELETE alors que seul un SELECT était nécessaire. Un compte de service à privilèges élevés utilisé en lieu et place du contexte utilisateur initial.

Excessive Autonomy, le système exécute des actions à fort impact sans validation ou approbation explicite. Pas de boucle humaine sur les opérations critiques.

OWASP précise que dans les architectures multi-agents : « The decision over which extension to invoke may also be delegated to an LLM 'agent' to dynamically determine based on input prompt or LLM output ». Cette délégation dynamique amplifie le risque : l'orchestrateur ne sait pas à l'avance quels sub-agents seront invoqués, et donc l'analyse statique des chemins d'autorisation devient difficile.

Le scénario d'ouverture de cet article relève simultanément des trois racines : excessive functionality (un sub-agent dans le pool de l'orchestrateur sans justification fonctionnelle), excessive permissions (l'orchestrateur exécutant les actions avec son propre contexte d'autorité plutôt qu'avec celui de l'utilisateur initial), et excessive autonomy (pas de validation utilisateur sur les requêtes mobilisant des données sensibles).

Pattern d'erreur #1 : Orchestrateur sans complete mediation

Le principe de complete mediation, un des dix principes de sécurité informatique formalisés par Saltzer et Schroeder en 1975, exige que toute requête d'accès à un objet soit vérifiée par un mécanisme d'autorisation au moment où l'accès est tenté. Ce principe est rappelé par OWASP dans sa liste de mitigations LLM06 : « Complete mediation, enforce authorization at downstream systems ».

En architecture multi-agents, le pattern d'erreur typique consiste à concentrer toute la logique d'autorisation au niveau de l'orchestrateur, voire pire, à l'omettre en pensant que les sub-agents la portent. Or, deux raisons rendent cette concentration risquée.

D'abord, l'orchestrateur dispatche dynamiquement vers les sub-agents en fonction du prompt utilisateur et du contexte. Le développeur ne peut pas énumérer à la conception tous les chemins d'invocation possibles. Une logique d'autorisation centralisée doit donc traiter toute la combinatoire, ce qui est presque toujours sous-spécifié dans les implémentations réelles.

Ensuite, les sub-agents sont souvent réutilisés dans plusieurs contextes (le même agent recherche documentaire peut être invoqué par plusieurs orchestrateurs différents pour des cas d'usage distincts). Si chaque orchestrateur applique sa propre logique d'autorisation, les sub-agents accumulent silencieusement des chemins d'accès non documentés.

La règle correcte : l'autorisation doit être enforced au niveau de chaque agent qui accède à des données ou des outils, pas au niveau de l'orchestrateur. L'orchestrateur conserve un rôle de coordination fonctionnelle (quel agent est le mieux qualifié pour cette sous-tâche) mais ne porte pas la responsabilité de l'autorisation (cet utilisateur a-t-il le droit de déclencher cet agent sur ces données). Chaque sub-agent doit recevoir explicitement le contexte d'identité de l'utilisateur initial et vérifier ses droits avant d'agir.

Pattern d'erreur #2 : Sub-agent à données sensibles dans un pool générique

Le deuxième pattern porte sur le positionnement architectural des agents qui accèdent à des données sensibles. La règle simple : un agent qui manipule des données critiques ne doit pas figurer dans le pool générique de sub-agents qu'un orchestrateur transverse peut invoquer dynamiquement.

Le raisonnement est asymétrique. Un agent recherche documentaire qui interroge la base de connaissances publique de l'organisation peut légitimement être appelé par n'importe quel orchestrateur, son périmètre d'accès est public, son comportement est non-modificatoire. Un agent qui interroge le SIRH avec accès aux fiches de paie individuelles, ou un agent qui consulte les notes confidentielles du comité juridique, n'a pas la même nature. Mettre ce type d'agent dans le pool générique revient à transformer chaque orchestrateur qui le découvre en canal d'accès à ces données.

La décision d'architecture correcte place ce type d'agent en service métier dédié, exposé uniquement à des workflows explicitement autorisés, avec son propre mécanisme de contrôle d'accès enforcé au niveau du service indépendamment de qui l'appelle. L'orchestrateur transverse ne sait même pas que ce service existe ; il ne peut pas l'invoquer.

Cette séparation revient au principe OWASP de minimize permissions : « Apply principle of least privilege to database/system access ». Appliqué à l'architecture multi-agents : chaque agent n'a accès qu'aux données strictement nécessaires à sa fonction, et un agent n'est exposé qu'aux flux qui ont besoin de lui. Si un sub-agent demande à être ajouté au pool générique pour un cas d'usage spécifique, c'est un signal pour interroger son périmètre fonctionnel, pas pour l'accorder par défaut.

Pattern d'erreur #3 : Délégation transitive sans contexte utilisateur

Un troisième pattern, moins fréquent mais plus subtil, concerne la propagation du contexte d'identité à travers la chaîne de délégation. L'orchestrateur reçoit la requête de l'utilisateur Alice. Il l'analyse, identifie qu'il faut invoquer le sub-agent A. L'agent A, dans le cadre de sa propre exécution, détermine qu'il a besoin d'invoquer le sub-agent B pour obtenir une information manquante. Le sub-agent B est appelé avec le contexte d'exécution du sub-agent A, pas avec le contexte d'Alice.

Si le sub-agent B vérifie l'autorisation sur la base du contexte qui l'appelle (le sub-agent A), il accordera des droits correspondant à A et non à Alice. Si A dispose d'un compte de service à privilèges élevés pour ses besoins fonctionnels, B exécutera la requête avec ces privilèges, indépendamment des droits réels d'Alice.

Le pattern correct : chaque appel inter-agent doit propager le contexte d'identité de l'utilisateur initial, et chaque agent doit vérifier l'autorisation par rapport à ce contexte, pas par rapport à l'agent appelant. Techniquement, ceci s'implémente via un security token utilisateur transporté dans la chaîne d'appels, ou via un mécanisme d'on-behalf-of tel que ceux supportés par les protocoles OAuth 2.0 (RFC 8693 Token Exchange).

OWASP formule cette règle de manière condensée : « User context execution, ensure actions occur in the specific user's security scope ». C'est une des mitigations les plus systématiquement omises dans les architectures multi-agents en production observées en mission.

Les huit mitigations OWASP appliquées aux multi-agents

OWASP LLM06 liste huit mitigations principales. Voici leur traduction opérationnelle au contexte multi-agents.

1. Minimize extensions. Le pool de sub-agents accessible à un orchestrateur doit être restreint à ceux strictement nécessaires au périmètre fonctionnel de l'orchestrateur. Un agent générique exposé à tous les orchestrateurs est un anti-pattern.

2. Minimize functionality. Chaque sub-agent ne dispose que des capacités requises pour sa fonction. Un agent de lecture documentaire ne dispose pas, par construction, de capacité d'écriture ou de suppression sur la source documentaire.

3. Avoid open-ended extensions. Pas d'agent générique de type « exécute n'importe quelle requête SQL sur la base ». Préférer des agents granulaires avec interfaces typées (« récupère le dossier client par ID », « liste les contrats actifs pour un compte »).

4. Minimize permissions. Chaque agent dispose du périmètre d'accès strictement nécessaire à sa fonction. Pas de connexion base de données avec droits étendus par défaut.

5. User context execution. Toute action d'agent s'exécute dans le contexte d'identité de l'utilisateur initial, propagé à travers la chaîne de délégation. Pas d'usage de comptes de service à privilèges élevés pour exécuter des actions au nom d'utilisateurs.

6. Require approval. Les actions à fort impact (modifications de données, envois de communications, déclenchement de processus métier critiques) requièrent une validation humaine explicite avant exécution. Implémenté via un mécanisme d'interruption du workflow et de présentation utilisateur.

7. Complete mediation. L'autorisation est enforced au niveau de chaque agent qui accède à des données ou des outils, pas centralisée au niveau de l'orchestrateur. Chaque sub-agent vérifie indépendamment l'autorisation de la requête entrante.

8. Sanitize inputs / outputs. Pratiques classiques de sécurité applicative étendues aux flux entre agents : validation des données reçues d'un autre agent comme on validerait des données reçues d'un client externe.

À ces huit mitigations principales s'ajoutent deux mesures de damage reduction : la journalisation détaillée des activités inter-agents (traçabilité a posteriori des chemins de délégation) et le rate-limiting (limitation du débit d'invocations pour contenir l'impact d'un comportement anormal).

Recommandation par maturité de l'architecture

Toutes les recommandations qui suivent sont des estimations IgnitionAI basées sur les missions d'audit multi-agents conduites en 2024-2025.

Architecture multi-agents en phase de conception

Le coût d'application des huit mitigations OWASP est négligeable en phase de conception. La principale difficulté est de tenir la ligne face à la pression de livrer rapidement. La règle opérationnelle : ne pas mettre en production un système multi-agents sans avoir documenté explicitement, pour chaque sub-agent, son périmètre de capacités, son périmètre d'accès, son mode de propagation du contexte utilisateur, et son niveau d'autonomie autorisé. Ce document de quelques pages constitue la base de l'audit de sécurité ultérieur.

Architecture multi-agents déjà en production sans audit préalable

Lancer un audit OWASP LLM06 sur l'architecture en place. Identifier en priorité : les sub-agents qui exposent des données sensibles ; l'absence ou la présence de propagation du contexte utilisateur ; les chemins de délégation transitive (un agent qui appelle un autre agent). Le résultat type est une matrice de risque par sub-agent classée selon les trois racines (functionality, permissions, autonomy). La remédiation se planifie sur trois à six mois selon la complexité, en commençant par les sub-agents les plus exposés.

Architecture multi-agents avec incident déjà remonté

Suspendre l'orchestrateur le temps de l'investigation, ou restreindre temporairement son pool de sub-agents aux services non sensibles. Mener l'investigation forensique : quels utilisateurs ont reçu des données dépassant leurs droits, sur quelle période, via quels chemins de délégation. Notifier les parties prenantes selon l'Article 33 du RGPD si données personnelles impliquées. Lancer la remédiation architecturale en parallèle.

Conclusion

Les architectures multi-agents échouent rarement au niveau de l'agent unitaire. Pris isolément, chaque agent peut être bien conçu, correctement testé, sécurisé selon les meilleures pratiques applicatives. Le défaut apparaît dans la composition : l'orchestration entre agents, la propagation du contexte d'identité, le positionnement architectural des agents à données sensibles. C'est un type de risque qu'aucune revue de code unitaire ne détecte, parce qu'il vit dans les interactions et non dans les composants.

Le framework OWASP LLM06 Excessive Agency fournit un référentiel de risque applicable directement à ces architectures. Ses huit mitigations sont opérationnelles, vérifiables, et compatibles avec les principaux frameworks multi-agents (LangGraph, CrewAI, AutoGen, frameworks maison). La discipline d'application reste à la charge de l'équipe d'architecture.

Trois questions à poser systématiquement en revue d'architecture multi-agents : « Chaque sub-agent vérifie-t-il indépendamment l'autorisation, ou s'appuie-t-il sur l'orchestrateur ? », « Le contexte d'identité de l'utilisateur initial est-il propagé à travers la chaîne de délégation, ou perdu en route ? », « Existe-t-il un sub-agent dans le pool générique qui accède à des données dont l'exposition serait inacceptable ? ». Si l'une de ces trois questions n'a pas de réponse documentée et testée, l'architecture est exposée au type de défaut décrit dans cet article.

Méthodologie et sources

Sources techniques (consultées le 24 mai 2026)

OWASP, Top 10 for LLM Applications 2025
OWASP, LLM06:2025 Excessive Agency
OWASP, LLM01:2025 Prompt Injection (référence pour le contexte attaque inter-agents)

Principes de sécurité référencés

Saltzer, J. H., et Schroeder, M. D. (1975), The Protection of Information in Computer Systems, Proceedings of the IEEE 63(9). Source canonique pour les principes de complete mediation, least privilege, fail-safe defaults, toujours référencés dans les framework de sécurité modernes (MIT, version en ligne).
IETF RFC 8693, OAuth 2.0 Token Exchange, pour la propagation contrôlée du contexte d'identité entre services.

Sources réglementaires (consultées le 24 mai 2026)

Règlement (UE) 2024/1689 du 13 juin 2024 (AI Act, modifié par le Digital Omnibus du 7 mai 2026), version officielle EUR-Lex. Les architectures multi-agents tombent typiquement dans le champ des systèmes à risque élevé Annexe III selon leur usage (gestion des travailleurs, accès à des services essentiels, etc.) ; les Articles 9 (gestion des risques), 12 (journalisation) et 14 (surveillance humaine) s'appliquent.
Règlement (UE) 2016/679 du 27 avril 2016 (RGPD), version officielle EUR-Lex. Article 33 cité (notification de violation de données à caractère personnel).

Frameworks multi-agents mentionnés

Les principaux frameworks open-source d'orchestration multi-agents en production en 2026 : LangGraph, CrewAI, AutoGen. Ces frameworks fournissent les primitives techniques pour implémenter le pattern supervisor-worker. Les mitigations de sécurité décrites dans cet article doivent être implémentées par l'équipe d'architecture, ces frameworks ne les imposant pas par défaut.

Estimations IgnitionAI

Les patterns d'erreur décrits sont des cas reconstitués agrégés à partir de missions IgnitionAI 2024-2025 portant sur l'audit d'architectures multi-agents en production. Aucun client n'est identifiable. Les recommandations d'architecture (placement des agents à données sensibles en service dédié, propagation du contexte utilisateur via OAuth Token Exchange, etc.) sont des bonnes pratiques expert applicables à la majorité des contextes, à adapter selon le stack technique précis du client.

Limites et invitations à vérification

Le framework OWASP Top 10 for LLM Applications est en évolution rapide. La version 2025 référencée ici peut avoir été supplantée par une version ultérieure à la date de votre lecture. Consulter la page officielle pour la version courante.
Cet article ne constitue pas un audit de sécurité applicable directement à une architecture précise. Chaque architecture multi-agents a ses spécificités qui nécessitent une analyse au cas par cas.

Politique de rectification

Si vous identifiez une erreur factuelle, une source devenue obsolète ou une référence inexacte, signalez-le via le formulaire dédié sur notre politique éditoriale. La procédure de rectification s'applique sous 5 jours ouvrés.

Dernière relecture des sources

24 mai 2026. Cet article fait partie de notre revue annuelle de janvier.

Cet article s'inscrit dans notre approche de la gouvernance IA chez IgnitionAI. Pour un audit OWASP LLM06 de votre architecture multi-agents, un cadrage de mise en conformité ou la conception d'une nouvelle architecture, présentez-nous votre projet. Notre page dédiée à la gouvernance IA détaille notre approche complète. Voir aussi notre article sur le contrôle d'accès dans un RAG d'entreprise qui couvre la dimension contrôle d'accès au niveau du retrieval, et notre article Microsoft 365 Copilot qui traite des architectures agentic Microsoft.