Le problème du jailbreak de l'IA ne disparaît pas, et les cadres de conformité doivent rattraper leur retard

La vérité dérangeante sur les protections de l'IA

Voici quelque chose que la plupart des fournisseurs d'IA ne diront pas clairement : chaque modèle déployé aujourd'hui est vulnérable à une forme de jailbreaking. L'injection d'invite, les attaques par jeu de rôle, la manipulation indirecte des invites, la dérive du contexte. Ces techniques sont documentées, de plus en plus automatisées, et sont utilisées actuellement contre les déploiements d'IA en entreprise.

Mais beaucoup des vecteurs de jailbreak les plus dangereux ne ciblent pas du tout le modèle. Ils ciblent l'infrastructure autour : les fichiers de configuration, les paramètres de déploiement, les contrôles de surveillance et les pipelines d'audit qui régissent le comportement du modèle en production.

Désactivez le bon contrôle de sécurité, modifiez le bon paramètre de configuration, et vous n'avez pas besoin d'une invite intelligente. Vous avez déjà gagné.

C'est un problème classique d'intégrité de configuration. Et nous savons exactement comment l'aborder.

À quoi ressemble réellement la falsification de l'infrastructure IA

Lorsque nous parlons de sécuriser les systèmes d'IA du point de vue de l'infrastructure, nous parlons de protéger un ensemble spécifique d'actifs que la plupart des organisations n'ont pas encore placés sous un contrôle formel des changements :

Fichiers d'invite système et ensembles de règles de politique

De nombreux déploiements d'IA en entreprise reposent sur des fichiers de prompt système stockés qui définissent le comportement du modèle, les politiques de contenu et les restrictions d'accès. Ces fichiers sont stockés sur disque ou dans des magasins de configuration. Ils sont souvent modifiables par toute personne ayant accès au système de fichiers. Une modification d'une seule instruction dans un prompt système peut fondamentalement changer ce que le modèle fera ou ne fera pas, sans qu'aucune protection au niveau du modèle ne soit déclenchée.

Configuration du déploiement du modèle

Les paramètres régissant la température, la longueur du contexte, l'accès aux outils et l'activation du filtre de sécurité sont généralement stockés dans des fichiers de configuration ou des variables d'environnement. La modification non autorisée de ces paramètres peut supprimer les comportements de sécurité sans toucher au modèle lui-même.

Paramètres du filtre de sécurité et de la politique de contenu

De nombreuses plateformes d'IA mettent en œuvre le filtrage de contenu comme une couche distincte du modèle. Ces filtres sont eux-mêmes des logiciels, avec des fichiers de configuration, des définitions de politiques et des ensembles de règles sous contrôle de version. Les attaquants qui peuvent modifier ces fichiers peuvent discrètement abaisser le seuil de ce que le modèle produira.

Surveillance et pipelines de journalisation

Les pistes d’audit ne sont utiles que si elles sont intactes. Si un attaquant peut désactiver ou modifier la configuration des journaux pour un système d’IA, il peut masquer son activité et rendre l’enquête judiciaire beaucoup plus difficile.

Aucun de ces vecteurs d'attaque ne nécessite une invite sophistiquée. Ils requièrent un accès, une opportunité et l'absence de surveillance des changements. C'est précisément le vide que les outils d'intégrité de configuration sont conçus pour combler.

Où s'intègre Change Tracker

Netwrix Change Tracker a été conçu précisément pour ce type de problème : maintenir une référence connue et fiable sur les systèmes critiques et détecter toute déviation en temps réel.

Appliqué à l'infrastructure IA, cela signifie :

Surveillance de l'intégrité des fichiers pour les actifs de configuration AI

Change Tracker utilise le hachage cryptographique pour établir une base vérifiée pour chaque fichier surveillé. Si un fichier d'invite système, une définition de politique de sécurité ou une configuration de modèle change, que ce soit par une mise à jour légitime ou une modification non autorisée, Change Tracker le détecte immédiatement. Chaque changement est enregistré avec un horodatage, l'identité de l'utilisateur qui l'a effectué et l'attribut spécifique qui a changé. Il n'y a aucune ambiguïté. Il n'y a aucun contexte manquant.

