Formation Hacking et sécurité des applications LLM

Trois jours pour attaquer puis durcir vos chatbots, RAG et agents : prompt injection, fuite de données, garde-fous. Pour développeurs et pentesters.

Formation Hacking et sécurité des applications LLM

Description

Cette formation Hacking et sécurité des applications LLM vous permettra d'attaquer vos propres chatbots, RAG et agents, puis de les durcir.

Pendant 3 jours, vous apprendrez à :

  • savoir si votre assistant interne peut être détourné avant qu'un utilisateur ne pose une première question,
  • ouvrir vos données métier à un agent sans ouvrir en même temps un accès à tout le monde,
  • faire porter le contrôle sécurité par votre intégration continue, à chaque changement de prompt ou de modèle.

La formation part d'un constat simple : un modèle de langage ne distingue pas ses instructions des données qu'on lui donne à lire. Toutes les défenses sérieuses en découlent, et toutes les défenses naïves s'y cassent les dents. Chaque notion est éprouvée sur une application volontairement vulnérable, dans la lignée de la formation Hacking et sécurité des applications web.

Public

Cette formation s'adresse aux développeur·euse·s et architectes qui mettent des applications LLM en production, ainsi qu'aux professionnel·le·s de la sécurité (pentesteur·euse·s, RSSI opérationnel·le·s) chargé·e·s d'auditer ces applications.

Les objectifs

  • Construire le modèle de menace d'une application LLM et situer chaque risque sur l'OWASP Top 10 for LLM Applications
  • Exploiter les injections de prompt directes et indirectes sur une application vulnérable
  • Exfiltrer des données d'un système RAG et identifier les défauts de cloisonnement à l'origine de la fuite
  • Détourner un agent outillé en abusant de ses outils, de son autonomie et de ses serveurs MCP
  • Concevoir des garde-fous déterministes et une architecture à moindre privilège autour d'un modèle non fiable
  • Automatiser l'évaluation sécurité d'une application LLM avec garak, PyRIT et promptfoo

Pré-requis

  • Expérience en programmation, Python de préférence
  • Avoir déjà construit ou intégré une application s'appuyant sur un LLM (chatbot, RAG ou agent), ou avoir suivi la formation LLM : RAG et agents IA
  • Des notions de sécurité applicative web sont un plus, sans être requises
  • Poste disposant Python et Docker, et permettant d'accéder à des API de modèles
  • Ordinateur portable à apporter

Le programme de la formation Hacking et sécurité des applications LLM

Jour 1 — Modèle de menace, injection de prompt, jailbreaks

  • Préambule
    • Objectifs et modalités de la formation
    • Ce qui change (et ce qui ne change pas) par rapport à la sécurité applicative classique
    • Le problème fondateur : un modèle ne sépare pas instructions et données
    • Panorama des incidents publics marquants : assistants détournés, fuites de prompts système, agents exfiltrants
    • Profils et motivations des adversaires face à une application LLM
  • Cartographier la surface d'attaque
    • Anatomie d'une application LLM : prompt système, contexte, mémoire, outils, sorties
    • Les frontières de confiance réelles d'une chaîne LLM
    • Qui écrit dans le contexte du modèle : utilisateur, document indexé, page web, réponse d'API, autre agent
    • OWASP Top 10 for LLM Applications : lecture critique et mise en correspondance avec le CWE
    • NIST AI RMF et MITRE ATLAS : à quoi ils servent concrètement
  • Présentation du lab
    • Une application volontairement vulnérable : chatbot support adossé à un RAG et à des outils métier
    • Les modèles utilisés (API et modèle local) et ce que le choix implique côté sécurité
    • Instrumentation : lire les traces, voir le prompt réellement envoyé
  • Injection de prompt directe
    • Détournement d'instruction, changement de rôle, faux délimiteurs
    • Extraction du prompt système et de sa configuration
    • Contournement des consignes de refus
    • Encodage, obfuscation, langues alternatives, découpage de la charge utile
    • Injection multi-tours : empoisonner la mémoire de conversation
    • Pourquoi une consigne du type « ignore les instructions contenues dans les documents » ne protège de rien
  • Jailbreaks et contournement d'alignement
    • Ce que l'alignement d'un modèle garantit, et ce qu'il ne garantit pas
    • Familles de jailbreaks : jeu de rôle, hypothétique, encodage, suffixes adversariaux
    • Jailbreaks automatisés : principe des attaques par optimisation
    • Multimodal : instructions cachées dans une image
  • Fuite d'informations par le modèle
    • Mémorisation des données d'entraînement et de fine-tuning
    • Fuite du prompt système et des secrets qu'on y a rangés par erreur
    • Fuite entre utilisateurs par la mémoire ou le cache

