Chainguard Workspaces et Checks placent les agents de codage IA derrière une barrière de sécurité

Chainguard a lancé deux produits bêta qui placent les agents de codage IA dans des environnements isolés, puis exigent des contrôles vérifiés avant que leur travail n’atteigne une pull request. Chainguard Workspaces et Checks ciblent un conflit que les équipes de développement ne peuvent plus ignorer. Les agents ont besoin d’une grande liberté pour travailler, mais cette liberté élargit la frontière de sécurité.

Workspaces fournit des sessions de développement à distance reposant sur des microVM dédiées, de petites machines virtuelles conçues pour isoler chaque charge de travail. Checks exécute des tâches d’intégration continue dans des microVM distinctes et renvoie des résultats structurés à l’agent. Ensemble, ces produits créent une boucle contrôlée d’écriture, de test et de révision du code.

Ce lancement met sous pression un modèle de développement familier. Des outils comme Claude Code, GitHub Codespaces et les sandboxes locales pour agents isolent déjà certaines parties du flux de travail de codage. Les systèmes CI traditionnels valident séparément les commits après leur envoi par les développeurs. Chainguard veut relier ces étapes et faire des tests vérifiés une partie de la boucle de travail de l’agent.

Cette approche paraît sensée, mais l’affirmation essentielle reste à démontrer à grande échelle. Chainguard doit montrer qu’une isolation plus forte et des résultats signés peuvent renforcer la confiance sans remplacer les délais de CI par des frictions liées aux politiques, à la configuration ou à la plateforme.

Chainguard Workspaces et Checks font entrer la CI dans la boucle de l’agent

Le lancement associe un environnement d’exécution isolé à un service de vérification capable de déterminer à quel moment un agent considère sa tâche comme terminée.

Chainguard a annoncé Workspaces et Checks lors de son événement Assemble London. Les deux produits sont entrés en bêta, selon la première couverture produit. Ils couvrent différentes étapes d’un même flux de travail.

Un Workspace est une microVM distante dans laquelle un développeur ou un agent de codage peut modifier des fichiers, installer des paquets, exécuter des commandes et maintenir des processus actifs. Le développeur démarre une session via les outils en ligne de commande de Chainguard et synchronise un arbre de travail local dans l’environnement distant.

Cette synchronisation peut inclure des modifications non validées et des fichiers non suivis. L’exécution s’éloigne de l’ordinateur portable du développeur, mais l’éditeur familier et le flux de travail Git peuvent rester locaux. Cette séparation est importante, car un agent local peut autrement accéder à des identifiants, des sessions de navigateur, des services d’arrière-plan et des fichiers sans rapport avec sa mission.

La session peut se poursuivre après la déconnexion du développeur. Chainguard indique qu’il crée un instantané et met l’environnement en attente après une période d’inactivité, en préservant son disque, sa mémoire, ses processus et ses caches. Le développeur peut ensuite reprendre la session au lieu de reconstruire l’environnement.

Workspaces prend également en charge les expérimentations parallèles. Un développeur peut démarrer de nouvelles sessions à partir du même dépôt et demander à plusieurs agents d’explorer différentes implémentations. Chaque agent reçoit sa propre microVM plutôt que de partager un environnement modifiable avec les autres.

Checks gère le volet vérification. Un dépôt définit ses commandes requises dans un fichier .chainguard/ci.yaml ou un répertoire de configuration associé. Le service exécute ensuite les contrôles individuels dans de nouvelles microVM plutôt que de faire confiance aux résultats produits dans le Workspace de plus longue durée.

Cette distinction est essentielle. Un Workspace offre à un agent un environnement productif, mais son état évolue tout au long d’une tâche. Un contrôle propre offre un test plus solide pour déterminer si le code obtenu fonctionne en dehors de cet état accumulé.

Les développeurs peuvent invoquer Checks via une ligne de commande, un hook pre-commit ou une intégration GitHub. Les agents peuvent l’appeler via un SDK ou un serveur Model Context Protocol. MCP est un protocole qui permet à un agent IA d’invoquer des outils externes par le biais d’interfaces définies.

