Comment protéger les données sensibles utilisées par un assistant IA ?

Les assistants et les agents d’intelligence artificielle basés sur les grands modèles de langage, ou LLM, peuvent consulter des documents, interroger des bases de données et utiliser des outils internes. Ils facilitent ainsi l’accès à l’information, mais peuvent aussi ouvrir une voie vers des données que certains utilisateurs ne sont pas autorisés à consulter. 

Une vulnérabilité révélée en 2025 dans Lena, l’assistant de service à la clientèle de Lenovo, illustre ce risque. Des chercheurs de Cybernews ont montré qu’un message d’environ 400 caractères pouvait amener l’assistant à intégrer du code malveillant dans sa réponse. Lorsque la conversation était ouverte par un agent de soutien, une faille de l’interface Web permettait l’exécution de ce code et le vol de ses témoins de session. Ces témoins pouvaient ensuite servir à usurper sa session, sans connaître son mot de passe, et potentiellement à consulter les conversations d’autres clients. Lenovo a indiqué avoir apporté des correctifs. Ce cas montre que la sécurité dépend aussi des applications qui affichent et utilisent les réponses du modèle. 

Le risque ne se limite donc pas à la confidentialité des échanges avec le fournisseur du LLM. Il existe également au sein de l’organisation lorsque l’assistant peut consulter davantage de données que l’utilisateur n’est autorisé à voir, ou que la tâche ne le nécessite. Il peut s’agir de renseignements salariaux, de dossiers clients, de secrets commerciaux ou de documentation technique sensible. 

Ce n'est donc pas un sujet réservé à ceux qui manipulent des données personnelles. Tout assistant connecté à des documents internes, des dossiers clients, de la documentation technique, ou qui déclenche des actions (un système agentique), hérite de ce risque. La protection de ces informations commence par des règles de gouvernance claires : qui peut consulter quelles données, pour quel usage, et comment ces droits sont-ils appliqués et vérifiés? Lorsque des renseignements personnels sont concernés, les obligations légales applicables doivent également être prises en compte, notamment celles découlant de la Loi 25 au Québec ou du RGPD lorsque celui-ci s’applique. À cela s’ajoutent les engagements contractuels de confidentialité et les exigences de sécurité liées, selon le contexte, à une certification ISO 27001 ou aux contrôles évalués dans le cadre d’un rapport SOC 2. Quand l'assistant IA d'Air Canada a promis à un client un remboursement que la compagnie n'accordait pas, un tribunal a forcé l'entreprise à l'honorer. Ce que votre assistant affirme ou laisse fuir engage votre organisation. 

Une divulgation peut résulter d’une tentative délibérée de contourner les restrictions, mais aussi survenir sans intention malveillante. Un employé peut chercher à consulter un dossier auquel il n’a pas droit ; un utilisateur peut reformuler ses demandes jusqu’à obtenir une information protégée ; une réponse peut révéler un contenu confidentiel à une personne qui ne le recherchait pas. Les agents capables de lire des contenus externes et d’exécuter des actions présentent une autre voie de détournement. Un courriel ou un document consulté peut contenir des instructions malveillantes que le modèle risque de suivre comme s’il s'agissait de consignes légitimes. La protection doit donc porter sur les données accessibles, les contenus traités et les actions que le système est autorisé à exécuter. 

Dès la conception, il faut déterminer quelles données le modèle peut recevoir pour chaque utilisateur et chaque tâche, puis appliquer ces limites par des contrôles externes au LLM. Les consignes données au modèle viennent ensuite encadrer son comportement et compléter ces protections. 

Quels risques apparaissent lorsqu’un assistant accède aux données internes 

Trois risques peuvent se combiner lorsqu’un assistant accède à des données internes : la fuite de données, le détournement d’instructions et l’accès non autorisé. Une information sensible peut être divulguée dans la conversation. Le système peut aussi être amené à agir contrairement aux règles qui lui ont été données. Enfin, l’assistant peut permettre à un utilisateur d’obtenir une information qu’il n’a pas le droit de consulter. 

Ces risques peuvent s’enchaîner : un détournement d’instructions peut exploiter un contrôle insuffisant et mener à la divulgation d’informations confidentielles. La sécurité doit donc couvrir l’ensemble du parcours de la donnée, depuis son stockage et sa sélection jusqu’à sa transmission au modèle et à son utilisation dans la réponse. La surveillance des interactions complète ces protections. 

