Comment Datarelix garde les identifiants hors du modèle IA

Datarelix garde les identifiants de base de données hors du modèle IA. Les identifiants de connexion ne sont jamais placés dans le contexte du modèle : ils sont déchiffrés au moment de l’exécution uniquement, par un service de requêtes isolé. Le modèle reçoit votre question et la structure de votre schéma, et renvoie un plan structuré. Il n’exécute rien. Les identifiants sont chiffrés au repos et conservés par une couche d’exécution distincte. Un prompt ne peut pas extraire un secret qui n’y a jamais figuré.

À qui s’adresse cette réponse

Les ingénieurs sécurité et les équipes plateforme qui évaluent un fournisseur d’analytique conversationnelle avant de laisser la moindre base de données s’en approcher. Les administrateurs de bases de données à qui l’on demande de provisionner une connexion et qui doivent décider quoi accorder. Toute personne qui a lu « l’IA se connecte à votre base de données » sur une page produit et veut savoir précisément quel composant détient le mot de passe — parce que ce seul fait détermine la forme du modèle de menace.

Deux façons de relier un modèle IA à une base de données

La conception naïve place le modèle dans la boucle : il détient une chaîne de connexion dans son contexte, ou il peut appeler directement une fonction « exécute cette requête ». Dans cette conception, les identifiants font partie du monde du modèle, et chaque défense contre une instruction trompeuse — dans un prompt, dans un document, jusque dans la description d’une colonne — porte alors tout le poids, parce qu’un modèle que son entrée peut orienter peut être orienté vers la divulgation ou le détournement de ce qu’il détient.

La conception retenue par Datarelix sépare la proposition de l’exécution. Le modèle ne produit qu’un plan structuré ; il n’exécute rien lui-même. La couche d’exécution valide ce plan avant d’exécuter la moindre étape, lance chaque étape elle-même et enregistre ce qui s’est passé. Dans cette conception, les identifiants vivent entièrement du côté exécution de la ligne. C’est cette même séparation qui applique l’accès en lecture seule — l’argumentaire de cette moitié de la frontière se trouve dans analyse de données par IA en lecture seule. Ce guide traite la moitié consacrée aux identifiants.

Le flux de données, étape par étape

Vous posez une question en langage naturel. Le service assemble le contexte du modèle : votre question, la conversation en cours et la structure du schéma connecté — noms de tables et de colonnes, types, clés et les descriptions que vous avez rédigées. La structure seulement : aucune valeur d’exemple, aucune ligne et aucun détail de connexion, quel qu’il soit.
Le modèle renvoie un plan structuré. Le plan décrit les étapes à suivre, y compris la requête à exécuter. Le modèle lui-même n’exécute rien — il ne détient aucune connexion, aucun identifiant et aucune fonction qui atteigne votre base de données.
La couche d’exécution valide le plan. Le plan est vérifié par rapport à un schéma strict avant que quoi que ce soit ne s’exécute, et chaque instruction générée est analysée en arbre syntaxique complet et rejetée si ce n’est pas une lecture — comment fonctionne le validateur. Des limites de lignes automatiques s’appliquent à chaque requête.
Un service de requêtes isolé exécute la requête. Ce service est le seul composant qui détient la connexion à la base de données. Les identifiants sont déchiffrés à ce moment précis, servent à exécuter la requête validée, et le résultat est capturé. Le modèle ne joue aucun rôle dans cette étape.
La réponse vous revient, avec ses preuves. Chaque réponse est accompagnée de la requête exécutée, des tables sources, du nombre de lignes et du temps d’exécution — ce que chacun des quatre vous apprend. Les tables de résultats ne repartent pas vers le modèle. L’exécution complète est enregistrée étape par étape et réouvrable depuis l’historique, ce qui rend praticable l’habitude de vérification décrite dans comment vérifier les réponses d’une IA sur vos données.

L’IA voit-elle mes données ? Ce que le modèle reçoit

Le modèle reçoit	Le modèle ne reçoit jamais
Votre question, telle que vous l’avez saisie	Les identifiants de connexion : mots de passe, jetons, clés
La structure du schéma : noms de tables et de colonnes, types, clés et descriptions rédigées — la structure seulement, aucune valeur d’exemple	Les noms d’hôtes, les ports ou tout autre détail de connexion
Le contexte de la conversation en cours	Les tables de résultats brutes de vos requêtes
Une valeur de réponse sur une seule ligne, reprise dans le contexte des questions suivantes (voir ci-dessous)	Des copies de vos tables — vos données ne sont jamais répliquées dans le contexte du modèle

Une nuance, dite simplement. Une exception : une valeur de réponse sur une seule ligne peut être reprise dans le contexte des questions suivantes, pour qu’un « et par rapport à l’an dernier ? » ait du sens. Les questions, la structure du schéma et les valeurs de réponse uniques circulent vers le modèle ; les identifiants et les tables de résultats, non.

Où vivent réellement les secrets