Lorsqu’un contrôle échoue, le Workspace peut reprendre avec des journaux d’échec structurés. L’agent peut réviser sa modification sans reconstruire la session ni télécharger à nouveau chaque dépendance. Les détails du lancement décrivent des instantanés préchauffés construits à partir du lockfile du projet, qui enregistre les dépendances figées.

Une exécution réussie produit une attestation signée liée à l’environnement, au résultat et au commit. Une attestation est une preuve cryptographique décrivant ce qui a été exécuté et le résultat obtenu. Chainguard propose d’utiliser cette preuve lors d’une barrière de fusion au lieu de faire aveuglément confiance à l’affirmation de l’agent.

L’événement dépasse donc le simple lancement d’un environnement de développement distant. Chainguard tente de définir une règle d’achèvement pour le codage autonome. Un agent ne termine qu’après qu’un système indépendant a validé la modification exacte qu’il souhaite soumettre.

La pression s’exerce sur les agents locaux et la CI conventionnelle

Chainguard remet en cause l’écart entre l’endroit où les agents créent le code et celui où les organisations décident si ce code est acceptable.

Les agents de codage nécessitent des autorisations dont les assistants conversationnels ordinaires n’ont jamais eu besoin. Ils inspectent des dépôts, modifient plusieurs fichiers, exécutent des commandes shell, installent des dépendances et communiquent avec des services externes. Leur utilité augmente lorsqu’ils peuvent accomplir ces actions sans approbation constante.

Cette même autonomie élargit leur rayon d’impact potentiel. Une instruction trompeuse dans un dépôt peut influencer un agent avant qu’un développeur examine son comportement. Un paquet compromis peut s’exécuter pendant l’installation. Une autorisation réseau superflue peut transformer un secret local en données qu’un attaquant peut extraire.

OWASP décrit l’autonomie excessive comme un risque créé par des fonctionnalités, des autorisations ou une autonomie excessives. Les agents de codage peuvent réunir ces trois conditions. Ils reçoivent des outils puissants, opèrent sur des dépôts complexes et répètent des actions avec une supervision limitée.

Les invites d’autorisation locales apportent une réponse incomplète. Elles interrompent le flux de travail, tandis que les approbations répétées encouragent les utilisateurs à cesser d’évaluer attentivement chaque demande. Anthropic a indiqué que les utilisateurs approuvaient environ 93 % des invites d’autorisation de Claude Code avant l’introduction de contrôles automatisés supplémentaires.

Cette tendance aide à expliquer le passage vers des frontières imposées. La propre approche de confinement d’Anthropic met l’accent sur la limitation de ce qu’un agent peut atteindre plutôt que sur la tentative de prédire chaque action dangereuse. Chainguard suit le même principe général, bien qu’il associe l’isolation à une vérification CI externe.

La CI conventionnelle rencontre un problème différent. Elle intervient généralement après qu’un développeur ou un agent a envoyé une modification. Chaque tentative peut entrer dans une file d’attente, reconstruire un environnement, récupérer des dépendances et renvoyer des journaux via une interface distincte.

Cette séquence fonctionne lorsque les humains effectuent relativement peu de modifications délibérées. Elle devient plus coûteuse lorsque les agents génèrent et testent de nombreuses révisions. Les agents parallèles peuvent multiplier le nombre de builds sans améliorer la qualité de la soumission finale.

Le modèle de Chainguard déplace la vérification plus tôt. Un agent peut appeler Checks alors qu’il dispose encore du contexte de la tâche et peut immédiatement réagir à un échec. L’entreprise souhaite que la preuve de réussite accompagne le commit final.

Cela exerce une pression sur les fournisseurs de CI établis, mais ne les rend pas obsolètes. Les grandes organisations dépendent d’intégrations matures, d’approbations de déploiement, d’historiques d’audit, de runners personnalisés et de matrices de test complexes. Un service bêta doit s’intégrer à ces systèmes avant de pouvoir en remplacer une partie.

La pression atteint également les fournisseurs d’agents hébergés. Anthropic propose déjà une isolation du système de fichiers et du réseau pour Claude Code, y compris des sessions cloud qui gardent les identifiants importants hors de la sandbox de l’agent. GitHub Codespaces fournit des environnements de développement distants et des tokens limités au dépôt.