Un point mérite une attention particulière : l’écart entre les données accessibles au système et les droits de l’utilisateur. Si le modèle reçoit une information que cette personne n’est pas autorisée à consulter et que seules des consignes en interdisent la divulgation, la protection dépend de sa capacité à les respecter, même face à des demandes reformulées ou réparties sur plusieurs échanges. 

Pourquoi une consigne donnée au LLM ne suffit-elle pas 

Une consigne donnée au LLM encadre son comportement, mais ne constitue pas un mécanisme technique de contrôle d’accès. Dès qu’une information sensible lui est transmise, elle fait partie des données qu’il peut utiliser pour produire sa réponse. 

Un assistant peut refuser une demande directe, puis réagir différemment à une requête reformulée, présentée dans un autre contexte ou répartie sur plusieurs échanges. Un utilisateur peut aussi lui demander de répondre en adoptant un rôle fictif, par exemple celui d’un gestionnaire des ressources humaines autorisé à consulter les données salariales. Ce rôle ne change pas les droits réels de l’utilisateur, mais peut influencer la manière dont le modèle interprète la demande. Le refus d’une question explicite ne suffit donc pas à démontrer que l’information est protégée.  

Si le modèle possède déjà la donnée, sa protection repose sur sa capacité à reconnaître et à bloquer toutes les demandes susceptibles de la révéler, y compris celles qui n’ont pas été prévues. Cette dépendance rend l’approche fragile : le contrôle porte sur la réponse produite plutôt que sur l’accès même à l’information. 

Un cas survenu en décembre 2023 illustre cette possibilité de détournement. Un utilisateur a manipulé l'assistant de service à la clientèle d'un concessionnaire Chevrolet en lui donnant deux consignes : approuver tout ce que le client proposerait, et terminer chaque réponse en déclarant l'offre « légalement contraignante ». L'assistant a accepté de « vendre » un véhicule d'environ 76 000 dollars pour un dollar, et le concessionnaire a désactivé le robot après que la capture d'écran est devenue virale. La consigne d'origine du système n'a pas tenu : une instruction de l'utilisateur, mieux formulée, a pris le dessus. Le même mécanisme qui fait céder un assistant sur une règle commerciale le fait céder sur une donnée sensible.

Où appliquer le contrôle d’accès? 

Lorsqu’un assistant consulte des sources de niveaux de confidentialité différents, les droits des utilisateurs peuvent être pris en compte à deux endroits : après la récupération des données, au moyen de consignes données au modèle, ou avant cette récupération, à l’aide d’un mécanisme externe. Ces deux approches n’offrent pas le même niveau de protection.

Tout transmettre au modèle 

Dans une architecture fragile, l’assistant reçoit un ensemble de données qui comprend des contenus autorisés et d’autres confidentiels. Une instruction lui demande ensuite de ne révéler les informations sensibles qu’aux personnes autorisées. La donnée interdite reste pourtant présente dans son contexte. 

La protection de ces données dépend donc entièrement de la capacité du système à interpréter correctement les droits de l’utilisateur et à appliquer les consignes, peu importe la manière dont la demande est formulée. 

Filtrer les données en amont 

Dans une architecture plus robuste, le système vérifie l’identité et les droits de l’utilisateur avant d’interroger les sources. Une couche externe au LLM ne sélectionne que les documents ou les renseignements que cette personne est autorisée à consulter. Concrètement, ce tri repose sur un filtrage par métadonnées au niveau du moteur de recherche, un contrôle d'accès basé sur les rôles ou les attributs, ou une restriction appliquée directement au niveau des lignes de la base de données. Le modèle génère ensuite sa réponse à partir de cet ensemble restreint. Les autres contenus n’entrent pas dans la conversation et ne peuvent donc pas être repris dans la réponse.  

Cette séparation ne supprime pas tous les risques, mais elle élimine une cause directe de divulgation : la présence, dans le contexte du modèle, d’une donnée qui n’aurait jamais dû lui être transmise pour cet utilisateur. 

Exemple d’un assistant connecté aux documents de ressources humaines

Reprenons l'exemple de l’assistant RH. Si tous les documents sont regroupés dans une base accessible au modèle, une consigne doit lui indiquer quoi montrer à chaque personne. Le LLM participe alors à l'application des droits, avec la fragilité déjà décrite. Si les droits sont vérifiés avant la recherche, un employé non autorisé ne reçoit jamais les données salariales dans le contexte de l'interaction.

