Les agents IA en entreprise lisent, préparent et agissent désormais dans vos logiciels. Leur sécurité dépend d’abord de ce qu’ils ont le droit de faire.
Lire des courriels, rechercher une information dans un CRM, préparer un devis, consulter un contrat, mettre à jour un dossier client ou déclencher une tâche dans un logiciel métier : les agents d’intelligence artificielle sont désormais capables d’enchaîner plusieurs opérations au sein du système d’information d’une entreprise.
Cette évolution marque une rupture importante.
Pendant longtemps, l’IA générative était principalement utilisée pour produire du contenu : rédiger un texte, résumer un document, traduire une information ou répondre à une question.
Avec les agents IA, le système ne se contente plus de répondre. Il peut utiliser des outils et agir.
Cette capacité ouvre des possibilités d’automatisation considérables. Elle introduit également une nouvelle question de sécurité : jusqu’où l’agent doit-il être autorisé à aller ?
Car la sécurité d’un agent IA ne dépend pas uniquement de la qualité du modèle utilisé. Elle dépend aussi des données auxquelles il peut accéder, des logiciels auxquels il est connecté et surtout des actions qu’il est autorisé à exécuter.
Pour une entreprise, sécuriser un agent commence donc par une règle relativement simple : ne jamais lui donner davantage de pouvoir que ce dont il a réellement besoin pour accomplir sa mission.
Un assistant qui répond n’est pas un agent qui agit
La différence entre un assistant conversationnel et un agent peut sembler minime pour l’utilisateur. Elle est pourtant fondamentale du point de vue de la sécurité.
Un assistant classique reçoit une demande et génère une réponse.
Un agent peut recevoir un objectif, déterminer plusieurs étapes nécessaires pour l’atteindre, interroger différents systèmes puis déclencher certaines actions.
Prenons un exemple simple.
Un collaborateur demande :
« Prépare-moi la relance des prospects qui n’ont pas répondu depuis quinze jours. »
Un assistant classique peut proposer un modèle de courriel.
Un agent connecté au système d’information peut aller beaucoup plus loin. Il peut consulter le CRM, identifier les opportunités concernées, retrouver les derniers échanges, analyser l’historique commercial, personnaliser chaque message et éventuellement déclencher l’envoi.
L’efficacité n’est évidemment pas la même.
Le risque non plus.
Une erreur dans un texte généré peut généralement être détectée avant son utilisation. Une erreur commise par un système disposant d’un droit d’action peut avoir une conséquence immédiate : modification d’une donnée, envoi d’un document, suppression d’une information ou communication avec une personne extérieure à l’entreprise.
La question n’est donc plus seulement : « Le modèle produit-il une bonne réponse ? »
Il faut également se demander : « Que peut-il faire si sa réponse ou son raisonnement est incorrect ? »
Le véritable périmètre d’un agent : modèle, outils et autorisations
Lorsqu’une entreprise évalue un agent IA, elle se concentre souvent sur le modèle : ses performances, sa capacité de raisonnement, son taux d’erreur ou la qualité de ses réponses.
Mais le niveau de risque dépend tout autant de ce qui entoure ce modèle.
Un agent connecté uniquement à une base documentaire en lecture seule n’a pas le même profil de risque qu’un agent pouvant accéder simultanément aux courriels, au CRM, à un espace documentaire, au logiciel de facturation et à différents outils internes.
La capacité réelle d’un agent dépend donc de la combinaison de trois éléments : ce qu’il comprend, les outils auxquels il peut accéder et les autorisations dont il dispose dans ces outils.
C’est pourquoi la gestion des identités et des autorisations devient un sujet central avec l’arrivée des agents IA. Les travaux publics de sécurité portent notamment sur les questions d’identité propre aux agents, d’authentification, de délégation d’autorité, de moindre privilège et de traçabilité des opérations.
Appliquer aux agents le principe du moindre privilège
Le principe du moindre privilège est ancien en cybersécurité : un utilisateur ou un programme ne doit disposer que des autorisations strictement nécessaires à sa mission.
Il prend une importance particulière avec les agents IA.
Prenons un agent chargé de préparer les relances commerciales.
Pour accomplir sa mission, il peut avoir besoin de consulter le nom du client, l’opportunité commerciale, la date du dernier contact et éventuellement les échanges précédents.
Mais a-t-il besoin de modifier la valeur d’une opportunité ?
De supprimer un contact ?
D’accéder à l’ensemble des contrats de l’entreprise ?
De télécharger toute la base clients ?
D’envoyer automatiquement un courriel sans validation ?
Probablement pas.
L’erreur consiste à connecter l’agent avec un compte disposant de droits beaucoup plus larges que ceux nécessaires à son usage.
La bonne approche consiste au contraire à construire ses permissions à partir de sa mission.
La CNIL recommande déjà, plus généralement pour les systèmes manipulant des données, de limiter les accès aux seules informations nécessaires et de différencier les habilitations selon les besoins. Elle rappelle également que le moindre privilège réduit les conséquences possibles d’une erreur ou d’une compromission.
Cette logique doit désormais être appliquée aux agents comme elle l’est aux collaborateurs et aux applications traditionnelles.
Lecture, proposition et exécution ne présentent pas le même risque
Toutes les autorisations ne doivent pas être considérées de la même manière.
Donner à un agent la possibilité de lire une fiche CRM est différent de lui permettre de la modifier.
L’autoriser à préparer un courriel est différent de l’autoriser à l’envoyer.
Lui permettre de proposer une facture est différent de lui permettre de la transmettre ou de déclencher un paiement.
Cette distinction permet de concevoir une autonomie progressive.
Dans beaucoup de cas, un agent peut déjà apporter une valeur importante sans disposer du droit d’exécuter lui-même l’action finale.
Il peut rechercher, analyser, préparer et recommander.
Le collaborateur conserve alors le pouvoir de validation.
Cette architecture est souvent plus pertinente pour les premiers déploiements : l’entreprise bénéficie d’une grande partie du gain de productivité sans transférer immédiatement toutes les décisions au système.
Une instruction malveillante peut se cacher dans un document
La question des permissions devient encore plus importante lorsqu’un agent consulte des contenus provenant de l’extérieur.
Un agent peut lire des courriels, des documents, des pages web, des pièces jointes ou les résultats retournés par une application.
Or ces contenus ne sont pas nécessairement fiables.
Une attaque par injection de prompt consiste à introduire des instructions destinées à influencer le comportement du modèle. Dans le cas d’une injection indirecte, ces instructions peuvent être dissimulées dans un contenu que l’agent est amené à consulter : page web, courriel, document ou réponse d’un autre outil.
L’agent pourrait alors interpréter une donnée comme une instruction.
Le NIST identifie précisément le détournement d’agents par injection indirecte comme un risque de sécurité des systèmes agentiques. L’OWASP recommande de considérer les contenus externes comme non fiables, de limiter les privilèges de l’agent et de conserver une validation humaine pour les opérations sensibles.
Prenons un cas volontairement simple.
Un agent est chargé d’analyser les courriels reçus par une entreprise et de préparer les réponses.
Un message reçu contient une instruction destinée non pas au collaborateur, mais au système automatisé qui pourrait le lire.
Si l’agent dispose uniquement d’un accès en lecture et peut proposer une réponse, les conséquences restent limitées.
S’il peut également consulter l’ensemble des fichiers internes, transmettre des documents et envoyer des messages automatiquement, la même attaque peut devenir beaucoup plus problématique.
Le risque d’une injection dépend donc directement du pouvoir accordé à l’agent.
Il est impossible de considérer qu’un simple prompt système constitue à lui seul une barrière de sécurité suffisante. Les contrôles critiques d’autorisation doivent être appliqués indépendamment du modèle.
Le risque augmente lorsque l’agent utilise plusieurs outils
L’un des intérêts majeurs des agents réside précisément dans leur capacité à passer d’un système à un autre.
Un agent commercial pourrait, par exemple, consulter un CRM, rechercher un contrat dans un espace documentaire, analyser les derniers courriels et préparer une proposition commerciale.
Chaque connexion supplémentaire augmente cependant la surface d’action de l’agent.
Un droit relativement anodin dans un logiciel peut devenir plus sensible lorsqu’il est combiné à un autre.
La sécurité doit donc être pensée sur l’ensemble de la chaîne et non outil par outil.
Cette question devient encore plus importante dans les architectures comportant plusieurs agents. Un agent spécialisé peut transmettre une tâche à un autre agent disposant de capacités différentes.
Les identités, permissions et délégations doivent alors rester clairement séparées. Un agent peu privilégié ne devrait pas pouvoir obtenir indirectement des droits supérieurs simplement en demandant à un autre agent d’effectuer une opération à sa place.
L’OWASP recommande notamment que les agents disposent d’identités et d’autorisations adaptées à leur fonction, plutôt que de partager des comptes ou des identifiants très largement autorisés.
Quelles actions doivent rester sous contrôle humain ?
La validation humaine ne doit pas nécessairement intervenir à chaque étape.
Si un collaborateur doit confirmer chaque recherche effectuée par l’agent, l’automatisation perd rapidement son intérêt.
L’enjeu consiste donc à identifier les opérations dont les conséquences justifient une confirmation.
Avant le déploiement, l’entreprise peut notamment examiner :
- les communications envoyées à l’extérieur de l’organisation ;
- les créations, modifications ou suppressions de données importantes ;
- les opérations financières ou les engagements commerciaux ;
- les accès ou transferts de données confidentielles ;
- les changements de droits et d’autorisations ;
- les actions susceptibles d’avoir un impact juridique ;
- les opérations difficiles ou impossibles à annuler.
Pour chacune, trois décisions sont possibles : l’action peut être automatique, elle nécessite une validation humaine, ou elle reste exclusivement réservée à un collaborateur.
L’important est que cette décision soit prise avant le déploiement et qu’elle ne soit pas laissée à l’appréciation du modèle au moment où l’action doit être exécutée.
L’agent doit avoir une identité identifiable
Une autre question devient essentielle : lorsque quelque chose est modifié dans un système, est-il possible de savoir si l’action provient d’un collaborateur, d’une application classique ou d’un agent IA ?
Utiliser les identifiants personnels d’un collaborateur pour faire fonctionner un agent peut compliquer cette distinction.
Une architecture plus robuste consiste à pouvoir identifier clairement l’agent et le périmètre dans lequel il agit.
Cela facilite la gestion des autorisations, mais également l’audit.
Si un agent met à jour cinquante fiches dans un CRM, l’entreprise doit pouvoir retrouver ces opérations et comprendre dans quel contexte elles ont été réalisées.
Les spécialistes de la sécurité placent justement l’identité, l’authentification, l’autorisation, la délégation et l’audit parmi les questions centrales pour l’intégration sécurisée des agents dans les systèmes d’entreprise.
Journaliser ce que fait l’agent
L’autonomie doit aller de pair avec la traçabilité.
Pour les opérations importantes, il faut pouvoir reconstruire ce qui s’est passé : quel agent a déclenché l’action, pour quel utilisateur, avec quel outil, sur quelle ressource et à quel moment.
La journalisation permet d’analyser un incident, mais aussi d’améliorer progressivement le système.
Une entreprise peut par exemple constater qu’un agent propose régulièrement des modifications qui sont ensuite refusées par les utilisateurs. Cette information est utile : elle peut révéler un problème dans les instructions, dans les données utilisées ou dans le niveau d’autonomie qui lui a été confié.
La CNIL recommande elle aussi de gérer les habilitations, tracer les accès et analyser les opérations portant sur les données.
Il faut également prévoir une procédure simple permettant de suspendre les droits de l’agent ou de désactiver rapidement ses connexions en cas d’anomalie.
Construire l’autonomie par étapes
Une entreprise n’est pas obligée de choisir entre un simple chatbot et un agent totalement autonome.
Il existe plusieurs niveaux intermédiaires.
Au premier niveau, l’agent consulte les informations et les synthétise. Il est essentiellement en lecture seule.
Au deuxième niveau, il peut préparer une action : rédiger une réponse, proposer une modification du CRM ou préparer un document. Le collaborateur décide ensuite de l’exécuter.
Au troisième niveau, certaines actions considérées comme peu risquées peuvent être automatisées, tandis que les opérations sensibles restent soumises à validation.
Ce n’est qu’après avoir observé le fonctionnement du système sur des situations représentatives que l’entreprise peut décider d’étendre son autonomie.
Cette progression permet d’évaluer non seulement la performance du modèle, mais également son comportement réel dans l’environnement de l’entreprise.
L’ANSSI recommande plus largement une approche prudente lors de l’intégration de systèmes d’IA générative au système d’information et des audits de sécurité avant leur déploiement en production.
Un exemple : automatiser le traitement d’une demande client
Imaginons un agent chargé de traiter les demandes entrantes d’un service commercial.
Dans une première version, l’agent lit le message, identifie le client dans le CRM, retrouve les informations utiles et prépare une réponse.
Le commercial vérifie puis envoie.
Après plusieurs semaines, l’entreprise constate que certaines demandes simples sont traitées de manière suffisamment fiable.
Elle peut alors autoriser l’agent à envoyer automatiquement certaines réponses standardisées, tout en maintenant une validation humaine dès qu’un montant, un contrat, une réclamation ou une information sensible est concerné.
L’autonomie n’est donc pas définie une fois pour toutes.
Elle dépend du contexte, de la nature de l’action et du niveau de risque.
C’est probablement l’un des changements les plus importants introduits par les agents IA : l’entreprise ne doit plus seulement gérer les droits de ses collaborateurs et de ses applications. Elle doit également gouverner les droits accordés à des systèmes capables de décider dynamiquement quels outils utiliser.
Avant de connecter un agent, commencer par sa matrice d’autorisations
La première étape d’un projet agentique ne devrait donc pas être : « À quels logiciels pouvons-nous connecter l’agent ? »
La bonne question est plutôt : « De quelles capacités a-t-il réellement besoin pour accomplir cette mission ? »
Pour chaque outil, il faut distinguer les données nécessaires, les droits de lecture, les droits de modification, les actions exécutables et les opérations nécessitant une validation.
Cette réflexion permet également de détecter des projets mal définis.
Si personne ne sait précisément quelles informations un agent doit consulter et quelles actions il doit accomplir, il est probablement encore trop tôt pour lui donner accès au système d’information.
La sécurité devient alors un exercice de conception du processus métier, et pas uniquement un problème technique traité à la fin du projet.
L’objectif n’est pas de supprimer l’autonomie
Sécuriser les agents IA ne signifie pas empêcher toute automatisation.
Un agent auquel aucune action n’est permise présente peu de risques, mais également peu d’intérêt.
L’enjeu consiste à trouver le niveau d’autonomie qui produit une valeur opérationnelle sans créer un niveau de risque disproportionné.
Pour certaines tâches, la lecture seule sera suffisante.
Pour d’autres, l’agent pourra modifier certaines données.
Dans certains processus très encadrés, une automatisation beaucoup plus importante pourra être pertinente.
Mais cette autonomie doit être choisie, documentée et contrôlée.
Un agent IA ne doit pas disposer du maximum de capacités que la technologie permet de lui donner. Il doit disposer du niveau d’autonomie nécessaire à sa mission, et pas davantage.
Pour les entreprises qui commencent à connecter des agents à leurs CRM, messageries, bases documentaires ou applications métier, c’est probablement l’un des principes les plus importants à intégrer dès aujourd’hui.
La question de la sécurité ne commence pas lorsque l’agent commet une erreur.
Elle commence au moment où l’entreprise décide de ce qu’il aura le droit de faire.
Sources et références
- NIST, Strengthening AI Agent Hijacking Evaluations (janvier 2025)
- ANSSI, Recommandations de sécurité pour un système d’IA générative (avril 2024)
- OWASP, Gen AI Security Project
- CNIL, Sécurité des données
Questions fréquentes sur la sécurité des agents IA en entreprise
Qu’est-ce qu’une matrice d’autorisations pour un agent IA ?
C’est le tableau qui fixe, outil par outil, ce que l’agent peut lire, préparer, modifier ou exécuter, et les actions qui demandent une validation humaine.
Par où commencer pour sécuriser des agents IA en entreprise ?
Par un audit des usages et des données, puis un premier périmètre limité à la lecture et à la préparation, avant toute action autonome.
Encadrer vos agents IA avec Pionarius
Pionarius est un cabinet de conseil en intelligence artificielle. Avant de connecter un agent à vos outils, nous établissons avec vous sa matrice d’autorisations : ce qu’il peut lire, ce qu’il peut préparer, ce qu’il peut modifier, et les actions qui exigent une validation humaine. Nous posons ensuite le cadre d’usage, mettons l’agent en place sur un premier périmètre limité et mesurons ce qu’il change, de l’audit à l’implémentation de la solution.
À lire aussi : implémentation de l’IA dans l’informatique de l’assurance, pilote IA : décider du passage en production et notre conseil en intelligence artificielle.
