Avancé 15 min

Sécuriser l'exécution des agents IA autonomes : architecture d'un sandbox hardened

Comment concevoir un environnement de sandboxing hermétique pour exécuter des agents de code non approuvés via gVisor, Docker-in-Docker et un proxy L7 zero-trust.

L’utilisation d’agents de code autonomes (comme Claude, Gemini ou Codex) est devenue courante pour accélérer le développement. Cependant, exécuter ces agents directement sur une machine hôte ou au sein d’un conteneur classique présente des risques majeurs : exécution de code destructeur par injection de prompt, installation de paquets malveillants ou exfiltration de données propriétaires.

Ce projet propose un environnement de virtualisation conteneurisé et hardened permettant d’isoler et d’exécuter des agents de développement de manière sécurisée sans compromettre la machine hôte.

Architecture et modèle de sécurité

Le système repose sur une isolation multi-couches combinant la virtualisation des appels système, le cloisonnement réseau et le contrôle strict des privilèges.

  1. Virtualisation de noyau avec gVisor : Contrairement à un conteneur standard qui partage le noyau de l’hôte, l’agent s’exécute ici via le runtime runsc (gVisor). Les appels système (syscalls) sont interceptés et traités dans l’espace utilisateur, limitant l’impact d’une éventuelle évasion de conteneur.
  2. Imbrication Docker-in-Docker (DinD) : L’hôte physique fait tourner un conteneur principal hardened. C’est à l’intérieur de ce sous-environnement isolé que le démon Docker imbriqué instancie les bacs à sable des agents.
  3. Filtrage réseau Zero-Trust L7 : Le réseau des agents (172.20.0.0/16) est strictement interne. Tout le trafic sortant est intercepté au niveau de la couche transport par une bibliothèque injectée via LD_PRELOAD et redirigé vers le proxy L7 Ottergate. Ce dernier inspecte les requêtes DNS et les extensions SNI/Host des connexions HTTPS pour n’autoriser que les domaines explicitement déclarés dans une allowlist.

Gestion sécurisée des secrets (Credential Vault)

Pour éviter d’exposer des clés d’API ou des jetons d’accès (GitHub, GitLab) directement dans l’environnement de l’agent, le projet implémente un modèle d’accès asymétrique :

  • Les secrets sont montés dans un espace de stockage accessible uniquement par l’utilisateur root de l’hôte imbriqué.
  • Lorsqu’un utilitaire (comme l’outil CLI de GitHub gh ou git) requiert une authentification, un binaire de transition configuré avec le bit setuid délègue la requête à un démon local (vault-daemon) via une socket Unix.
  • Le démon interroge l’appel système getsockopt pour auditer le PID et le chemin d’exécution du processus appelant. Le token n’est injecté dans le pipe de l’application que si la chaîne de processus correspond à une commande autorisée.

Commandes opérationnelles

Le cycle de vie de l’infrastructure et des instances s’administre via le script de contrôle principal ./ac.

Démarrage de l’infrastructure globale (hôte DinD, démon gVisor et proxy) :

./ac start

Instanciation d’un agent spécifique à partir d’un blueprint (exemple avec Claude) en limitant ses ressources matérielles :

./ac run claude instance_dev_01 --cpus 2 --memory 1g

Accès à un shell interactif sécurisé au sein du sandbox pour le débogage :

./ac shell claude instance_dev_01

Consultation des logs du proxy réseau pour analyser les requêtes de routage et les résolutions DNS :

./ac logs proxy

Nettoyage des identifiants volatils (Git/GitHub) tout en préservant le workspace de travail local :

./ac clean instance_dev_01

Destruction complète de l’instance, suppression de son espace de travail et arrêt du conteneur :

./ac destroy instance_dev_01

Blueprints supportés

Les configurations de bacs à sable sont modélisées sous forme de blueprints standardisés :

  • claude / gemini / codex / mistral : Environnements pré-configurés et optimisés pour les runtimes des assistants de code d’Anthropic, Google et OpenAI.
  • opencode : Sandbox sécurisé pour les agents d’interprétation de code (Code Interpreters).
  • antigravity / hermes / pi : Runtimes spécifiques adaptés aux architectures logicielles et CLI de ces agents autonomes.
  • base : Image épurée contenant les utilitaires de compilation standard et les outils de débogage système essentiels.

Url

https://github.com/gni/agents-container