Quand vous créez une connexion, les identifiants sont chiffrés au repos — un chiffrement applicatif par-dessus un stockage lui-même chiffré — et conservés du côté exécution de la frontière. Ils sont déchiffrés au moment de l’exécution uniquement, à l’intérieur du service de requêtes isolé, et pour cette seule exécution.

Vous pouvez remplacer des identifiants à tout moment : renouvelez le mot de passe ou le jeton côté base de données au rythme que suit votre équipe, puis mettez à jour la connexion avec le nouveau secret. Datarelix ne renouvelle pas vos identifiants à votre place.

Les connexions restent privées au compte qui les a créées

Les connexions, tableaux de bord et exécutions sont strictement rattachés à leur propriétaire. Une connexion que vous créez ne peut être ni vue ni utilisée depuis un autre compte, pas plus que les exécutions ou les tableaux de bord qui reposent dessus. Aucun mécanisme ne déplace des identifiants — ni quoi que ce soit qui en dérive — au-delà de la frontière d’un compte.

Quand une requête échoue

Les schémas réels produisent de vraies erreurs : une colonne mal orthographiée, un type qui ne correspond pas, une particularité de dialecte. Quand une requête échoue, le message d’erreur de la base repart vers le modèle, qui révise la requête et relance : une reprise automatique, dans des limites strictes, chaque tentative passant par la même validation en lecture seule que la première. L’échec ne change rien à la frontière des identifiants. Une reprise est un nouveau plan soumis à la même couche d’exécution et à la même validation : le modèle voit le texte de l’erreur, jamais la connexion qui l’a produit.

Votre côté de la frontière : accordez des identifiants restreints, en lecture seule

Datarelix lit ce que les identifiants connectés peuvent lire, et rien de plus. La validation en lecture seule et les limites de lignes automatiques s’appliquent quoi que vous accordiez — mais des identifiants restreints transforment une couche de protection en deux. Connectez-vous avec un utilisateur de base de données qui ne peut lire que les schémas sur lesquels vous voulez poser des questions.

Sur PostgreSQL, sur le schéma de démonstration d’un distributeur fictif, cette autorisation ressemble à ceci (à titre d’illustration, non relevé sur un système réel) :

CREATE ROLE datarelix_reader LOGIN PASSWORD '<generated-secret>';
GRANT USAGE ON SCHEMA demo_retail TO datarelix_reader;
GRANT SELECT ON demo_retail.customers,
               demo_retail.orders,
               demo_retail.order_items
TO datarelix_reader;

Cet utilisateur peut lire trois tables et rien d’autre — aucune écriture, aucun DDL, aucune visibilité sur les autres schémas. Sur Azure SQL, Databricks et Kusto, les arrangements Enterprise peuvent aller plus loin : une connexion peut s’exécuter avec les permissions de base de données de la personne connectée (On-Behalf-Of par utilisateur), de sorte que ce que chacun peut demander reste borné par ce que son propre compte peut déjà lire. Les étapes de configuration par moteur, dont le motif d’utilisateur en lecture seule pour chaque moteur pris en charge, se trouvent dans les guides de connexion.

Ce que cette frontière ne couvre pas

La frontière couvre les identifiants et les tables de résultats, pas la question elle-même. Vos questions, la structure de votre schéma et les valeurs de réponse uniques sont traitées par le modèle IA qui alimente le service ; nous gérons le fournisseur, les clés et la configuration, et la politique de confidentialité documente les fournisseurs qui interviennent dans l’exploitation du service. Si votre exigence est qu’aucun modèle externe ne traite ne serait-ce que des noms de tables et de colonnes, un service hébergé conçu ainsi n’est pas le bon outil.

Les noms de colonnes et les descriptions rédigées encodent parfois du savoir interne : écrivez-les en sachant que le modèle les lit. La frontière des identifiants ne compense pas non plus des droits trop larges : des identifiants capables de lire tous les schémas rendent tous les schémas interrogeables, alors restreignez-les comme ci-dessus.

Les comptes sont isolés : les connexions, tableaux de bord et exécutions sont strictement rattachés à leur propriétaire (isolation des comptes). En pratique, chacun se connecte avec ses propres identifiants, ou avec ses propres permissions via On-Behalf-Of sur les moteurs qui le prennent en charge. Transmettre une analyse à un collègue passe par un export.

Notes et provenance

Les affirmations produit décrivent Datarelix tel que livré en août 2026 ; la page sécurité fait foi. L’exemple SQL utilise le schéma de démonstration d’un distributeur fictif et vaut à titre d’illustration. Le cadrage en deux conceptions est le nôtre, et aucune citation externe n’est utilisée.

Envoyer un questionnaire de sécurité

Si vous évaluez Datarelix dans le cadre d’une revue de sécurité, envoyez vos questionnaires et vos demandes sur l’état de conformité via la page contact. La liste de contrôle de sécurité, indépendante de tout fournisseur énumère les éléments qu’il vaut la peine de demander à n’importe quel fournisseur de cette catégorie.