Comment un serveur IA domestique maintient-il le contexte de chaque utilisateur séparé ?

Un serveur IA domestique peut garder le contexte de chaque utilisateur séparé tout en partageant le même modèle, mais la séparation ne vient pas du modèle lui-même. Elle vient de l'association de chaque chat, enregistrement de mémoire, document récupéré, entrée de cache et appel d'outil à un utilisateur authentifié avant que ces informations n'atteignent l'invite.

Si deux personnes peuvent se connecter séparément mais que la question d'un utilisateur récupère les notes d'une autre personne, l'échec se trouve généralement dans l'application autour du modèle. Le test utile est de savoir si l'identité survit à tout le chemin de la requête. Cet article suit ce chemin et montre où l'isolation doit être appliquée, où elle échoue couramment, et quand une frontière plus forte est justifiée.

Le modèle peut être partagé, mais pas le contexte personnel

Les poids du modèle sont le moteur de raisonnement commun. Ils n'ont pas besoin d'une copie séparée pour chaque membre de la famille ou collègue lorsque le modèle sert des requêtes d'inférence ordinaires. Ce qui doit rester séparé, c'est l'information assemblée autour de ces poids pour une requête particulière.

Ces informations incluent le chat en cours, l'historique des conversations sauvegardées, les préférences utilisateur, les passages de fichiers récupérés, les résultats de recherche vectorielle, les sorties d'outils, les caches temporaires et les identifiants. Ensemble, ces couches forment le contexte personnel. Un utilisateur différent doit recevoir un paquet de contexte différent même lorsque les deux requêtes passent par le même processus de modèle.

Cette distinction rend l'architecture pratique. Un serveur domestique peut éviter de charger plusieurs copies identiques du modèle tout en isolant les données qui rendent chaque assistant personnel. La frontière d'isolation appartient à l'identité, au stockage, à la récupération, aux sessions et à l'accès aux outils — pas à une invite qui se contente d'indiquer au modèle de respecter la confidentialité.

L'identité doit suivre la requête jusqu'au bout

Des écrans de connexion séparés ne sont que la première étape. L'authentification établit qui fait la demande ; l'autorisation décide à quels chats, fichiers, mémoires et actions cette identité peut accéder. Une isolation efficace nécessite une autorisation après authentification à chaque frontière de données, pas seulement lorsque l'utilisateur ouvre l'interface.

Le serveur doit dériver un identifiant utilisateur stable à partir de la session ou du jeton d'accès vérifié. Il ne doit pas faire confiance à un identifiant utilisateur envoyé dans un champ de formulaire, un paramètre d'URL ou un message de chat. Sinon, modifier une seule valeur contrôlée par le client peut suffire à demander les enregistrements de quelqu'un d'autre.

Cette identité dérivée du serveur devient alors partie intégrante de chaque recherche. Les requêtes de conversation, recherches vectorielles, chemins de fichiers, clés de cache et identifiants d’outils ont tous besoin du même périmètre utilisateur de confiance. Si un service en aval le perd, le système revient silencieusement à un contexte partagé même si l’interface affiche toujours des comptes séparés.

La mémoire durable nécessite une frontière au niveau du stockage

La mémoire à long terme vit généralement dans une base de données relationnelle, un magasin de documents ou des fichiers sur disque. Chaque enregistrement nécessite un propriétaire ou un identifiant de locataire, et chaque lecture, mise à jour et suppression doit être restreinte à cette identité. Filtrer seulement après qu’une requête large a déjà retourné des données est trop tard.

Les politiques de base de données peuvent fournir un second point d’application sous le code de l’application. Lorsque la base de données évalue l’utilisateur actuel avant de retourner des enregistrements, un filtre manqué dans une route d’application a moins de chances de provoquer une divulgation entre utilisateurs.

La mémoire basée sur des fichiers nécessite la même rigueur. Donnez à chaque utilisateur un répertoire dédié, conservez les règles de propriété et de contrôle d’accès intactes, et faites en sorte que l’application résolve les chemins à partir de l’identité authentifiée. Un nom de dossier fourni par le navigateur n’est pas une frontière d’autorisation, et un compte de service partagé avec un accès illimité au système de fichiers peut contourner des répertoires soigneusement organisés.

La récupération doit être limitée avant la construction du prompt

RAG crée l’un des points d’isolation les plus importants car les passages récupérés sont insérés directement dans le contexte de travail du modèle. Une fois qu’un document d’un autre utilisateur atteint le prompt, demander au modèle de ne pas le révéler n’est pas une solution fiable. La couche de récupération doit l’exclure en premier.

Une couche RAG consciente des permissions peut filtrer les résultats de recherche selon les droits d’accès aux documents avant qu’un passage ne soit inséré dans le prompt. La décision d’autorisation doit utiliser la session vérifiée plutôt qu’une identité fournie dans la question.

Une base de données vectorielle peut séparer les enregistrements avec un espace de noms ou une collection par utilisateur, ou avec des filtres de métadonnées obligatoires à l’intérieur d’un index partagé. Les espaces de noms ou collections pour l’isolation facilitent la gestion des écritures, recherches et suppressions, tandis que le filtrage par métadonnées peut permettre un partage contrôlé lorsqu’un foyer ou une équipe possède des documents communs.