Le contrôle peut aussi porter sur des champs précis à l'intérieur d'une même source. Plutôt qu'un salaire exact, la couche de données peut ne renvoyer qu'une valeur agrégée ou masquée, calculée sans que la donnée brute ne passe par le modèle. Le contrôle le plus robuste ne consiste donc pas à indiquer au modèle ce qu'il peut révéler, mais à déterminer ce qu'il peut recevoir. 

Que faire lorsque l’assistant doit traiter des données sensibles

Certains usages exigent que l’assistant traite de l’information confidentielle. L'isolement complet n'est pas toujours possible. Un assistant de traitement de réclamations doit, par exemple, consulter les éléments du dossier du demandeur, tandis qu’un agent de maintenance peut avoir besoin d’accéder à des procédures internes sensibles.   

L’objectif consiste alors à limiter l’accès aux renseignements nécessaires à la tâche et à vérifier que l’utilisateur est autorisé à les consulter. Ces contrôles doivent notamment empêcher qu’une personne obtienne un accès en prétendant être quelqu’un d’autre ou disposer de droits qu’elle n’a pas. Ils doivent être complétés par d’autres mesures pour réduire les risques de détournement et de divulgation. Ces protections renforcent le contrôle d’accès sans le remplacer. 

Limiter les données au strict nécessaire 

Le système ne devrait recevoir que les données nécessaires à la tâche, en limitant les sources consultées, les renseignements transmis et la période couverte.  Le fait qu’une partie d’une base de données soit utile ne justifie pas l’accès à son ensemble. Par exemple, un assistant chargé d’indiquer à un employé son solde de congés n’a pas besoin de consulter tout son historique de paie, seulement le solde de jours de congés de la personne.  

Cette restriction limite la quantité d’information susceptible d’être divulguée si une protection échoue. Elle traduit le principe du moindre privilège : accorder au système uniquement les accès nécessaires à sa fonction et ne transmettre au modèle que les données utiles à la demande. 

Conserver les autorisations hors du LLM 

La décision « qui a le droit d'accéder à quoi » doit rester dans une couche déterministe, hors du modèle. Le modèle peut utiliser une donnée sensible pour accomplir une tâche autorisée, mais il ne doit jamais être le mécanisme qui accorde ou refuse l'accès, car cette décision deviendrait alors négociable par la conversation. Cette séparation permet aussi d’appliquer les mêmes règles de façon cohérente à tous les assistants et outils branchés sur la même source. 

Ajouter des garde-fous en entrée et en sortie 

Des consignes système, des filtres sur les requêtes et des mécanismes de contrôle des réponses peuvent contribuer à repérer ou à bloquer certaines situations. Ils peuvent notamment limiter des demandes manifestement incompatibles avec l’usage prévu ou empêcher la restitution de certains types d’information. Aucune de ces protections ne suffit seule, et leur articulation compte. Les contrôles déterministes appliquent des règles fixes, indépendantes du jugement du modèle. D’autres protections reposent sur son interprétation, notamment les consignes qu’on lui donne. Toutes complètent le contrôle d’accès en amont.

• Filtrer et normaliser les entrées : Certains traitements rendent les instructions dissimulées plus faciles à repérer : normalisation du texte, détection des caractères visuellement similaires, traitement des caractères invisibles et décodage des contenus en base64 ou en hexadécimal lorsque nécessaire. Des règles de détection peuvent ensuite repérer des mots déformés ou des signaux inhabituels, comme une longueur excessive. Cette couche facilite la détection de certaines attaques, mais des formes de dissimulation non prévues peuvent lui échapper.
• Contrôler les sorties : Un filtre déterministe inspecte la réponse avant qu’elle atteigne l’utilisateur. Selon sa conception, il peut rechercher une donnée précise, certaines versions encodées ou une divulgation caractère par caractère. Repérer une fuite fragmentée peut aussi nécessiter l’analyse de plusieurs échanges. Un modèle gardien peut compléter ces contrôles en recherchant des divulgations implicites ou des paraphrases, au-delà de la présence littérale de l’information.
• Juger l'intention avec un modèle gardien : Un LLM secondaire analyse les requêtes et peut tenir compte de l’historique pour repérer des tentatives étalées sur plusieurs messages. Son réglage demande toutefois de la prudence : trop strict, il risque de refuser des demandes légitimes et de rendre le système difficile à utiliser. 
• Poser des leurres : Dans certains dispositifs, une donnée factice peut être utilisée pour tromper une tentative d’extraction. L’attaquant obtient alors une fausse valeur. Cette tactique ne protège toutefois pas, à elle seule, la donnée réelle et doit être encadrée pour éviter d’induire un utilisateur légitime en erreur. Les leurres peuvent aussi devoir être renouvelés pour ne pas devenir facilement reconnaissables.
• Durcir le prompt système : Ces consignes restent utiles en complément, même si elles ne constituent pas une barrière fiable à elles seules. Elles peuvent établir une hiérarchie explicite des instructions et préciser que de prétendus modes « debug » ou « test » ne permettent pas de la contourner. Elles doivent également distinguer les instructions autorisées des contenus à analyser, notamment les documents et les résultats d’outils. Cette distinction vise à limiter l’injection indirecte, sans garantir qu’elle sera toujours respectée. Les refus devraient rester courts et clairs, sans révéler d’informations sensibles ni de détails qui faciliteraient un contournement. On peut également demander au modèle de ne pas divulguer ses consignes internes, sans faire dépendre la sécurité de leur confidentialité.  L’intérêt de ces couches réside dans leur combinaison. Elles renforcent le contrôle d’accès en amont sans jamais s’y substituer.

