Docker Sandboxes isole les agents IA dans GitHub Actions avec une microVM

Docker Sandboxes peut désormais servir d’environnement d’exécution aux agents de GitHub Agentic Workflows. L’agent obtient un shell, les droits administrateur et son propre démon Docker dans une microVM jetable, tandis que le runner hôte, le réseau et les sorties vers GitHub restent limités.

La réponse rapide

L’intégration est disponible dans gh-aw depuis la version 0.82.9. Un runner auto-hébergé doit disposer de KVM et des prérequis système adaptés.

Pourquoi un conteneur seul ne suffit pas toujours

Un agent de code utile installe des paquets, exécute le projet, démarre des bases et lance des commandes choisies dynamiquement. Lui monter le socket Docker de l’hôte revient souvent à lui donner un contrôle très large sur la machine du runner.

Docker Sandboxes place un démon Docker privé dans une microVM. L’agent peut utiliser Testcontainers et créer des conteneurs sans atteindre le démon de l’hôte. Le dépôt partagé reste le pont explicite entre les deux environnements.

Des privilèges larges à l’intérieur, étroits à l’extérieur

Le modèle repose sur une séparation : sudo et shell complet dans la sandbox, mais destinations réseau autorisées, permissions GitHub minimales et fichiers modifiables limités en sortie. Une correction peut par exemple produire uniquement une pull request brouillon touchant src/**.

Cette frontière est plus robuste qu’une succession de confirmations humaines. Un opérateur finit par approuver une commande qu’il n’a pas le temps d’auditer. Une microVM réduit l’impact d’une erreur, mais ne garantit pas que le patch produit est correct ou dépourvu de code malveillant.

Les secrets restent le point sensible

L’injection d’un secret dans la sandbox le rend accessible au processus qui y travaille. Utilisez des identifiants dédiés au job, courts, limités au dépôt et incapables de publier directement en production. Bloquez les destinations réseau inutiles pour réduire l’exfiltration.

Les actions et images exécutées par l’agent doivent être épinglées. Un environnement jetable ne protège pas la chaîne d’approvisionnement si une dépendance compromise reçoit volontairement le jeton du workflow.

Une adoption progressive

Commencez par une tâche à faible risque : ajout d’un test, diagnostic d’une erreur ou proposition de documentation. Exigez une pull request brouillon, une revue humaine et la suite de contrôles habituelle. Observez les commandes, le trafic et les coûts avant d’augmenter l’autonomie.

Sur runner auto-hébergé, vérifiez également l’isolation matérielle, le nettoyage des espaces partagés et la concurrence entre jobs. La microVM protège son périmètre, pas une mauvaise configuration autour d’elle.

Docker Sandboxes apporte une frontière crédible aux agents de CI en leur donnant de la liberté dans un espace sacrifiable. La sécurité finale dépend toujours du réseau autorisé, des secrets injectés et des actions que le workflow accepte de publier.