Un assistant conversationnel répond. Un agent agit : il lit des documents, interroge des systèmes, déclenche des traitements, écrit dans des applications. Le déplacement est discret dans l’usage, considérable du point de vue de la sécurité. Un assistant qui se trompe produit un texte faux. Un agent qui se trompe produit une action.
Le sujet arrive maintenant dans les organisations françaises par la voie habituelle : une direction métier expérimente, l’outil rend service, et l’informatique découvre le déploiement au moment de la demande d’accès aux données.
Le problème central : l’agent hérite de droits
Pour être utile, un agent a besoin d’accès. Et parce que définir finement ses permissions est fastidieux, il reçoit très souvent les droits complets de la personne qui l’utilise — parfois davantage, via un compte technique créé pour l’occasion.
Il en découle une propriété inconfortable : toute personne capable d’influencer le comportement de l’agent dispose indirectement de ces droits. Or influencer le comportement d’un agent ne demande pas d’accès privilégié. Il suffit de lui faire lire un contenu.
L’injection par les données
C’est la classe de risque propre à ces systèmes, et elle n’a pas d’équivalent dans les architectures antérieures.
Un agent qui traite des courriels, des tickets, des documents partagés ou des pages consultées ne distingue pas de façon fiable les instructions de son opérateur du contenu qu’il analyse. Un texte inséré dans un document — éventuellement invisible à l’œil — peut être interprété comme une consigne.
Le scénario n’est pas théorique : un agent chargé de trier les demandes entrantes, disposant d’un accès en lecture à un référentiel interne et d’une capacité d’envoi de messages, peut être détourné par le contenu d’une demande externe. L’attaquant n’a compromis aucun compte, franchi aucun pare-feu, exploité aucune vulnérabilité logicielle. Il a écrit un message.
Aucune correction ne supprime ce risque à ce jour. Les protections existantes le réduisent ; elles ne le ferment pas. C’est une raison suffisante pour ne pas confier à un agent une action irréversible sur la base d’un contenu non maîtrisé.
Trois autres effets sous-estimés
L’enchaînement. Un agent décompose un objectif en étapes qu’il détermine lui-même. Une erreur d’interprétation à la deuxième étape se propage aux suivantes sans point d’arrêt. Là où un traitement automatisé classique échoue sur une exception, un agent improvise un contournement — et poursuit.
La traçabilité. Les journaux enregistrent généralement l’invocation et le résultat, rarement le raisonnement intermédiaire ni les données consultées en cours de route. Reconstituer après coup pourquoi un agent a pris une décision est souvent impossible. C’est un problème d’exploitation, mais aussi de conformité lorsque la décision concerne des personnes.
La circulation des données. Un agent qui consulte plusieurs sources pour répondre les agrège dans un contexte unique. Des données auxquelles l’utilisateur avait accès séparément se retrouvent combinées, parfois transmises à un service tiers pour traitement. Les cloisonnements applicatifs existants sont contournés sans intention malveillante.
Ce qui fonctionne en pratique
- Séparer lecture et écriture. Un agent en lecture seule présente un risque de fuite, borné. Un agent capable d’écrire, d’envoyer ou de déclencher présente un risque d’action, non borné. Ce sont deux niveaux de validation différents, et la distinction doit être explicite dès la conception.
- Un compte dédié, avec des droits propres. Jamais les droits de l’utilisateur. Le compte de l’agent est dimensionné pour sa tâche, et cette tâche est écrite quelque part.
- Une validation humaine sur les actions irréversibles. Virement, suppression, envoi externe, modification de droits, publication. Pas de validation par accusé de réception automatique — une validation qui demande de lire ce qui va être fait.
- Ne pas mélanger contenu non fiable et droits élevés. Un agent qui traite du courrier entrant ne doit pas être le même que celui qui accède au référentiel client. C’est le cloisonnement le plus efficace, et le plus souvent négligé au nom de la commodité.
- Journaliser les actions, pas seulement les échanges. Ce que l’agent a fait, sur quel système, avec quel compte, avec quelles données en entrée.
Le cadre réglementaire
Deux textes s’appliquent sans qu’il soit nécessaire de développer soi-même le système.
Le règlement européen sur l’intelligence artificielle impose des obligations qui dépendent de l’usage, pas de la technologie : un agent utilisé dans le recrutement, la gestion du personnel ou l’accès à des services essentiels relève de catégories plus exigeantes, y compris pour un déployeur qui n’a rien conçu.
Le RGPD s’applique dès que l’agent traite des données personnelles : base légale, information des personnes, minimisation, et encadrement spécifique lorsque la décision produit des effets significatifs. Un agent qui prépare une décision que personne ne réexamine réellement pose la question du caractère automatisé de cette décision.
La question à poser avant le déploiement
Elle tient en une phrase : si cet agent exécutait, une fois, l’action la plus dommageable que ses droits permettent, quelles en seraient les conséquences et combien de temps mettrions-nous à nous en apercevoir ?
Si la réponse est inconnue, ce n’est pas l’agent qu’il faut évaluer d’abord, ce sont ses droits.
Sources
- Règlement (UE) 2024/1689 établissant des règles harmonisées concernant l’intelligence artificielle
- Règlement (UE) 2016/679 (RGPD) — article 22, décision individuelle automatisée
- ANSSI — recommandations de sécurité pour les systèmes d’IA générative
- OWASP — Top 10 for Large Language Model Applications, sur l’injection de consignes