Chainguard lance Workspaces et Checks pour sécuriser les agents de codage IA

Un agent de codage IA peut apporter une correction utile tout en provoquant un incident de sécurité. Il peut installer une dépendance compromise, suivre des instructions intégrées à du contenu non fiable ou exécuter une commande avec des identifiants qui lui donnent bien plus d’accès que ne l’exige la tâche. À mesure que les équipes font travailler davantage d’agents en parallèle, sécuriser le code qu’ils produisent ne constitue qu’une partie du problème.

Chainguard s’attaque à cette exposition plus large avec trois annonces à Assemble London : Workspaces, des environnements isolés pour les développeurs et les agents de codage ; Checks, un moteur de vérification conçu pour s’exécuter dans le cycle de développement de l’agent ; et des protections étendues de Libraries, qui couvrent des langages de programmation supplémentaires et la correction des vulnérabilités.

Ces lancements répondent à trois questions auxquelles les entreprises doivent de plus en plus souvent répondre : où un agent s’exécute, comment son travail est vérifié et quels logiciels externes il peut introduire dans l’organisation. Workspaces et Checks sont lancés en version bêta, tandis que les nouvelles offres Libraries pour Go et .NET entrent en accès anticipé.

Délimiter un espace de travail pour chaque agent de codage

Chainguard Workspaces fournit à chaque développeur et à chaque agent une microVM distante distincte. L’environnement synchronise l’arborescence de travail locale du développeur, ce qui lui permet de conserver son éditeur et son flux de travail Git pendant que l’exécution se déroule à distance, hors de sa machine. Des environnements distincts permettent également à plusieurs agents de tenter des modifications en parallèle sans partager le même environnement de travail.

Cette distinction est importante, car les capacités utiles d’un agent — exécuter des commandes, installer des paquets et accéder à des services — peuvent aussi servir de voies de compromission. Une règle inscrite dans les instructions de l’agent suppose que celui-ci la respecte. Une limite imposée par l’environnement d’exécution peut restreindre ce qui se passe même si le modèle prend une mauvaise décision.

Selon l’annonce, les identifiants réels sont injectés à l’extérieur de l’espace de travail. Les outils qui exigent un identifiant stocké sur disque reçoivent un substitut chiffré à durée de vie courte. Des règles facultatives de sortie réseau limitent les connexions sortantes aux destinations approuvées, réduisant ainsi la capacité d’une dépendance compromise ou d’un agent ayant subi une injection de prompt à envoyer des données ailleurs.

Ces contrôles répondent à différents risques. L’isolation matérielle sépare les charges de travail ; la gestion des identifiants empêche l’agent d’accéder aux secrets réutilisables ; et les règles réseau limitent les destinations avec lesquelles il peut communiquer. Leur efficacité dépend néanmoins des autorisations et des destinations approuvées par l’organisation. L’isolation ne rend pas inoffensive toute action autorisée.

Les environnements utilisent Chainguard OS Packages et vérifient les dépendances par rapport au fichier de verrouillage au moment de l’exécution. L’offre existante OS Packages de Chainguard fournit des paquets maintenus en continu, les construit à partir du code source et inclut des nomenclatures des composants logiciels. Ce contexte explique l’approche de l’entreprise : étendre sa base logicielle contrôlée à l’environnement où les agents s’exécutent.

Workspaces génère également des enregistrements signés portant sur l’environnement, les modifications du code et les résultats des vérifications. Pour les équipes de sécurité, cela permet d’enquêter sur les actions d’un agent plutôt que de se fier uniquement à son propre résumé de la session.

Intégrer la vérification au cycle de travail de l’agent

La génération de code peut être rapide alors que le processus de vérification du code reste lent. Un agent apporte une modification, la soumet à l’intégration continue, attend qu’un exécuteur soit configuré, puis reçoit un échec alors que son contexte de travail a déjà évolué. Répéter ce processus avec de nombreux agents peut allonger les files d’attente et multiplier les tâches de configuration.

Chainguard Checks intègre la vérification à ce cycle sous la forme d’un appel d’outil. Associée à Workspaces, la session de l’agent est suspendue pendant l’exécution des vérifications, puis reprend avec des journaux d’échec structurés dans son contexte. Le flux de travail visé est itératif : apporter une modification, lancer les vérifications, examiner l’échec et réessayer avant de transmettre le résultat.

Les instantanés préconfigurés contiennent des dépendances préinstallées et sont reconstruits lorsque le fichier de verrouillage change. Chaque étape du flux de travail s’exécute dans sa propre microVM isolée matériellement. L’annonce décrit également l’injection, côté hôte, d’identifiants à durée de vie courte dans les requêtes sortantes, ainsi que des règles déclaratives d’accès au réseau.

Une exécution réussie produit une attestation signée qui relie l’environnement, le résultat des tests et le commit. Selon Chainguard, les contrôles de fusion en aval peuvent vérifier ces éléments et accepter le résultat sans relancer la même suite de tests.

