À suivreGuide suivant
Conception d'outils pour les agents LLM
Technique
GUIDE Technique
Bacs à sable d'exécution de code pour les agents
Un bac à sable d'exécution de code est un environnement isolé dans lequel un agent d'IA peut exécuter le code qu'il écrit sans pouvoir endommager la machine hôte, accéder à des données qu'il ne devrait pas voir ou utiliser des ressources illimitées.
Sur cette page4 minutes de lecture
Aperçu
C'est important car un agent capable d'exécuter du code est bien plus performant (il peut calculer, analyser des fichiers et tester son propre travail), mais le code écrit par modèle n'est pas fiable par défaut et peut être bogué, inutile ou manipulé par injection rapide.
Plongée profonde
Lorsqu'un agent génère du code, quelque chose doit l'exécuter. Exécuter ce code directement sur un ordinateur portable de développeur ou un serveur de production est risqué : le code pourrait supprimer des fichiers, lire les informations d'identification des variables d'environnement, installer des logiciels, extraire de la crypto-monnaie ou ouvrir des connexions réseau. Un bac à sable met une frontière entre le code et tout le reste. Il existe plusieurs niveaux d’isolement, avec différents compromis. Les conteneurs standard (par exemple Docker) utilisent les espaces de noms et les groupes de contrôle Linux pour donner au code sa propre vue des processus, des fichiers et du réseau, et pour limiter le processeur et la mémoire. Ils démarrent rapidement, mais chaque conteneur partage le noyau de l'hôte, donc une vulnérabilité du noyau peut laisser du code s'échapper. gVisor, un projet open source de Google, ajoute un noyau d'espace utilisateur qui intercepte les appels système, réduisant ainsi le code non fiable qui peut toucher le noyau réel. Les microVM telles que Firecracker, initialement construites par AWS pour Lambda et Fargate, donnent à chaque charge de travail sa propre machine virtuelle et son propre noyau léger tout en démarrant en une fraction de seconde. Les services sandbox hébergés pour les agents, tels qu'E2B, s'appuient sur cette approche microVM. À l'extrémité la plus légère, les environnements d'exécution WebAssembly et des outils comme Pyodide peuvent exécuter Python dans un navigateur ou un bac à sable Wasm sans accès direct au système. La technologie d’isolation ne représente que la moitié de la conception. Les bons bacs à sable restreignent également le réseau (souvent refusé par défaut avec une liste autorisée), montent le système de fichiers en lecture seule, à l'exception d'un répertoire de travail, gardent entièrement les secrets hors de l'environnement et imposent des limites de temps, de mémoire, de nombre de processus et de disque. Ils sont généralement éphémères : créés par tâche et détruits ensuite. Une idée fausse très répandue est qu’un bac à sable assure la sécurité d’un agent. Cela limite les dommages causés par le code lui-même, mais cela n'empêche pas un agent de produire de mauvaises réponses, et tout outil ou identifiant que vous transmettez dans le bac à sable devient accessible par tout code qui y est exécuté, y compris le code écrit en réponse aux instructions injectées.
Impact stratégique
Coût et budget
Les décisions en matière d'architecture déterminent les performances et les coûts d'exploitation pendant des années.
Décisions plus claires
La formation technique aide les équipes à choisir la bonne pile, pas seulement la plus récente.
Contrôle qualité
De meilleurs choix d’ingénierie réduisent les incidents de fiabilité en production.
L’avenir des sandbox d’exécution de code pour les agents
L'exécution de code devient une fonctionnalité standard pour les assistants et les agents d'IA, de sorte que le sandboxing deviendra probablement davantage un service de base avec des valeurs par défaut raisonnables plutôt que quelque chose que chaque équipe construit à partir de zéro. Attendez-vous à un travail continu sur un démarrage, un instantané et une reprise plus rapides, ainsi qu'à des politiques plus fines pour l'accès au réseau et aux fichiers qui peuvent être ajustées par tâche. Le problème le plus difficile à résoudre est celui de la politique plutôt que de l'isolement : décider ce qu'un agent doit être autorisé à atteindre et tenir les utilisateurs informés lorsque les agents entreprennent des actions autonomes plus longues. L'isolement restera une couche parmi plusieurs, aux côtés des autorisations, de la journalisation et de l'examen humain.
Mise en œuvre dans le monde réel
Un assistant d'analyse de données reçoit un CSV téléchargé, écrit du code pandas pour le nettoyer et tracer les tendances, et exécute ce code dans un bac à sable jetable qui est supprimé à la fin de la session.
Un agent de codage exécute la suite de tests d'un référentiel dans un conteneur sans accès réseau sortant, de sorte qu'un script de dépendance malveillant ne peut pas envoyer de code source ou de secrets à un serveur externe.
Une plate-forme éducative permet aux étudiants de demander à un tuteur d'IA d'exécuter des exemples Python, chaque exécution étant limitée à quelques secondes de CPU et à une limite de mémoire fixe afin qu'une boucle infinie accidentelle ne puisse pas bloquer le service.
Une équipe de recherche donne à un agent une microVM avec une copie en lecture seule d'un ensemble de données et un seul dossier de sortie inscriptible, afin que l'agent puisse produire des résultats sans modifier ni supprimer les données d'origine.
Risques et garde-fous
L’optimisation d’un benchmark peut masquer des faiblesses plus larges du système.
Les coûts d’infrastructure et de maintenance sont souvent sous-estimés.
Les lacunes en matière de sécurité et d’observabilité peuvent se creuser à mesure que les systèmes deviennent plus complexes.
Feuille de route de mise en œuvre
Définissez les objectifs de latence, de qualité et de coût avant la mise en œuvre.
Benchmark dans des conditions de charge et de données réalistes.
Surveillance des instruments pour détecter les erreurs, la dérive et l'impact sur l'utilisateur.
Préparez les chemins de restauration et de réponse aux incidents avant la mise à l’échelle.
Continuez à explorer
Free newsletter
Get the daily AI briefing
Three verified AI stories every weekday morning, written in plain English. Free forever, no ads.
One email each weekday. Unsubscribe in one click. We never sell or share your address.
Test yourself
Take the Code Execution Sandboxes for Agents quiz
Instant feedback on every answer, and a shareable certificate with a verifiable ID once you pass a course.
Support free AI education. AI Understanding is a 501(c)(3) nonprofit — no ads, no paywall, ever. Make a donation
Questions fréquemment posées
Qu’est-ce que les sandbox d’exécution de code pour les agents ?
Un bac à sable d'exécution de code est un environnement isolé dans lequel un agent d'IA peut exécuter le code qu'il écrit sans pouvoir endommager la machine hôte, accéder à des données qu'il ne devrait pas voir ou utiliser des ressources illimitées. C'est important car un agent capable d'exécuter du code est bien plus performant (il peut calculer, analyser des fichiers et tester son propre travail), mais le code écrit par modèle n'est pas fiable par défaut et peut être bogué, inutile ou manipulé par injection rapide.
Pourquoi le code écrit par un agent IA est-il traité comme non fiable par défaut ?
Le guide explique que le code écrit par modèle peut contenir des bogues, consommer des ressources excessives ou suivre des instructions injectées. Il doit donc s'exécuter à l'intérieur d'une limite plutôt que directement sur un hôte.
Quelle est la principale faiblesse de sécurité des conteneurs standards par rapport aux microVM ?
Les conteneurs utilisent des espaces de noms et des groupes de contrôle mais partagent tous le noyau hôte, donc une vulnérabilité du noyau peut permettre une évasion. Les MicroVM donnent à chaque charge de travail son propre noyau.
Qu'est-ce que gVisor ajoute pour réduire les risques liés au code non fiable ?
gVisor, de Google, exécute un noyau d'espace utilisateur qui gère les appels système, réduisant ainsi la quantité de code non fiable du noyau hôte réel qui peut atteindre.
Les microVM Firecracker ont été initialement conçues par AWS pour alimenter quel type de services ?
Firecracker a été créé pour les charges de travail sans serveur AWS telles que Lambda et Fargate, où de nombreuses charges de travail isolées doivent démarrer rapidement.
Pourquoi la restriction de l’accès au réseau sortant est-elle souvent considérée comme le contrôle sandbox le plus important lorsqu’une injection rapide est possible ?
Si les instructions injectées amènent l'agent à écrire du code malveillant, un réseau de refus par défaut empêche ce code d'exfiltrer les données.
Continuez à apprendre
Guides associés
Plus de guides sélectionnés pour ce sujet