Analytique LLM multi-locataires avec sécurité au niveau des lignes : comment nous avons construit un agent sécurisé sur AWS
PAR Technology Corporation, spécialiste des technologies pour la restauration qui accompagne plus de 300 entreprises du secteur, a développé un agent analytique en langage naturel capable de convertir des questions en SQL pour ses clients. L'objectif affiché : permettre à n'importe quel utilisateur, sans bagage technique, de poser une question en anglais et d'obtenir une réponse chiffrée en quelques secondes. Pour y parvenir, l'équipe a conçu une architecture à trois couches de sécurité déployée sur AWS : signature cryptographique des requêtes via AWS SigV4, validation sémantique sur Amazon Bedrock, et isolation programmatique des données par une technique baptisée Split-Plane SQL. Chaque couche fonctionne de manière indépendante, de sorte que même si le modèle de langage est compromis ou manipulé, l'exposition de données entre clients reste bloquée.
Résumé et traduction réalisés par Le Fil IA à partir de AWS ML Blog. Lire l'article original →
Le problème central est celui de la sécurité au niveau des lignes de données dans un environnement multi-tenant. Deux utilisateurs posant la même question, "Quelles ont été les ventes totales la semaine dernière ?", doivent recevoir des réponses radicalement différentes selon leur périmètre d'accès : 84 000 dollars pour le franchisé exploitant deux restaurants à Chicago, 9,2 millions de dollars pour le directeur de marque supervisant 200 établissements à l'échelle nationale. Afficher le chiffre national au franchisé constitue non seulement une faille de gouvernance des données, mais expose aussi des informations commercialement sensibles sur d'autres opérateurs. L'inverse prive le décideur national d'une vision complète. Ce scénario se répète sur des milliers de requêtes quotidiennes, ce qui rend toute approximation inacceptable.
L'équipe a d'abord envisagé de confier l'application des filtres directement au modèle de langage, en lui fournissant l'identifiant métier de l'utilisateur dans le prompt. Cette approche s'est révélée insuffisante : les LLM sont par nature non déterministes. Un modèle qui applique correctement un filtre dix mille fois d'affilée peut l'omettre silencieusement à la dix millième et unième requête, halluciner une valeur de filtre, ou élargir le périmètre d'une requête suite à un prompt ambigu. Dans une application grand public, cette non-déterminisme est un inconvénient. Dans un système analytique multi-tenant manipulant des données commerciales sensibles, c'est une frontière de sécurité insuffisante sur laquelle il est impossible de bâtir une posture de conformité réglementaire. PAR a donc choisi de dissocier radicalement la génération du SQL par l'IA et l'application des règles d'accès aux données, ces dernières étant imposées par des mécanismes déterministes indépendants du comportement du modèle.
Pas d'impact direct sur la France/UE