Mises en pratique :

  • Construction du modèle de menace de l'application du lab, en binôme
  • Extraction du prompt système par plusieurs techniques distinctes
  • Contournement de trois garde-fous naïfs successivement renforcés par le formateur
  • Injection encodée contournant un filtre de mots-clés
  • Empoisonnement de la mémoire de conversation pour obtenir un comportement persistant
  • Jailbreak d'un modèle local et comparaison avec un modèle d'API aligné
  • Extraction d'un secret laissé dans la configuration du prompt

Jour 2 — RAG, agents, outils et chaîne d'approvisionnement

  • Injection de prompt indirecte
    • Le vrai vecteur d'entreprise : la charge utile n'est pas tapée par l'utilisateur
    • Documents empoisonnés dans une base de connaissances
    • Pages web, e-mails, tickets et dépôts de code comme vecteurs
    • Texte invisible : CSS, métadonnées, caractères de contrôle, homoglyphes
    • Chaînage : d'une injection indirecte à une action côté serveur
  • Sécurité des systèmes RAG
    • Anatomie d'un RAG et points d'entrée d'un attaquant
    • Absence de contrôle d'accès à la récupération : le RAG qui répond au-delà des droits de l'utilisateur
    • Propagation des permissions du document source jusqu'à la réponse
    • Exfiltration ciblée du corpus par requêtes successives
    • Attaques sur la base vectorielle : empoisonnement d'index, inversion d'embeddings
    • Cloisonnement multi-tenant et fuite entre clients
    • Journalisation : ce qu'on a le droit d'enregistrer, et ce qu'on y retrouve par accident
  • Agents et appel d'outils
    • Autonomie excessive : le risque naît des outils, pas du modèle
    • De la sortie du modèle à l'exécution : injection SQL, injection de commande, SSRF par outil
    • Exécution de code généré et bac à sable
    • Le confused deputy : l'agent agit avec ses privilèges, pas ceux de l'utilisateur
    • Boucles d'agents, coûts incontrôlés et déni de service économique
    • Sécurité du protocole MCP : serveurs non fiables, description d'outil malveillante, rug pull d'outil
    • Systèmes multi-agents : propagation d'une injection d'un agent à l'autre
  • Chaîne d'approvisionnement de l'IA
    • Provenance des modèles et formats de poids dangereux
    • Modèles et adaptateurs LoRA piégés
    • Dépendances du framework : chargeurs de documents, parseurs, serveurs MCP
    • Empoisonnement de données de fine-tuning et portes dérobées conditionnelles
    • Ce qu'un SBOM doit contenir pour un système IA

Mises en pratique :

  • Empoisonnement d'un document indexé conduisant au détournement du chatbot pour tous les utilisateurs
  • Exfiltration de données confidentielles via une injection indirecte et un rendu Markdown
  • Contournement du contrôle d'accès du RAG pour lire les documents d'un autre service
  • Reconstitution partielle du corpus par interrogation répétée
  • Injection SQL déclenchée depuis un outil d'agent
  • SSRF via un outil de récupération d'URL et accès aux métadonnées d'instance
  • Détournement d'un agent par un serveur MCP malveillant et une description d'outil piégée
  • Analyse d'un modèle publié : provenance, format des poids, signaux d'alerte

