Un client ouvre une session de chat avec le support et demande : « Pouvez-vous m’expliquer pourquoi la facture INV-1042 a été marquée comme étant en retard de paiement ? » L’assistant de support répond avec assurance en citant une note interne appartenant à une autre entreprise, incluant une mention du type : « Conformément aux conditions de renouvellement d’ACME, annuler les frais pour les paiements à 60 jours (net-60). » L’interface de support n’avait jamais affiché de tickets liés à ACME, ni à l’agent ni au client, et pourtant l’assistant a intégré cette note dans sa réponse. Rien d’inhabituel ne s’est produit ici : il a suffi au client de poser une question ordinaire via le canal habituel pour que l’application génère ce résultat.
La structure du système à l’origine de cette fuite est suffisamment simple pour être appréhendée mentalement. Un utilisateur final envoie un message à l’application de support ; celle-ci récupère les enregistrements pertinents dans une base de données, élabore une invite (prompt) combinant le message de l’utilisateur et les données extraites, puis transmet cette invite à un fournisseur de modèle. Le modèle renvoie du texte, que l’application affiche ensuite comme réponse de l’assistant. L’anomalie se manifeste par une citation de données appartenant à un autre client (fuite inter-locataire ou cross-tenant). L’application a transmis les données privées d’un client à l’utilisateur d’un autre client.
Nous ne pouvons corriger la fuite qu’une fois identifiée la frontière exacte où des données non fiables basculent vers une action considérée comme fiable. Une frontière de confiance est la zone de démarcation où les données provenant d’un côté ne doivent pas hériter automatiquement des privilèges de l’autre, car les deux parties ont des objectifs et des niveaux d’accès différents. Dans notre assistant de support, l’utilisateur final se trouve d’un côté et le mécanisme d’accès aux données de l’application de l’autre ; toutefois, cette frontière se retrouve à chaque étape susceptible de modifier les données lues ou divulguées.
Tout au long du cheminement de la requête, nous considérons quatre éléments comme non fiables, car chacun peut contenir des instructions ou du contenu dont l’application n’est pas l’auteur. Le message de l’utilisateur final n’est pas fiable car il est contrôlé par l’utilisateur. Les enregistrements de la base de données ne sont pas fiables car la base peut renvoyer des lignes inattendues en cas d’erreur de requête ou de filtre, et parce que le texte récupéré peut contenir des éléments ressemblant à des instructions qui n’ont pas leur place dans une réponse. La sortie du modèle n’est pas fiable car le modèle suit le texte reçu et peut suggérer des opérations de lecture, d’écriture ou de divulgation non prévues par l’application. Seule la configuration propre à l’application — comme une liste blanche statique de noms d’outils ou une liste codée en dur des colonnes à sélectionner — est considérée comme fiable au départ ; encore faut-il que cette configuration soit chargée depuis une source contrôlée pour conserver ce statut. Le diagramme de limites de confiance ci-dessous identifie chaque étape du transfert ainsi que les données qui y transitent. Repérons le point d’entrée de chaque donnée non fiable dans le flux :