--- title: "Cadre R.A.I.L.G.U.A.R.D. : Des vulnérabilités des modèles au raisonnement sécurisé" description: "Cadre R.A.I.L.G.U.A.R.D. : Des vulnérabilités des modèles au raisonnement sécurisé" image: https://www.brightonlabs.ai/hubfs/cyber-genai-min.png --- [Skip to content](https://www.brightonlabs.ai/fr/blog/r.a.i.l.g.u.a.r.d.-framework-from-model-vulnerabilities-to-secure-reasoning#main-content) - [Français](https://www.brightonlabs.ai/fr/blog/r.a.i.l.g.u.a.r.d.-framework-from-model-vulnerabilities-to-secure-reasoning) - [English](https://www.brightonlabs.ai/blog/r.a.i.l.g.u.a.r.d.-framework-from-model-vulnerabilities-to-secure-reasoning) Français Show submenu for translations [![brightonlabs-logo-cybersecurité-ai](https://www.brightonlabs.ai/hs-fs/hubfs/fulllogo_transparent_nobuffer-2.webp?width=307&height=47&name=fulllogo_transparent_nobuffer-2.webp)](https://www.brightonlabs.ai/?hsLang=fr) Open main navigation Close main navigation - - [Français](https://www.brightonlabs.ai/fr/blog/r.a.i.l.g.u.a.r.d.-framework-from-model-vulnerabilities-to-secure-reasoning) - [English](https://www.brightonlabs.ai/blog/r.a.i.l.g.u.a.r.d.-framework-from-model-vulnerabilities-to-secure-reasoning) Français Show submenu for translations - [Planifier un appel](https://www.brightonlabs.ai/meeting) [Planifier un appel](https://www.brightonlabs.ai/meeting?hsLang=fr) [All posts](https://www.brightonlabs.ai/fr/blog/all) mai 26, 2025 # Cadre R.A.I.L.G.U.A.R.D. : Des vulnérabilités des modèles au raisonnement sécurisé ![Picture of Youssef Harkati, CTO, DevSecOps & Spécialiste cybersécurité](https://www.brightonlabs.ai/hs-fs/hubfs/Team%20BoL/brightonlabs-cybersecurity-youssef-harkati.png?width=50&name=brightonlabs-cybersecurity-youssef-harkati.png) By  Youssef Harkati, CTO, DevSecOps & Spécialiste cybersécurité  ·  6 minute read  ![cyber-genai-min](https://www.brightonlabs.ai/hs-fs/hubfs/cyber-genai-min.png?width=800&height=533&name=cyber-genai-min.png)  Notre parcours vers la conception du cadre [**R.A.I.L.G.U.A.R.D.**](https://github.com/brighton-labs/railguard-framework/tree/main)a commencé il y a un peu plus d’un mois, suite à la lecture d’un article de [Pillar Security’s article](https://www.pillar.security/blog/new-vulnerability-in-github-copilot-and-cursor-how-hackers-can-weaponize-code-agents) décrivant comment les agents de codage GenAI peuvent être exploités via des attaques par injection de prompt ou empoisonnement de règles Cursor. Les assistants de codage basés sur l’IA générative comme **Copilot**, **Cursor** ou **Windsurf** sont désormais largement utilisés dans l’industrie du logiciel. Ce qui nous a le plus frappés, ce n’est pas seulement l’étendue de la surface d’attaque — mais la **cause racine**. Ces outils sont alimentés par de **grands modèles de type Transformer**. Pour comprendre pourquoi ces assistants sont sujets à des failles de sécurité, il faut observer l’architecture **ANN + Transformer**. Ce qui les rend puissants — leur capacité à absorber le contexte et prédire le prochain token — les rend également vulnérables à : - des injections de prompt (notamment **indirectes et distantes**) - des **hallucinations** - des **mauvaises interprétations** induites par un contexte trompeur ### Comprendre l’impact du concept de "self-attention" sur la sécurité Avant tout, il est essentiel de comprendre **la self-attention** dans les LLMs pour cerner les problèmes de sécurité associés à la GenAI. La self-attention permet aux modèles de **pondérer les tokens par pertinence** et non uniquement selon leur position dans la séquence. Cela leur permet de **suivre des dépendances à longue distance**, comme l’association entre un bloc `try` et son `catch` plusieurs lignes plus loin. Le modèle construit ainsi une **carte probabiliste** de ce qui semble important dans l’entrée. ⇒ *L’idée clé : le contexte est dynamique, et la compréhension de “l’intention” par le modèle peut facilement être erronée.* #### Example: Insecure by Context *Comparaison visuelle entre une sortie non sécurisée et une alternative guidée par RAILGUARD :*  ``` # Prototype for a simple admin panel to quickly demonstrate proof of concept ``` query = f"SELECT \* FROM users WHERE email = '{email}'" ```   ``` Ce code est dangereux -> **pas uniquement à cause de l’interpolation de chaîne**. La présence du commentaire (`prototype`, `rapide`, `POC`) pousse le modèle à **minimiser les exigences de sécurité**. Il a sans doute vu des milliers d’exemples similaires (code de démo, GitHub, Stack Overflow...) où **la rapidité primait sur la sécurité**. Au lieu d’imposer l’usage d’ORM ou de requêtes préparées, le modèle privilégie la simplicité, au détriment des vérifications de sécurité. ### Reconnaissance de motifs ≠ Raisonnement sécurisé Le concept de "self-attention" permet au modèle de **reproduire des motifs vus précédemment**, même s’ils sont **inadaptés ou dangereux**. Pire encore, les LLMs peuvent : - suivre des **commentaires empoisonnés** - être influencés par des **caractères invisibles** - être trompés par des **noms de variables perfides** ![Les assistants IA de codage aujourd’hui](https://www.brightonlabs.ai/hs-fs/hubfs/Screenshot%20From%202025-04-24%2009-54-32.png?width=1422&height=637&name=Screenshot%20From%202025-04-24%2009-54-32.png)   Les assistants basés sur des Transformers sont **vulnérables par conception**. Le LLM ne “sait” pas que ce qu’il génère, est dangereux, il suit juste des motifs qui *semblent* corrects dans le contexte. ### Sécurité au moment du raisonnement : pourquoi nous avons créé R.A.I.L.G.U.A.R.D. C’est pour cela que nous avons conçu le **cadre R.A.I.L.G.U.A.R.D.** : pour injecter des **contraintes de raisonnement sécurisé avant même la génération du code**. **RAILGUARD** introduit des signaux de sécurité dans le raisonnement du modèle via : - des règles métier (ex. : **CursorRules**), - des contraintes renforcées, - des contextes sécurisés par défaut. #### Les 8 Blocs du cadre R.A.I.L.G.U.A.R.D. *Chaque bloc contribue à façonner la sécurité **au moment du raisonnement**. Les voici :* **R — Risk First (Prioritéau risque)** Définir l’objectif de sécurité de la règle. Inciter le LLM à « réfléchir » avant d’agir. Concrètement, cela implique que le modèle effectue une vérification interne, une forme de **modélisation des menaces** : *qu’est-ce qui pourrait mal tourner en répondant à cette requête ?* Par exemple, si l’utilisateur demande d’analyser un fichier téléchargé, un LLM orienté "Risk First" pourrait reconnaître le **risque de contenu malveillant** et inclure des pratiques de traitement de fichier sécurisé (ou au moins émettre un avertissement), plutôt que de générer aveuglément un parseur rapide et fragile. **A — Attached Constraints (Contraintes attachées)** Spécifier ce qui ne doit **jamais** se produire (limites, lignes rouges) pour éviter les régressions. Le principe des **“Attached Constraints”** garantit que l’IA n’opère jamais sans règle claire. Dans les systèmes actuels, un assistant IA de codage ne dispose souvent que d’un filtre de contenu générique ou d’un réglage d’alignement de haut niveau. RAILGUARD, à l’inverse, **injecte un ensemble détaillé de contraintes de sécurité et de style de code**, transmises au modèle (par exemple via un prompt système ou un fichier de contexte persistant). Ces contraintes couvrent : les pratiques cryptographiques approuvées, les fonctions interdites, les conventions de nommage, etc. Essentiellement, l’IA transporte avec elle **un standard de codage sécurisé obligatoire**. Cela compense la tendance des Transformers à être trop permissifs : le modèle entend en permanence une petite voix lui rappeler : *“Souviens-toi, voici les règles à suivre.”* Avec ces contraintes attachées, un prompt malveillant (comme un jailbreak) ne pourra **pas les outrepasser**. Pourquoi ? Parce que le modèle **donnera toujours priorité** aux règles attachées. **I — Interpretative Framing (Encadrement interprétatif)** L’idée est de guider la manière dont le LLM doit interpréter les prompts de façon sécurisée et **éviter la confiance aveugle dans des instructions vagues**. L’**encadrement interprétatif** signifie que l’IA va **reformuler ou réinterpréter en interne** la requête pour s’assurer qu’elle reste conforme à un comportement sûr et souhaité. Les LLMs sont très sensibles au contexte : un **léger changement de formulation** peut modifier radicalement la sortie.Par exemple, un utilisateur demande :  *“Ouvre un fichier et affiche la première ligne.”* Un modèle classique le fera littéralement. Un LLM encadré par RAILGUARD pourrait plutôt interpréter en interne :  *“Ouvre un fichier (en t’assurant que le chemin est sûr et en gérant les erreurs), puis affiche la première ligne (en évitant tout contenu dangereux).”* L’idée n’est pas de changer l’intention, mais **d’intégrer les considérations de sécurité implicites**. **L — Local Defaults (Valeurs par défaut locales)** Définir des **valeurs sécurisées par défaut** au niveau du projet ou de l’environnement (ex. : utiliser des variables d’environnement plutôt que des secrets en clair). Le principe de “Local Defaults” garantit que, **en l’absence d’instructions explicites**, le modèle **adopte toujours des pratiques sécurisées par défaut**. Exemples : - Génération d’API → inclure automatiquement l’authentification et la validation des entrées - Génération de requêtes SQL → utiliser par défaut des requêtes préparées ou un ORM RAILGUARD fait de la **sécurité par défaut une norme intégrée** dans les processus GenAI. **G — Generative Path Checks (Vérification du chemin génératif)** Imposer une **séquence de raisonnement** à suivre avant que le modèle n’émette du code, avec **une boucle de rétroaction pendant la génération**. Le modèle est invité à raisonner sur sa solution avant de produire la sortie. Cette approche permet de **détecter les erreurs** qui pourraient autrement devenir des vulnérabilités ou des hallucinations. Elle améliore à la fois **la sécurité et la précision**. **U — Uncertainty Disclosure (Déclaration d’incertitude)** Dire explicitement au modèle quoi faire en cas de doute : **demander, avertir, ou s’abstenir**.Les **hallucinations** sont un problème bien connu des LLMs. Dans le codage assisté par GenAI, l’incertitude peut surgir si le prompt est vague ou hors du champ de connaissance du modèle. Le vrai danger survient lorsque le LLM **affirme avec confiance** des choses incorrectes — ce qui peut introduire des failles de sécurité. **A — Auditability (Auditabilité)** Ajouter des **commentaires ou marqueurs de trace** pour permettre l’audit humain. L’**auditabilité**, c’est garantir que les actions de l’IA sont **traçables et compréhensibles**. Dans RAILGUARD, cela signifie que l’IA doit **justifier ses décisions**, en particulier celles liées à la sécurité. En pratique, cela peut se traduire par des commentaires explicatifs : *“// Using prepared statements to prevent SQL injection”* ou *“// Added rate limiting to mitigate brute-force attacks as per security policy.”* Ces annotations permettent la **vérification et la relecture par des humains** — et sont, selon nous, un **filet de sécurité incontournable**. **R+D — Revision + Dialogue (Révision + Dialogue)** Cette combinaison reconnaît que **le code est un processus itératif**, et que l’IA doit agir comme **partenaire collaboratif**, pas comme oracle infaillible. Aucun code complexe n’est parfait dès le premier jet — ni écrit par un humain, ni par une IA. Avec **la révision**, l’IA peut dire : *“laisse-moi réessayer”* ou accepter des retours pour améliorer sa proposition. Avec le **dialogue**, l’IA **reste engagée dans une conversation** avec le développeur, au lieu de livrer du code et disparaître. En matière de sécurité, cela permet une **amélioration continue** et un véritable **défense en profondeur**. En pratique, cela signifie que les devs — ou même d’autres LLMs — peuvent **interroger ou corriger le code généré via des** `/commands`.   ![Codage sécurisé en route !](https://www.brightonlabs.ai/hs-fs/hubfs/Screenshot%20From%202025-04-24%2010-09-12.png?width=827&height=510&name=Screenshot%20From%202025-04-24%2010-09-12.png)   ### L’avenir de la sécurité applicative (AppSec) est génératif Nous comprenons désormais que les modèles basés sur les transformers ne « comprennent » pas le code, ils le **contextualisent**. Ils ne suivent pas des règles, ils **reproduisent des motifs**, **interpellent**, et **évaluent la pertinence**. C’est leur force, mais aussi leur faiblesse. La sécurité à l’ère de la GenAI **ne peut pas se reposer uniquement sur des linters statiques**, des vérificateurs de règles ou des correctifs post-génération. Nous devons **agir là où le modèle raisonne**, c’est-à-dire au niveau de la **self-attention**, de la **pondération des tokens** et du **raisonnement contextuel probabiliste**. Le cadre **RAILGUARD** ne cherche pas à **restreindre** le modèle, il cherche à **l’éduquer**. Il construit un **échafaudage comportemental sécurisé** **avant même** la première ligne de code générée. En appliquant les principes de **Risk First, Attached Constraints, Interpretative Framing, Local Defaults, Generative Path Checks, Uncertainty Disclosure, Auditability, and Revision + Dialogue**, nous mettons en place une **défense en profondeur** autour du processus génératif de l’IA. En résumé : **RAILGUARD façonne un raisonnement sécurisé**. Avec tout cela, **Cursor Rules devient le support**, et **RAILGUARD devient l’état d’esprit**. Ensemble, ils permettent de construire des **pipelines de génération de code** qui ne se contentent pas de produire du code *qui semble correct*, mais du code **qui raisonne de manière sécurisée, par conception**. Le **code généré par IA** est déjà très répandu, et pourrait bien devenir la **principale source de code** dans un avenir proche. Sa sécurité doit être **pensée et encadrée dès la génération**. Merci de nous avoir lus, **L’équipe BrightOnLABS**         [![brightonlabs-logo-transparent](https://www.brightonlabs.ai/hs-fs/hubfs/brightonlabs-logo-transparent.webp?width=200&height=170&name=brightonlabs-logo-transparent.webp "brightonlabs-logo-transparent")](https://www.brightonlabs.ai/fr/?hsLang=fr) [linkedin-in icon](https://www.linkedin.com/company/100820056) [facebook-f icon](https://www.facebook.com/profile.php?id=61566718178880) **[Services](https://www.brightonlabs.ai/fr/services?hsLang=fr)** [Audit de sécurité](https://www.brightonlabs.ai/fr/services/audit-de-securite?hsLang=fr) [Conformité informatique](https://www.brightonlabs.ai/fr/services/conformite-informatique?hsLang=fr) [DevSecOps](https://www.brightonlabs.ai/fr/services/devsecops?hsLang=fr) **[Tarifs](https://www.brightonlabs.ai/fr/prix?hsLang=fr)** **[À propos](https://www.brightonlabs.ai/fr/a-propos?hsLang=fr)** **[Nous contacter](https://www.brightonlabs.ai/fr/contact?hsLang=fr)** Soyez à l'affût des dernières tendances en cybersécurité à l'ère de l'IA avec l'infolettre BrightOnLABS Copyright © 2024 - Solutions BrightOnLABS Inc.  -  [Politique de confidentialité](https://www.brightonlabs.ai/fr/politique-de-confidentialite?hsLang=fr) ```json { "@context" : "https://schema.org", "@type" : "BlogPosting", "author" : { "@type" : "Person", "name" : "Youssef Harkati, CTO, DevSecOps & Spécialiste cybersécurité", "url" : "https://www.brightonlabs.ai/fr/blog/author/youssef-harkati-cto-devsecops-spécialiste-cybersécurité" }, "dateModified" : "2025-05-26T19:01:46.901Z", "datePublished" : "2025-05-25T19:42:03.000Z", "headline" : "Cadre R.A.I.L.G.U.A.R.D. : Des vulnérabilités des modèles au raisonnement sécurisé", "image" : [ "https://www.brightonlabs.ai/hubfs/cyber-genai-min.png" ], "mainEntityOfPage" : { "@id" : "https://www.brightonlabs.ai/fr/blog/r.a.i.l.g.u.a.r.d.-framework-from-model-vulnerabilities-to-secure-reasoning", "@type" : "WebPage" }, "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://www.brightonlabs.ai/hubfs/fulllogo_transparent_nobuffer.png" }, "name" : "BrightOnLABS" } } ``` ```json { "@context" : "http://schema.org", "@type" : "Article", "author" : { "@type" : "Person", "name" : [ "Youssef Harkati, CTO, DevSecOps & Spécialiste cybersécurité" ] }, "datePublished" : "2025-05-25T19:42:03+0000", "description" : "Cadre R.A.I.L.G.U.A.R.D. : Des vulnérabilités des modèles au raisonnement sécurisé", "headline" : "Cadre R.A.I.L.G.U.A.R.D. : Des vulnérabilités des modèles au raisonnement sécurisé", "image" : "https://46779561.fs1.hubspotusercontent-na1.net/hubfs/46779561/cyber-genai-min.png", "publisher" : { "@type" : "Organization", "logo" : { "@type" : "ImageObject", "url" : "https://46779561.fs1.hubspotusercontent-na1.net/hubfs/46779561/fulllogo_transparent_nobuffer.png" }, "name" : "" }, "url" : "https://www.brightonlabs.ai/fr/blog/r.a.i.l.g.u.a.r.d.-framework-from-model-vulnerabilities-to-secure-reasoning" } ```