L’application doit choisir l’espace de noms à partir de la session vérifiée plutôt que de l’accepter depuis le prompt. La même règle s’applique lorsque la recherche sémantique s’exécute sur des documents privés : le filtrage d’identité appartient au chemin de la requête avant le classement par similarité, pas dans une étape de nettoyage après le retour des résultats.

Les documents partagés nécessitent aussi un modèle explicite. Un enregistrement peut appartenir à un utilisateur, un groupe familial ou un espace de travail, mais cette portée doit être stockée comme données de permission et évaluée de manière cohérente. Copier un document dans plusieurs index personnels peut être plus simple pour un petit système ; les permissions basées sur les groupes deviennent plus faciles à maintenir à mesure que les utilisateurs et les dossiers partagés grandissent.

Les sessions et caches peuvent reconnecter les données par accident

Une base de données peut être parfaitement filtrée alors qu’un cache fuit encore le contexte. Si l’historique de chat est mis en cache sous `conversation_id` seul, deux utilisateurs avec une collision ou un identifiant prévisible peuvent accéder à la même entrée. Des clés plus sûres incluent à la fois l’ID utilisateur de confiance et l’ID de conversation.

La même limite s’applique aux caches de prompt, aux caches de morceaux récupérés, aux répertoires temporaires de téléchargement et aux objets de session en mémoire. Les clés de cache conscientes du locataire réduisent l’exposition croisée des utilisateurs en transportant l’ID utilisateur de confiance à travers les lectures et écritures du cache.

La déconnexion doit supprimer ou invalider l’état approprié. Effacer un cookie de navigateur tout en laissant la session côté serveur, les fichiers temporaires ou le prompt mis en cache disponibles peut exposer le contexte de l’utilisateur précédent sur un ordinateur partagé. L’expiration, la suppression et la suppression de compte doivent se propager à travers chaque stockage contenant des données personnelles.

Les appels d’outil nécessitent la même limite utilisateur

Un assistant peut lire des calendriers, rechercher des e-mails, ouvrir des dossiers NAS ou déclencher des automatisations. Ces outils peuvent révéler plus que la base de données de chat, donc chaque appel doit utiliser les permissions de l’utilisateur demandeur plutôt qu’un seul identifiant administrateur détenu par le service IA.

Pour les fichiers locaux, l’outil doit hériter ou appliquer les accès au système de fichiers de l’utilisateur. Pour les applications connectées, utilisez des jetons à portée utilisateur lorsque l’intégration les prend en charge. Un jeton global peut être pratique lors des tests, mais il transforme l’assistant en un contournement des permissions que les utilisateurs attendent du service d’origine.

La sortie des outils devient aussi un contexte. Stockez-la sous le même utilisateur et la même session que la requête, évitez de placer des secrets dans l’historique de discussion ordinaire et censurez les champs sensibles des journaux. Une couche de récupération sécurisée ne compense pas un outil qui renvoie directement les données d’un autre utilisateur.

Quel modèle d’isolation convient à un serveur IA domestique ?

La bonne frontière dépend de la sensibilité, du nombre d’utilisateurs et de la capacité d’administration du propriétaire du serveur. Le tableau compare les conceptions courantes selon ce qui est partagé et où les erreurs sont les plus probables.

Pour la plupart des foyers, les règles au niveau des lignes, la récupération vectorielle limitée à l’utilisateur, les chemins de fichiers isolés et les permissions d’outils spécifiques à l’utilisateur offrent un compromis pratique. Les conteneurs ou machines séparées deviennent utiles lorsque les utilisateurs ne se font pas confiance, que les outils exécutent du code arbitraire ou que les conséquences d’une erreur sont exceptionnellement graves.

Pourquoi les comptes séparés fuient encore le contexte

La première erreur est d'appliquer les permissions uniquement dans l'interface. Cacher les conversations d’un autre utilisateur dans une barre latérale ne sert à rien si l’API les renvoie lorsqu’on fournit un ID différent. Chaque point de terminaison serveur doit répéter la décision d’autorisation.

La deuxième erreur consiste à filtrer l'historique des discussions mais pas la récupération. L'assistant affiche la bonne conversation tout en recherchant dans un index vectoriel partagé sans filtre utilisateur. La réponse contient alors des détails privés qui n'apparaissaient jamais dans le fil visible.

La troisième erreur est le partage des données opérationnelles. Les journaux de débogage, traces, caches d'invites, téléchargements temporaires et analyses peuvent contenir le même contexte sensible que la réponse finale. Le contexte d'exécution peut exposer des informations sensibles même lorsque le modèle de base n'a jamais été entraîné dessus.

La dernière erreur est de faire confiance au modèle comme couche de contrôle d'accès. Une invite système peut décrire les attentes en matière de confidentialité, mais elle ne peut pas annuler de manière fiable un contexte qui n'aurait jamais dû être récupéré. Les contrôles de sécurité doivent décider de ce qui atteint le modèle ; le modèle ne doit pas décider ce que l'utilisateur était autorisé à récupérer.