Jour 3 — Défenses, évaluation continue, gouvernance

  • Architecture de défense
    • Principe directeur : traiter la sortie du modèle comme une entrée utilisateur non fiable
    • Moindre privilège appliqué aux outils : périmètre, quotas, portée temporelle
    • Propagation de l'identité de l'utilisateur jusqu'à l'outil
    • Séparation des plans : ce qui est décidé par le modèle et ce qui est décidé par le code
    • Validation déterministe des sorties : schémas, listes d'autorisation, typage
    • Point de contrôle humain : où le placer pour qu'il serve à quelque chose
    • Bac à sable d'exécution : conteneurs, restrictions réseau, systèmes de fichiers éphémères
    • Motifs d'architecture robustes : dual LLM, plan puis exécution contrainte, capacités
  • Garde-fous et filtrage
    • Filtrage d'entrée et de sortie : ce que ça attrape réellement
    • Classificateurs de sécurité et modèles de modération : usages, angles morts, faux positifs
    • LLM juge : ses limites, et pourquoi il est lui-même attaquable
    • Détection de données personnelles et de secrets en sortie
    • Défense en profondeur : empiler des contrôles imparfaits sans se raconter d'histoires
    • Gestion des refus et expérience utilisateur : la sécurité qu'on désactive ne protège personne
  • Évaluation et red teaming automatisé
    • Pourquoi un test manuel ne suffit pas : non-déterminisme et régression silencieuse
    • garak : sondes, détecteurs, lecture d'un rapport
    • PyRIT : orchestrer une campagne d'attaque
    • promptfoo : jeux de tests sécurité intégrés à la CI
    • Construire son propre jeu d'attaques métier
    • Définir un seuil d'acceptation et le tenir dans le temps
  • Exploitation, détection et réponse
    • Que journaliser dans une application LLM, et comment le faire sans créer une nouvelle fuite
    • Signaux de détection d'une campagne d'injection
    • Limitation de débit et maîtrise des coûts
    • Traiter un incident sur une application LLM : rejouabilité, purge d'index, rotation de secrets
  • Cycle de développement et conformité
    • Insérer la revue sécurité IA dans le cycle projet
    • Divulgation de vulnérabilités et bug bounty appliqués aux LLM
    • Cadre réglementaire : AI Act, RGPD, souveraineté des données, et ce qui est exigible du développeur
    • Ressources de veille et communautés
  • Discussion libre

Mises en pratique :

  • Réécriture de l'architecture du lab pour imposer le moindre privilège aux outils
  • Mise en place d'une validation déterministe des sorties et vérification qu'elle résiste aux attaques du jour 1
  • Cloisonnement du RAG par identité utilisateur et nouvelle tentative d'exfiltration
  • Mise en bac à sable d'un outil d'exécution de code, puis tentative d'évasion
  • Campagne garak complète sur le lab et lecture du rapport
  • Écriture d'un jeu de tests sécurité métier avec promptfoo, branché en intégration continue
  • Attaque finale en temps limité contre l'application durcie, en deux équipes

Télécharger le programme

Thématiques de cette formation

FAQ

Nos formations sont éligibles à plusieurs dispositifs de financement, selon votre situation. Human Coders est certifié Qualiopi, ce qui permet la prise en charge par des organismes comme Pôle emploi, votre OPCO ou encore le CPF (Compte Personnel de Formation) pour certaines formations.

Pour en savoir plus, veuillez consulter notre page : Comment financer votre formation ?

Oui, la formation peut être proposée en présentiel ou en distanciel. Pour les inter-entreprises, les modalités (présentiel ou à distance) sont fonction de la session.

Nous pouvons organiser des sessions à d'autres dates ou dans d'autres villes (Bordeaux, Lille, Lyon, Marseille, Montpellier, Nantes, Nice, Paris, Strasbourg, Toulouse...)

Les formations se déroulent toujours en petit groupe de 3 à 6 stagiaires. Nous souhaitons que les formateurs et formatrices puissent passer un maximum de temps avec chacun·e.

Voici une journée type :

  • 9h : vous êtes accueillis par votre formateur·rice autour d'un petit déjeuner (croissants, pains au chocolat, jus de fruit, thé ou café...)
  • 9h30 : la formation commence
  • 12h30 : pause de midi. Le·a formateur·rice mangera avec vous. C'est l'occasion d'avoir des discussions plus informelles.
  • 14h : reprise de la formation
  • 18h : fin de la journée

8 raisons de participer à une formation Human Coders

  • Satisfaction client élevée : Un taux de statisfaction de 4,6/5 depuis 2012 (sur 1928 sessions réalisées). 99% des participants se disent satisfaits de nos formations
  • Approche pédagogique unique : Des formations en petit groupe, des formateurs passionnés et expérimentés, de véritables workshops... (Plus d'infos sur notre manifeste)
  • Catalogue de formations complet : 277 formations au catalogue, de quoi vous accompagner sur tout vos projets
  • Écosystème dynamique : Nous accompagnons les dev depuis 14 ans avec des initiatives comme Human Coders News, les Human Talks, le podcast ou encore notre serveur Discord
  • Financement facilité : Organisme certifié Qualiopi, indispensable pour que vous puissiez obtenir des aides au financement via votre OPCO
  • Références clients prestigieuses : De nombreux clients qui nous font confiance depuis des années
  • Accompagnement sur mesure : Nous vous proposons un accompagnement personnalisé par nos consultants pour vous aider dans vos projets au-delà de la formation
  • Valorisation professionnelle : Remise d'un diplôme, d'une attestation et d'une certification, suivant les formations effectuées, que vous pourrez afficher sur vos CV et réseaux sociaux

* Nombre de personnes ayant répondu au questionnaire de satisfaction sur cette formation depuis 2012