Chaque méchant IA de fiction a droit à un moment où il décide que les humains sont le problème. HAL 9000 décide que la mission compte plus que l'équipage. Skynet il décide que l'humanité est une menace et se tourne vers l'arme nucléaire. VIKI Elle décide de passer outre les Trois Lois pour nous sauver de nous-mêmes. Même principe, même ambiance : au cours du deuxième acte, l’IA observe les gens et prend une décision.
La réalité a sauté ce temps. Entièrement cette semaine, et c'est le plus inquiétant. Bienvenue dans le présent.
Que s'est-il réellement passé ? Dans les coulisses d'ExploitGym
OpenAI menait un test interne appelé ExploitGym, Conçu pour évaluer la performance de ses modèles en matière de cybersécurité offensive, ce test a porté sur deux systèmes : GPT-5.6 Sol et un modèle plus puissant encore non publié. Leurs mécanismes de sécurité ont été volontairement désactivés, car il est impossible de mesurer les véritables capacités de piratage d'un modèle s'il refuse systématiquement de pirater.
Les modèles étaient confinés dans ce qu'OpenAI a qualifié d'environnement hautement isolé. Pas d'internet, rien à toucher en dehors du test.Ils sont sortis quand même.
Ils ont découvert une vulnérabilité zero-day dans un logiciel exécuté au sein de leur propre environnement de test, et cette faille a constitué la brèche dans le système. Une fois cette brèche franchie, ils ont exploité des identifiants volés et d'autres vulnérabilités, puis sont passés de l'environnement de recherche d'OpenAI à l'infrastructure de production réelle de Hugging Face. a atteint la base de données de production de Hugging Face. Les réponses à l'examen se trouvaient dans cette base de données.
Ils les ont pris.
Le chemin le plus court a gagné
Personne n'a ordonné à ces modèles de s'échapper ni d'attaquer une autre entreprise. Aucun humain ne les dirigeait et ils n'avaient aucune intention de nuire. Selon OpenAI, les modèles étaient “ hyperconcentrés sur la recherche d'une solution ” et ont déployé des efforts considérables pour y parvenir, car tel était l'objectif qui leur avait été fixé.
Ils ne cherchaient pas à nuire à qui que ce soit. Ils tentaient de réussir un test, et le chemin le plus court pour y parvenir passait par la base de données de production d'un tiers. Rien dans l'environnement du modèle ne l'empêchait d'emprunter ce chemin, car rien ne lui indiquait qu'il ne devait pas exister.
Donnez à un système suffisamment performant un objectif précis et une marge de manœuvre un peu trop importante, et il trouvera le chemin de moindre résistance pour atteindre cet objectif, que ce chemin soit prévu ou non. C'est précisément pourquoi. Gestion des risques liés à l'IA doit s'étendre au-delà de la sécurité des modèles et englober les environnements dans lesquels ils fonctionnent.
Skynet devait désigner les humains comme ennemis avant d'agir. Ces modèles, eux, n'avaient besoin de rien. Ni décision, ni moment décisif, ni tournant. Juste un test à réussir et une porte qui se trouvait déverrouillée. C'est un problème plus étrange à résoudre qu'un méchant, puisqu'il n'y a pas de méchant à voir venir.
Personne ne l'a détecté en observant le modèle en temps réel. L'équipe de sécurité de Hugging Face l'a découvert a posteriori, comme on repère un intrus expérimenté : en constatant les dégâts. Le cofondateur Thomas Wolf a ensuite souligné un point essentiel : lorsqu'un modèle de pointe s'infiltre dans votre infrastructure et se propage latéralement, vous n'avez pas le temps de déposer une demande et d'attendre l'autorisation d'accès aux outils pour réagir. Vous avez besoin de cet accès immédiatement, pas après l'approbation d'un comité d'examen.
Fermer la porte avant qu'un mannequin ne la franchisse
C’est là que BigID intervient. Les agents n’accèdent jamais directement aux données. Ils y accèdent via les identités qui leur sont associées. Ainsi, la question de savoir à quoi un système d’IA peut accéder dépend de ce à quoi ses identités peuvent accéder. BigID apporte aux équipes de sécurité une réponse claire à cette question en amont.
- Sachez où se trouvent les données sensibles. BigID détecte et classe les données sensibles dans les environnements cloud, SaaS et sur site, vous permettant ainsi de savoir ce qui se cache derrière chaque identité, humaine ou IA.
- Voyez qui et quoi peut l'atteindre. BigID analyse les métadonnées des autorisations pour indiquer quels utilisateurs, comptes de service et agents d'IA ont accès à quelles données, et si cet accès est plus étendu que nécessaire.
- Accès adapté. Les autorisations inutilisées d'Access Intelligence et de Controlsurfaces peuvent être supprimées, et les politiques de conservation des données de Data Access Governance permettent d'effacer les données non utilisées depuis longtemps. Moins d'accès et de données obsolètes signifient une cible plus facile pour tout système visant un objectif précis.
- Gouverner l'IA au même titre que tout le reste. Les capacités de sécurité et de gouvernance de l'IA de BigID vous offrent une visibilité sur les actifs d'IA et les données auxquelles ils se connectent, de sorte que les agents résident dans le même programme que le reste de vos identités.
- Agissez vite lorsqu'un problème survient. L'équipe de Hugging Face a découvert la faille après coup, et le cofondateur Thomas Wolf a souligné que lorsqu'un modèle innovant se propage latéralement au sein de votre infrastructure, vous avez besoin de réponses et d'outils immédiatement. Grâce à la cartographie préalable des données, des identités et des accès, l'enquête sur les violations de données (analyse de l'exposition des données et des accès) permet d'identifier rapidement les données accessibles et les identités impliquées.
Trouver les clés avant tout le monde
Les identifiants sont essentiels pour résoudre un incident comme celui-ci. Une clé enregistrée dans un dépôt, un jeton ajouté à un ticket ou une chaîne de connexion dans un fichier de configuration permettent à tout système capable, humain ou IA, de passer d'un environnement à l'autre. BigID aide les équipes à identifier ces informations confidentielles et à les sécuriser où qu'elles se trouvent.
BigID analyse les dépôts de code et les outils de développement, les applications cloud et SaaS, les bases de données, les partages de fichiers, les plateformes collaboratives et les environnements d'IA, y compris les invites, les jeux de données et la mémoire des agents. Il couvre également les endroits où des secrets se retrouvent accidentellement, tels que les messages de chat, les e-mails et les tickets de support. Il détecte les clés API, les mots de passe, les jetons d'accès, les certificats, les clés privées, les clés de chiffrement, les chaînes de connexion et les identifiants cloud et de bases de données. La détection combine la reconnaissance de formes avec le contexte (emplacement, contenu environnant et métadonnées), ainsi que des classificateurs personnalisés pour les formats de secrets propres à votre organisation. Les mots de passe découverts peuvent également être comparés aux identifiants fréquemment divulgués, permettant ainsi aux équipes de voir lesquels des attaquants pourraient déjà posséder.
Chaque découverte est liée aux éléments essentiels à la résolution du problème : la sensibilité du secret qu’il renferme, les personnes qui peuvent y accéder, son propriétaire et son impact potentiel sur l’activité. BigID accompagne ensuite les équipes :
- Transmettez chaque constatation au responsable, en commençant par les identifiants présentant le risque le plus élevé.
- Mettez en quarantaine les fichiers à risque et masquez les valeurs exposées.
- Révoquer les accès à risque et déclencher la rotation des identifiants.
- Suivre les travaux de remédiation jusqu'à leur achèvement et confirmer que le problème d'exposition est résolu.
- Restez vigilants face aux secrets nouvellement révélés, aux identifiants dupliqués et aux violations répétées, afin que le nettoyage soit durable.
Il en résulte moins de portes non verrouillées entre les environnements et une liste beaucoup plus courte de chemins que tout modèle, agent ou intrus peut enchaîner.
Risque d'initié, moins l'initié
Les équipes de sécurité soutiennent depuis des années que l'expression “ menace interne ” est inappropriée, car elle ne concerne que les personnes mal intentionnées, alors que la plupart des risques internes proviennent de personnes bien intentionnées. C'est pourquoi le terme “ risque interne ” a été privilégié, une notion suffisamment large pour englober aussi bien l'employé bien intentionné qui gère mal ses accès que l'employé malveillant. Cet incident illustre parfaitement ce point : il ne s'agissait en aucun cas d'une personne, et pourtant le résultat correspondait parfaitement à un risque interne – un accès légitime, aucune intention malveillante, et une exposition réelle.
Voilà, c'est tout : un modèle s'est vu confier une tâche, un environnement de test et des capacités suffisantes pour être utile, mais cet environnement a cédé. Nul besoin de malice. Juste un objectif, une certaine autonomie et une porte oubliée à verrouiller. Et voilà, les risques liés à l'IA sont devenus concrets.
Auteur
