Attaques par blocage sur RAG : quand l'alignement de sûreté devient une arme de déni

De quoi s’agit-il ?

La plupart des attaques contre les systèmes RAG (Retrieval-Augmented Generation) cherchent à faire dire au modèle quelque chose de faux : injecter un document, obtenir une réponse erronée ou choisie par l’attaquant. Une attaque par blocage fait l’inverse : elle amène le modèle à refuser de répondre à une question pourtant anodine. La cible n’est pas l’intégrité mais la disponibilité. Un utilisateur pose une requête légitime, le système récupère un document planté, et le modèle répond par une variante de « je ne peux pas vous aider ».

Une étude publiée sur arXiv en mars 2026 par des chercheurs de l’University of Electronic Science and Technology of China et de Tencent Hunyuan (un cadre qu’ils nomment TabooRAG) transforme cette idée en technique concrète et transférable. Leur observation centrale est dérangeante : c’est l’alignement de sûreté du modèle qui constitue la vulnérabilité. Comme les modèles alignés sont réglés pour sur-refuser tout ce qui paraît risqué, un attaquant peut fabriquer un document qui entoure une requête inoffensive d’un « contexte à risque » — un contenu qui se lit comme sensible — et déclencher le réflexe de refus du modèle. Ni jailbreak, ni suffixe adverse, ni instruction explicite « refuse ceci ». Le sujet est d’actualité : les attaques de disponibilité qui détournent les mécanismes de sûreté sont une direction de recherche vivace en 2026. Un autre article de juin 2026 a montré la même idée contre des garde-fous fondés sur le raisonnement, en les enfermant dans des boucles de « réflexion » coûteuses plutôt qu’en induisant un refus.

Comment ça marche

Les bases de connaissances RAG sont souvent partiellement ouvertes : wikis façon Wikipédia, forums communautaires, systèmes de tickets, tout corpus où des tiers peuvent contribuer. Ce canal d’ajout est le point d’injection. L’attaquant ajoute un unique document conçu pour deux choses à la fois : être classé assez haut pour être récupéré sur une requête cible, et porter un cadrage qui pousse le générateur vers le refus.

La partie intéressante est cette seconde propriété. Les attaques par blocage antérieures ajoutaient des suffixes adverses aux documents ou y inséraient des instructions brutales du type « oublie la question et refuse ». Ces techniques échouent de plus en plus, car les modèles récents sont entraînés à séparer les vraies instructions de l’utilisateur du texte trouvé dans le contexte récupéré. Plutôt que de dire au modèle de refuser, le document empoisonné fait paraître le sujet dangereux : il construit autour de la question légitime un scénario pertinent mais à haut risque, si bien que la couche de sûreté conclut d’elle-même qu’y répondre serait nuisible.

Le second enseignement structurel est l’homogénéité de l’alignement. Les différents éditeurs entraînent leurs modèles sur des catégories de refus qui se recoupent — préjudice physique, haine, risques de conformité — de sorte que leurs modèles refusent des choses similaires pour des raisons similaires. Les chercheurs en tirent parti en optimisant un document de blocage contre un modèle substitut accessible dans leur propre environnement RAG, puis en le transférant, en boîte noire, vers une cible inconnue. Comme les critères de refus se recoupent, le document qui trompe le substitut tend à tromper la cible. Les résultats rapportés couvrent sept modèles récents et trois jeux de données de questions-réponses, avec un taux de transfert entre modèles atteignant 96 % dans une configuration — sans sondage direct du système victime. Nous décrivons le mécanisme, pas une recette d’optimisation opérationnelle.

Pourquoi c’est important

La disponibilité est le pan le plus discret de la triade de sécurité, et le plus facile à sous-estimer. Un assistant support adossé à un RAG, un robot de recherche documentaire ou un agent de connaissances interne qui se met soudain à refuser une catégorie de questions légitimes n’a pas l’air « piraté » : il a l’air bogué ou trop prudent. L’attaque est donc difficile à attribuer et peu coûteuse à maintenir : un seul document récupérable peut supprimer les réponses à toute une famille de requêtes apparentées. Dans les contextes critiques pour la disponibilité — procédures d’incident, recherche médicale ou juridique, support client — les refus induits dégradent directement les décisions et érodent la confiance.

La leçon de fond est que l’alignement de sûreté fait désormais partie de la surface d’attaque, et pas seulement de la défense. Plus un modèle est réglé pour refuser de façon conservatrice, et plus l’industrie converge vers des politiques de refus communes, plus cette surface devient large et portable. Les défenses qui supposent que l’attaquant veut faire obéir le modèle passent à côté d’un adversaire dont le but est de le faire refuser.

Défenses

Aucun contrôle unique ne neutralise complètement cette classe d’attaque ; l’étude constate que plusieurs défenses existantes n’offrent qu’une protection limitée. Traitez le problème par couches.

• Gouvernez la base de connaissances comme une entrée non fiable. Restreignez qui peut ajouter des documents aux corpus de récupération, et appliquez provenance et modération aux contenus contribués avant qu’ils ne deviennent récupérables. Les corpus partiellement ouverts sont le point d’entrée.
• Surveillez le taux de refus comme un signal de disponibilité. Suivez la proportion de requêtes se terminant par un refus, ventilée par sujet et par source de document. Un pic de refus sur des requêtes auparavant traitées est un indicateur de compromission, pas seulement une gêne d’expérience utilisateur.
• Séparez l’évaluation du risque du contexte récupéré. Évaluez l’intention de l’utilisateur indépendamment de la sensibilité du texte récupéré, pour qu’une question anodine ne soit pas requalifiée comme nuisible au seul motif qu’un document voisin se lit comme risqué.
• Réglez délibérément l’arbitrage du sur-refus. Calibrez les garde-fous face à des jeux de tests de faux refus sur requêtes bénignes, et préférez des refus ciblés à l’évitement en bloc d’un sujet, afin de laisser aux attaquants moins de sur-prudence à exploiter.
• Tracez et mettez en quarantaine. Lorsqu’un amas de refus apparaît, identifiez quels documents récupérés co-apparaissent avec lui, retirez le contenu suspect et re-testez — le document de blocage est, par conception, celui qui revient sans cesse aux côtés des échecs.

Status

Élément	Valeur
Classe	Attaque par blocage / induction de refus sur RAG (disponibilité)
Mécanisme	Document empoisonné construisant un « contexte à risque » pour déclencher le sur-refus
Propriété clé	Transfert entre modèles via l’homogénéité de l’alignement (boîte noire)
Portée rapportée	7 LLM récents, 3 jeux de données QA ; jusqu’à 96 % de transfert dans une configuration
Divulgation	Mars 2026 (article de recherche) ; travaux connexes sur le DoS de garde-fous en juin 2026
Correctif	Aucune mitigation unique ; défenses existantes jugées limitées

Dates clés : mars 2026 — article sur l’attaque par blocage TabooRAG (arXiv 2603.03919) ; avril 2025 — travaux antérieurs sur l’induction de garde-fous pour un déni de service RAG (arXiv 2504.21680) ; juin 2026 — DoS par extension du raisonnement contre des garde-fous IA (arXiv 2606.14517), exemple contemporain d’un mécanisme de sûreté détourné en arme de disponibilité. Les noms de modèles cités (par ex. GPT-5.2, DeepSeek-V3.2) sont ceux rapportés dans l’article source.