Il est utile de distinguer le transfert de preuves du simple transfert d’une affirmation de l’agent selon laquelle les tests ont réussi. Une attestation peut établir quelles vérifications ont été exécutées sur quel commit et dans quel environnement. Elle ne peut pas établir que les tests couvrent tous les comportements importants ni qu’une modification validée respecte toutes les exigences de sécurité. Les équipes ont toujours besoin de tests appropriés, de règles de vérification fiables et d’un examen humain lorsque le jugement est nécessaire.

Chainguard indique que cette conception fournit des résultats en quelques secondes et réduit les calculs redondants. Les documents de lancement ne présentent aucun test de performance validé de manière indépendante qui démontrerait un gain universel de vitesse ou de coût pour l’ensemble des dépôts.

Sécuriser les dépendances intégrées par les agents

La troisième annonce élargit Chainguard Libraries, son catalogue géré et ses points de terminaison pour les dépendances de langages open source. Le service existant est conçu pour s’intégrer aux gestionnaires d’artefacts et aux flux de développement, avec des informations de provenance et des nomenclatures des composants logiciels signées pour les paquets conçus par Chainguard.

Le nouveau point de terminaison Go comprend l’analyse des logiciels malveillants et des logiciels gris, des règles de gestion des paquets configurables et la correction des CVE. Le point de terminaison .NET propose une solution de remplacement à l’utilisation directe de NuGet, avec des contrôles d’analyse et de règles. Les deux passent en accès anticipé.

Chainguard ajoute également la correction des CVE pour JavaScript et Go, notamment des correctifs rétroportés pour les vulnérabilités critiques et de gravité élevée. Le rétroportage est important lorsqu’une équipe ne peut pas passer immédiatement à une version majeure plus récente sans modifier l’application ni effectuer des tests approfondis. Il peut réduire l’exposition aux vulnérabilités pendant la préparation de la mise à niveau plus importante.

Pour Java et Python, l’entreprise indique qu’Athena, sa coalition sectorielle, fournira des artefacts corrigés pour les vulnérabilités découvertes par des modèles d’IA de pointe dès le jour où elles seront rendues publiques. Cette affirmation porte sur la rapidité de la réponse au moment de la divulgation publique ; elle ne garantit pas l’absence de failles non divulguées.

Une enquête montre pourquoi l’application des correctifs est mise à rude épreuve

Parallèlement à ses produits, Chainguard publie The AI Exploit Gap, une enquête commandée à Wakefield Research. Elle a recueilli en septembre 2026 les réponses de 1 300 responsables de la cybersécurité dans neuf marchés. Les répondants occupaient au moins un poste de directeur et travaillaient généralement dans des organisations comptant au moins 500 employés, le seuil minimal étant de 250 employés à Singapour et aux Émirats arabes unis et en Arabie saoudite.

Dans cette enquête, 54 % ont déclaré que leur organisation laissait sciemment, au moins parfois, des vulnérabilités élevées ou critiques sans correctif, et 93 % se sont dits préoccupés par leur capacité à corriger assez rapidement les exploits liés à l’IA. Quelque 76 % ont signalé une attaque liée à l’IA, confirmée ou suspectée, au cours de l’année précédente.

Ce dernier chiffre regroupe les incidents confirmés et les soupçons. Il ne faut pas y voir une mesure vérifiée de manière indépendante des attaques causées par l’IA. Plus généralement, il s’agit des déclarations et des attentes des répondants, et non de données de télémétrie établissant la fréquence de réussite d’une technique d’attaque donnée.

Les résultats opérationnels sont révélateurs. Parmi les entreprises dont le chiffre d’affaires atteint au moins 1 milliard de dollars, 66 % ont déclaré laisser, au moins parfois, des vulnérabilités élevées ou critiques sans correctif, contre 27 % des entreprises dont le chiffre d’affaires est inférieur à 250 millions de dollars. Les grandes organisations ont évoqué des arbitrages commerciaux, comme les perturbations et les priorités concurrentes en matière de produits. L’écart tient donc autant à la capacité de déployer des changements qu’à celle de détecter les failles.

Une plus grande autonomie exige des contrôles plus vérifiables

Les trois lancements de Chainguard forment une approche cohérente : encadrer l’environnement d’exécution, fournir aux agents une vérification rapide et attribuable, et contrôler les dépendances qu’ils utilisent. Chacun porte sur un aspect différent du même flux de développement.

L’épreuve concrète consistera à déterminer si ces contrôles s’intègrent aux dépôts, aux intégrations de services et aux politiques de mise en production réels sans devenir un nouveau goulot d’étranglement. Les versions bêta et l’accès anticipé montrent que ce travail reste à accomplir. L’orientation est toutefois claire : à mesure que les agents de programmation acquièrent la capacité d’agir, les entreprises ont besoin de contrôles de sécurité qui restent applicables et vérifiables tout au long du travail.