Agent Sandboxing

La mise en bac à sable d’un agent consiste à exécuter un agent IA, ses outils ou le code qu’il génère dans un environnement d’exécution restreint. Le bac à sable limite les fichiers, les réseaux, les identifiants, les processus et les ressources informatiques auxquels l’agent peut accéder. Si l’agent prend une décision dangereuse ou traite des instructions malveillantes, ces limites réduisent les conséquences potentielles pour les systèmes de production et les données sensibles.

Fonctionnement de la mise en bac à sable des agents#

Un agent fonctionne souvent à l’aide d’un environnement d’exécution pour agent qui relie un modèle à des outils, à de la mémoire, à des API et à des boucles d’exécution. La mise en bac à sable ajoute une couche de contrôle autour de ces capacités. Au lieu de faire confiance au modèle pour suivre une consigne telle que « ne pas accéder aux fichiers privés », l’environnement d’exploitation bloque techniquement cet accès.

Un bac à sable pratique peut combiner les éléments suivants :

• Un conteneur éphémère ou une machine virtuelle, détruit après la tâche.
• Un système de fichiers de base en lecture seule et un petit espace de travail accessible en écriture.
• Des règles de trafic réseau sortant qui n’autorisent que les domaines approuvés ou les services internes.
• Des identifiants à durée de vie limitée, associés à l’utilisateur et à la tâche en cours.
• Des limites sur le CPU, la mémoire, le stockage, les processus et la durée d’exécution.
• Des journaux d’audit couvrant les appels d’outils, les modifications de fichiers, les requêtes réseau et les violations des règles.

Les mécanismes de contrôle de Linux, comme le profil seccomp par défaut de Docker, peuvent restreindre les appels système, tandis que les limites de ressources de Docker plafonnent la consommation des ressources. À l’échelle d’un cluster, les NetworkPolicies de Kubernetes peuvent contrôler les services avec lesquels une charge de travail d’agent communique.

Pourquoi la mise en bac à sable des agents est importante#

Les agents peuvent agir grâce à l’appel de fonctions et à l’utilisation d’outils, ce qui rend leurs défaillances plus lourdes de conséquences qu’une réponse incorrecte d’un chatbot. Un agent de programmation peut exécuter des commandes shell, tandis qu’un agent d’exploitation peut modifier des enregistrements ou déclencher des déploiements.

Les recommandations de l’OWASP sur la sécurité des agents IA recensent notamment les risques d’utilisation abusive des outils, d’élévation des privilèges, d’empoisonnement de la mémoire et d’exfiltration de données. La mise en bac à sable aide à contenir ces risques, surtout lorsqu’un agent rencontre une injection de prompt dissimulée dans une page Web, un document, les métadonnées d’une image ou une réponse d’outil. Les recommandations de l’OWASP pour prévenir les injections de prompt préconisent des défenses à plusieurs niveaux, car le filtrage des entrées ne permet pas à lui seul de détecter de manière fiable toutes les instructions malveillantes.

La mise en bac à sable permet aussi de limiter l’autonomie excessive. Un agent disposant d’outils inutiles, d’identifiants trop étendus et d’une autonomie sans restriction risque de mener des actions dommageables à la suite d’une erreur du modèle ou d’une entrée manipulée. Les recommandations de l’OWASP sur l’autonomie excessive préconisent de limiter les fonctionnalités des outils, les autorisations et l’autonomie plutôt que de compter uniquement sur le comportement du modèle.

Mise en bac à sable et mécanismes de contrôle connexes#

La mise en bac à sable des agents complète les autres mécanismes de sécurité, mais ne les remplace pas :

• Garde-fous pour l’IA : les garde-fous examinent les entrées, les sorties ou les actions envisagées. Un bac à sable impose des limites à l’environnement même lorsqu’un garde-fou ne détecte pas une menace.
• Contrôle des accès : l’autorisation détermine si une action est permise. La mise en bac à sable limite les ressources disponibles si la logique d’autorisation est contournée. Les bonnes pratiques d’AWS en matière de gestion des identités et des accès mettent l’accent sur les identifiants temporaires et les autorisations selon le principe du moindre privilège.
• Conteneurisation : les conteneurs regroupent et isolent les processus, mais les paramètres par défaut des conteneurs ne constituent pas nécessairement une frontière de sécurité solide. Le guide de démarrage rapide Docker d’Ultralytics permet de créer des environnements de vision par ordinateur cohérents et isolés, tandis que les bacs à sable de production nécessitent des restrictions supplémentaires concernant le système de fichiers, les capacités, le réseau et les ressources.
• Environnements de test : un « bac à sable » de développement est une copie hors production d’un système. La mise en bac à sable des agents restreint spécifiquement l’exécution et peut être appliquée en développement comme en production.

Les compétences d’agent d’Ultralytics fournissent des instructions réutilisables aux agents de programmation, mais ne créent pas de frontière d’isolation. Leurs scripts et dépendances doivent tout de même être examinés et exécutés avec les autorisations appropriées.

Applications concrètes#

Agents de programmation en entreprise : un agent de programmation peut examiner un dépôt, modifier des fichiers et exécuter des tests dans un espace de travail temporaire. Le bac à sable ne monte que le dépôt attribué, bloque les identifiants de production, limite le trafic sortant aux registres de paquets approuvés et exige une approbation humaine avant toute fusion ou tout déploiement. Une dépendance compromise ou une instruction injectée ne peut donc pas analyser librement le stockage interne ni transmettre le code source.

Agents d’exploitation dotés de capacités de vision : un agent d’entrepôt peut analyser des images de caméra avec Ultralytics YOLO26, repérer les allées bloquées et ouvrir des tickets de maintenance. Son bac à sable peut fournir un accès en lecture seule aux images entrantes et un accès réseau limité aux API d’inférence et de gestion des tickets. Il ne doit pas recevoir un accès sans restriction à l’administration des caméras, aux dossiers des employés ou aux identifiants de déploiement.

L’étape de perception peut utiliser le flux de travail de prédiction Ultralytics YOLO documenté :

from pathlib import Path

from ultralytics import YOLO

source = "https://ultralytics.com/images/bus.jpg"
output_path = Path("sandbox_result.jpg")

# Exécute l’inférence visuelle dans l’espace de travail restreint
model = YOLO("yolo26n.pt")
results = model(source)

result = results[0]
result.save(filename=str(output_path))

Le code Python effectue une inférence classique ; l’environnement d’exécution qui l’entoure fournit le bac à sable en restreignant l’accès aux fichiers, au réseau, aux identifiants et aux ressources.

Conseils pratiques de conception#

Commence par n’accorder aucun accès, puis autorise explicitement uniquement ce qui est nécessaire à chaque tâche. Utilise des espaces de travail temporaires, des identifiants à durée de vie limitée, des montages en lecture seule, des listes d’autorisation pour le trafic réseau sortant, des délais d’expiration et des quotas de ressources. Exige une approbation pour les actions irréversibles et maintiens les contrôles d’autorisation en dehors du modèle.

Consigne chaque tentative d’action, y compris les opérations bloquées, sans exposer de secrets dans les journaux. Les équipes peuvent utiliser la surveillance des déploiements sur la plateforme Ultralytics pour observer les requêtes aux points de terminaison de vision, la latence, les erreurs et l’état de santé dans les flux de travail des agents. Enfin, teste le système complet avec des fichiers malveillants, des prompts indirects, des appels d’outils répétés et des tentatives d’épuisement des ressources. Le guide de mise en œuvre du cadre de gestion des risques liés à l’IA du NIST propose une structure plus générale pour gouverner, mesurer et gérer ces risques de façon continue.