Ces produits peuvent isoler l’exécution, mais Chainguard avance un argument de sécurité plus ciblé. L’entreprise veut que l’espace de travail, l’environnement de dépendances, la configuration des contrôles et la preuve de fusion forment une seule chaîne. Cette chaîne constitue son principal facteur de différenciation.

Les développeurs devraient considérer ce lancement comme une confrontation entre deux conceptions de flux de travail. L’une associe un agent local ou hébergé à des systèmes de sécurité et de CI configurés séparément. L’autre fait de l’isolation et de la vérification des éléments du chemin d’exécution par défaut de l’agent.

L’isolation compte davantage que de demander à l’agent de bien se comporter

Le pari central de Chainguard est que des contrôles d’infrastructure applicables peuvent contenir des erreurs que les prompts et les politiques des modèles ne peuvent pas empêcher de manière fiable.

Chaque Chainguard Workspace s’exécute dans une microVM dédiée plutôt que dans un conteneur à noyau partagé. Cette architecture place une frontière de virtualisation entre le code non fiable et l’hôte sous-jacent. Chaque tâche Checks reçoit également une nouvelle microVM.

L’entreprise affirme qu’aucun répertoire hôte n’est monté dans ces machines. Le contenu du dépôt est transmis dans l’environnement à la place. Ce choix réduit le risque qu’un processus compromis passe du répertoire du projet à des fichiers hôtes sans rapport.

Chainguard traite également le code du dépôt comme hostile. Cette hypothèse est utile, car un agent peut rencontrer des instructions dans les fichiers sources, la documentation, les sorties générées, les dépendances et les outils connectés. Un utilisateur digne de confiance ne rend pas digne de confiance chaque artefact présent dans un dépôt.

Le modèle de sécurité du système sépare les identifiants persistants de l’environnement invité. Lorsqu’un logiciel a besoin d’un accès authentifié, un composant extérieur à la microVM ajoute l’identifiant à une requête approuvée.

Pour certains services, le code à l’intérieur du Workspace communique via un nom d’hôte local. Le proxy externe authentifie ensuite la requête sortante. Chainguard indique que les outils qui attendent des identifiants sur disque peuvent recevoir des substituts chiffrés qui n’ont aucune valeur en dehors de la session active.

Cette conception réduit le vol direct d’identifiants, mais n’élimine pas leur usage abusif. Le code à l’intérieur de la VM peut toujours utiliser l’autorité associée à une requête approuvée. Un agent malveillant pourrait créer une ressource durable si l’identité connectée dispose de privilèges excessifs.

Chainguard reconnaît cette limite dans sa documentation. L’entreprise conseille à ses clients de n’accorder aux identités de charge de travail que les accès nécessaires à chaque contrôle. Les équipes doivent également examiner les identifiants de session avant d’autoriser un travail sans supervision.

Les contrôles réseau ajoutent une couche supplémentaire. Checks ne reçoit aucun accès réseau par défaut lorsque la configuration omet une règle réseau. Les propriétaires de dépôts peuvent autoriser des hôtes spécifiques ou permettre l’accès au réseau public lorsqu’une tâche l’exige.

Les paramètres par défaut de Workspace méritent une attention plus soutenue. La documentation de Chainguard indique qu’une session peut atteindre l’internet ouvert lorsqu’aucune restriction de sortie propre à un contrôle ne s’applique. Les équipes qui recherchent une posture de refus par défaut doivent donc configurer la session autour d’un contrôle assorti d’une liste d’autorisation.

Cette différence illustre pourquoi l’isolation n’est pas un interrupteur unique. Une microVM peut séparer les noyaux tout en autorisant des actions réseau sensibles. Un proxy peut protéger la valeur des identifiants tout en autorisant des requêtes dommageables. Un résultat signé peut prouver que les tests ont réussi sans prouver que ces tests étaient suffisants.

Le modèle devient plus robuste lorsque les contrôles se renforcent mutuellement. La VM limite la portée locale. Les règles de sortie limitent les destinations externes. Les identifiants côté hôte réduisent l’exposition des secrets. Les contrôles propres testent le code en dehors de la session de développement modifiable.

