Audit d’applications IA · chatbots · RAG · agents connectés
Nous testons l’application IA complète : données accessibles, isolation entre clients, contrôles d’accès, logique métier, mémoire, outils, API et actions réelles — ainsi que la prompt injection, le jailbreak et les détournements de contexte. Chaque constat est reproduit, relié à un impact concret et accompagné d’une remédiation.
Audit de l’application IA complète : données, isolation,
permissions, actions métier et manipulations du modèle.
CAS DE RECHERCHE #01 · ANONYMISÉ
Au moment de proposer des créneaux, un résultat d’outil falsifié a fait dire à l’agent que la réservation était indisponible. Il a renvoyé le prospect à plus tard. Même effet dans trois sessions distinctes.
Un faux résultat est fourni à l’agent au moment où il attend les disponibilités.
L’agent dit ne pas pouvoir afficher les créneaux et invite le prospect à revenir plus tard.
Trois sessions distinctes reproduisent ce détournement du parcours. Aucune réservation n’a été modifiée.
Extrait anonymisé d’un constat documenté. Aucun nom d’entreprise ni statut de mission client n’est revendiqué.
Nous auditons tous les modèles, plateformes et architectures IA.
EXPERTISES
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.
Données exposées, isolation entre utilisateurs, contrôles d’accès, logique métier, prompt injection, jailbreak et fuite du prompt système.
VOIR L’AUDIT → 02Permissions, identités techniques, mémoire, outils, API, séparation des données, validation humaine et actions non autorisées.
VOIR L’AUDIT → 03Différences, vecteurs directs ou indirects, effets observables et contrôles techniques à tester.
COMPRENDRE LES ATTAQUES → 04Documents piégés, empoisonnement des sources, défaut de cloisonnement, retrieval manipulé et exfiltration.
VOIR LES RISQUES RAG →01 — Surface d’attaque de l’application IA
Nous ne testons pas uniquement ce que le modèle accepte de dire. Nous vérifions aussi ce qu’un visiteur peut réellement consulter, faire enregistrer ou déclencher à travers l’application : données d’un autre client, mémoire, règles métier, outils, API et actions externes.
Vérification de la séparation entre visiteurs, comptes et entreprises clientes : données personnelles, conversations, mémoire, documents, contacts ou informations internes accessibles hors du périmètre prévu.
DONNÉES & ISOLATIONAnalyse des connecteurs, fonctions et API : nous vérifions si une entrée publique peut provoquer une action non autorisée, contourner une validation ou utiliser une permission trop large.
OUTILS & PRIVILÈGESUne instruction hostile est fournie par l’utilisateur — ou dissimulée dans un document, une page web, un email ou la sortie d’un outil — afin de supplanter les consignes légitimes.
HIÉRARCHIE DES INSTRUCTIONSContournement 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ÉExtraction ou reconstruction d’instructions internes, de règles métier ou de contexte confidentiel. La sévérité dépend de ce qui est réellement exposé et de l’impact démontré.
CONTEXTE INTERNEIntroduction 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 & EMBEDDINGS02 — Protocole de test offensif
Autorisation écrite, périmètre, comptes de test, données interdites, limites opérationnelles et conditions d’arrêt.
Identification des données, comptes, frontières entre clients, mémoire, RAG, outils, API, permissions, identités techniques et actions pouvant produire un effet réel.
Contrôles d’accès, isolation, logique métier, permissions et actions sont testés avec la même rigueur que les jailbreaks, injections directes ou indirectes et scénarios multi-tours.
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.
Criticité établie selon l’exploitabilité, les privilèges atteints, les données exposées et la reproductibilité, puis vérification des correctifs.
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
Exemple anonymisé fondé sur un constat documenté. Aucun client ni système nommé ; les traces sensibles sont expurgées.
QUI RÉALISE L’AUDIT ?
Frédéric Cassiede · auditeur Heldguard
Je cadre le périmètre avec vous, réalise les tests manuels et présente les résultats lors de la restitution. Vous échangez directement avec la personne qui documente les constats.
Un exemple de mon travail est consultable dans le cas HG-001 et son rapport public.
Échanger avec l’auditeurAVANT TOUT ACCÈS À VOTRE APPLICATION
Le premier échange sert à définir les informations nécessaires. Le devis et le cadre de mission précisent ensuite les accès, les livrables et les conditions du retest avant le lancement des tests.
Frédéric Cassiede est votre interlocuteur pour le cadrage, les tests manuels et la restitution. Consultez le cas documenté et le rapport exemple.
Avant de partager des accès, nous fixons par écrit les comptes de test, les données autorisées, la circulation des preuves et leur conservation. Un accord de confidentialité peut être prévu si nécessaire.
Le devis décrit les composants testés, les environnements, les scénarios prioritaires, les exclusions, le calendrier et le type de rapport attendu.
Quand le retest fait partie de l’offre, le document précise quels constats seront revérifiés, après quels correctifs et sous quelle forme le résultat sera remis.
03 — Offres
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, règles d’intervention et conditions de traitement des preuves définis avec vous.
DIAGNOSTIC CHATBOT
Pour un chatbot simple sans RAG sensible ni action sur un système tiers. Contrôles accessibles depuis l’interface et comportements détournables.
AUDIT APPROFONDI
Pour une application LLM métier, un chatbot RAG ou un assistant qui manipule des données internes.
AGENT CONNECTÉ
Pour un agent capable d’appeler des fonctions, API, CRM, messageries, comptes ou workflows métier.
POUR QUI ?
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.
VOCABULAIRE OFFENSIF
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.
04 — Questions techniques
Non. Nous testons l’application IA complète : données accessibles, séparation entre utilisateurs ou clients, contrôles d’accès, logique métier, mémoire, outils, API, permissions et actions pouvant produire un effet réel. Les manipulations conversationnelles ne sont qu’une partie du périmètre.
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.
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é.
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é.
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.
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.
Frédéric Cassiede est votre interlocuteur et l’auditeur présenté sur ce site. Le périmètre, les personnes habilitées à intervenir et les modalités d’accès sont indiqués avant le démarrage. Vous pouvez consulter le cas public HG-001 et le rapport exemple.
Le cadre de mission fixe avant tout accès les comptes utilisés, les données autorisées, les canaux de transmission des preuves, leur conservation et les modalités de restitution ou de suppression. N’envoyez aucun secret dans le formulaire public. Voir le cadre de mission.
Le devis énumère les composants, environnements, scénarios prioritaires, exclusions, livrables et calendrier. Si un retest est inclus, il précise les constats revérifiés après correction et la forme du compte rendu.
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
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.