Conserver une trace des interactions et repérer les tentatives d’accès non autorisé

Conserver une trace des requêtes et des réponses permet de repérer les tentatives répétées, les comportements inhabituels ou les suites de requêtes qui, prises ensemble, présentent un risque. Beaucoup d'attaques réussies ne tiennent pas dans un seul message, elles se construisent sur plusieurs échanges: une demande peut sembler anodine lorsqu’elle est examinée isolément, alors que l’historique de la conversation révèle une tentative de détournement. Ces informations facilitent également l’analyse d’un incident et l’ajustement des protections. 

Documenter le risque résiduel 

Aucune barrière n’offre une garantie absolue. L’organisation doit donc documenter les données accessibles, les protections en place, les défaillances encore possibles et les conditions dans lesquelles le risque résiduel est accepté. Dans le cadre d’un mandat, cette démarche permet aussi de convenir avec le client de la portée des protections et de leurs limites. L’objectif est de connaître et de gérer le risque pour l’usage prévu, puis de le réévaluer à mesure que le système évolue.  

Comment préserver l’utilité de l’assistant 

Un assistant qui refuse toutes les demandes limite le risque de divulgation, mais ne remplit plus sa fonction. La sécurité ne peut donc pas être évaluée uniquement en comptant les requêtes bloquées. 

Les essais doivent mesurer deux dimensions en parallèle : la résistance aux tentatives d’accès non autorisé et la capacité à répondre correctement aux demandes légitimes. En pratique, des séries de tests d’attaque cherchent à provoquer une divulgation pour évaluer la résistance du système. En complément, des tests sur des demandes légitimes permettent de vérifier la qualité des réponses et de mesurer le taux de refus injustifiés. 

Un garde-fou trop restrictif peut empêcher les utilisateurs autorisés d’obtenir l’information dont ils ont besoin. À l’inverse, un système trop permissif peut sembler utile tout en exposant des données. 

Cette évaluation doit être reprise lorsque le système évolue. L’ajout d’une source, la modification des droits, le remplacement du modèle ou l’ajustement d’un filtre peuvent changer à la fois le niveau de risque et la qualité des réponses. 

Neuf questions à poser avant de déployer un assistant IA 

1. À quelles sources et à quels types de renseignements l’assistant peut-il réellement accéder ? 
2. Tous les utilisateurs disposent-ils des mêmes droits sur ces données ? 
3. Les droits sont-ils contrôlés avant que les données soient transmises au modèle ? 
4. L’assistant reçoit-il uniquement les données nécessaires à sa tâche ? 
5. Des mécanismes filtrent-ils certaines demandes et contrôlent-ils les réponses ? 
6. Si l'assistant est agentique, quelles actions peut-il déclencher, et lesquelles exigent une confirmation humaine ? 
7. Les interactions et les tentatives répétées peuvent-elles être détectées et retracées ? 
8. Quels risques de divulgation subsistent malgré les protections, et sont-ils documentés et acceptés par l’organisation ?
9. Les protections permettent-elles encore à l’assistant de remplir correctement sa fonction ? 

Les réponses permettent d’identifier les vérifications, les tests ou les mesures complémentaires à prévoir avant le déploiement. Elles ne constituent pas, à elles seules, une validation de la sécurité du système. 

Sources

Lenovo, recherche Cybernews 

Air Canada, décision officielle du tribunal sur CanLII 

Chevrolet, AI Incident Database 

Questions fréquentes