Sandbox pour outils IA : isoler les actions et vérifier les limites

Une sandbox pour outils IA limite l’environnement dans lequel un agent peut lire, écrire, exécuter ou appeler un réseau. Elle réduit l’impact d’une erreur ou d’une instruction hostile, mais elle n’est jamais une preuve suffisante à elle seule : les volumes montés, identités, secrets, connexions sortantes et interfaces d’outils doivent rester limités. La bonne question est donc : quelle action l’agent peut-il faire même s’il reçoit une mauvaise instruction ?

Une sandbox utile est définie par un contrat de tâche, des frontières mesurables et des tests de refus. Elle doit permettre le travail annoncé tout en empêchant les actions qui sortent du périmètre.

Ce que vous allez apprendre

Vous allez définir le contrat d’une sandbox, isoler les fichiers et le réseau, limiter les ressources et outils, observer l’exécution, tester les échecs et préparer un arrêt. Les mécanismes concrets peuvent être un compte système, un conteneur, une VM ou un runner isolé ; le modèle de contrôle reste le même.

Prérequis

• Une tâche précise et un jeu de données de test non sensible.
• La liste des fichiers, commandes et domaines indispensables.
• Un répertoire de sortie séparé et revu avant intégration.
• Des identifiants de test à portée minimale, ou aucun secret si possible.
• Une personne responsable de l’environnement et de son arrêt.

Ne créez pas une sandbox qui monte tout le projet, le dossier personnel ou le socket de conteneur « pour éviter les erreurs ». Ces accès annulent une grande partie de l’isolation recherchée.

1. Définir le contrat d’exécution

Écrivez les entrées, sorties, outils, durée maximale, mémoire, CPU et destinations réseau de la tâche. Ajoutez les interdictions : pas d’accès hôte, pas de lecture hors corpus, pas d’installation de paquets, pas d’écritures de production et pas d’actions externes sans approbation. Ce contrat sert à choisir la technologie de sandbox, mais surtout à décider si un comportement est anormal.

Conservez une séparation entre ce que l’agent propose et ce que la sandbox autorise. Un document lu ou une réponse d’outil ne peut pas changer les montages, la limite de temps ou les identités accordées.

Vérification : relisez le contrat avec un scénario normal et un scénario interdit. Pour chacun, vous devez pouvoir nommer la règle technique qui permet ou bloque l’action.

2. Isoler les fichiers

Montez ou copiez uniquement le corpus nécessaire dans la sandbox. Préférez la lecture seule pour les entrées et un chemin de sortie séparé pour les résultats. Un agent qui analyse un dépôt ne doit pas pouvoir modifier directement la branche de travail ; un agent qui génère un rapport n’a besoin d’écrire que ce rapport.

Évitez les répertoires sensibles : clés SSH, fichiers d’environnement, profils de navigateur, gestionnaires de mots de passe, caches d’identifiants et racine du système. Les données temporaires doivent être effacées selon une procédure contrôlée après revue, pas pendant l’exécution d’une tâche qui pourrait encore les utiliser.

Vérification : tentez de lire un fichier hors périmètre et d’écrire dans une entrée en lecture seule. Les opérations doivent échouer ; l’écriture normale dans le dossier de sortie doit fonctionner.

3. Limiter réseau et identités

Si la tâche est locale, n’accordez pas de sortie Internet. Si elle appelle un modèle ou un service, autorisez uniquement les destinations nécessaires et ajoutez des délais, quotas et une identité dédiée. Un token de sandbox ne doit pas donner accès aux systèmes de production ou aux comptes humains. Préparez une expiration et une révocation qui peuvent être testées.

Les réponses reçues du réseau restent non fiables. Le fait qu’une API soit autorisée ne lui donne pas le droit d’ordonner une nouvelle action, d’augmenter les permissions ou d’exfiltrer des fichiers. Les sorties doivent être contrôlées par la couche d’outils et non par une instruction dans le contenu.

Vérification : appelez une destination non autorisée depuis le test. La connexion doit échouer, tandis que l’appel indispensable fonctionne avec l’identité limitée.

4. Limiter ressources et outils

Définissez des plafonds de temps, CPU, mémoire, espace disque et nombre de processus. Ces limites ne corrigent pas une permission trop large, mais empêchent qu’une boucle ou un fichier hostile monopolise l’hôte. Limitez aussi les outils : une fonction de recherche ciblée est plus sûre qu’un shell général ; une API de sortie contrôlée est plus sûre qu’un accès à n’importe quelle URL.

