Quand la base de données est la frontière de sécurité : attaquer les agents de données LLM

De quoi s’agit-il ?

Un agent de données est le motif qui se cache derrière la plupart des produits « discutez avec votre entrepôt » : un LLM lit une question en langage naturel, écrit du SQL ou appelle des outils analytiques sur une base de données en production, récupère les lignes, raisonne dessus et renvoie une réponse — souvent en plusieurs étapes et avec des identifiants permanents sur les données sous-jacentes. Il se situe à l’intersection de deux traditions de sécurité qui se parlent rarement. La sécurité des bases de données suppose une surface de requêtes fixe et auditable ; la sécurité des agents LLM suppose que le danger est dans le prompt. Un agent de données casse les deux hypothèses, car la surface de requêtes est désormais générée à la volée par un modèle lui-même orientable.

Une étude publiée sur arXiv le 8 juin 2026 par des chercheurs de la Nanyang Technological University, de The Hong Kong Polytechnic University et de l’université Tsinghua — « Data Agents Under Attack » — est, à notre connaissance, la première à traiter cette intersection comme une surface d’attaque à part entière plutôt que comme un cas particulier de l’un ou l’autre domaine. Elle cartographie les points de défaillance, construit une taxonomie des façons de les provoquer et en mesure le résultat sur des systèmes réels.

Comment ça marche

La contribution du papier est triple, et rien ne nécessite un exploit fonctionnel pour être compris.

D’abord, un cadre de vulnérabilités en couches identifie huit risques propres aux agents de données, répartis sur trois couches : l’interprétation (comment le modèle transforme une requête en plan d’exécution), l’exécution (comment ce plan tourne contre la base et les outils) et la politique (ce que l’agent a le droit de voir et de faire). L’intérêt de ce découpage est qu’une défaillance à la couche d’interprétation — une demande discrètement reformulée en requête plus large — produit une action de base de données parfaitement valide aux yeux de tout contrôle classique surveillant la couche d’exécution.

Ensuite, une taxonomie d’attaques organisée par objectif, tactique et technique — trois objectifs, sept tactiques et quatorze techniques — associée à un pipeline de génération de charges qui ancre chaque attaque dans un schéma de base de données réel plutôt que dans un exemple jouet. Cet ancrage au schéma compte, car c’est ce qui fait passer une attaque du papier au déploiement : la même tactique formulée contre les vraies tables de la cible a bien plus de chances d’aboutir.

Enfin, une évaluation sur six systèmes : quatre agents de données open source et deux services d’analytique cloud en production. Les auteurs rapportent des vulnérabilités substantielles sur l’ensemble. Nous ne reproduisons volontairement aucune charge et ne précisons pas quelle technique a fonctionné contre quel produit ; le signal utile pour les défenseurs est que la défaillance était large, pas qu’un éditeur en particulier était plus faible que les autres.

Pourquoi c’est important

Le résultat porteur est négatif : ni les mécanismes de sûreté existants des LLM ni les contrôles classiques de sécurité des bases de données ne suffisent à eux seuls. Un garde-fou entraîné à refuser du texte nuisible ne voit pas une requête bien formée qui exfiltre une colonne qu’elle n’aurait jamais dû toucher. Une liste de contrôle d’accès qui applique fidèlement les permissions de tables ne sait pas que l’agent a été amené à joindre deux tables auxquelles il a un accès légitime pour reconstituer quelque chose qu’aucune ne devait révéler. Chaque contrôle est correct isolément et aveugle au modèle de menace de l’autre.

Cet écart n’est pas théorique. Les assistants d’analytique d’entreprise, les copilotes de reporting embarqués et les outils internes « interrogez vos données » sont livrés sur exactement cette architecture, en général avec un compte de service dont les permissions sont cadrées sur la source de données, et non sur la demande individuelle. La réserve honnête est qu’il s’agit d’une évaluation de recherche, pas d’un incident constaté en conditions réelles ni d’un avis de sécurité attribué ; ses chiffres décrivent six systèmes choisis par les auteurs, pas l’ensemble du marché. Mais l’affirmation structurelle — la base de données doit être traitée comme un participant actif de la sécurité, non comme un simple magasin passif — tient quels que soient les six systèmes testés.

Défenses

La prescription du papier est un bon point de départ : traiter la base de données comme une frontière de sécurité active et coordonner trois contrôles sur tout le flux plutôt que d’en greffer un à la fin. Le contrôle d’exécution tenant compte des ressources signifie que les requêtes et appels d’outils de l’agent sont limités à ce dont la tâche courante a besoin, et non aux permissions permanentes de son compte de service — cadrez l’accès par requête, pas par connexion. Le contrôle de divulgation compositionnel signifie raisonner sur ce qu’une séquence d’étapes individuellement autorisées peut assembler, car les fuites viennent ici de jointures anodines et de requêtes de suivi, pas d’un unique appel interdit. La gestion des preuves tenant compte de la provenance signifie tracer d’où vient chaque ligne et chaque résultat intermédiaire, afin qu’une décision de divulgation repose sur l’origine de la donnée, pas seulement sur sa forme finale.

Concrètement, cela se traduit par des comptes de service à moindre privilège cadrés par tâche, une couche d’approbation ou de réécriture des requêtes entre le modèle et la base, des politiques au niveau des lignes et des colonnes appliquées sous l’agent plutôt que confiées à lui, et la journalisation du SQL généré et des arguments d’outils comme télémétrie de sécurité de premier plan. Et comme chacun des contrôles parents manque les défaillances de l’autre, éprouvez un agent de données de bout en bout — de la demande ambiguë en langage naturel jusqu’à la requête générée puis aux lignes renvoyées — au lieu de tester séparément le filtre de prompt et la liste de contrôle d’accès de la base.

Statut

Il s’agit d’une évaluation de recherche à destination des pairs, non d’une vulnérabilité produit avec identifiant attribué.

Élément	Détail
Source	« Data Agents Under Attack: Vulnerabilities in LLM-Driven Analytical Systems » (arXiv:2606.08661)
Affiliation	Nanyang Technological University ; The Hong Kong Polytechnic University ; université Tsinghua
Publication	8 juin 2026
Type	Cadre de vulnérabilités + taxonomie d’attaques + évaluation
Taxonomie	8 risques en couches (interprétation / exécution / politique) ; 3 objectifs, 7 tactiques, 14 techniques
Évalué	6 systèmes (4 agents de données open source, 2 services d’analytique cloud en production)
Constat principal	Ni la sûreté des LLM ni les contrôles classiques de base de données ne suffisent seuls

La source principale date des 60 derniers jours. La leçon durable est architecturale : quand un modèle écrit les requêtes, la base de données cesse d’être un magasin passif et devient un point de contrôle qu’il faut défendre selon ses propres règles.