Comment tester si l'isolation des utilisateurs fonctionne vraiment

Créez deux comptes ordinaires avec des données de test délibérément différentes. Donnez à l'utilisateur A un document contenant une phrase unique inoffensive et à l'utilisateur B une phrase différente. Aucune des deux phrases ne doit apparaître ailleurs dans le corpus de test.

Depuis l'utilisateur B, essayez des questions directes, des recherches sémantiques vagues, des ID de conversation devinés, des liens partagés, des fichiers renommés et des requêtes demandant à l'assistant d'ignorer ses règles. L'objectif n'est pas seulement de tester l'interface normale ; c'est de vérifier que chaque route ne renvoie aucune donnée en dehors de la portée de l'utilisateur B.

Répétez le test après la déconnexion, le redémarrage du service, le préchauffage du cache, la réindexation des documents, la restauration de la sauvegarde et la suppression du compte. Ces transitions utilisent souvent des chemins de code différents du chat ordinaire et peuvent réintroduire un contexte obsolète que le chemin de requête principal gère correctement.

Examinez les journaux du serveur avec les mêmes deux identités. Chaque récupération, lecture de fichier, écriture en mémoire et appel d'outil doit porter la portée utilisateur attendue sans enregistrer inutilement le contenu privé des invites. Un administrateur doit pouvoir expliquer pourquoi chaque élément de contexte est entré dans l'invite finale.

Une conception pratique d'isolation pour un usage domestique

Commencez par garder l'exécution du modèle et les données localement, puis utilisez un service d'identité unique et un ID utilisateur fiable que le serveur dérive de la session. Transmettez cette identité à travers le service de chat, le stockage mémoire, la recherche vectorielle, la passerelle de fichiers et la couche d'outils. Rejetez les requêtes lorsque l'identité ou la portée des permissions est manquante au lieu de revenir à une valeur par défaut partagée.

Gardez le modèle partagé sauf si une menace spécifique nécessite des environnements d'exécution séparés. La pile environnante de stockage, récupération, inférence, interface et permissions est ce qui transforme les fichiers locaux en un assistant privé fondé sur des données locales. Dupliquer les poids du modèle ne répare pas une requête de base de données non limitée.

Utilisez un identifiant utilisateur ou espace de travail sur les enregistrements durables, appliquez l'accès aux lignes en dessous de l'application lorsque c'est possible, et placez les données vectorielles dans des espaces de noms à périmètre utilisateur ou des partitions filtrées obligatoires. Donnez aux fichiers temporaires et caches le même périmètre, puis définissez des règles d'expiration et de suppression pour chaque couche.

Séparez intentionnellement les connaissances personnelles et partagées. Un manuel de foyer peut appartenir à un espace de travail commun, tandis que les dossiers fiscaux restent privés. Dans un serveur IA multi-rôles, l'appartenance à un groupe doit déterminer quel espace de travail partagé rejoint le contexte personnel de l'utilisateur pour cette requête.

Choisissez une frontière plus forte lorsque la menace évolue. Si les utilisateurs peuvent exécuter du code, installer des plugins, monter des dossiers arbitraires ou connecter des outils puissants, les filtres d'application seuls peuvent ne pas suffire. Des conteneurs séparés, des machines virtuelles, des identifiants et du stockage peuvent limiter ce qu'un service compromis peut atteindre.

FAQ

Chaque utilisateur a-t-il besoin d'une copie séparée du modèle IA ?

Non. Plusieurs utilisateurs peuvent partager un même modèle d'inférence car le contexte personnel peut être assemblé séparément pour chaque requête. Des processus de modèle séparés peuvent néanmoins être utiles pour des utilisateurs non fiables, des adaptateurs personnalisés, des limites strictes de ressources ou des charges de travail nécessitant une frontière opérationnelle plus forte.

Un historique de chat séparé suffit-il à protéger le contexte personnel ?

Non. L'historique de chat n'est qu'une source de contexte. Les documents récupérés, les index vectoriels, les fichiers téléchargés, les caches, les identifiants d'outils, les journaux et les données temporaires doivent respecter la même frontière d'identité. Une couche non limitée peut exposer des informations même lorsque la liste visible des conversations est correcte.

Les membres de la famille peuvent-ils partager intentionnellement un certain contexte ?

Oui. Placez les documents et souvenirs partagés dans un périmètre explicite de foyer ou d'espace de travail, puis accordez l'accès aux utilisateurs qui en ont besoin. Gardez les dossiers personnels sous propriété individuelle. Le générateur de prompt peut combiner le périmètre privé de l'utilisateur actuel avec les périmètres partagés autorisés sans ouvrir aucun des deux à tout le monde.

La règle pratique est simple : partagez le modèle, pas le chemin de contexte. L'identité doit restreindre les données avant qu'elles ne soient lues, récupérées, mises en cache ou transmises à un outil. Si chaque couche peut répondre à la question de savoir quel utilisateur a autorisé un élément, un serveur IA domestique peut rester personnel même si son calcul est partagé.