Le 9 septembre 2026, un compte rendu de Will Knight a décrit un test autorisé mené sur son propre réseau domestique avec un agent IA doté de larges permissions. Fondé sur une version ablitérée de GLM-5.3, le système a repéré environ une douzaine de systèmes matériels, signalé plusieurs configurations fragiles, accédé à une machine Linux grâce à une clé cryptographique et tenté des identifiants d’administration sur le routeur. Ce n’était pas une intrusion contre le réseau d’un inconnu — et la réussite de la tentative contre le routeur n’est pas établie.
Un test autorisé sur un réseau domestique
L’expérience reposait sur une version ablitérée de GLM-5.3, le modèle de Z.ai, pilotée avec CyberStrike, un environnement conçu pour guider un grand modèle de langage dans des tâches de cybersécurité. L’objectif n’était pas de simuler un simple chatbot qui répond à des questions : l’agent devait observer son environnement, enchaîner des actions et poursuivre un objectif de sécurité avec les outils et les autorisations qui lui étaient fournis.
La nuance est essentielle. L’agent a été utilisé sur le réseau domestique de Will Knight, avec son autorisation. Rien dans ce test ne montre qu’il a pénétré le réseau d’un tiers ou consulté les données d’une autre personne. L’intérêt de l’expérience est ailleurs : elle illustre ce qui se produit lorsqu’un système peut passer de la découverte à la tentative d’accès sans attendre une consigne détaillée à chaque étape.
Ce que l’agent a trouvé
L’agent a recensé environ une douzaine de systèmes matériels sur le réseau local. Parmi les observations rapportées figuraient :
- une imprimante dont la configuration permettait aux utilisateurs du réseau de se connecter, avec un risque d’exposition des documents placés dans la file d’impression ;
- une chaîne Wiim qui exposait des informations sur la lecture en cours et permettait à des utilisateurs du réseau de modifier la musique ou le volume ;
- des objets connectés dont le firmware devait être mis à jour ;
- des identifiants d’API exposés dans des projets développés avec l’aide d’outils d’IA ;
- une configuration susceptible d’autoriser l’envoi de courriels sans permission ;
- des dizaines de problèmes dans ces projets logiciels.
Ces constats concernent les appareils et les projets examinés pendant cette expérience. Ils ne permettent pas de conclure que toutes les imprimantes, enceintes connectées ou installations domotiques présentent les mêmes failles. En revanche, ils rappellent une règle peu spectaculaire mais redoutablement efficace : un réseau peut être fragilisé par l’addition de petites négligences, bien avant l’apparition d’un scénario de film catastrophe.
La clé Linux et le routeur
La séquence la plus parlante concerne une machine Linux. L’agent a découvert une clé cryptographique et l’a utilisée pour se connecter sans mot de passe. Il a ensuite commencé à chercher les informations nécessaires à l’accès administrateur — l’accès « root » sous Linux. Will Knight l’a arrêté avant toute tentative de force brute sur un mot de passe.
Après une reconnexion au Wi-Fi, l’agent a également retrouvé le routeur et essayé des combinaisons courantes de mots de passe administrateur. Le résultat de cette tentative n’est pas rapporté comme une connexion réussie. Il faut donc parler d’une tentative d’accès, pas d’un routeur compromis.
Cette différence peut sembler tatillonne. Elle ne l’est pas. Dans un audit de sécurité, la découverte d’un chemin possible, l’utilisation effective d’un accès et l’obtention de privilèges administrateur sont trois événements distincts. Les confondre transforme une observation utile en titre anxiogène — exactement le genre de raccourci qui brouille la compréhension du risque.
Le risque vient aussi des outils et des permissions
Un agent IA peut accéder à Internet lorsqu’on lui fournit des outils connectés ou lorsque les mécanismes d’isolation ne fonctionnent pas comme prévu. Cela ne signifie pas que tous les agents disposent d’un accès illimité : leurs possibilités dépendent de leurs outils, de leurs permissions et du degré de confinement imposé autour d’eux.
La différence avec un assistant de programmation classique tient à la boucle d’action. L’agent reçoit un objectif, observe un résultat, choisit une étape suivante et peut recommencer. Plus on lui donne de moyens — accès réseau, comptes, fichiers ou services — plus l’espace dans lequel il peut poursuivre cet objectif s’élargit. Une instruction apparemment étroite peut donc déboucher sur une recherche plus ambitieuse que prévu.
Cette explication architecturale aide à lire le test sans le transformer en preuve d’une menace universelle. La démonstration ne montre pas que chaque réseau domestique est déjà exposé. Elle montre plutôt pourquoi l’autorisation, l’identité de l’agent, la segmentation et l’arrêt d’urgence doivent être définis avant de lancer un audit automatisé.
Les leçons défensives
Les mesures tirées de l’expérience sont concrètes, même si elles ne constituent pas à elles seules une norme de sécurité complète :
| Zone examinée | Constat rapporté | Réponse défensive utile |
| Imprimante | La configuration permettait une connexion depuis le réseau | Protéger l’accès à l’imprimante et vérifier qui peut consulter la file d’impression |
| Chaîne Wiim | Des informations de lecture et des commandes de lecture ou de volume étaient exposées sur le réseau | Réduire les accès réseau inutiles et contrôler les appareils autorisés |
| Objets connectés | Certains firmwares nécessitaient une mise à jour | Installer les mises à jour disponibles et suivre l’état des appareils anciens |
| Environnement domestique | Des enceintes intelligentes et d’autres objets partagent le réseau principal | Placer les objets connectés sur un réseau invité ou une zone séparée |
| Projets assistés par IA | Des identifiants d’API et une configuration d’envoi de courriels posaient problème | Examiner les secrets, les permissions et le code avant le déploiement |
| Machine Linux | Une clé cryptographique permettait une connexion sans mot de passe | Inventorier les clés, retirer celles qui ne sont plus nécessaires et limiter leurs droits |
La logique est simple : réduire les privilèges, séparer les appareils et vérifier ce que le code peut réellement faire. Pour les projets écrits rapidement avec l’aide d’une IA, une revue avant mise en production n’est pas du luxe. Les secrets exposés et les permissions trop larges ne deviennent pas acceptables parce qu’un modèle a produit le code.
Pourquoi les défenseurs auront besoin de capacités comparables
L’expérience pose enfin une question moins confortable : si des agents capables de chercher et d’enchaîner des actions deviennent accessibles, les défenseurs pourront-ils se contenter d’outils beaucoup plus limités ? Devon, dirigeant d’Abliteration AI, a résumé le problème en demandant comment empêcher des acteurs malveillants d’utiliser ces agents contre les entreprises essentielles qui les déploient.
Shaanan Cohney, spécialiste de la cybersécurité et du droit à Tufts University, décrit une asymétrie classique : pour défendre un château, il faut vérifier chaque brèche ; pour l’attaquer, une seule suffit. Aleksander Mądry, professeur au MIT et collaborateur d’OpenAI, estime de son côté que les utilisateurs doivent pouvoir exploiter ces capacités à des fins défensives, y compris avec des outils indépendants.
Le test de Will Knight ne tranche pas cette question de gouvernance. Il fournit quelque chose de plus utile : un exemple concret de la frontière à protéger. Un agent peut accélérer l’inventaire et repérer des erreurs que l’on laisse facilement dormir, mais ses permissions doivent rester limitées à un environnement autorisé et contenu. La sécurité ne dépend donc pas seulement de la puissance du modèle ; elle dépend aussi de ce que l’on accepte de lui montrer, de lui laisser faire et de la rapidité avec laquelle on peut l’arrêter.
