Quelles compétences renforcer pour sécuriser l’IA générative

Votre expertise en sécurité reste transférable, avec quelques hypothèses à revoir

Les professionnels de la sécurité qui abordent l’IA générative font face à un problème d’apprentissage plus limité qu’il n’y paraît au premier abord. L’injection, le risque lié à la chaîne d’approvisionnement, le contrôle d’accès défaillant, l’escalade de privilèges, l’audit et l’investigation forensique restent d’actualité. L’auteur non nommé de la courte formation GenAI Security Foundations, qui indique avoir quinze ans d’expérience dans la sécurité, exprime clairement cette continuité : « Les fondamentaux que nous connaissons déjà, comme les attaques par injection, le risque lié à la chaîne d’approvisionnement, le contrôle d’accès défaillant, l’escalade de privilèges, ainsi que les disciplines de l’audit et de l’investigation forensique, restent tous pertinents. Ils s’appliquent directement aux systèmes d’IA. »

Ces concepts familiers deviennent utiles dès lors que les praticiens savent où ils s’insèrent dans un système d’IA générative. Un grand modèle de langage (LLM), un modèle qui traite des prompts et génère des réponses en langage naturel, interagit avec des instructions, des informations récupérées, des utilisateurs et des outils d’une manière qui modifie certaines hypothèses de sécurité bien connues. Comme le dit l’auteur de la formation : « Ce qui change, c’est l’architecture de l’IA générative, et c’est ce que nous devons comprendre pour pouvoir la sécuriser. »

Cette différence architecturale définit le problème de montée en compétences. Un praticien disposant de solides connaissances en sécurité conventionnelle peut s’appuyer sur cette expertise en apprenant suffisamment d’architecture pour positionner correctement les contrôles existants. L’étape suivante consiste à comprendre les comportements propres à l’IA générative, car ils montrent où les contrôles et hypothèses familiers doivent évoluer.

Commencez par la fenêtre de contexte : l’architecture détermine la surface d’attaque

Le premier concept architectural est la fenêtre de contexte : les informations dont dispose un LLM lorsqu’il génère une réponse. Dans le modèle décrit par l’auteur de la formation, le LLM n’a pas de mémoire persistante propre. Son contexte actuel peut en revanche contenir des prompts et réponses antérieurs, des instructions fournies par le concepteur du système, ainsi que des documents chargés pour être utilisés pendant l’interaction.

Parce que le modèle agit à partir de ce contexte, le contrôle de son contenu devient un enjeu de sécurité. Lorsqu’un humain ou un autre agent automatisé soumet un prompt, le modèle lit le contexte disponible, génère sa réponse, puis s’arrête. L’auteur décrit le risque ainsi : « La fenêtre de contexte est la principale surface d’attaque. Si un attaquant peut influencer ce qui arrive sur ce tableau blanc, il peut influencer ce que fait le modèle. » Le tableau blanc mentionné dans la citation représente le contexte actuel du modèle ; la question opérationnelle est donc de savoir qui peut y placer des informations.

Dès lors que le contexte est traité comme une surface d’attaque, le niveau de confiance de chaque entrée devient important. La hiérarchie de l’auteur place l’entraînement intégré au modèle au niveau de confiance le plus élevé et compare cette position au firmware dans un système conventionnel. Le prompt système, qui donne au modèle des instructions au-dessus de la conversation, vient ensuite, tandis que l’entrée humaine ou agentique se situe tout en bas et exige la même suspicion et la même sanitation que les autres informations fournies par l’utilisateur.

Cette hiérarchie de confiance devient encore plus importante lorsque les organisations ajoutent la Retrieval Augmented Generation (RAG). La RAG récupère des informations dans les bibliothèques documentaires d’une organisation et place les éléments pertinents dans le contexte de travail du modèle afin qu’ils puissent influencer la réponse. Une revue de sécurité doit donc se demander quels documents peuvent entrer dans le contexte, comment ils ont intégré la collection de confiance de l’organisation, et si un attaquant peut manipuler des contenus que le modèle récupérera ensuite.

La récupération élargit les entrées que le modèle peut consommer, tandis que les agents élargissent ce que le modèle peut en faire. Un agent peut permettre à un modèle d’invoquer des outils qui envoient des e-mails, accèdent au web, interrogent des bases de données ou exécutent du code. Une fois ces capacités disponibles, un contexte manipulé peut influencer un modèle autorisé à modifier d’autres systèmes, ce qui signifie que la frontière de sécurité inclut à la fois les entrées du modèle et l’autorité accordée via ses outils.

