La plateforme d’IA de support client d’une entreprise avait été configurée avec des paramètres de conservation nulle : les conversations des clients étaient traitées par l’infrastructure d’inférence LLM du fournisseur et aucune donnée de conversation n’était conservée à la fin de chaque session. L’entreprise avait vérifié cette configuration à l’aide du DPA du fournisseur et des paramètres de la console d’administration. Ce que l’entreprise n’avait pas évalué, c’était l’exposition des données en cours de session pendant l’appel d’inférence lui-même. La plateforme d’IA du fournisseur chargeait le contexte client au début de chaque session de support (historique du compte, tickets ouverts, détails de l’abonnement et interactions précédentes) et conservait ce contexte dans la fenêtre de contexte du modèle pendant toute la session. Un chercheur en sécurité qui testait la plateforme a démontré que, dans certaines conditions, des saisies utilisateur soigneusement conçues pouvaient amener le modèle à reproduire un contenu du contexte de la même session qui n’avait pas fait partie de la conversation explicite, plus précisément des détails de compte et un historique de tickets chargés comme contexte système à l’initialisation de la session mais non affichés à l’utilisateur. La configuration de conservation nulle empêchait correctement la persistance des données après la session. Elle n’empêchait pas que les données présentes dans le contexte de la session soient accessibles à une manipulation de prompt en cours de session. La fenêtre de session était la fenêtre d’exposition des données.
Qu’est-ce que la fuite de données à l’inférence de l’IA, au fond ?
La fuite de données à l’inférence de l’IA est l’exposition des données présentes dans l’environnement d’inférence d’un modèle d’IA (la fenêtre de contexte, le prompt système enrichi par la récupération, les sources de données connectées chargées comme contexte et les états de traitement intermédiaires du modèle) à une extraction par des saisies utilisateur, une manipulation de prompt ou des techniques par canal auxiliaire pendant la session d’inférence. Contrairement à la conservation des données après la session, qui fait persister les données une fois la session terminée, la fuite de données à l’inférence se produit pendant la session active et peut être exploitable quelle que soit la configuration de conservation.
Le problème de l’exposition de la fenêtre de contexte est le mécanisme principal. Les assistants d’IA modernes et les applications LLM en contact avec la clientèle chargent un contexte important dans la fenêtre de contexte du modèle à l’initialisation de la session : profils clients, historiques de compte, autorisations, contenu de la base de connaissances et instructions système. Ce contexte sert au modèle à générer des réponses éclairées et personnalisées. Il est aussi présent dans l’environnement de traitement du modèle et potentiellement accessible à des techniques de manipulation de prompt qui amènent le modèle à mentionner ou à reproduire un contenu du contexte sur lequel il n’a pas été explicitement interrogé.
La dimension de l’extraction du prompt système est une surface d’attaque connexe. Les applications d’IA comportent généralement des prompts système, c’est-à-dire des instructions au modèle qui définissent son rôle, ses contraintes et son accès aux ressources connectées. Ces prompts système peuvent contenir des informations de configuration sensibles, des contraintes de sécurité ou des références à des sources de données connectées. Les attaques par injection de prompt qui amènent le modèle à reproduire ou à décrire son prompt système exposent des informations de configuration censées rester opaques pour les utilisateurs finaux. Dans les déploiements d’IA multi-locataires, les prompts système peuvent contenir une configuration propre à un locataire qu’un autre locataire ne devrait pas pouvoir extraire.
Le risque de contamination entre sessions concerne les déploiements d’IA dans lesquels l’historique des conversations est conservé d’une session à l’autre : systèmes de mémoire à long terme, résumés de conversation et fonctionnalités de contexte persistant. Dans ces configurations, des données d’une session peuvent être présentes dans le contexte des sessions suivantes. La contamination entre sessions se produit lorsque des données d’une session antérieure deviennent accessibles dans une session ultérieure par le mécanisme de contexte persistant, ce qui peut exposer des données de la session d’un utilisateur à un autre utilisateur qui interagit avec le système lors d’une session suivante.
Le problème de l’isolation multi-locataire est le risque propre à l’entreprise dans les modèles de déploiement d’IA partagés. Les plateformes d’IA des fournisseurs qui servent plusieurs entreprises clientes sur une infrastructure partagée créent des risques de fuite de données d’inférence entre locataires, en particulier le risque que le contexte chargé pour la session d’un locataire soit accessible aux appels d’inférence d’un autre locataire en raison d’un état de modèle partagé, d’une isolation insuffisante entre les contextes des locataires ou d’une injection de prompt qui franchit les frontières entre locataires. Ces risques entre locataires sont analogues aux défaillances d’isolation des bases de données entre locataires, mais appliqués à la couche d’inférence de l’IA.
Pourquoi c’est important
La fuite de données à l’inférence de l’IA est importante pour la TPRM car la configuration de conservation nulle, bien que nécessaire, ne suffit pas à protéger les données sensibles qui transitent par l’environnement d’inférence de l’IA. Les données clients chargées comme contexte de session, les prompts système et le contenu récupéré de la base de connaissances sont tous présents dans l’environnement d’inférence pendant la session et doivent être protégés au niveau de la couche d’inférence comme au niveau de la couche de conservation.
Là où la plupart des équipes se trompent
L’échec le plus constant consiste à considérer la configuration de conservation nulle comme la réponse complète en matière de protection des données pour les déploiements d’IA, sans évaluer les risques d’exposition en cours de session que les contrôles de conservation ne traitent pas.
- Conservation nulle assimilée à une protection complète des données
- Exposition de la fenêtre de contexte en cours de session non évaluée
- Confidentialité du prompt système non évaluée
- Contamination entre sessions non évaluée dans les déploiements à contexte persistant
- Isolation de l’inférence multi-locataire non évaluée pour les déploiements sur plateforme partagée
À quoi ressemblent les bonnes pratiques
Les programmes matures de protection des données à l’inférence de l’IA traitent à la fois les contrôles de conservation et les contrôles d’exposition en cours de session, en particulier la délimitation de la fenêtre de contexte, les tests de confidentialité du prompt système et la validation de l’isolation multi-locataire, en complément de la configuration standard de la conservation.
- Réduction du périmètre de la fenêtre de contexte : ne charger que le contexte nécessaire à chaque session
- Tests de confidentialité du prompt système : vérification spécifique de la possibilité d’extraire les prompts
- Validation de l’isolation multi-locataire : confirmation de l’isolation des contextes entre locataires
- Tests d’injection de prompt en cours de session : tests d’extraction de contexte par des prompts en cours de session
- Évaluation de la contamination entre sessions : pour les déploiements à contexte persistant
Outils
Tests de sécurité des LLM : Garak, PromptBench pour les tests d’extraction en cours de session
Les outils de test de sécurité des LLM qui testent spécifiquement l’extraction de contexte et la divulgation du prompt système fournissent l’évaluation de sécurité en cours de session que les audits de conservation ne couvrent pas. Pour les praticiens de la TPRM, demander si le fournisseur a mené des tests d’injection de prompt en cours de session ciblant spécifiquement l’extraction de la fenêtre de contexte constitue une question de sécurité précise sur la phase d’inférence.
Enjeux de gouvernance
Le défi de gouvernance posé par la fuite de données à l’inférence de l’IA est le manque de visibilité pendant l’inférence : l’entreprise ne peut pas observer directement quelles données sont présentes dans la fenêtre de contexte du modèle pendant l’inférence. La solution de gouvernance passe par la transparence du fournisseur sur ses pratiques de chargement du contexte et par des tests de sécurité indépendants en cours de session qui valident l’isolation entre les couches de contexte.
- Demander quelles données sont chargées dans la fenêtre de contexte à l’initialisation de la session
- Demander les résultats des tests d’injection de prompt en cours de session visant l’extraction de contexte
- Interroger sur l’isolation de l’inférence multi-locataire sur une infrastructure partagée
- Évaluer la confidentialité du prompt système : les utilisateurs peuvent-ils extraire les prompts ?
- Évaluer les contrôles de contamination entre sessions pour les déploiements à contexte persistant
Si vous êtes une petite équipe
Pour toute plateforme d’IA d’un fournisseur dans laquelle des données clients sensibles sont chargées comme contexte de session, posez une question à laquelle l’évaluation de la conservation nulle ne répond pas : quelles données clients sont chargées dans la fenêtre de contexte du modèle à l’initialisation de la session, et la plateforme a-t-elle été testée spécifiquement pour confirmer qu’une manipulation de prompt en cours de session ne peut pas amener le modèle à reproduire un contenu du contexte qui ne faisait pas explicitement partie de la conversation visible par l’utilisateur ? Cette question révèle si l’exposition pendant l’inférence a été évaluée en plus de la conservation après la session.
- Demander quelles données clients sont chargées dans la fenêtre de contexte au début de la session
- Demander si des tests d’injection de prompt en cours de session visant l’extraction de contexte ont été menés
- Interroger sur l’isolation de l’inférence multi-locataire sur une infrastructure partagée
- Interroger sur les tests de confidentialité du prompt système
Ce qu’il faut exiger
Demandez directement :
« Quelles données clients sont chargées dans la fenêtre de contexte du modèle à l’initialisation de la session, et votre plateforme a-t-elle été testée spécifiquement pour confirmer qu’une manipulation de prompt en cours de session ne peut pas reproduire un contenu du contexte qui ne faisait pas partie de la conversation explicite avec l’utilisateur ? »
Preuves attendues
- Description du contenu de la fenêtre de contexte : ce qui est chargé au début de la session
- Résultats des tests d’injection de prompt en cours de session visant l’extraction de contexte
- Validation de l’isolation de l’inférence multi-locataire
- Résultats des tests de confidentialité du prompt système
Un fournisseur qui confirme une configuration de conservation nulle doit être interrogé sur l’exposition du contexte en cours de session. La conservation nulle traite la persistance après la session. Les tests en cours de session traitent la fenêtre d’exposition pendant la session elle-même. Les deux sont nécessaires.
Comment le prouver
- Documentation du contenu de la fenêtre de contexte
- Dossiers de tests de sécurité en cours de session
- Dossiers de validation de l’isolation multi-locataire
- Évaluation de la confidentialité du prompt système
À retenir
Conservation nulle : configurée. Contexte du compte client dans la fenêtre de contexte : présent pendant toute la session. Manipulation de prompt en cours de session extrayant ce contexte : possible dans certaines conditions. Le contrôle de conservation traitait correctement la persistance après la session. L’exposition pendant l’inférence était un risque différent que l’évaluation de la conservation ne couvrait pas. La conservation nulle est un contrôle nécessaire. Elle n’est pas suffisante lorsque les données qui ne doivent pas persister sont présentes dans l’environnement d’inférence pendant la session et accessibles à une extraction en cours de session. La réduction du périmètre de la fenêtre de contexte, les tests de confidentialité du prompt système et les tests d’injection en cours de session sont les contrôles qui traitent ce que les contrôles de conservation ne traitent pas.