getbb.app, Docker et Lima : où un agent est-il le plus sûr ?

Ce que la comparaison entre getbb.app, Docker et Lima recouvre réellement

Je ne placerais pas getbb.app, Docker et Lima strictement dans la même catégorie : ils répondent à un besoin similaire, mais placent la frontière de confiance à des endroits différents. Dans la discussion initiale de la communauté, l’utilisateur 144406 demandait des retours sur getbb.app, tandis que l’utilisateur 176533234 a immédiatement ramené le débat à la question centrale : est-il vraiment sûr d’exécuter un agent autonome sur l’hôte ?

Le flux de travail décrit paraît raisonnable : un conteneur séparé pour l’agent, un dossier de projet monté et un lanceur de tests. Cela limite le contexte accessible à l’agent et permet de supprimer l’environnement après l’exécution. Toutefois, un conteneur standard partage toujours le noyau avec l’hôte. Les namespaces, les cgroups et les couches du système de fichiers réduisent la surface d’attaque ; ils ne transforment pas Docker en machine virtuelle.

Lima ajoute une VM Linux distincte, surtout pour les usages locaux sur macOS. Pour protéger l’hôte, cette frontière est plus robuste qu’un conteneur exécuté directement sur le système partagé. Le développeur reste néanmoins responsable de la configuration, des images et du cycle de vie de cet environnement.

D’après le site public du produit et son compte X, getbb.app se rapproche davantage d’un sandbox spécialisé : une machine éphémère est créée à la demande, exécute une tâche, puis est détruite. Un plugin fournissant ces machines via les sandboxes Vercel est également mentionné. Les ressources disponibles ne donnent pas de description officielle complète du modèle de sécurité ; l’isolation des processus, du réseau et du système de fichiers ne doit donc pas être considérée comme établie sur la seule base de la présentation produit.

La vitesse de démarrage ne dit pas grand-chose sur la sécurité à elle seule. Dans une comparaison disponible de fournisseurs de sandboxes, le délai médian avant un état interactif allait de 0,34 à 45 secondes. Pour un agent ayant accès au shell, vérifier la résistance aux sorties de sandbox importe bien plus qu’un cold start séduisant.

Où se situe la frontière de sécurité concrète

Pour du code fiable, Docker offre généralement un bon compromis entre reproductibilité et vitesse. Pour un agent susceptible d’exécuter une commande shell injectée par un prompt, je considérerais le noyau partagé comme une partie du risque. La frontière VM de Lima ou un sandbox confirmé comme reposant sur une VM changent l’architecture, et pas seulement l’apparence de l’isolation.

Un service spécialisé profite d’un cycle simple de création, d’exécution et de suppression, ainsi que d’une surface d’exécution plus étroite. Le revers est évident : moins de contrôle bas niveau et une dépendance aux garanties réellement documentées par le fournisseur, plutôt qu’à celles qui sont seulement suggérées.

Avant d’évaluer le confort de l’API, je vérifierais les privilèges des processus, les restrictions réseau, la visibilité des fichiers, la gestion des secrets, la persistance du disque et les scénarios d’évasion. Tant que getbb.app ne documente pas ces propriétés avec assez de précision, le point essentiel reste le même : le caractère éphémère d’un environnement ne prouve pas la solidité de sa frontière.

Nous avons déjà présenté Pydantic Monty, un interpréteur Python sécurisé permettant d’exécuter du code généré par des LLM sans conteneurs. Son approche offre un contraste utile avec les questions de sandboxing par conteneurs soulevées par getbb.app.