Sous Windows, le pilote minifiltre Gen 7 Agent fonctionne au niveau du noyau, à l'altitude 388790 dans la pile Windows Filter Manager, capturant les modifications d'E/S de fichiers en temps réel sans verrouiller les fichiers ni ajouter de latence. Sous Linux, l'intégration Sysdig capture qui a effectué la modification au niveau de l'appel système. Dans les deux cas, la détection est continue et d'une précision médico-légale.

Gestion de la configuration de sécurité contre une base renforcée

CIS Benchmarks donnent aux organisations un point de départ prescriptif pour le durcissement des configurations des serveurs. Change Tracker est livré avec plus de 250 rapports de conformité préconstruits mappés sur CIS, NIST 800-53, PCI DSS, HIPAA, DISA STIG, et plus encore, couvrant Windows, Linux, bases de données et dispositifs réseau. Pour l'infrastructure IA spécifiquement, les mêmes principes de durcissement s'appliquent : réduire la surface d'attaque, appliquer le moindre privilège au niveau du système d'exploitation, et vérifier en continu que la configuration déployée est bien celle qui fonctionne réellement.

Contrôle des modifications en boucle fermée pour les modifications des systèmes d'IA

Toute modification légitime d’un déploiement d’IA doit être autorisée avant qu’elle ne se produise. Le contrôle des modifications en boucle fermée de Change Tracker s’aligne directement sur les principes ITIL et COBIT : les modifications planifiées sont documentées à l’avance, suivies dans une fenêtre de changement approuvée, et automatiquement rapprochées avec l’activité observée. Les modifications non planifiées, c’est-à-dire les modifications qui ne correspondent pas à une demande de changement autorisée, apparaissent immédiatement sous forme d’alertes.

Pour les équipes utilisant ServiceNow, BMC Remedy ou d'autres plateformes ITSM, les intégrations natives de Change Tracker importent automatiquement les demandes de changement et les utilisent pour classifier les changements détectés. Si votre infrastructure AI change en dehors d'un ticket approuvé, vous êtes informé. Si elle change à l'intérieur d'un ticket, le bruit est supprimé et votre équipe peut se concentrer sur ce qui compte vraiment.

Couverture avec agent et sans agent dans des environnements hybrides d'IA

L'infrastructure IA ne se trouve pas en un seul endroit. Le calcul peut être sur site. L'hébergement du modèle peut être sur AWS ou Azure. La gestion de la configuration peut utiliser un mélange d'outils. Change Tracker prend en charge la surveillance basée sur agent via le Gen 7 Agent sur Windows et Linux — et la couverture sans agent via SSH et WMI pour les systèmes où le déploiement d'agent n'est pas pratique. Les environnements ESXi et cloud sont couverts par une collecte sans agent basée sur PowerCLI. Le modèle de surveillance correspond au modèle d'infrastructure.

Pistes d’audit immuables pour la conformité et la criminalistique

Lorsqu'il y a un problème dans un système d'IA, qu'il s'agisse d'un résultat inattendu, d'une défaillance de sécurité signalée ou d'une compromission suspectée de l'infrastructure, la première question est toujours : qu'est-ce qui a changé ? Change Tracker conserve un enregistrement continu et inviolable de chaque modification de configuration sur les systèmes surveillés. Cet enregistrement est immédiatement disponible, consultable et exportable dans des formats qui satisfont les auditeurs et soutiennent les enquêtes sur les incidents.

Là où la réglementation fait défaut

La loi européenne sur l'IA est une étape significative. Le cadre de gestion des risques liés à l'IA de NIST est réfléchi. Mais aucun des deux ne traite adéquatement des contrôles de sécurité opérationnels qui doivent être en place autour des déploiements d'IA, le type de contrôles que les équipes de sécurité mettent réellement en œuvre et audite.

Voici ce que je considère comme les exigences de base et obligatoires pour tout déploiement d'IA en entreprise. Les CIS Controls vont déjà dans ce sens, même si les directives spécifiques à l'IA ne sont pas encore complètement arrivées :