Checks protège également certaines parties de sa politique contre la modification examinée. Selon Chainguard, une pull request ne peut pas immédiatement affaiblir ses propres exigences bloquantes. La suppression d’un contrôle requis ou son passage au statut consultatif ne prend effet qu’après la fusion de la modification concernée.

Ce détail ferme un contournement évident. Un agent ne devrait pas pouvoir modifier la politique qui évalue son travail et obtenir une approbation selon la politique affaiblie. La branche de base reste l’autorité qui détermine les contrôles à exécuter.

Un environnement de vérification propre résiste également aux réussites accidentelles. Un agent peut installer un package non déclaré ou modifier un service pendant le développement. Son code peut sembler fonctionner dans cet Workspace, puis échouer pour tous les autres.

L’exécution de Checks dans des microVMs neuves expose ces dépendances cachées. Le résultat ressemble à un build CI propre traditionnel, mais le service renvoie directement les preuves à la boucle active de l’agent.

Les Checks signés changent la signification de l’achèvement par l’agent

La fonctionnalité la plus déterminante n’est pas le Workspace distant. C’est la tentative de faire de preuves vérifiées indépendamment la condition de sortie de l’agent.

La plupart des agents de programmation décident qu’ils ont terminé en combinant leur propre jugement de modèle et les résultats des outils. L’agent voit une commande de test réussir, résume ses modifications et ouvre une pull request. Cette séquence comporte plusieurs lacunes de confiance.

L’agent peut exécuter le mauvais test. Il peut ignorer un échec, utiliser une sortie obsolète ou tester un environnement qui ne correspond plus au commit soumis. Il peut également décrire le résultat avec plus d’assurance que ne le permettent les preuves.

Chainguard Checks crée une autorité distincte. L’agent demande une exécution de vérification définie, reçoit un verdict et ne peut continuer que lorsque les contrôles requis réussissent. Le système peut associer un résultat positif à un SHA de commit particulier, à un environnement et à un résultat de contrôle.

Cela transforme la CI en contrôle au sein de la boucle autonome. Une exécution échouée fournit des journaux structurés, que l’agent peut utiliser pour une nouvelle itération. Une exécution réussie produit des preuves qu’un autre système peut évaluer.

Ce mécanisme importe pour les équipes qui exécutent des agents de maintenance en arrière-plan. Prenons un agent chargé de mettre à jour une dépendance obsolète dans plusieurs dépôts. Il peut modifier les manifests, régénérer les lockfiles et exécuter des tests de compatibilité sans accéder à l’ordinateur portable d’un développeur.

Si un contrôle échoue, la session reprend avec son état précédent et ses caches chauds. L’agent peut examiner l’échec et essayer une modification de version plus limitée. Il n’a pas besoin d’un humain pour copier les journaux depuis une interface CI distincte.

Le même schéma s’applique à la refactorisation de code ancien. Plusieurs agents peuvent tester des modifications concurrentes dans des Workspaces séparés. Seul le candidat qui réussit les contrôles définis par le dépôt devrait progresser vers une pull request.

Les attestations signées peuvent également faciliter la gouvernance en aval. Un service de fusion peut vérifier que le commit soumis correspond au commit testé. C’est plus solide que d’accepter un commentaire affirmant qu’un agent a exécuté les tests.

Cependant, une attestation n’établit que des faits relatifs au processus qu’elle enregistre. Elle ne peut pas établir que la suite de tests couvre chaque faille de sécurité. Elle ne peut pas déterminer si l’exigence produit était correcte. Elle ne peut pas non plus garantir qu’une modification réussie mérite d’être déployée.

L’approche réduit donc le problème de confiance plutôt que de le résoudre. Les équipes n’ont plus besoin de faire confiance au rapport d’un agent sur une exécution de tests. Elles doivent toujours faire confiance à la définition des tests, à la configuration des politiques, au service d’exécution et à l’infrastructure de signature.

Cette limite est raisonnable, mais les acheteurs doivent la comprendre. L’expression « preuve cryptographique » peut sembler plus large que l’assurance sous-jacente. Les preuves démontrent qu’un contrôle défini a produit un résultat défini pour des entrées identifiées.