Ensemble, le contexte, la récupération et les outils fournissent la cartographie architecturale nécessaire pour réutiliser des connaissances de sécurité établies. Les entrées utilisateur peuvent être hostiles, les documents récupérés peuvent être compromis, et les autorisations des outils peuvent dépasser ce qu’une tâche exige. Les praticiens expérimentés connaissent déjà ces types de risques, mais l’architecture de l’IA générative modifie l’endroit où ils apparaissent et où les contrôles doivent s’appliquer.

Une grande partie du modèle de menace est reconnaissable une fois cartographiée sur cette architecture

Une fois l’architecture établie, l’injection de prompt devient plus facile à analyser. L’injection de prompt se produit lorsqu’une entrée contrôlée par un attaquant atteint le contexte du modèle et modifie son comportement. L’auteur de la formation la compare, sur le plan conceptuel, à l’injection SQL : dans les deux cas, une entrée insuffisamment contrôlée atteint un composant dont l’attaquant cherche ensuite à influencer le comportement. Cette comparaison donne aux praticiens un concept de sécurité familier pour identifier la frontière des entrées et réfléchir à la sanitation, même si un LLM traite les entrées différemment d’une base de données.

Le même problème d’entrée peut survenir via des contenus que l’utilisateur n’a jamais saisis directement. Dans l’injection de prompt indirecte, un attaquant place une instruction malveillante dans un document ou une page web que le modèle récupère plus tard, permettant ainsi à un contenu hostile d’entrer dans le contexte via un contenu que l’application a choisi d’aller chercher. L’auteur compare ce comportement au cross-site scripting stocké, car le contenu malveillant peut être implanté d’abord puis rencontrer son environnement d’exécution plus tard. Les équipes de sécurité doivent donc examiner le chemin de récupération en plus des entrées utilisateur directes.

En remontant ce chemin de récupération, on arrive à l’empoisonnement de la RAG. L’auteur le caractérise comme une attaque de la chaîne d’approvisionnement, car l’attaquant compromet des données auxquelles le système fait confiance. Le modèle lui-même peut rester intact tandis que la collection de récupération d’une organisation lui fournit des informations empoisonnées et produit des réponses manipulées. L’intégrité du modèle et l’intégrité de l’information sont donc deux préoccupations de sécurité distinctes.

Dès lors que la sortie du modèle peut déclencher des actions, le principe du moindre privilège devient directement pertinent. Un agent compromis disposant d’un large accès aux outils présente, selon la comparaison de l’auteur, les caractéristiques fonctionnelles de sécurité d’un compte de service privilégié compromis. Un agent qui n’a besoin d’interroger qu’une seule base de données ne devrait recevoir que les privilèges nécessaires à cette tâche, tandis que les systèmes non liés et les opérations à plus haut risque doivent rester hors de son autorité.

Les actions aux conséquences plus importantes peuvent recourir à un autre contrôle établi : la séparation des tâches. L’auteur donne deux configurations : exiger la participation à la fois d’un agent et d’un humain, ou répartir la responsabilité entre deux agents utilisant des instructions ou des modèles différents. Dans les deux cas, cela réduit la capacité d’un chemin décisionnel compromis à accomplir seul une action conséquente. Les pratiques existantes de contrôle d’accès restent donc utiles lorsque la sortie du modèle est connectée à une autorité opérationnelle.

Ces correspondances montrent pourquoi l’expérience préalable en sécurité a une valeur pratique en IA générative, mais elles révèlent aussi où la simple transposition cesse de suffire. L’injection de prompt, l’empoisonnement de la récupération et les privilèges excessifs des agents relèvent de catégories familières : entrée hostile, compromission de la chaîne d’approvisionnement et autorité trop large. Cependant, le modèle qui prend des décisions possède des propriétés qui modifient les hypothèses concernant l’investigation, les frontières de sécurité et les tests.

Trois comportements de l’IA générative marquent la frontière où les hypothèses familières échouent

Cette limite conduit à trois comportements du modèle que l’auteur de la formation considère comme distinctifs : « Il existe trois comportements intrinsèques de l’IA générative qui ne ressemblent à rien de ce que nous avons rencontré auparavant. » Il s’agit du raisonnement opaque, de l’effondrement de la séparation entre instructions et données, et de la non-déterminisme. Chacun modifie une hypothèse que les équipes de sécurité utilisent couramment lorsqu’elles enquêtent sur un système, établissent une frontière ou valident un contrôle.

Le premier comportement, le raisonnement opaque, modifie ce qu’une investigation peut reconstituer. Selon l’auteur, le processus de décision d’un modèle ne peut pas être journalisé et rejoué de la manière attendue dans les logiciels conventionnels. Les journaux peuvent toujours capturer des événements périphériques comme une entrée ou une action effectuée via un outil, mais ces enregistrements ne reconstituent pas le processus décisionnel interne du modèle. Les équipes de réponse à incident peuvent observer des éléments de preuve importants autour d’une décision tout en restant incapables de retrouver pourquoi le modèle a pris cette décision précise.

