LLM et cybersécurité : pourquoi les assistants IA élargissent la surface d’attaque

Les assistants conversationnels, outils de rédaction, moteurs de recherche internes et agents capables d’agir sur des logiciels s’installent progressivement dans les organisations. Leur promesse est simple : comprendre une demande formulée en langage courant et produire une réponse, un résumé, du code ou une action. Mais cette facilité d’usage masque une réalité essentielle : lorsqu’un grand modèle linguistique accède à des données, à des documents ou à des outils, il devient aussi un nouveau point d’entrée potentiel pour les attaquants.

Un LLM, pour Large Language Model, ne fonctionne pas comme une base de données traditionnelle ni comme un programme aux règles parfaitement déterminées. Il génère du texte en prédisant la suite la plus vraisemblable d’une requête, à partir de son entraînement et du contexte qui lui est fourni. Cette souplesse fait sa force. Elle rend également ses réactions plus difficiles à anticiper dans toutes les situations, surtout lorsqu’il est relié à des systèmes d’information sensibles.

En juin 2025, le sujet ne consiste donc plus seulement à savoir ce qu’un modèle peut accomplir. Il faut aussi déterminer à quelles informations il a accès, quelles actions il peut déclencher, qui peut l’interroger et comment vérifier que ses réponses ne deviennent pas elles-mêmes un vecteur d’incident.

Pourquoi les LLM changent la donne en cybersécurité

Les grands modèles linguistiques sont utilisés dans des contextes très variés : service client, recherche dans une documentation interne, aide au développement, automatisation de tâches administratives ou analyse de contenus. Dans ces usages, le modèle peut recevoir des consignes de l’entreprise, des questions d’utilisateurs, des extraits de bases documentaires et, parfois, des droits pour appeler d’autres logiciels.

Cette architecture crée une surface d’attaque plus large. Une application classique suit généralement un ensemble de règles explicites : une donnée est attendue dans un format précis et un programme applique une logique définie. Avec un LLM, l’entrée est souvent du langage naturel. Or, le langage peut contenir une demande légitime, une instruction ambiguë, un contenu malveillant ou une consigne cachée dans un document que le modèle doit analyser.

Le risque ne vient pas du seul modèle. Il naît de l’ensemble de la chaîne qui l’entoure : interface de discussion, connecteurs vers les données de l’entreprise, bases documentaires, plugins, systèmes d’authentification et outils que l’assistant est autorisé à utiliser. Une faiblesse à l’un de ces niveaux peut compromettre le système entier.

La montée en puissance de l’IA générative profite aussi aux attaquants. Elle peut rendre plus rapide la production de messages frauduleux, de textes de manipulation ou de contenus adaptés à une cible. Mais le défi le plus immédiat pour les organisations qui déploient des LLM est souvent interne : éviter que leur propre assistant puisse être manipulé, divulgue une donnée ou transmette une commande dangereuse à un logiciel connecté.

Injection de prompt : comment un assistant peut être manipulé

L’injection de prompt est l’une des menaces les plus emblématiques associées aux LLM. Elle consiste à présenter au modèle des instructions conçues pour détourner son comportement. Un utilisateur peut, par exemple, tenter de lui faire ignorer ses consignes initiales, d’obtenir le détail de son paramétrage ou de lui demander de révéler des informations qu’il a reçues dans son contexte.

Il existe aussi une forme indirecte, particulièrement délicate à gérer. Imaginons un assistant chargé de lire des pages web, des courriels ou des fichiers internes pour répondre à une question. Un document analysé peut contenir une instruction malveillante, formulée comme du texte ordinaire. Le modèle risque alors de la traiter comme une consigne à suivre plutôt que comme une simple donnée à résumer.

Le problème est structurel : un LLM traite dans une même interface linguistique des ordres et des contenus. Séparer de manière absolument fiable une instruction légitime d’un texte non fiable reste difficile. Les consignes système et les garde-fous sont nécessaires, mais ils ne remplacent pas une conception prudente des droits accordés au modèle.

Une application devient plus risquée lorsque l’assistant peut agir au-delà de la conversation. S’il peut consulter une messagerie, interroger des fichiers confidentiels, envoyer un message ou réaliser une opération via un outil métier, une manipulation réussie peut avoir des effets concrets. Le principe de moindre privilège est donc central : le modèle ne doit recevoir que les accès strictement nécessaires à la tâche demandée.

Les principales failles à connaître

L’OWASP, organisation connue pour ses référentiels sur la sécurité des applications, a établi une cartographie des risques propres aux applications utilisant de grands modèles linguistiques. Elle rappelle un point fondamental : les vulnérabilités habituelles du numérique ne disparaissent pas avec l’IA générative. Elles prennent de nouvelles formes, auxquelles s’ajoutent des risques liés au comportement probabiliste des modèles.

Le traitement non sécurisé des sorties est un danger parfois sous-estimé. Une réponse de LLM peut sembler cohérente et inoffensive tout en contenant une instruction, une donnée ou une structure qui devient risquée si l’application la réutilise sans contrôle. Injecter directement ce contenu dans une page web, l’envoyer vers une commande système ou l’utiliser pour alimenter une requête sensible revient à faire confiance à une production qui n’est pas, par nature, sûre.

L’empoisonnement des données constitue un autre risque majeur. Il peut concerner les données utilisées pour entraîner un modèle, mais également les documents ajoutés à une base de connaissances consultée au moment de la réponse. Des contenus falsifiés, biaisés ou manipulés peuvent conduire l’assistant à générer des informations erronées, à privilégier une instruction indésirable ou à dégrader la fiabilité globale du service.

