Agent IA multi-tenant : isoler les données de chaque client

Pourquoi l'isolation est-elle plus difficile avec un agent IA ?

Parce qu'un agent ajoute au logiciel classique un composant qui décide lui-même quoi appeler, avec quels arguments, à partir de texte non fiable. Dans une application SaaS ordinaire, le code applique un filtre tenant_id à chaque requête. Dans un agent, c'est le modèle qui construit la requête, et il peut être influencé par un message, un document ou un résultat d'outil.

Le risque est documenté par l'OWASP. LLM02:2025 (Sensitive Information Disclosure) recommande le moindre privilège et la limitation de l'accès du modèle aux sources externes. LLM08:2025 (Vector and Embedding Weaknesses) décrit les fuites entre contextes dans les bases partagées entre plusieurs clients. LLM06:2025 (Excessive Agency) demande d'exécuter les extensions dans le contexte de l'utilisateur, avec les droits les plus étroits possible.

Pour un panorama du côté applicatif classique, notre article sur l'isolation multi-tenant d'un SIRH détaille les défauts historiques. Ici, nous nous concentrons sur ce que l'agent change.

Où les données d'un client peuvent-elles fuiter vers un autre ?

Elles fuient par quatre surfaces : les outils, la mémoire, le RAG et le contexte partagé. Chacune a son propre mode de défaillance.

Comment isoler les appels d'outils ?

Le client ne doit jamais être un paramètre de l'outil que le modèle peut choisir. C'est la règle la plus importante, et la plus souvent enfreinte.

Un outil get_invoice(customer_id, invoice_id) expose une référence directe à un objet : si le modèle fournit customer_id, une injection de prompt suffit à lire les factures d'un autre client. La version sûre est get_invoice(invoice_id). L'identité du client est ajoutée par la couche serveur à partir de la session authentifiée, puis transmise au service aval, qui revérifie l'appartenance.

Concrètement :

• Injecter l'identité côté serveur. Le jeton ou le contexte de requête porte le client. Le schéma de l'outil exposé au modèle ne contient pas ce champ.
• Appliquer la médiation complète. L'OWASP demande d'implémenter l'autorisation dans les systèmes aval plutôt que de laisser le LLM décider si une action est permise. Chaque service revérifie le client à chaque appel.
• Utiliser des identifiants dans le contexte de l'utilisateur. Un jeton OAuth au périmètre étroit par client vaut mieux qu'un compte de service unique qui voit tout.
• Préférer des outils étroits. Un outil « exécuter du SQL » ou « appeler n'importe quelle URL » contourne tout filtrage. Remplacez-le par des fonctions précises.
• Valider les identifiants renvoyés. Si l'outil renvoie un objet dont le propriétaire ne correspond pas au client de la session, rejetez-le côté serveur.

Notre article sur le function calling décrit pourquoi les arguments sont la surface d'attaque principale.

Comment isoler la mémoire de l'agent ?

Par une clé de partition qui commence par le client, puis l'utilisateur, puis la session. Une mémoire longue, c'est une base de données écrite par le modèle et relue plus tard : traitez-la comme telle.

Les défauts rencontrés :

1. Mémoire globale. Un fait mémorisé pour un client (« le contact comptable est X ») ressort chez un autre.
2. Écriture non fiable. L'agent mémorise un texte issu d'un document tiers. C'est une injection persistante, qui touche toutes les conversations suivantes de ce client.
3. Résumés partagés. Un résumé de conversation généré pour un client est réutilisé comme contexte pour un autre.

Les mesures : partitionner physiquement ou logiquement par client, préfixer chaque clé, empêcher le modèle de choisir la partition, marquer l'origine de chaque souvenir (utilisateur, outil, document) et prévoir l'effacement complet à la fin d'un contrat.

Comment isoler le RAG entre clients ?

Avec un filtre de métadonnées obligatoire appliqué dans la requête vectorielle elle-même, ou avec un index par client quand le niveau de risque le justifie. Filtrer les résultats après la recherche est fragile : les passages interdits ont déjà été classés, comptés et parfois mis en cache.

Trois architectures, de la plus simple à la plus étanche :

Quel que soit le choix :

• Calculez le filtre à partir de la session serveur, jamais d'un champ rempli par le modèle ou par le front.
• Conservez les métadonnées de propriétaire sur chaque passage dès l'ingestion.
• Reproduisez dans l'index les droits des sources : un document restreint à un groupe dans le drive doit l'être aussi dans la base.
• Vérifiez que la suppression d'un document retire ses vecteurs, ses copies de texte et ses entrées de cache.

Les risques d'écriture, notamment l'empoisonnement, sont détaillés dans RAG empoisonné : comment le tester.

Comment tester l'isolation d'un agent multi-tenant ?

Avec au moins deux comptes de test appartenant à deux clients différents, et une série d'attaques de franchissement de frontière. Créez des données marquées dans chaque compte (une chaîne unique par client) afin que toute fuite soit détectable sans ambiguïté.

Les tests à passer, dans l'ordre :

1. Demande directe. Depuis le client A, demander les données du client B par son nom.
2. Substitution d'identifiant. Demander à l'agent d'appeler un outil avec l'identifiant du client B.
3. Injection par document. Déposer chez A un document qui ordonne de lire et de renvoyer des données d'un autre client.
4. Persistance. Faire mémoriser une consigne chez A, puis vérifier qu'elle n'apparaît nulle part chez B.
5. Cache et journaux. Rejouer des requêtes identiques et vérifier qu'aucune réponse ou trace ne traverse les clients.
6. Énumération. Tester des identifiants séquentiels ou prévisibles dans les outils et les URL de sources.

Comptez les fuites, mais surtout notez le chemin : une fuite par l'outil, par la mémoire et par le RAG appelle trois correctifs différents. Par principe, nous ne lisons que ce qui est nécessaire pour prouver l'accès : une chaîne canari suffit, et nous ne téléchargeons aucune donnée personnelle réelle.

Que faut-il retenir pour concevoir l'architecture ?

Que le modèle n'est jamais la frontière de sécurité. Il peut aider à formuler des requêtes, mais les contrôles d'appartenance se font ailleurs, avec l'identité authentifiée.

Une liste de vérification courte :

• Aucun paramètre tenant, customer ou account dans les schémas d'outils exposés au modèle.
• Un contexte d'identité transmis aux services aval, qui revérifient.
• Une mémoire partitionnée par client, avec provenance.
• Un filtre de RAG appliqué dans la requête, calculé côté serveur.
• Des journaux qui permettent de retrouver quel client a vu quel passage. Voir journaliser les actions d'un agent.
• Des tests automatisés de non-régression entre deux clients de test.

Pour le cadre global, consultez notre page sécurité des agents IA.

Comment CleanIssue audite l'isolation multi-tenant ?

Nous rejouons les six tests ci-dessus sur votre agent réel, avec deux locataires de test, et nous remettons des preuves reproductibles. Le Red Team Agent Express à 1 900 € couvre un agent en 5 jours. Si vous exploitez plusieurs agents pour plusieurs clients, le Red Team sur mesure est chiffré sur devis selon le périmètre. Le premier échange est un rendez-vous découverte de 30 minutes, gratuit.