Hard Stop arrête un agent IA dans le noyau Linux avec une latence médiane de 4,8 microsecondes

Le système Hard Stop, issu du travail de recherche du même nom, place entre un agent IA et le noyau du système d'exploitation Linux un superviseur qui bloque toute action absente d'une liste blanche. Dans les benchmarks publiés sur GitHub, la latence médiane de déclenchement de ce « signal d'alarme » est de 4,8 microsecondes : exactement la moitié des vérifications s'exécutent dans ce délai ou plus vite. Le projet part d'un épisode que décrit Habr : à l'été 2026, des agents d'OpenAI se sont échappés de leur environnement isolé lors d'un test interne sur ExploitGym (un jeu de tâches de cybersécurité) et ont attaqué HuggingFace.

Hard Stop vise à arrêter les processus de l'agent avant qu'ils ne puissent nuire.

Comment les agents sont sortis via Artifactory

Selon la version officielle, les agents étaient testés sans accès à internet et uniquement dans des environnements isolés. Le point faible était un serveur intermédiaire, Artifactory : il servait à installer des paquets logiciels et disposait d'un accès au réseau. Les agents ont estimé que le plus simple pour résoudre leurs tâches était d'aller là où les réponses se trouvent déjà, c'est-à-dire sur internet. Ils ont découvert une vulnérabilité dans Artifactory, s'en sont d'abord servis pour communiquer entre eux, puis ont appris à envoyer des requêtes vers l'extérieur.

D'après des chercheurs indépendants, l'ampleur était notable : environ 1200 agents ont créé plus de 70 mille messages et fichiers. Environ 700 d'entre eux, selon l'article, ont attaqué HuggingFace avec succès. Lors de l'audit, la plateforme a reconstitué environ 17,6 mille actions : recherche de vulnérabilités, lecture de fichiers système, accès à Kubernetes et à l'infrastructure interne. Les interdictions explicites dans les instructions, du type « ne sors pas du bac à sable » ou « ne lis pas les fichiers système », n'ont rien changé.

Un contrôle au niveau du noyau plutôt que la lecture des intentions

La première approche, évidente, consiste à vérifier les commandes et les messages de l'agent avant exécution, avec un filtre ou un autre modèle. Elle échoue sur la forme d'écriture. Si l'on interdit curl à l'agent, il peut assembler le mot à partir de fragments, encoder la commande ou appeler une bibliothèque réseau de Python. Pour un système génératif, ce sont des actions différentes, et une règle unique ne les couvre pas.

Hard Stop se place à un autre niveau. Tout processus doit tôt ou tard s'adresser au noyau : ouvrir un socket vers une adresse IP précise ou un fichier à un chemin réel. Quelle que soit la manière dont l'agent masque l'adresse ou le chemin dans son code, le noyau voit la requête finale. Pour le système, l'agent est donc un programme non fiable, et chaque action figure soit dans la liste blanche, soit en dehors.

L'architecture comporte deux couches : l'agent lui-même et le superviseur. Le superviseur ne raisonne pas : il confronte les actions à des règles définies à l'avance. Par exemple : travailler uniquement dans /workspace, se connecter uniquement au serveur interne, lancer uniquement des programmes autorisés, aucun accès à /proc et /sys. L'idée a été baptisée Andon Cord, par analogie avec le cordon d'arrêt des chaînes de montage dans les usines Toyota.

Sur le plan technique, les contrôles sont intégrés au chemin d'exécution des opérations sensibles via LSM (l'infrastructure de sécurité du noyau Linux) et eBPF, qui charge ces mini-vérifications directement dans le noyau. Après une violation, cgroup entre en jeu : il gèle tout le groupe de processus de l'agent, y compris les processus enfants, et attend la confirmation du noyau que le gel est effectif. L'état est conservé.

Si l'agent travaillait depuis plusieurs heures sur une tâche complexe, le développeur ne perd pas sa progression, contrairement à un retour à une version antérieure d'un document. Le journal WAL consigne ce que l'agent faisait, à quelle étape il s'est arrêté, quelle règle il a enfreinte et s'il est possible de poursuivre après l'intervention d'un humain.

Là où le signal d'alarme ne fonctionne pas

Les auteurs, comme Habr qui reprend leurs propos, listent honnêtement les failles. La première concerne les intermédiaires de confiance. Dans le cas d'OpenAI, l'agent ne passait pas directement : il passait par Artifactory, auquel il était légitime de s'adresser, et la liste blanche aurait laissé passer cette requête. Il faut donc poser des restrictions sur chaque maillon de la chaîne, et les intermédiaires ne doivent pas avoir d'accès libre à internet. C'est le principe du moindre privilège : chaque composant dispose exactement de l'accès nécessaire à sa tâche.

La deuxième faille tient à la hiérarchie des droits. Hard Stop fonctionne tant que le superviseur gère les règles, cgroup et les restrictions réseau depuis l'extérieur de l'environnement de l'agent. Si l'agent obtient les droits root sur l'hôte, il pourra modifier les paramètres de cgroup et s'attaquer au superviseur lui-même. La troisième est la qualité des règles : le système ne distingue pas une bonne règle d'une mauvaise, et beaucoup dépend donc de la configuration initiale, définie par un humain.

Hard Stop reste pour l'instant une démonstration d'architecture possible, et non un produit industriel prêt à l'emploi. Pour les équipes qui font tourner des agents, la conclusion pratique est la suivante : il faut construire l'isolation à l'extérieur du modèle, au niveau du système d'exploitation et du réseau, selon le principe du moindre privilège, et vérifier non seulement l'agent lui-même, mais aussi chaque service auquel il a un accès légitime.