Agent Sandboxing

L'isolation des agents (agent sandboxing) consiste à exécuter un AI agent, ses outils ou le code généré dans un environnement d'exécution restreint. Le bac à sable limite les fichiers, réseaux, identifiants, processus et ressources de calcul auxquels l'agent peut accéder. Si l'agent prend une décision non sécurisée ou traite des instructions malveillantes, ces barrières réduisent l'impact potentiel sur les systèmes de production et les données sensibles.

Comment fonctionne l'isolation des agents#

Un agent opère souvent par le biais d'un agent harness qui connecte un modèle à des outils, de la mémoire, des API et des boucles d'exécution. L'isolation ajoute une couche de mise en application autour de ces capacités. Au lieu de faire confiance au modèle pour suivre une invite telle que « ne pas accéder aux fichiers privés », l'environnement d'exploitation empêche techniquement cet accès.

Un bac à sable pratique peut combiner :

• Un conteneur éphémère ou une machine virtuelle détruite après la tâche.
• Un système de fichiers de base en lecture seule doté d'un petit espace de travail inscriptible.
• Des règles de sortie réseau n'autorisant que les domaines approuvés ou les services internes.
• Des identifiants à courte durée de vie limités à l'utilisateur et à la tâche en cours.
• Des limites de processeur, de mémoire, de stockage, de processus et de temps d'exécution.
• Des journaux d'audit couvrant les appels d'outils, les modifications de fichiers, les requêtes réseau et les violations de politiques.

Des contrôles Linux tels que le Docker default seccomp profile peuvent restreindre les appels système, tandis que les Docker resource constraints limitent la consommation des ressources. À l'échelle d'un cluster, les Kubernetes NetworkPolicies peuvent contrôler les services avec lesquels une charge de travail d'agent communique.

Pourquoi l'isolation des agents est importante#

Les agents peuvent agir par le biais de function calling and tool use, ce qui rend leurs échecs plus lourds de conséquences qu'une réponse incorrecte de chatbot. Un agent de codage peut exécuter des commandes shell, tandis qu'un agent opérationnel peut mettre à jour des enregistrements ou déclencher des déploiements.

Le guide OWASP AI Agent Security guidance identifie des risques tels que l'abus d'outils, l'élévation de privilèges, l'empoisonnement de mémoire et l'exfiltration de données. L'isolation aide à contenir ces risques, en particulier lorsqu'un agent rencontre une prompt injection cachée dans une page Web, un document, des métadonnées d'image ou la réponse d'un outil. Le guide OWASP prompt injection prevention guidance recommande des défenses multicouches, car le filtrage des entrées ne peut pas à lui seul identifier de manière fiable chaque instruction hostile.

L'isolation répond également à une agence excessive. Un agent doté d'outils inutiles, de larges identifiants et d'une autonomie illimitée peut effectuer des actions dommageables suite à une erreur du modèle ou à une entrée manipulée. Le guide OWASP guidance on excessive agency recommande de minimiser les fonctionnalités des outils, les permissions et l'autonomie plutôt que de s'en remettre uniquement au comportement du modèle.

Isolation et contrôles associés#

L'isolation des agents complète d'autres mécanismes de sécurité sans les remplacer :

• AI guardrails : Les barrières de sécurité inspectent les entrées, les sorties ou les actions proposées. Un bac à sable impose des limites environnementales même lorsqu'une barrière rate une menace.
• Contrôle d'accès : L'autorisation détermine si une action est permise. L'isolation limite les ressources disponibles si la logique d'autorisation est contournée. Les bonnes pratiques AWS identity and access management best practices mettent l'accent sur les identifiants temporaires et les permissions à privilège minimal.
• Conteneurisation : Les conteneurs emballent et isolent les processus, mais les paramètres de conteneur par défaut ne constituent pas nécessairement une barrière de sécurité solide. Le guide Ultralytics Docker Quickstart prend en charge des environnements de vision par ordinateur cohérents et isolés, tandis que les bacs à sable de production nécessitent des restrictions supplémentaires sur 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. L'isolation des agents restreint spécifiquement l'exécution et peut être appliquée en développement et en production.

Les Ultralytics Agent Skills fournissent des instructions réutilisables pour les agents de codage, mais ces compétences ne créent pas de barrière d'isolation. Leurs scripts et dépendances doivent tout de même être examinés et exécutés avec les permissions appropriées.

Applications concrètes#

Agents de codage d'entreprise : Un agent de codage peut inspecter un dépôt, modifier des fichiers et exécuter des tests dans un espace de travail temporaire. Le bac à sable monte uniquement le dépôt assigné, bloque les identifiants de production, restreint le trafic sortant vers les registres de paquets approuvés et requiert l'approbation humaine avant la fusion ou le déploiement. Une dépendance compromise ou une instruction injectée ne peut donc pas balayer librement le stockage interne ni transmettre le code source.

Agents opérationnels activés par vision : Un agent d'entrepôt peut analyser des images de caméras avec Ultralytics YOLO26, identifier des 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 uniquement aux API d'inférence et de billetterie. Il ne doit pas recevoir d'administration de caméra sans restriction, de dossiers d'employés ni d'identifiants de déploiement.

L'étape de perception peut utiliser le flux documenté Ultralytics YOLO predict workflow :

from pathlib import Path

from ultralytics import YOLO

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

# Run visual inference inside the restricted workspace
model = YOLO("yolo26n.pt")
results = model(source)

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

Le code Python effectue une inférence ordinaire ; l'environnement d'exécution environnant fournit le bac à sable en restreignant les fichiers, la mise en réseau, les identifiants et les ressources.

Conseils de conception pratiques#

Commence sans aucun accès et autorise explicitement uniquement ce que chaque tâche requiert. Utilise des espaces de travail temporaires, des identifiants à courte durée de vie, des montages en lecture seule, des listes d'autorisation de réseau sortant, des délais d'attente et des quotas de ressources. Exige une approbation pour les actions irréversibles et garde les contrôles d'autorisation en dehors du modèle.

Consigne chaque action tentée, y compris les opérations bloquées, sans exposer de secrets dans les journaux. Les équipes peuvent utiliser la surveillance de déploiement Ultralytics Platform deployment monitoring pour observer les requêtes de points de terminaison de vision, la latence, les erreurs et la santé au sein des flux de travail des agents. Enfin, teste le système complet contre les fichiers malveillants, les invites indirectes, les appels d'outils répétés et les tentatives d'épuisement des ressources. Le guide NIST AI Risk Management Framework Playbook offre une structure plus large pour gouverner, mesurer et gérer continuellement ces risques.