Cette limite de reconstitution affecte aussi le travail de conformité, car les disciplines d’audit et d’investigation forensique dépendent de preuves qui soutiennent la responsabilité. L’expertise existante permet toujours à une équipe de savoir à quelles questions une investigation doit répondre, tandis que le modèle modifie les preuves capables d’y répondre. Les équipes de sécurité doivent distinguer les événements qu’elles peuvent capturer autour du modèle du raisonnement interne qu’elles ne peuvent pas recréer après coup.

Le deuxième comportement modifie la frontière entre instructions et données. Les architectures conventionnelles offrent aux praticiens une distinction utile entre commandes et informations stockées : dans les exemples de l’auteur, une base de données stocke des informations sans les traiter comme des instructions à exécuter, tandis qu’un processeur dispose de règles architecturales qui déterminent quelle mémoire est traitée comme exécutable. Ces séparations permettent aux systèmes d’appliquer des contrôles différents aux commandes et aux contenus.

Les modèles de langage affaiblissent cette séparation, car les instructions comme les informations peuvent arriver sous forme de langage dans le prompt et le contexte environnant. L’auteur indique qu’un modèle ne peut pas distinguer de manière fiable le code des données lorsque les deux y sont mêlés. Un document récupéré peut donc contenir un texte destiné à fournir des informations à l’utilisateur, tout en comportant aussi un langage conçu pour orienter le comportement du modèle.

Ce canal linguistique partagé explique l’importance particulière de l’injection de prompt indirecte. Assainir la requête immédiate de l’humain laisse d’autres entrées de contexte à examiner, car une page web ou un document RAG peut introduire des instructions plus tard dans le même chemin de traitement. Les équipes de sécurité doivent raisonner sur chaque partie capable d’influencer le contexte, y compris les sources que l’application choisit elle-même de récupérer.

Le troisième comportement, la non-déterminisme, modifie ce que les tests peuvent établir, car une même attaque contre une même défense peut produire des résultats différents lors d’exécutions distinctes. La répétabilité soutient de nombreux jugements conventionnels en matière de tests de sécurité : les équipes s’attendent souvent à ce qu’une condition de test produise des preuves stables quant à la résistance d’un contrôle face à une technique connue. Lorsque le comportement du modèle varie, un résultat observé fournit une preuve plus faible de ce qui se produira lors de l’exécution suivante dans une condition apparemment identique.

Cette variabilité modifie le niveau de confiance requis pour le red teaming et l’assurance. Un test qui ne déclenche pas un comportement nuisible une fois ne peut pas établir une résistance fiable lors d’une autre tentative, tandis qu’un exploit réussi démontre au moins une défaillance atteignable sans identifier toutes les conditions dans lesquelles elle apparaît. L’auteur de la formation soutient qu’un simple résultat ponctuel peut fournir une assurance insuffisante.

À partir de cette même variabilité, l’auteur avance l’affirmation plus large selon laquelle la surface d’attaque ne peut jamais être entièrement énumérée. Le problème va au-delà du nombre d’entrées possibles, car le comportement peut changer même lorsque l’attaque et la défense semblent rester identiques. L’évaluation de sécurité doit tenir compte de cette variabilité lorsqu’elle détermine ce qu’un ensemble fini de vérifications réussies peut établir au sujet du comportement du modèle.

Pris ensemble, ces comportements définissent les points où les méthodes établies doivent être révisées. Le raisonnement opaque limite la reconstitution, le mélange des instructions et des données affaiblit une frontière de sécurité familière, et la non-déterminisme affaiblit les conclusions tirées de résultats de test individuels. Ces différences font de l’architecture le point de départ du travail de sécurité sur l’IA générative et déterminent quelles parties des pratiques existantes peuvent être reprises sans changement.

Monter en compétences signifie apprendre où réutiliser un contrôle, et où réviser le modèle

Parce que la frontière est architecturale, le parcours d’apprentissage commence par l’architecture, puis cartographie les connaissances de sécurité existantes sur celle-ci. Les comparaisons précédentes fournissent des points d’ancrage pratiques : l’injection de prompt renvoie à l’expérience des injections, l’empoisonnement de la RAG à la réflexion sur la chaîne d’approvisionnement, et la compromission d’agent à la gestion des privilèges. L’auteur de la formation formule directement la conséquence professionnelle : « Vos façons de penser actuelles en tant que professionnel de la sécurité constituent une base précieuse lorsqu’il s’agit de sécuriser l’IA générative. Mais rester pertinent exigera d’apprendre à un rythme plus rapide que celui auquel la plupart d’entre nous ont été habitués. »