Surveillance continue de la configuration

Les configurations du système d'IA doivent être surveillées en continu pour détecter toute modification non autorisée : déploiements de modèles sur site tels que les versions, paramètres et garde-fous ; environnements d'exécution des agents tels que les invites système, fichiers d'identité, mémoires et définitions d'outils ; ainsi que l'infrastructure externe à laquelle les agents s'authentifient et écrivent, comme les serveurs MCP, les coffres-forts de clés, les magasins d'identifiants, les pipelines d'audit et les places de marché de compétences. Non révisé trimestriellement. Non vérifié lors du déploiement. En continu. Avec alertes en temps réel dès qu'une déviation par rapport à la base approuvée est détectée.

Gestion formelle des changements

Toute modification d’un système d’IA doit nécessiter une autorisation, une documentation et une révision. Pas comme une lourdeur bureaucratique, mais parce que les changements non planifiés sont la manière dont les attaquants et les accidents créent des failles. Le contrôle des modifications en boucle fermée transforme le changement d’un risque en preuve.

Surveillance de l'intégrité des fichiers pour les actifs IA

Les fichiers d'invite système, les règles de sécurité et les fichiers de configuration du modèle doivent respecter les mêmes exigences d'intégrité que les fichiers critiques du système d'exploitation. Vérification du hachage SHA-256. Comparaison de référence. Alerte immédiate en cas de déviation. C'est une pratique standard pour la conformité PCI DSS. Cela devrait également être une pratique standard pour les déploiements d'IA.

Pistes d’audit immuables

Chaque action administrative, modification de configuration, modification de politique et événement de sécurité affectant l'infrastructure IA doit être consigné de manière à ne pas pouvoir être facilement modifié ou effacé. Ce journal est à la fois une ressource médico-légale et un artefact de conformité.

Privilège minimal pour l'infrastructure IA

L'accès privilégié aux environnements de déploiement d'IA doit être géré de la même manière que nous gérons l'accès à Active Directory ou aux bases de données critiques, avec des contrôles stricts, une responsabilité totale et une surveillance continue de qui a accès et de ce qu'il en fait.

L'impératif de défense en profondeur

L'accent mis sur les mesures de protection au niveau des invites, bien que important, a créé une fausse impression de ce que signifie réellement la sécurité de l'IA. Les organisations évaluent les fournisseurs d'IA en fonction de la résistance de leurs modèles aux jailbreaks lors de tests contrôlés, tout en laissant l'infrastructure environnante essentiellement non gouvernée.

Les attaquants le savent déjà. Ils ne passent pas tout leur temps à créer des invites astucieuses. Ils recherchent le maillon le plus faible de la chaîne opérationnelle : un fichier de configuration non surveillé, un compte de service avec des privilèges excessifs, un filtre de sécurité désactivé discrètement, un changement que personne n’a enregistré.

Ce ne sont pas des problèmes de modèle. Ce sont des problèmes de configuration et de contrôle des modifications. Et ils ont des solutions simples que les organisations gérant des charges de travail réglementées savent déjà déployer.

Ce qui doit se passer ensuite

Les régulateurs doivent agir plus rapidement et avec précision. Les principes généraux concernant la gouvernance de l'IA sont un point de départ, mais ce dont les équipes de sécurité ont réellement besoin, ce sont des exigences de contrôle concrètes et auditées : celles que vous pouvez mettre en œuvre, tester et vérifier en continu.

Des contrôles de base obligatoires modélisés sur ce que CIS Controls prescrit déjà pour l'infrastructure informatique, étendus explicitement aux environnements de déploiement de l'IA, offriraient aux organisations un point de départ pratique et donneraient aux auditeurs un référentiel significatif. Surveillance de la configuration. Gestion des changements. Vérification de l'intégrité des fichiers. Exigences relatives aux pistes d'audit. Ce ne sont que des pratiques de sécurité disciplinées appliquées à un contexte qui a jusqu'à présent échappé à l'examen qu'il mérite. Nous savons à quoi ressemblent ces solutions. Les outils existent. Les cadres existent. Il est temps de rendre ces contrôles obligatoires.