Enfin, l’extraction d’informations mémorisées ou présentes dans le contexte pose une question de confidentialité. Les organisations doivent savoir quelles données sont envoyées à un fournisseur de modèle, combien de temps elles sont conservées, qui peut y accéder et dans quelles conditions elles peuvent être réutilisées. Ces questions relèvent autant de l’architecture technique que de la gouvernance.

Un LLM doit être protégé comme un composant critique

La bonne approche ne consiste pas à ajouter un filtre à la fin d’un projet. La sécurité doit être pensée avant le déploiement, puis entretenue pendant toute la durée de vie de l’application. Un assistant connecté aux données de l’entreprise mérite une analyse de risque comparable à celle menée pour un serveur, une base de données ou une application métier.

La première étape est de cartographier précisément les flux. Quelles informations entrent dans le modèle ? D’où viennent-elles ? Le modèle peut-il consulter des documents internes, et lesquels ? Peut-il appeler des outils externes ? Peut-il envoyer, modifier ou supprimer des informations ? Répondre à ces questions permet de repérer les accès excessifs et les dépendances mal maîtrisées.

La seconde étape consiste à distinguer clairement les rôles. Le LLM peut interpréter une demande et proposer une action, mais il ne devrait pas être l’unique mécanisme qui autorise cette action. Les systèmes d’identité et de gestion des droits doivent vérifier l’autorisation de l’utilisateur pour chaque ressource. Lorsqu’une opération est sensible, une validation humaine ou une confirmation explicite doit pouvoir s’interposer.

Les organisations ont aussi intérêt à adopter plusieurs mesures complémentaires :

• segmenter les données selon leur niveau de sensibilité et éviter de transmettre au modèle celles qui ne sont pas nécessaires ;
• restreindre les outils, connecteurs et plugins accessibles à l’assistant ;
• contrôler les entrées, mais aussi valider systématiquement les sorties avant leur affichage ou leur exécution ;
• limiter le nombre, la fréquence et le coût des requêtes afin de prévenir les abus et les dénis de service ;
• conserver des journaux d’activité exploitables pour enquêter sur un incident et améliorer les protections.

Détection, tests et surveillance : une sécurité en continu

Les dispositifs de détection d’anomalies ont un rôle important. Ils peuvent aider à repérer des séquences de requêtes inhabituelles, des tentatives répétées de contourner des consignes ou une utilisation anormale d’un connecteur. Ces signaux ne permettent pas d’arrêter toutes les attaques, mais ils donnent aux équipes de sécurité des éléments pour réagir rapidement.

La surveillance doit être accompagnée de tests réguliers. Tester une application LLM consiste notamment à essayer de la détourner : formuler des requêtes ambiguës, introduire des instructions dans des documents, vérifier la résistance des connecteurs et examiner ce qui se passe lorsqu’une réponse inattendue est produite. Cette démarche, parfois appelée « red teaming », cherche non pas à démontrer que l’assistant fonctionne dans le cas idéal, mais à comprendre comment il échoue dans des cas hostiles ou imprévus.

Les équipes doivent également suivre les évolutions du modèle, des bibliothèques utilisées et des services tiers. Une mise à jour peut corriger une vulnérabilité, mais elle peut aussi modifier le comportement d’un système déjà déployé. Chaque évolution importante mérite donc une nouvelle phase de tests, notamment lorsqu’elle touche aux permissions, aux données disponibles ou aux outils reliés à l’assistant.

La gouvernance, condition d’un déploiement responsable

La cybersécurité des LLM n’est pas qu’un sujet d’ingénierie. Une politique de gouvernance claire doit définir les usages permis, les catégories de données interdites ou encadrées, les responsabilités de chaque équipe et la procédure à suivre en cas d’incident.

Cette gouvernance commence par un inventaire. Une entreprise doit pouvoir identifier les assistants utilisés, les modèles sous-jacents, les fournisseurs concernés, les jeux de données connectés et les personnes responsables. Sans cette visibilité, il devient difficile de contrôler les échanges de données ou de retirer rapidement un outil devenu vulnérable.

Elle implique aussi de former les utilisateurs. Un collaborateur doit comprendre qu’un assistant peut se tromper, qu’il ne faut pas lui confier n’importe quelle information et qu’une réponse convaincante n’est pas une preuve. Pour les équipes techniques, la sensibilisation porte sur l’intégration : un LLM ne doit pas contourner les principes de sécurité déjà appliqués aux logiciels traditionnels.

Ce qu’il faut surveiller

L’intégration des LLM dans les systèmes d’information devrait se poursuivre, avec des assistants de plus en plus connectés aux documents, aux logiciels et aux processus de travail. Cette évolution rendra les questions d’autorisation et de contrôle des actions encore plus importantes. Un modèle qui conseille n’a pas le même niveau de risque qu’un modèle qui peut agir.

Les organisations les mieux préparées ne seront pas nécessairement celles qui déploient le plus vite. Elles seront celles qui savent précisément ce que fait leur assistant, quelles données il consulte, quels outils il peut utiliser et comment suspendre ses accès en cas de problème. La maturité en cybersécurité passera par une approche continue : évaluer, limiter, tester, surveiller, corriger, puis évaluer de nouveau.

Les LLM ne doivent ni être traités comme des oracles infaillibles ni être écartés par principe. Utilisés avec des garde-fous adaptés, ils peuvent apporter une aide réelle. Mais leur puissance linguistique ne dispense jamais des règles fondamentales de cybersécurité : réduire les privilèges, protéger les données, vérifier les résultats et préparer la réponse aux incidents.