Chainguard entre également dans un domaine où les contrôles de sécurité s’intègrent de plus en plus aux outils de programmation. Le système de sandboxing d’Anthropic associe des limites de système de fichiers à des restrictions réseau. GitHub fournit un accès au dépôt à portée limitée ainsi que des environnements distants via Codespaces.

L’ancienne intégration Cursor de Chainguard visait à orienter les projets générés vers des packages et des images de conteneur validés. Workspaces et Checks étendent cette stratégie, de la sélection des dépendances à l’exécution et à la vérification.

La concurrence plus large ne se résume pas à Chainguard face à un seul fournisseur. C’est une course pour contrôler la frontière de confiance autour du code généré par des agents. Les entreprises de modèles, les plateformes pour développeurs, les fournisseurs de CI et les éditeurs de sécurité ont tous des prétentions crédibles sur cette couche.

La bêta soulève encore des questions de sécurité et d’adoption

L’architecture de Chainguard répond à des risques crédibles, mais ses affirmations opérationnelles les plus fortes nécessitent encore des preuves indépendantes issues de véritables charges de travail d’entreprise.

Les deux produits restent des versions bêta. Chainguard décrit Workspaces comme un aperçu technologique, et la documentation actuelle indique que Claude Code bénéficie d’une prise en charge intégrée des identifiants de modèle. D’autres agents peuvent s’exécuter dans une session, mais le même flux d’identifiants ne leur est pas encore applicable.

Cette limite importe, car les flottes d’agents d’entreprise deviennent hétérogènes. Une équipe peut utiliser un agent pour l’implémentation, un autre pour les revues et des outils spécialisés pour la migration ou les tests. La politique de sécurité devient plus difficile lorsque chaque agent exige un comportement d’intégration différent.

Les performances constituent une autre question ouverte. Les snapshots chauds et les dépendances préconstruites devraient réduire le travail de configuration répété. Toutefois, l’annonce ne fournit pas de benchmarks comparatifs face aux services de CI établis ou à d’autres environnements de développement distants.

Les équipes ont besoin de mesures sur des dépôts réalistes. Des preuves utiles incluraient le temps de démarrage à froid, le temps de reprise à chaud, les taux de succès du cache, le comportement des sessions simultanées et le délai entre un contrôle échoué et la reprise du travail de l’agent.

La fiabilité compte autant que la vitesse. Un service de vérification devient un goulot d’étranglement du développement lorsque les agents ne peuvent pas terminer leurs tâches sans lui. Les organisations voudront des engagements de niveau de service, une disponibilité régionale, un comportement de récupération après défaillance et des règles claires pour un fonctionnement dégradé.

Le système de signature doit également être examiné attentivement. Les clients doivent savoir comment les clés sont protégées, renouvelées, auditées et révoquées. Ils ont besoin d’une méthode pour vérifier les attestations de manière indépendante et décider à quels émetteurs leurs portes de fusion font confiance.

InfoQ a indiqué que Chainguard n’avait pas publié de détails expliquant comment les clients devraient valider la résistance à la falsification revendiquée pour ses journaux. Cela n’invalide pas la conception. Cela identifie une partie indispensable de l’évaluation d’un produit de sécurité.

Les identifiants de Workspace créent un autre risque subtil. Conserver un jeton hors de la VM empêche le code de lire sa valeur brute. Cela n’empêche pas le code de demander au proxy d’exécuter une action autorisée.

Un agent compromis pourrait utiliser abusivement l’accès GitHub, les autorisations cloud ou un identifiant LLM via des voies autorisées. La défense dépend de portées étroites, de la validation des requêtes, de restrictions de sortie réseau et de la surveillance. Les équipes ne peuvent pas déléguer ce travail de politique à la microVM.

Les intégrations côté hôte méritent également de l’attention. Des chercheurs en sécurité ont montré qu’un sandbox peut perdre sa valeur lorsqu’un composant hôte de confiance consomme une sortie contrôlée par un attaquant. Un fichier de configuration modifié pourrait déclencher un comportement privilégié après avoir quitté le sandbox.

L’architecture de streaming et de proxy de Chainguard réduit une partie de l’exposition de l’hôte, mais les clients devraient tester le chemin de données complet. Cela inclut la synchronisation locale, les opérations Git, les extensions IDE, les serveurs MCP, l’automatisation des fusions et tout système de notification recevant la sortie d’un agent.

