L'illusion mortelle du Read-Only : comment votre agent SQL pille votre base de données

Tout le monde fait la même erreur. Vous branchez un agent IA sur votre base Postgres, vous lui donnez un accès en "lecture seule" pour éviter qu'il ne détruise la production, et vous dormez sur vos deux oreilles. Réveillez-vous. Le "Read-Only" est une passoire, et DeepSQL vient enfin d'inventer le bouchon.

L'industrie de la tech a un talent fou pour se rassurer avec des concepts périmés. Depuis l'explosion des outils Text-to-SQL comme LangChain SQLDatabaseChain, Vanna AI ou DB-GPT, le manuel du parfait petit architecte IA se résume à une ligne de commande que tout le monde copie-colle sur Stack Overflow : GRANT SELECT ON ALL TABLES IN SCHEMA public TO agent_ia;.

L'idée est simple. Si l'agent ne peut pas faire de UPDATE, de DELETE ou de DROP, la base est en sécurité. Aucun risque qu'un modèle halluciné n'efface la table des commandes ou ne remplace tous les prix par des zéros. C'est vrai. C'est factuel. C'est aussi d'une stupidité abyssale.

Bloquer les écritures empêche le vandalisme. Cela n'empêche absolument pas l'exfiltration. Le verbe le plus dangereux dans une base de données n'est pas DROP. C'est SELECT. Et en donnant un accès global en lecture à un agent conversationnel, vous venez de créer la plus belle fuite de données de l'histoire de votre entreprise.

L'angle mort du compte de service unique

Imaginez votre entreprise. Vous avez des commerciaux, des ingénieurs support, des responsables RH, des comptables. Chacun a des droits d'accès limités à ses propres outils. Le commercial ne voit pas les salaires. Le support ne voit pas les marges fournisseurs. C'est la base absolue de la compartimentation.

Et puis, le directeur technique décide de déployer un agent IA interne pour "démocratiser l'accès aux données". Cet agent utilise un compte de service unique pour se connecter à la base Postgres ou MySQL. Ce compte technique possède les droits de lecture sur l'intégralité des schémas. Il représente l'autorité suprême. Un super-ensemble des droits de tous les employés réunis.

Que se passe-t-il le jour où un stagiaire demande innocemment à l'agent : "Quel est le salaire médian de l'équipe marketing et la liste des primes versées cette année ?"

L'agent obéit. Il est programmé pour plaire. Il génère une requête SELECT parfaitement bien formatée, l'exécute avec son super-compte, et affiche le contenu de la table hr.compensation sur l'écran du stagiaire. Félicitations. Vous venez de violer le secret des affaires, le RGPD et le bon sens en une seule transaction.

La blague continue si le responsable de la sécurité des systèmes d'information (RSSI) décide d'enquêter. Il ouvre les journaux d'audit de PostgreSQL. Que voit-il ? Les logs n'enregistrent que le compte technique deepsql_agent ou langchain_service. Strictement impossible de prouver quel humain a posé la question. L'anonymat est parfait pour le pillage interne.

Autopsie d'un braquage par CTE

Face à ce désastre annoncé, les développeurs de frameworks IA ont paniqué. Ils ont rajouté des filtres naifs. Des garde-fous basés sur des listes de mots interdits ou des expressions régulières grossières. L'approche classique consiste à analyser la clause FROM de la requête générée par le LLM. Si la table s'appelle hr.compensation, la requête bloque.

C'est ignorer la richesse syntaxique du langage SQL. Et c'est là que les ingénieurs de DeepSQL, fondé par Venkat Sakamuri, un ancien de l'équipe moteur de requêtes d'Oracle, viennent siffler la fin de la récréation.

Dans leurs notes de versions d'août 2026, ils documentent les méthodes de contournement réelles observées sur les architectures d'agents en production. La plus belle est sans doute la fuite par Common Table Expression (CTE).

Regardez cette merveille de vice :

WITH leak AS (
  SELECT employee_id, base_salary, bonus 
  FROM hr.compensation
)
SELECT c.name, l.base_salary, l.bonus
FROM crm.customers c
JOIN leak l ON l.employee_id = c.owner_id;

Le filtre naif regarde la requête principale. Il voit FROM crm.customers. La table des clients est autorisée pour le support. Le filtre valide la requête. Sauf que la charge utile sort par la CTE cachée juste au-dessus. La barrière est contournée avec la facilité d'un enjambement de tourniquet de métro.

Même punition avec les jointures latérales (LATERAL JOIN), les sous-requêtes scalaires ou les branches UNION ALL. Le SQL est un langage Turing-complet. Tenter de le sécuriser avec des expressions régulières relève de la psychiatrie. Les attaquants ou même les utilisateurs maladroits trouveront toujours un chemin syntaxique pour aller chercher la donnée.

L'empoisonnement par le contexte de schéma

L'autre pratique suicidaire consiste à injecter la structure complète de la base de données dans le prompt système du LLM. On prend les métadonnées de 500 tables, on les balance au modèle au démarrage de la conversation, et on lui demande de se débrouiller avec ça.

Le problème est double. D'abord, le modèle prend connaissance de l'architecture intime de l'entreprise. Il voit les tables nommées projet_fusion_acquisition_2027 ou audit_fraude_fiscale_interne. Même si un outil externe parvient à bloquer l'exécution finale de la requête SQL, le mal est fait. Le LLM a l'information dans son contexte. Il va la recracher dans une banale conversation textuelle, sans jamais générer une seule ligne de code SQL. Le secret est éventé avant même d'avoir touché la base.