Ce rythme d’apprentissage est important parce que les capacités et les techniques d’attaque évoluent pendant même que les praticiens les étudient. S’appuyant sur quinze années dans la sécurité, l’auteur déclare : « Les capacités de l’IA générative, ainsi que les techniques d’attaque qui la ciblent, évoluent plus vite que n’importe quel changement technologique que j’ai vu en quinze ans dans ce domaine. La demi-vie de toute technologie que nous connaissons semble diminuer plus rapidement que jamais. » Cette déclaration reflète l’évaluation de l’auteur fondée sur son expérience professionnelle, et elle explique pourquoi l’expertise accumulée doit être associée à un apprentissage continu.

L’apprentissage continu, dans la prescription de l’auteur, commence par l’architecture et utilise l’expertise existante comme structure. « En tant que professionnel de la sécurité déjà en poste, les connaissances et compétences que vous avez acquises jusqu’à aujourd’hui comptent toujours. Vous devez simplement en ajouter de nouvelles rapidement. Mon conseil est de commencer par l’architecture, d’y cartographier ce que vous savez déjà, et de continuer à apprendre, idéalement plus vite que vous ne l’avez jamais fait auparavant. » Pour les praticiens, cela oriente l’attention vers le raisonnement opaque, le mélange des instructions et des données, et le comportement variable du modèle, là où les hypothèses établies exigent le plus de révision.

GenAI Security Foundations est la propre courte formation de l’auteur, construite autour de ce problème d’apprentissage. Son public visé est constitué de professionnels de la sécurité qui comprennent déjà la sécurité mais ont peu d’expérience de l’IA générative au-delà de son usage, et l’auteur la présente comme un point d’entrée pour les équipes. L’auteur a un intérêt commercial direct dans l’adoption de la formation ; la recommandation doit donc être lue comme le parcours d’apprentissage proposé par le créateur du cours, et non comme une validation indépendante.

Cette recommandation commerciale véhicule aussi la vision plus large de l’auteur sur ce que les équipes de sécurité doivent développer. L’auteur conclut : « En fin de compte, les organisations les plus performantes ne sont pas celles qui ont les équipes de sécurité les plus expérimentées, mais celles dont les équipes apprennent le plus vite. J’espère que ma nouvelle formation constituera un bon point de départ pour vous et vos équipes. » Dans cette perspective, la tâche immédiate d’un praticien de la sécurité consiste à continuer d’ajouter suffisamment vite des connaissances architecturales et spécifiques au modèle pour appliquer une expertise établie à un environnement d’IA générative en évolution.

Points clés

• S’appuyer sur l’expertise de sécurité existante : L’injection, la sécurité de la chaîne d’approvisionnement, le contrôle d’accès, le moindre privilège, l’audit et l’investigation forensique restent pertinents pour l’IA générative. Les responsables sécurité peuvent concentrer la montée en compétences sur la manière dont ces contrôles établis se transposent à l’architecture et aux workflows de l’IA.
• Traiter le contexte comme une surface d’attaque : Les prompts, les documents récupérés, les instructions système et les outils agentiques créent des voies permettant aux attaquants d’influencer le comportement du modèle. Les équipes de sécurité doivent gouverner ce qui entre dans la fenêtre de contexte et limiter l’autorité disponible via les outils connectés.
• Cartographier les menaces familières sur l’architecture de l’IA : L’injection de prompt, l’empoisonnement de la RAG et les agents sur-privilégiés ont des parallèles dans les pratiques de sécurité établies. Les équipes peuvent utiliser leur expertise existante en sécurité des entrées, en intégrité de la chaîne d’approvisionnement et en gestion des privilèges pour concevoir des contrôles appropriés.
• Réviser les hypothèses pour les comportements propres au modèle : Le raisonnement opaque limite la reconstitution forensique, le mélange des instructions et des données affaiblit les frontières de sécurité traditionnelles, et la non-déterminisme réduit le niveau d’assurance fourni par des tests individuels. Les programmes de sécurité et d’assurance ont besoin de pratiques de test et de preuve conçues autour de ces propriétés.
• Faire de l’apprentissage continu une composante des capacités de sécurité : Les capacités de l’IA générative et les techniques d’attaque évoluent rapidement, ce qui fait de la connaissance architecturale une exigence permanente. Les organisations de sécurité peuvent prioriser un apprentissage qui relie les comportements émergents des modèles aux contrôles et modèles de menace que les praticiens comprennent déjà.