Questions d'entretien AI & LLM Security

Une autonomie sans limites associée à l'accès aux outils, c'est l'« agence excessive » d'OWASP LLM : un modèle manipulé ou en erreur peut entreprendre des actions destructrices. Encadrez-le avec des outils au moindre privilège, exigez une confirmation humaine pour les opérations irréversibles, et gardez des permissions restreintes et auditées. Lui faire confiance ou lui donner les droits admin élargit le rayon d'impact, et masquer un bouton dans l'interface ne change rien à la capacité sous-jacente du modèle à appeler l'action.

Le contenu non fiable que le modèle ingère peut porter des instructions — c'est l'injection de prompt indirecte. Vous ne pouvez pas empêcher totalement le modèle d'être influencé, alors isolez le contenu récupéré en tant que donnée, limitez les outils/permissions de l'agent, exigez une confirmation pour les actions sensibles, et évitez de lui confier des secrets qu'il pourrait être contraint de divulguer. Supposer que le modèle ignorera simplement les instructions injectées, c'est exactement le mode de défaillance exploité.

Un modèle tiers est une dépendance de chaîne d'approvisionnement : vérifiez qu'il provient d'une source de confiance avec des sommes de contrôle/signatures correspondantes, que sa licence autorise votre usage, et que le format de fichier n'exécute pas de code arbitraire au chargement (préférez une sérialisation sûre aux formats de type pickle). « Il se charge » et « la vitesse de téléchargement » ne disent rien de la confiance, et supposer que les modèles publics sont sûrs ignore les risques réels d'empoisonnement et de désérialisation.

C'est la « gestion incorrecte des sorties » d'OWASP LLM : une sortie de modèle influencée par l'entrée utilisateur peut devenir une injection de commande lorsqu'elle est transmise à un shell ou à eval. Traitez-la comme non fiable — faites correspondre les intentions à une petite liste blanche d'actions paramétrées, validez strictement et exécutez dans un bac à sable plutôt que de lancer des chaînes générées brutes. Faire confiance à la sortie, augmenter la limite de jetons ou se contenter de journaliser n'arrête en rien l'injection.

Envoyer des données personnelles de clients à une API externe les expose au traitement et à la conservation d'un tiers et peut enfreindre des obligations de confidentialité. Minimisez et anonymisez ce qui est envoyé, confirmez les conditions d'usage/conservation du fournisseur et un accord de traitement des données (ou des garanties de non-entraînement), ou passez à un déploiement privé pour les données sensibles. La longueur de la clé n'a aucune importance, et envoyer plus de données personnelles augmente l'exposition.

Si la récupération extrait n'importe quel document indexé quelle que soit la personne qui interroge, le modèle restituera fidèlement des données que l'utilisateur ne devrait pas voir — c'est une faille d'autorisation, pas une hallucination. Imposez les permissions de l'utilisateur au niveau du document au moment de la récupération, pour que seuls les fragments autorisés entrent dans le contexte. Un prompt système plus long est contournable et n'implémente aucun contrôle d'accès, la température n'a aucun rapport, et un autre modèle présente la même faille.

S'entraîner sur des données utilisateurs non vérifiées permet à un attaquant d'empoisonner le modèle — en y implantant des portes dérobées, des déclencheurs ou un comportement biaisé qui surgit plus tard. Maîtrisez-le par la vérification et le filtrage des données, le suivi de provenance, la détection d'anomalies sur le jeu de données et l'évaluation du comportement du modèle après l'entraînement. « Plus de données, c'est mieux » ignore l'intégrité, et le vrai souci est l'empoisonnement, pas la vitesse ni l'espace disque.

