Docker Sandboxes et MCP : isoler l'exécution des agents IA en CI/CD

Pourquoi l'isolation des agents IA est devenue critique

Les agents IA qui génèrent et exécutent du code en autonomie sont désormais une réalité dans nos pipelines de développement. Mais cette puissance pose une question fondamentale : comment s'assurer qu'un agent ne compromet pas votre environnement de production, votre codebase ou vos secrets d'infrastructure ?

Docker a récemment publié un retour d'expérience sur la façon dont ses propres équipes internes utilisent une flotte d'agents pour accélérer la livraison logicielle (source originale). Ce qui est frappant dans leur approche, c'est la place centrale donnée à Docker Sandboxes pour isoler chaque agent dans un environnement jetable et contrôlé. Chez MulerTech, nous avons adopté une architecture similaire sur nos projets PHP/Symfony — et les bénéfices sont réels.

Docker Sandboxes : des environnements éphémères pour agents autonomes

Docker Sandboxes est une fonctionnalité conçue spécifiquement pour les agents de code : chaque agent obtient un conteneur isolé, avec accès restreint au système de fichiers, sans accès réseau non autorisé, et avec une durée de vie limitée à la tâche en cours.

Concrètement, voici ce que cela change dans un pipeline CI/CD :

• Isolation totale : l'agent ne peut pas lire les variables d'environnement de l'hôte, ni accéder aux autres conteneurs du pipeline.
• Reproductibilité : chaque exécution repart d'une image propre, garantissant que les effets de bord d'une tâche précédente n'affectent pas la suivante.
• Traçabilité : les logs de chaque sandbox sont capturés indépendamment, ce qui facilite l'audit des actions de l'agent.

Pour un projet Symfony, cela se traduit par exemple par un agent capable de générer des migrations Doctrine, de les tester dans un sandbox éphémère avec une base de données PostgreSQL injectée, et de proposer une PR — le tout sans jamais toucher l'environnement de staging.

# Exemple simplifié : déclaration d'un sandbox agent dans un pipeline Docker
services:
  agent-migration:
    image: mulertech/php-agent:8.3
    environment:
      - APP_ENV=test
      - DATABASE_URL=postgresql://postgres:secret@db:5432/app_test
    depends_on:
      - db
    network_mode: none  # isolation réseau stricte
    volumes:
      - ./src:/app/src:ro  # lecture seule sur le code source

Le protocole MCP comme colonne vertébrale de la flotte d'agents

Docker s'appuie également sur MCP (Model Context Protocol), un standard open source initié par Anthropic, pour connecter les agents LLM aux outils et contextes dont ils ont besoin — sans leur donner un accès brut à tout le système.

MCP fonctionne comme un contrat d'interface : l'agent déclare les outils qu'il souhaite utiliser (lecture de fichiers, appel d'API, exécution de commandes), et le serveur MCP valide, filtre et journalise chaque requête. C'est une couche de gouvernance entre le LLM et votre infrastructure.

Chez MulerTech, nous utilisons cette approche pour exposer aux agents uniquement les outils strictement nécessaires à leur tâche :

Cette granularité évite le scénario catastrophe où un agent mal dirigé tenterait de modifier des fichiers de configuration sensibles ou d'appeler des endpoints non prévus.

Ce que cela change concrètement en CI/CD

L'article de Docker illustre un modèle organisationnel que nous reconnaissons : une équipe virtuelle d'agents spécialisés, chacun responsable d'une portion du cycle de livraison. Plutôt qu'un agent généraliste qui fait tout, plusieurs agents étroits et fiables collaborent.

Dans notre stack chez MulerTech :

1. Agent de revue — analyse les PR entrantes, vérifie les standards PSR et les règles métier documentées.
2. Agent de test — génère ou complète les tests manquants avant la merge.
3. Agent de migration — propose et valide les migrations de base de données dans un sandbox isolé.
4. Agent de documentation — met à jour les fichiers CHANGELOG.md et les annotations OpenAPI.

Chaque agent s'exécute dans son propre sandbox, avec son propre périmètre MCP, et ses actions sont auditables via les logs centralisés de notre stack Docker sur le serveur dédié IONOS.

Le gain est mesurable : les tâches répétitives à faible valeur ajoutée (mise à jour des fixtures de test, synchronisation de la doc API) sont déléguées, et les développeurs concentrent leur attention sur la logique métier et l'architecture.

Conclusion : l'isolation comme fondation de confiance

Adopter des agents IA en production sans garde-fous, c'est introduire un vecteur de risque difficile à maîtriser. Docker Sandboxes et MCP ne sont pas des gadgets — ils représentent une réponse architecturale sérieuse à un problème réel : comment donner de l'autonomie à un LLM sans perdre le contrôle de votre infrastructure ?

La réponse de Docker — et la nôtre chez MulerTech — repose sur trois principes : isolation par conteneur, permissions minimales via MCP, et observabilité complète des actions. C'est exactement l'approche que nous recommandons à nos clients avant d'introduire tout agent autonome dans un pipeline de livraison.

Si vous explorez l'intégration d'agents IA dans votre workflow PHP/Symfony, n'hésitez pas à nous contacter pour discuter d'une architecture adaptée à votre contexte.