Chainguard muscle la sécurité des agents de code avec des environnements isolés

Chainguard a dévoilé à Assemble London une série d’outils pensés pour un même problème : des agents de codage capables d’écrire du bon code tout en créant, au passage, un incident de sécurité. Workspaces isole l’exécution dans une microVM distante, Checks vérifie les changements dans la boucle de travail, et Libraries élargit la gestion sécurisée des dépendances. La société ouvre aussi Harness, un service de recherche de vulnérabilités qui s’appuie sur Anthropic Claude Mythos 5.1. L’enjeu est simple à formuler, moins simple à exécuter : laisser les agents travailler sans leur laisser trop de liberté.

Des agents utiles, mais pas toujours sages

Le constat de départ est celui que beaucoup d’équipes de développement commencent à mesurer : un agent peut produire un correctif pertinent et déclencher une faille en même temps. Il peut installer une dépendance compromise, suivre des instructions cachées dans un contenu non fiable ou utiliser des identifiants trop puissants pour la tâche. Dans ce contexte, sécuriser uniquement le code produit ne suffit plus. Il faut aussi encadrer l’endroit où l’agent exécute, ce qu’il peut lire et les preuves qu’il laisse derrière lui.

Chainguard répond à ce glissement avec Workspaces, Checks et une extension de Libraries. Les deux premiers produits arrivent en bêta, tandis que les nouvelles offres Go et .NET de Libraries passent en Early Access. L’idée est de déplacer une partie du contrôle hors de la bonne volonté du modèle, car une politique écrite dans un prompt reste une promesse, pas une barrière.

Workspaces : une frontière autour de chaque agent

Workspaces attribue à chaque développeur ou agent une microVM distante, c’est-à-dire une machine virtuelle très isolée, dédiée à une seule session. L’environnement synchronise l’arborescence locale, ce qui permet de conserver l’éditeur et le flux Git, mais l’exécution se fait ailleurs. Plusieurs agents peuvent ainsi travailler en parallèle sans partager le même bac à sable.

Chainguard dit injecter les véritables identifiants en dehors de l’espace de travail. Quand un outil a besoin d’un secret, il reçoit à la place un substitut chiffré et de courte durée. Des politiques d’egress optionnelles limitent aussi les connexions sortantes vers des destinations approuvées. Cela réduit la marge de manœuvre d’un agent compromis, même si l’isolation ne rend évidemment pas inoffensives les actions autorisées. Un cadenas, ce n’est pas une dispense morale.

L’environnement s’appuie sur Chainguard OS Packages et vérifie les dépendances au runtime à partir du lockfile. La société met aussi en avant des enregistrements signés couvrant l’environnement, les changements de code et les résultats des vérifications, afin de faciliter les audits a posteriori.

Checks raccourcit la boucle de validation

Avec Checks, Chainguard veut réduire le décalage entre une modification et sa validation. Au lieu d’attendre un pipeline CI classique, l’agent lance la vérification comme un appel d’outil, puis reprend avec des logs structurés en cas d’échec. Le schéma est pensé pour l’itération : changer, vérifier, corriger, puis recommencer avant la livraison.

La société décrit des instantanés “chauds” avec dépendances préinstallées, reconstruits quand le lockfile change. Chaque étape s’exécute dans une microVM isolée matériellement. Si le run passe, un attestat signé relie l’environnement, le test et le commit. Ce n’est pas la même chose qu’une simple affirmation de l’agent disant que tout va bien, ce qui rassurera probablement les équipes qui ont déjà vu un “tests passed” optimiste se transformer en ticket de production.

Chainguard avance un retour en quelques secondes et une réduction du calcul redondant, mais ne publie pas de mesure indépendante montrant un gain universel sur tous les dépôts. Le bénéfice dépendra donc des projets, des politiques et du niveau de contrôle déjà en place.

Libraries s’étend aux dépendances Go et .NET

Le troisième volet concerne Libraries, le catalogue géré de dépendances open source de Chainguard. Les nouvelles offres pour Go et .NET ajoutent du scanning de paquets, des politiques configurables et une remédiation des CVE. Pour JavaScript et Go, la société annonce aussi des correctifs rétroportés pour les vulnérabilités critiques et élevées, utile quand une équipe ne peut pas migrer tout de suite vers une version majeure plus récente.

