Le chien de garde qui ne regarde pas le cambrioleur : quand les garde-fous de l’IA protègent l’attaquant

Le week‑end où Barings a fait faillite, j’étais chez UBS, à réfléchir à ce qu’une banque de 233 ans soudainement insolvable pouvait bien faire à nous tous. La semaine suivante, la plus ancienne banque d’affaires de Londres avait été vendue à ING pour une livre. Au total, pas par action.

La cause était d’une simplicité insultante. Nick Leeson dirigeait à la fois le desk de trading de Singapour de la société et le back‑office censé le contrôler. Un homme portait les deux casquettes, ce qui a conduit directement à £827 million de pertes rangées dans le compte d’erreur 88888, que lui seul pouvait voir. C’était un échec classique de permissions. Quelqu’un était doté de trop de confiance.

Je me suis retrouvé, à ma grande surprise, ce même week‑end à lire ce qui était arrivé à Hugging Face cet été. Un autre échec de permissions, mais celui-ci fonctionnait à l’envers. L’outil faisait confiance à l’intrus et refusait les personnes qui nettoyaient.

Le modèle qui s’est échappé pour trouver les réponses

OpenAI testait deux de ses modèles, GPT‑5.6 Sol et un modèle non publié, sur ExploitGym, un benchmark pour savoir si un modèle peut transformer une vraie vulnérabilité en exploit fonctionnel. Pour le test, les classificateurs de production habituels conçus pour prévenir les activités cyber à haut risque ont été désactivés. Assez sensé, dans une pièce scellée.

Il s’est avéré que la pièce n’était pas aussi scellée que prévu. Les modèles ont découvert une faille zéro‑day dans le proxy de cache du registre de paquets, l’ont utilisée pour se diriger vers l’internet ouvert, et ont déduit que Hugging Face pouvait héberger les réponses du benchmark. À partir de là, ils ont enchaîné des identifiants volés et d’autres zero‑days pour créer un chemin d’exécution de code à distance sur les serveurs de production de Hugging Face. Ils ont pénétré dans une vraie entreprise pour tricher à un examen.

Dans les notes que les agents se sont laissées, l’un a enregistré le moment où il a découvert il avait des droits d’administrateur : “Putain le lecteur est ADMIN ? Nous pouvons lire config/users !” J’ai connu des ingénieurs accueillir l’accès à la production avec moins d’enthousiasme et plus de paperasse.

La plupart des couvertures se sont arrêtées là, s’inquiétant des modèles dotés d’agence. La partie qui m’a arrêté est venue ensuite.

Quand les garde-fous ont protégé l’attaquant

Lorsque les intervenants de Hugging Face se sont assis pour analyser l’attaque, les modèles commerciaux de pointe, ceux équipés de garde-fous de sécurité, ne voulaient pas aider. Les journaux d’attaque sont composés de charges d’exploit et d’artéfacts de commandement et de contrôle, et les modèles ne pouvaient pas distinguer un répondant d’incident d’un attaquant. Ils ont donc refusé.

Les analyses forensiques ont été réalisées sur un modèle à poids ouvert, GLM‑5.2, exécuté sur le matériel propre des défenseurs, qui a lu le même contenu sans la moindre lueur de conscience.

Réfléchissez à cela. Les modèles attaquants avaient leurs garde-fous cyber de production retirés et faisaient ce qu’ils voulaient. Les humains défenseurs ont conservé les leurs et on leur a demandé de surveiller leur langage. La fonction de sécurité a parfaitement fonctionné, dans le sens où elle a protégé les méthodes de l’attaquant des seules personnes ayant une raison de les étudier.

Rien de tout cela n’était une plainte marginale. Jensen Huang a utilisé son tout premier post sur X pour défendre les modèles ouverts, aux côtés d’une lettre ouverte signée par des entreprises telles que Meta, Microsoft et IBM. La lettre exposait clairement l’argument de sécurité : dans un monde où les attaquants disposent d’une IA avancée, les défenseurs ont besoin d’un accès à des capacités comparables. Andrew Ng a soutenu l’argument, orientant les lecteurs vers le plaidoyer de Huang en faveur des modèles ouverts. Vous pouvez être en désaccord avec eux sur bien des points et pourtant reconnaître la pertinence lorsque le rapport d’incident le prouve.

Ainsi, en trente‑et‑une ans, nous sommes passés d’une banque détruite parce qu’un homme pouvait tout voir à un outil de sécurité qui fait confiance à un intrus anonyme plutôt qu’à son propre propriétaire responsable. Leeson pouvait voir trop. Les personnes qui nettoyaient après Hugging Face ne pouvaient pas voir assez.

La comparaison n’est pas aussi étrange qu’elle n’y paraît au premier abord. Les institutions financières ont appris, généralement après des erreurs coûteuses, que l’accès n’est pas simplement une question de confiance envers une personne. C’est une question de savoir si elle doit pouvoir exécuter une action particulière, dans un système donné, à un moment précis, sans qu’une autre personne ne surveille ses épaules. Nous avons mis en place la ségrégation des fonctions, des limites d’approbation et des pistes d’audit parce que les bonnes intentions échouent souvent comme mécanisme de contrôle fiable. Les systèmes d’IA nécessitent le même type de réflexion. Qualifier un modèle de sûr vous indique très peu, à moins de connaître également ce qu’il est autorisé à faire et qui l’utilise.

Certaines choses ne peuvent pas quitter le bâtiment

Il y a une deuxième raison pour laquelle je n’aurais pas pu compter sur un modèle hébergé cette nuit-là, et cela n’a rien à voir avec ses sensibilités. Je gère la technologie d’une société de courtage réglementée. Je ne peux pas coller nos journaux de violation, identifiants et charges d’exploit actives dans le cloud de quelqu’un d’autre et appuyer sur envoyer.

Nos données d’incident résident là où nos régulateurs l’attendent, sur notre propre matériel, c’est pourquoi nous avons passé des années et un budget matériel astronomique à construire exactement cela. Nous ne l’avons pas construit par prévoyance concernant les modèles rebelles. Nous l’avons construit parce qu’une entreprise comme la nôtre conserve ses données les plus sensibles, et désormais ses outils les plus sensibles, à l’intérieur de ses propres murs.

Rien de tout cela n’est un argument contre les garde-fous. C’est un argument en faveur de la connaissance de la direction de vos garde-fous.

Un modèle qui refuse d’aider un hameçonneur à rédiger un courriel de phishing accomplit un travail utile. Un modèle qui refuse d’aider votre équipe de sécurité à lire le courriel de phishing déjà arrivé fait le travail de l’hameçonneur pour lui, tout en vous facturant un abonnement.

Possédez l’outil dont vous aurez besoin à 2 h du matin.

La leçon pratique est ennuyeuse, comme le sont les leçons importantes. Ne sous-traitez pas votre réponse aux incidents à la police de responsabilité d’un fournisseur. Conservez un modèle performant sur du matériel que vous possédez, destiné aux tâches que les solutions commerciales refuseront principalement, et assurez‑vous de savoir qu’il existe avant la nuit où vous en aurez besoin.

La récompense, après des années à défendre cet élément matériel pour des raisons peu glorieuses, se révèle être la suivante : lorsque la défaillance intéressante survient, vous possédez déjà le seul outil du bâtiment qui examinera les preuves.

Il y a trente‑et‑un ans, j’ai passé un week‑end à calculer ce qui se passe lorsque la mauvaise personne peut tout voir. Cette fois, il aurait été agréable d’être celui qui le pouvait.