Ne donnez pas de mode privilégié, de périphérique hôte ou de socket d’orchestrateur sans analyse explicite. Une sandbox qui peut démarrer d’autres conteneurs ou modifier l’hôte possède déjà une voie de sortie importante. Si une tâche exige cet accès, décomposez-la ou utilisez un environnement séparé avec une revue renforcée.

Vérification : lancez une charge de test qui dépasse une limite et vérifiez l’arrêt propre. Testez aussi l’appel d’un outil non enregistré : il doit être refusé sans effet secondaire.

5. Observer sans collecter tout le contexte

Journalisez la version de l’environnement, l’identifiant de tâche, les outils utilisés, la durée, les refus et les fichiers produits. Évitez le dump de mémoire, les prompts complets, les secrets et le contenu intégral des documents. Les logs servent à comprendre pourquoi une règle s’est déclenchée, pas à créer une copie durable du corpus.

Ajoutez des métriques simples : taux de refus, dépassements de limite, erreurs d’outil et durée. Une augmentation soudaine peut signaler une dérive de tâche ou une configuration cassée. Limitez l’accès aux journaux et leur rétention : une trace de sandbox reste une donnée sensible selon le corpus traité.

Vérification : exécutez un scénario autorisé puis un refus ; vous devez pouvoir distinguer les deux dans les traces sans retrouver de secret ou de contenu complet.

6. Arrêter, revoir et intégrer

À la fin de la tâche, arrêtez l’environnement, collectez les résultats dans le répertoire de sortie et faites-les relire avant intégration. Si l’agent a proposé un diff, un email ou une action, validez le chemin, le contenu et la cible indépendamment. Ne reliez pas directement la sortie de sandbox à une publication ou à une production.

Préparez une procédure d’urgence : interrompre le runner, révoquer le token, vérifier les appels récents et conserver les traces nécessaires à l’analyse. Une suppression aveugle peut détruire la preuve d’un incident ; suivez votre politique de conservation et d’investigation.

Vérification : interrompez un test en cours, puis confirmez que l’environnement ne possède plus d’accès actif et que les sorties prévues sont séparées de l’application cible.

Problèmes fréquents et solutions

La sandbox ne peut pas accéder au projet. Réduisez le corpus ou ajoutez un sous-dossier précis, plutôt que de monter le répertoire personnel complet.

L’agent a besoin d’un package. Construisez l’image ou l’environnement avec une dépendance épinglée ; ne lui donnez pas un installateur libre au runtime.

Un résultat doit être intégré. Utilisez un répertoire de sortie et une revue humaine ou automatisée avant le rapprochement.

Les limites empêchent une tâche légitime. Mesurez le besoin, augmentez une seule limite documentée et conservez un test qui prouve sa justification.

FAQ

Un conteneur est-il toujours une sandbox ?

Non. Il peut offrir une isolation, mais ses volumes, capacités, réseau et secrets déterminent ce qu’il protège réellement.

Faut-il bloquer tout réseau ?

Quand la tâche est purement locale, oui. Sinon, utilisez une allowlist de destinations et des identités limitées.

Peut-on exécuter des commandes dans une sandbox ?

Oui si elles sont nécessaires et limitées. Préférez une liste d’outils ou un runner dédié plutôt qu’un shell libre.

La sandbox remplace-t-elle les permissions API ?

Non. L’API doit continuer d’authentifier, autoriser et valider l’appelant, même si l’appel vient d’un environnement isolé.

Comment savoir si l’isolation fonctionne ?

Par des tests négatifs : chemins interdits, réseau non autorisé, outils inconnus, dépassement de ressources et révocation d’identité.

Conclusion

Une sandbox pour outils IA est efficace lorsqu’elle rend les limites visibles et vérifiables : corpus restreint, sortie séparée, réseau et identité réduits, ressources plafonnées et refus testés. Elle complète les permissions et validations applicatives ; elle ne les remplace pas.

Sources et limites

Sources primaires : OWASP Agentic AI Threats and Mitigations, NIST SP 800-190 Application Container Security Guide et NIST AI RMF. Le niveau d’isolation dépend de la technologie, de l’hôte et des montages réels. Ce guide ne garantit pas qu’une sandbox empêchera toute compromission.