Un agent IA en CI, isolé dans une microVM

Ce qui se passe

Depuis juillet 2026, GitHub Agentic Workflows accepte Docker Sandboxes comme environnement d'exécution d'agent. L'intégration a été livrée dans la version 0.82.9 de gh-aw.

Concrètement : dans votre CI, un agent de code peut disposer d'un contrôle large sur son environnement — y compris lancer des conteneurs Docker — pendant que cet environnement reste isolé dans une micro machine virtuelle, avec politique réseau et injection de secrets.

Pourquoi l'isolation est le vrai sujet

Un agent de code utile ne se contente pas de lire un dépôt et de proposer un correctif. Il installe des outils, exécute des commandes shell arbitraires, lance le code du projet, démarre des bases de données — et découvre parfois des acceptions inattendues du mot « nettoyage ».

Ce sont précisément ces capacités qui font sa valeur. Et sur un runner de CI, un accès direct donne à chaque erreur un rayon d'action considérable.

Le montage

GitHub Actions reste le système de CI. Il planifie le job, fournit le runner Ubuntu, gère permissions et secrets, enregistre le résultat.

gh-aw est une extension open source de la CLI GitHub, doublée d'un compilateur. On décrit un workflow agentique dans un fichier Markdown : configuration d'exécution en frontmatter YAML, tâche de l'agent dans le corps. La commande gh aw compile transforme cette source en workflow GitHub Actions conventionnel, suffixé .lock.yml.

La chaîne complète ressemble à ceci :

Code

Workflow Markdown
   │  gh aw compile
   ▼
Workflow GitHub Actions généré (.lock.yml)
   │  runs-on: ubuntu-24.04
   ▼
Docker Sandbox (microVM)
   │
   ▼
Agent et ses outils

Trois lignes suffisent à sélectionner le runtime :

YAML

sandbox:
  agent:
    id: awf
    runtime: docker-sbx
    sudo: true

Le .lock.yml est du code généré : les modifications se font dans la source Markdown, suivies d'une recompilation.

La frontière est une microVM, pas un conteneur

C'est le point technique qui compte. On suppose souvent que « Docker » implique un conteneur applicatif unique. Ici, la frontière d'isolation principale est une micro machine virtuelle.

Chaque sandbox dispose de son propre noyau, de son propre système de fichiers, de sa propre pile réseau — et surtout de son démon Docker privé. L'agent y obtient les privilèges root complets sans jamais prendre le contrôle du démon Docker de l'hôte. Le seul pont entre les deux est l'espace de travail partagé du dépôt.

Ce démon privé est ce qui débloque les tests d'intégration : dans l'exemple publié, l'application lance Testcontainers exactement comme le ferait un développeur sur sa machine, avec un PostgreSQL démarré à la volée.

Code

Runner GitHub Actions
└── Docker Sandbox (microVM)
    ├── Agent gh-aw
    └── Démon Docker privé
        ├── Conteneur Maven / Java 21
        └── Conteneur PostgreSQL (Testcontainers)

Le scénario de démonstration : l'agent entre dans le sandbox, exécute une suite d'intégration Java avec PostgreSQL, trouve un bug volontairement introduit, le corrige et ouvre une pull request en brouillon. Le run complet a pris 11 minutes et 16 secondes sur un runner Ubuntu hébergé par GitHub.

L'autre moitié : la surface extérieure

Large à l'intérieur, étroit à l'extérieur. C'est la répartition que décrit l'article, et c'est ce qui rend l'exercice défendable.

Le bloc network liste explicitement les destinations autorisées.
Le jeton GitHub de l'agent se limite à lire le contenu du dépôt et à solliciter Copilot.
La création de la pull request se fait dans un job séparé, de type safe-output, dont le patch ne peut contenir que des fichiers sous src/**.

Dans la démonstration, la PR générée contenait exactement deux fichiers : le test de non-régression et le correctif d'une ligne. Configuration du workflow, scripts, dépendances et documentation étaient hors de la surface autorisée.

Et le résultat reste un brouillon, qui attend une relecture humaine.

Pour l'essayer

L'installation passe par gh extension install github/gh-aw. Le runtime compilé a besoin d'identifiants Docker (DOCKER_USERNAME et DOCKER_PAT en secrets d'Actions) pour s'authentifier et récupérer son modèle de sandbox. Il faut aussi autoriser GitHub Actions à créer des pull requests dans les réglages du dépôt.

Le plus simple pour comprendre reste toutefois de mettre un sandbox autour d'un agent en local : sbx run sur un projet réel, avec une tâche qui exige de vrais outils — lancer les tests, construire une image, démarrer une dépendance Testcontainers.

À noter : sur un runner auto-hébergé, il faut une configuration compatible KVM. L'exemple fonctionne tel quel sur les runners ubuntu-24.04 hébergés par GitHub.