L'injection de prompt ne se résout pas entièrement avec plus de texte ; supposez que le modèle peut être détourné et contraignez ce qu'il est autorisé à FAIRE. Donnez aux outils le moindre privilège, conditionnez les actions à fort impact à une confirmation humaine, et validez ou isolez les appels d'outils avant d'agir (OWASP LLM « excès d'autonomie » et « gestion inadéquate des sorties »). Implorer dans le prompt système est contournable. Une température plus élevée n'ajoute que de l'aléa, et la seule journalisation enregistre le dommage sans empêcher l'action injectée.

L'IA aide le SOC en triant et dédupliquant les alertes, en résumant les incidents, en enrichissant le contexte, en rédigeant des détections et en accélérant l'intégration des analystes — réduisant la fatigue et le temps de présence. Les risques : conclusions hallucinées ou fausses avec assurance, biais d'automatisation où les analystes cessent de vérifier, prompt injection via des données de logs ou d'alertes contrôlées par l'attaquant, fuite de données sensibles vers des modèles tiers, et adversaires utilisant les mêmes outils. Gardez un humain dans la boucle, vérifiez les sorties et isolez les entrées non fiables.

La prompt injection directe, c'est quand un utilisateur tape des instructions adverses directement dans le prompt pour écraser le system prompt ou les règles de sécurité. La prompt injection indirecte cache des instructions malveillantes dans du contenu externe que le modèle ingère ensuite — une page web, un e-mail, un PDF ou un document RAG — si bien que l'attaque se déclenche sans que la victime ne la tape jamais. L'injection indirecte est le plus grand risque parce que l'attaquant et la victime sont des personnes différentes, et que la charge arrive via des données que l'application fait implicitement confiance.

Le traitement non sécurisé des sorties consiste à faire confiance à ce que le modèle renvoie et à le transmettre à un système en aval sans validation ni encodage. Comme la sortie du modèle est influençable par l'attaquant, l'afficher en HTML brut cause du XSS, l'envoyer à un récupérateur d'URL cause du SSRF, et la passer à un shell ou une requête SQL cause une command ou SQL injection. La solution est de traiter la sortie du modèle exactement comme une entrée utilisateur non fiable : encodage de sortie sensible au contexte, allowlisting, assainissement et paramétrage avant qu'elle n'atteigne un sink.

Un jailbreak vise l'alignement de sécurité du modèle : il pousse le modèle à produire du contenu que le fournisseur a cherché à interdire, comme des instructions nuisibles. La prompt injection vise la hiérarchie d'instructions de l'application : elle écrase le system prompt du développeur ou détourne le comportement du modèle dans une application, souvent via des données non fiables. Les jailbreaks attaquent le modèle ; la prompt injection attaque le système environnant. Ils se recoupent, mais l'objectif et la frontière de confiance franchie diffèrent.

La chaîne d'approvisionnement LLM couvre les modèles de base, les variantes fine-tunées, les jeux de données, les embeddings, les plugins, les bibliothèques et la plateforme d'hébergement — chacun un endroit où introduire du risque. Les menaces incluent le téléchargement de poids de modèle altérés ou avec backdoor, des fine-tunes malveillants, des jeux de données empoisonnés ou à la licence viciée, des plugins vulnérables ou sur-permissionnés et des dépôts de modèles typosquattés. Défenses : sourcer les modèles depuis des registres de confiance, vérifier l'intégrité et la provenance, maintenir un AI bill of materials, scanner et épingler les dépendances, vérifier les plugins et appliquer le moindre privilège à tout ce que le modèle intègre.

Le NIST AI Risk Management Framework (AI RMF 1.0) est un cadre volontaire et fondé sur le risque pour gouverner une IA digne de confiance tout au long de son cycle de vie. Son cœur est constitué de quatre fonctions : Govern (culture, politique, responsabilité — et elle traverse les autres), Map (contexte et identification des risques), Measure (évaluer et suivre les risques) et Manage (prioriser et répondre). Il définit aussi des caractéristiques de fiabilité — valide et fiable, sûr, sécurisé et résilient, responsable et transparent, explicable, respectueux de la vie privée et équitable. Il complète des listes techniques comme l'OWASP LLM Top 10 au niveau du programme.

L'OWASP Top 10 for LLM Applications est la liste consensuelle des risques les plus critiques lorsqu'on construit avec de grands modèles de langage. L'édition 2025 couvre la prompt injection, la divulgation d'informations sensibles, la supply chain, l'empoisonnement des données et du modèle, le traitement non sécurisé des sorties, l'excessive agency, la fuite de system prompt, les faiblesses des vecteurs et embeddings, la désinformation et la consommation non bornée. Elle existe parce que les listes appsec traditionnelles ne capturent pas les modes de défaillance propres aux LLM, et elle donne aux équipes un vocabulaire commun et une checklist pour prioriser les contrôles.

La sécurité RAG, c'est traiter chaque document récupéré comme une entrée non fiable. Risques clés : prompt injection indirecte cachée dans le contenu récupéré, empoisonnement de la base de connaissances ou des embeddings, et absence d'autorisation par utilisateur si bien que le modèle renvoie des données auxquelles l'utilisateur n'a pas accès. Les défenses incluent le contrôle d'accès appliqué à la récupération, la provenance du contenu et la vérification à l'ingestion, traiter le texte récupéré comme des données et non des instructions, la validation des sorties et l'isolement du magasin de vecteurs par locataire.

Un agent LLM transforme du texte en actions via des outils et des function calls, donc une prompt injection devient une action réelle — le risque d'excessive agency. Sécurisez-le en donnant à chaque outil le moindre privilège et la portée dont il a besoin, en validant et contraignant les arguments d'outils, en exigeant une confirmation humaine pour les actions sensibles ou irréversibles, en sandboxant l'exécution, en limitant le débit et en budgétant les appels, et en journalisant chaque invocation d'outil. Ne laissez jamais la sortie du modèle, influencée par des données non fiables, autoriser directement une action à fort impact.

Les applis LLM divulguent des données de plusieurs façons : le modèle mémorise et restitue des données d'entraînement ou de fine-tuning sensibles, le system prompt (qui peut contenir des secrets ou de la logique) est extrait, des documents RAG récupérés exposent des données que l'utilisateur ne devrait pas voir, et le contexte d'un utilisateur ou d'une session déborde sur un autre. La prévention passe par la minimisation des données avant l'entraînement, ne jamais mettre de secrets dans les prompts, appliquer l'autorisation par utilisateur à la récupération, le filtrage des sorties et la rédaction de PII, et l'isolement par locataire.

L'empoisonnement des données d'entraînement, c'est quand un attaquant altère les données utilisées pour pré-entraîner, fine-tuner ou créer les embeddings d'un modèle afin que le modèle résultant se comporte de façon malveillante — en intégrant un déclencheur de backdoor, en injectant du biais ou en dégradant la précision. Il exploite le fait que les modèles aspirent et font confiance à de vastes jeux de données souvent issus du web. Les défenses incluent la curation et la signature des sources de données, les vérifications de provenance et d'intégrité, la détection d'anomalies sur les données d'entraînement, le versionnage des jeux de données, et la limitation de qui peut contribuer aux corpus d'entraînement et RAG.