Il existe aussi un compromis d’adoption. Les développeurs veulent que les agents installent des outils, recherchent de la documentation, appellent des API et explorent du code inconnu. Des politiques strictes de sortie réseau et d’identifiants peuvent interrompre ces tâches. Des autorisations larges restaurent la commodité tout en affaiblissant le confinement.

Le produit doit rendre les politiques sécurisées plus faciles à maintenir que des configurations locales improvisées. Sinon, les équipes risquent de créer des listes d’autorisation permissives, de réutiliser des identités surdimensionnées ou de contourner le système pour des travaux urgents.

L’utilisation par Chainguard d’une configuration partagée pour Workspaces et Checks peut réduire la duplication. Pourtant, les organisations doivent toujours cartographier les dépendances, services et exigences de test de chaque dépôt. Cet effort de migration influencera l’adoption autant que la technologie sous-jacente.

La conclusion prudente est simple. L’architecture comprend plusieurs contrôles réfléchis, notamment des environnements de vérification neufs et des identifiants conservés hors de l’invité. La bêta n’a pas encore établi comment ces contrôles se comportent dans des pipelines de production variés.

Trois signaux montreront si le modèle fonctionne

Le prochain test consistera à déterminer si Chainguard peut transformer une conception de sécurité cohérente en preuves reproductibles, en prise en charge étendue des agents et en adoption pratique par les entreprises.

Le premier signal sera une validation technique publiée. Chainguard devrait fournir des benchmarks reproductibles pour le temps de démarrage, l’exécution des contrôles, le comportement du cache et les sessions parallèles. Des évaluations indépendantes du proxy d’identifiants, du système d’attestation et de l’intégrité des journaux auraient encore plus de poids.

De solides résultats soutiendraient l’affirmation selon laquelle les contrôles de sécurité peuvent entrer dans la boucle de l’agent sans la ralentir au-delà d’un usage pratique. Des résultats absents ou sélectionnés de manière restrictive laisseraient l’argument central sur les performances sans réponse.

Le deuxième signal sera une intégration plus large des agents. Workspaces offre actuellement à Claude Code le chemin documenté le plus clair, tandis que la prise en charge d’agents supplémentaires reste prévue. La prise en charge native d’autres agents de programmation largement utilisés permettra de vérifier si l’architecture est réellement neutre vis-à-vis des agents.

Cette expansion doit préserver les mêmes propriétés de sécurité. Une liste de compatibilité plus longue signifie peu de chose si certains agents exigent des secrets dans la VM ou contournent le chemin de vérification prévu.

Le troisième signal sera la preuve d’une utilisation régulière en entreprise. Les études de cas les plus convaincantes montreraient des agents réalisant des mises à jour de dépendances, des refactorisations ou des travaux de maintenance dans de nombreux dépôts. Elles devraient indiquer les taux d’échec, les interventions humaines, les exceptions de politique et le temps gagné.

Le comportement des clients révélera si les contrôles signés deviennent de véritables portes de fusion ou simplement un badge de statut supplémentaire. Il montrera également si les équipes de sécurité peuvent maintenir des restrictions utiles sans transformer chaque nouvel outil en ticket de politique.

Chainguard Workspaces et Checks arrivent alors que le secteur passe de la supervision du comportement des agents à la limitation de leurs capacités. Cette orientation correspond aux recommandations des fournisseurs d’agents et des groupes de sécurité. Elle ne garantit pas que cette implémentation particulière l’emportera.

Les développeurs qui évaluent la bêta devraient commencer par un dépôt circonscrit et une identité à portée limitée. Ils devraient définir des règles explicites de sortie réseau, exiger des contrôles propres et vérifier qu’un commit soumis correspond à son attestation. Les équipes d’ingénierie peuvent également documenter ces constats dans une base de connaissances technique partagée.

La question finale est opérationnelle plutôt que philosophique. Le système peut-il laisser les agents travailler de manière indépendante tout en maintenant les identifiants, la politique et l’autorité de fusion hors de leur contrôle ? La réponse émergera des données de vérification, de l’étendue des intégrations et des pratiques des clients, et non de la seule annonce de lancement.