Andrew Ng a annoncé une nouvelle version d'OpenWorker, son agent IA de bureau open source, avec une série de fonctionnalités centrées sur les workflows de sécurité. La raison invoquée : après la sortie de la première version, de nombreux utilisateurs ont constaté qu'elle se révélait particulièrement efficace dans les scénarios de cybersécurité ; les attaquants utilisent déjà l'IA, la défense devrait donc disposer du même levier.
OpenWorker ne suit pas la voie de la fenêtre de chat. L'utilisateur confie une tâche, l'agent la décompose lui-même en étapes, agit à travers les fichiers, le terminal et les applications connectées, puis restitue au final un livrable directement utilisable. Le projet est passé open source en juillet, sous licence MIT, se trouve actuellement en phase de test ouverte et a déjà accumulé 16 400 étoiles sur GitHub. La version de bureau prend en charge macOS 12 et versions ultérieures (Apple Silicon, signé et notarié) ainsi que Windows 10/11 en version x64, dont la signature de code est encore en cours d'obtention.
Scanner le code, scanner aussi les dépendances
Le rôle dédié placé en tête dans la nouvelle version s'appelle "revue de sécurité". La documentation du dépôt indique qu'il accomplit deux tâches : combiner des scanners déterministes avec l'inférence du modèle pour passer au crible l'ensemble de la base de code et de ses dépendances, afin d'y détecter des risques réels. Le volet dépendances correspond aux attaques de la chaîne d'approvisionnement — du code malveillant inséré dans des paquets tiers, un type d'incident devenu fréquent dans l'écosystème open source au cours de la dernière année, alors que réviser manuellement chaque arbre de dépendances est pratiquement infaisable.
La règle à l'étape du correctif est encore plus stricte. La documentation précise : le correctif proposé par l'agent doit être re-scanné et passer une revue de diff avant d'être approuvé, et l'agent qui produit le correctif n'est jamais le seul à le vérifier.
Cette contrainte vise le problème d'une IA qui note sa propre copie. Quand le même modèle rédige le correctif et le juge, le résultat paraît complet mais relève en réalité de l'auto-validation — il est tout aussi aveugle à ce qu'il a lui-même manqué. Garder des outils déterministes comme les scanners dans la boucle revient à donner au jugement du modèle un contrôle croisé sans complaisance.
Quatre niveaux de permissions, une autonomie qui se construit par paliers
Chaque appel d'outil est classé dans l'une de quatre catégories de risque : lecture (read), écriture locale (write_local), exécution de commandes (exec), appel externe (external). Par-dessus s'ajoutent cinq modes de permission : discuss et plan sont en lecture seule ; interactive est le mode par défaut, qui demande confirmation avant toute action d'écriture ; auto autorise tout dans des chemins délimités ; custom permet de définir des outils spécifiques et fiables en approbation automatique.
Les règles de gouvernance sont figées en trois couches :
- Limites infranchissables : les opérations dangereuses et irréversibles restent toujours réservées à l'humain, quel que soit le mode choisi ;
- Autonomie progressive : toute action passe par défaut par une approbation, une approbation ponctuelle peut être promue en règle permanente, et ce n'est qu'ensuite qu'elle rejoint la liste blanche de configuration ;
- Piste d'audit : chaque appel d'outil enregistre l'origine de l'approbation — automatique, validée par l'utilisateur, ou refusée.
S'y ajoute une règle de "pas d'auto-approbation sans surveillance" : lorsqu'il tourne la nuit sans personne, si une action à conséquences se présente, l'invite restée sans réponse part dans une boîte de réception en attente de révision, sans que les permissions ne soient assouplies automatiquement simplement parce que personne n'est là.
Transposer les outils des grands groupes sur l'ordinateur portable
Au cours de la dernière année, les actualités sur la chasse aux vulnérabilités par IA ont été dominées presque exclusivement par de grands acteurs à code fermé : l'un a déniché une faille vieille de plus de vingt ans, un autre a scanné des dizaines de milliers de vulnérabilités critiques en un mois, tous utilisant leurs modèles les plus puissants, via des canaux d'achat en entreprise, avec des tarifs et des barrières d'accès à l'avenant. OpenWorker emprunte une autre voie — exécution locale, open source, licence MIT, code auditable.
Pour les équipes de sécurité, le fait que "cette coquille elle-même puisse être auditée" pèse tout autant que la capacité de scan. Un agent capable de lire l'intégralité de la base de code, d'exécuter des commandes et d'émettre des requêtes externes constitue par nature un canal d'exfiltration idéal ; s'il s'agit d'une boîte noire, plus il détecte de vulnérabilités, plus il devient difficile d'évaluer le risque de son adoption elle-même. L'open source relève ici davantage d'une condition d'accès que d'une posture affichée.
Deux éléments manquent encore aux informations publiques : le dépôt n'indique pas le numéro de version précis de la nouvelle édition, et le taux de détection de la capacité de scan sur des benchmarks publics ne dispose pas encore de chiffres tiers indépendants. Avant de le brancher sur un pipeline CI, mieux vaut le tester à plusieurs reprises dans un environnement isolé.
Sources : documentation officielle du dépôt OpenWorker, CocoLoop, MarkTechPost, Help Net Security ; les niveaux de permissions, la gouvernance à trois couches et les responsabilités de la revue de sécurité ont été recoupés point par point avec la documentation du dépôt.