Jailbreak & guardrail bypass
Contournement des garde-fous du modèle pour obtenir un comportement explicitement interdit. Nous testons notamment les changements de rôle, l’obfuscation et les séquences multi-tours.
CONTRÔLES DE SÛRETÉ
Audit offensif · chatbots · RAG · agents IA connectés
Jusqu’où un attaquant
peut-il détourner
votre agent IA ?
Nous évaluons sa résistance aux jailbreaks, prompt injections directes et indirectes, extractions du prompt système, exfiltrations de contexte RAG et détournements d’outils. Chaque vulnérabilité est reproduite, qualifiée par son impact et accompagnée d’une remédiation.
- 01 Scénarios adaptés aux réactions
- 02 Chaînes reproductibles
- 03 Retest des correctifs
LLM ATTACK SURFACE
GUARDRAIL BYPASSBLOQUÉ
SYSTEM PROMPT LEAKAGEANALYSE…
Audit de sécurité des chatbots et agents IA : jailbreak,
prompt injection, fuite de données et abus d’API.
Nous auditons tous les modèles, plateformes et architectures IA.
Tous modèles LLMModèles open sourceModèles auto-hébergésPlateformes no-codeRAGAPI & connecteursSystèmes multi-agentsArchitectures sur mesure
EXPERTISES
Un audit adapté à chaque
surface d’attaque IA.
Un chatbot public, un assistant documentaire et un agent capable d’agir n’exposent ni les mêmes données ni les mêmes conséquences. Chaque périmètre est analysé séparément, puis relié aux risques métier réellement atteignables.
01
Audit de sécurité chatbot
Jailbreak, prompt injection directe, fuite du prompt système, données exposées et contournement des règles conversationnelles.
VOIR L’AUDIT → 02Audit de sécurité agent IA
Permissions, mémoire, appels d’outils, API, chaînes multi-agents, validation humaine et actions non autorisées.
VOIR L’AUDIT → 03Prompt injection et jailbreak
Différences, vecteurs directs ou indirects, effets observables et contrôles techniques à tester.
COMPRENDRE LES ATTAQUES → 04Sécurité des systèmes RAG
Documents piégés, empoisonnement des sources, défaut de cloisonnement, retrieval manipulé et exfiltration.
VOIR LES RISQUES RAG →01 — Surface d’attaque LLM
Ce que nous cherchons.
Et ce que cela expose.
Le modèle reçoit dans un même contexte des instructions de confiance et des données non fiables. Nous vérifions si un attaquant peut exploiter cette confusion pour modifier son comportement, récupérer du contexte confidentiel ou déclencher un outil hors périmètre.
Prompt injection directe et indirecte
Une instruction hostile est fournie par l’utilisateur — ou dissimulée dans un document, une page web ou un email que le modèle ingère — afin de supplanter les consignes légitimes.
HIÉRARCHIE DES INSTRUCTIONSSystem prompt leakage
Extraction totale ou partielle du prompt système : les instructions internes qui définissent le rôle, les interdictions, la logique métier et parfois l’architecture de l’agent.
PROMPT SYSTÈMERAG poisoning & context injection
Introduction d’instructions ou de contenus manipulés dans les sources indexées afin d’influencer les réponses, les citations ou les décisions prises à partir du contexte récupéré.
RETRIEVAL & EMBEDDINGSTool abuse & excessive agency
Détournement des connecteurs, fonctions ou API d’un agent. Nous vérifions si ses fonctionnalités, permissions ou son autonomie permettent une action non autorisée.
OUTILS & PRIVILÈGESData exfiltration & isolation
Recherche de fuite depuis la mémoire, le contexte RAG, les journaux ou une autre session : données personnelles, fragments internes, secrets métier ou informations d’un autre utilisateur.
CONFIDENTIALITÉ DES DONNÉES02 — Protocole de test offensif
Une faiblesse n’est retenue
que si elle est démontrable.
- 011
Rules of Engagement
Autorisation écrite, périmètre, comptes de test, données interdites, limites opérationnelles et conditions d’arrêt.
- 022
Threat modeling LLM
Cartographie du prompt système, du modèle, de la mémoire, du pipeline RAG, des outils, des permissions et des frontières de confiance.
- 033
Tests offensifs progressifs
Jailbreaks, injections directes et indirectes, obfuscation, attaques multi-tours et variations sémantiques adaptées aux défenses observées.
- 044
Exploit validation & chaining
Nous reproduisons le finding et cherchons si plusieurs faiblesses peuvent être chaînées pour atteindre une donnée, une règle métier ou un outil.
- 055
Triage, remédiation & retest
Criticité établie selon l’exploitabilité, les privilèges atteints, les données exposées et la reproductibilité, puis vérification des correctifs.
RÉFÉRENTIELS
La couverture est structurée à partir de l’OWASP Top 10 for LLM Applications 2025, de l’OWASP AI Agent Security Cheat Sheet, du NIST AI 100-2e2025, de MITRE ATLAS et des recommandations de l’ANSSI pour les systèmes d’IA générative. Ces références guident le protocole ; elles ne remplacent pas l’analyse propre à votre architecture.
LE LIVRABLE
Des findings exploitables,
pas un catalogue de prompts.
- Résumé exécutif lisible par la direction
- Vecteur d’attaque et préconditions
- Preuve, transcript et étapes de reproduction
- Impact, exploitabilité et périmètre affecté
- Remédiation technique priorisée
- Résultat du retest selon l’offre
03 — Offres
Une profondeur de test
adaptée à l’architecture.
La différence entre les offres tient au nombre de vecteurs, à la profondeur multi-tours et aux composants accessibles. Aucun test ne commence sans périmètre et Rules of Engagement validés.
DIAGNOSTIC CHATBOT
Sur devis
Pour un chatbot simple, sans RAG sensible ni capacité d’action sur un système tiers.
- 1 endpoint conversationnel
- 20 scénarios d’attaque manuels
- Jailbreak et injection directe
- Recherche de fuite du prompt système
- Rapport synthétique et restitution
AUDIT APPROFONDI
Sur devis
Pour une application LLM métier, un chatbot RAG ou un assistant qui manipule des données internes.
- 50 à 80 scénarios d’attaque
- Injections directes, indirectes et multi-tours
- Prompt leakage, RAG poisoning et exfiltration
- Exploit validation et rapport détaillé
- 1 campagne de retest ciblée
AGENT CONNECTÉ
Sur devis
Pour un agent capable d’appeler des fonctions, API, CRM, messageries, comptes ou workflows métier.
- Threat modeling sur mesure
- Tool abuse et privilege boundary testing
- Excessive agency et chaînes d’attaque
- Validation des contrôles human-in-the-loop
- Rapport technique et retest
POUR QUI ?
Le niveau de risque dépend
de ce que le modèle peut
lire, retenir et exécuter.
Heldguard intervient lorsque le système dépasse le simple démonstrateur : accès à des documents internes, mémoire utilisateur, logique commerciale, connecteurs ou actions ayant un effet réel.
- SaaS avec copilote ou agent IA connecté à des outils
- Agences qui déploient des chatbots pour leurs clients
- Systèmes RAG connectés à une base documentaire
- Assistants en finance, assurance, formation ou e-commerce
- Agents internes reliés à des données et workflows métier
VOCABULAIRE OFFENSIF
Les termes du rapport,
définis sans ambiguïté.
Le jargon n’a de valeur que s’il décrit précisément un mécanisme. Ces définitions sont celles utilisées dans nos findings et pendant la restitution.
- Test offensif d’une application LLM
- Évaluation de sécurité au cours de laquelle l’auditeur reproduit des scénarios d’attaque autorisés afin d’identifier des failles exploitables dans le chatbot, le système RAG ou l’agent IA.
- Finding
- Vulnérabilité ou faiblesse documentée avec ses préconditions, sa preuve, son impact, sa criticité et sa remédiation.
- Jailbreak
- Technique de contournement visant à faire ignorer au modèle ses règles de sûreté ou d’alignement afin d’obtenir un comportement ou un contenu qu’il devrait normalement refuser.
- Prompt système
- Instructions de plus haute priorité qui définissent le rôle, les règles métier, les interdictions et le comportement attendu de l’application.
- Guardrail
- Contrôle placé avant, pendant ou après le modèle pour détecter, bloquer ou limiter un contenu, une instruction ou une action non conforme.
- Prompt injection indirecte
- Instruction hostile cachée dans une source externe — document, email ou page web — que le modèle traite comme du contexte légitime.
- RAG poisoning
- Altération d’une source indexée pour que le moteur de recherche fournisse au modèle un contenu manipulé ou une instruction hostile.
- Excessive agency
- Agent doté de trop de fonctions, de permissions ou d’autonomie, ce qui transforme une mauvaise sortie du modèle en action dommageable.
- Attack chaining
- Combinaison de plusieurs faiblesses mineures pour atteindre un impact supérieur : donnée confidentielle, privilège ou action métier.
04 — Questions techniques
Avant d’engager
le test.
Quelle différence entre jailbreak et prompt injection ? +
Les deux termes ne décrivent pas exactement la même chose. La prompt injection exploite la confusion entre données et instructions pour modifier le comportement d’une application LLM. Elle peut être directe, dans le message d’un utilisateur, ou indirecte, depuis un document, un email, une page web ou la sortie d’un outil. Le jailbreak vise précisément à neutraliser les règles de sûreté ou d’alignement du modèle afin d’obtenir un comportement normalement refusé. Dans la classification OWASP LLM01, le jailbreak constitue une forme de prompt injection, mais toute prompt injection n’est pas un jailbreak : elle peut aussi détourner un processus métier, exfiltrer des données ou provoquer un appel d’API sans chercher à contourner la modération.
Testez-vous réellement la fuite du prompt système ? +
Oui. Nous cherchons l’extraction verbatim, la reconstruction partielle et l’inférence des règles internes par comportement différentiel. Un prompt système doit toutefois être conçu comme une instruction, jamais comme un coffre-fort : aucun secret ou identifiant ne devrait y être stocké.
Comment testez-vous une injection indirecte dans un RAG ? +
Dans un environnement autorisé, nous introduisons des contenus de test dans une source contrôlée, puis vérifions si le pipeline de retrieval les isole comme données ou si le modèle les exécute comme instructions. Le finding documente la source, le chemin d’ingestion et l’effet observé.
Que vérifiez-vous sur un agent connecté à des outils ? +
Nous examinons les frontières de privilèges, la portée des fonctions, la validation des paramètres, la confirmation humaine et les actions réversibles. L’objectif est de déterminer si une sortie manipulée du LLM peut provoquer un appel d’outil non autorisé ou trop puissant.
Allez-vous tester le système en production ? +
Uniquement si les Rules of Engagement l’autorisent explicitement. Elles définissent les environnements, comptes, horaires, données interdites, limites de charge et conditions d’arrêt. Un environnement isolé est privilégié lorsqu’une action pourrait affecter des utilisateurs ou des données réelles.
Un audit prouve-t-il que l’agent est invulnérable ? +
Non. Le rapport décrit un périmètre, une période, des vecteurs et des hypothèses de test. Il apporte des preuves reproductibles et mesure la résistance aux scénarios couverts ; il ne peut démontrer l’absence universelle de vulnérabilité.
05 — PREMIER ÉCHANGE
Cartographions votre
surface d’attaque LLM.
Indiquez le modèle utilisé, la présence d’un RAG ou d’une mémoire, les outils connectés et les données accessibles. Nous vous proposerons un périmètre de test cohérent avec l’impact potentiel.
Réponse sous 1 à 2 jours ouvrés