Pour Java et Python, Chainguard dit qu’Athena, sa coalition de divulgation coordonnée, fournira des artefacts corrigés le jour où des vulnérabilités découvertes par des modèles d’IA de pointe seront rendues publiques. Cette promesse porte sur la réactivité à la divulgation, pas sur l’absence de failles inconnues.

Harness apporte la recherche de vulnérabilités dans une microVM

En parallèle des outils de développement, Chainguard lance Harness, un service qui utilise Claude Mythos 5.1 pour chercher des vulnérabilités exploitables dans une application isolée et exécutable. Les clients connectent leurs dépôts via l’application GitHub de Chainguard, ou déposent une archive source. Le système reconstruit l’application comme pour une mise en production, la lance dans une microVM, puis laisse le modèle explorer les failles de logique, d’injection ou d’épuisement de ressources.

Le déroulé est séparé en deux phases. D’abord, un modèle de préparation assemble l’application et ses dépendances ; ensuite, Mythos 5.1 reprend dans un environnement sans sortie réseau ni identifiants locaux. Tous les appels d’outils sont journalisés hors du sandbox. Chainguard dit traiter le code testé comme une donnée non fiable, afin de limiter le risque d’instructions cachées dans le code analysé.

Chaque exploit doit être reproductible pour figurer dans le rapport. Même chose pour le correctif proposé : il est validé contre le code actuel puis contre la version corrigée. Le rapport livré comprend un résumé exécutif, la sévérité, l’impact, les étapes de reproduction et une recommandation de remédiation. Un ingénieur Chainguard valide ensuite l’ensemble avant livraison.

Un premier cas public dans vLLM

Chainguard a publié le premier résultat public de Harness la veille de cette annonce. Le système a trouvé une faille dans vLLM, moteur open source de service de grands modèles de langage, où un client pouvait forcer la sortie d’une requête d’un autre client sur un moteur partagé. Le problème venait de allowed_token_ids, un paramètre qui limite les jetons générés : la ligne d’un client était réaffectée sans effacer l’ancienne restriction, ce qui permettait à une requête suivante d’hériter des contraintes précédentes.

Selon la publication, la vulnérabilité concernait les versions antérieures à v0.31.0. Chainguard dit avoir reproduit l’exploitation trois fois sur trois, avoir signalé le problème le 23 septembre 2026, et avoir vu le correctif publié le 2 octobre 2026. L’avis GHSA-6cxc-2vcg-w5qc est arrivé le 6 octobre 2026. Le cas était resté dans le tracker public depuis le 28 mai 2026, classé comme simple bug. Le projet vLLM a jugé la faille de sévérité faible.

Le rapport évoque aussi 10 heures et 48 minutes d’exécution, environ 115 millions de tokens traités, 30 parties du projet examinées, 37 candidats reproduits sur un hôte propre et 13 validés par l’équipe d’ingénierie. Chainguard dit avoir testé Harness sur plus de 65 projets et validé plus de 680 findings. Ces chiffres viennent de l’éditeur et ne constituent pas une mesure indépendante.

Pourquoi la stratégie de Chainguard compte

Les trois lancements de Chainguard dessinent une même ligne : contrôler l’environnement d’exécution, rendre la vérification rapide et traçable, puis assainir les dépendances que les agents récupèrent. C’est cohérent, et plutôt bien ciblé. La vraie question est maintenant celle du terrain : est-ce que ces contrôles s’intègrent sans ralentir les équipes ni fabriquer un nouveau goulot d’étranglement ? Les versions bêta et Early Access laissent encore cette réponse ouverte.

Dans la foulée, le sondage The AI Exploit Gap donne un arrière-plan utile. Réalisé en septembre 2026 auprès de 1 300 responsables cybersécurité dans neuf marchés, il montre que 93 % des répondants s’inquiètent de remédier assez vite aux attaques pilotées par l’IA, et que 76 % disent avoir subi une attaque confirmée ou suspectée sur un an. Parmi les entreprises de plus d’un milliard de dollars de chiffre d’affaires, 66 % déclarent laisser parfois des vulnérabilités critiques non corrigées, contre 27 % sous 250 millions de dollars. Le frein n’est donc pas seulement technique ; il est aussi organisationnel et budgétaire.

Au fond, Chainguard parie que l’IA de développement ne pourra pas gagner la confiance des entreprises sans preuve, isolation et remédiation intégrées. Le pari est raisonnable. Le maintien à terme, lui, se jouera dans les dépôts réels, pas dans les slides.