Quelle est la sécurité du bac à sable IA pour l'exécution de code ?

Un bac à sable IA pour exécuter du code est aussi sécurisé que sa frontière d’isolation — et la frontière d’isolation n’est qu’une partie de la réponse. La meilleure question est : qu’est-ce que le bac à sable isole réellement, et que peut-il encore s’échapper ? La plupart des bacs à sable bloquent bien certaines choses (exécution de code au niveau du processus, écritures arbitraires dans le système de fichiers de l’hôte) et laissent d’autres choses ouvertes par défaut (réseau sortant, installations de paquets, secrets dans les variables d’environnement). Comprendre ces lacunes est la clé pour évaluer si un bac à sable correspond à votre modèle de risque. Pour un contexte sur ce qu’est un bac à sable pour agent IA et comment les concepts fondamentaux — isolation, sortie, instantanés, microVM — s’articulent, consultez le guide de définition avant d’entrer dans les détails de sécurité.

Ce que « sécurisé » signifie pour un bac à sable d’exécution de code

La sécurité dans un bac à sable d’exécution de code n’est pas une propriété binaire. C’est un ensemble de contrôles, chacun répondant à une catégorie spécifique de risque. Lorsque quelqu’un demande « ce bac à sable est-il sécurisé ? », il pose généralement plusieurs questions distinctes à la fois :

• Isolation de l’hôte : Le code exécuté à l’intérieur du bac à sable peut-il s’échapper vers le système hôte ?
• Isolation des locataires : Le code d’un utilisateur peut-il affecter la session d’un autre utilisateur ?
• Contrôle de la sortie : Le code à l’intérieur du bac à sable peut-il atteindre Internet, les services internes ou les points de terminaison de métadonnées ?
• Portée des secrets : Les informations d’identification sont-elles accessibles à une partie plus large du bac à sable que nécessaire ?
• Risque lié à la chaîne d’approvisionnement : Les installations de paquets peuvent-elles introduire du code inattendu ou malveillant ?
• Auditabilité : Pouvez-vous reconstruire ce que l’agent a réellement fait après coup ?

Un bac à sable peut être solide sur l’isolation de l’hôte et faible sur la sortie. Solide sur la sortie et faible sur les secrets. Évaluer « à quel point c’est sécurisé » nécessite de vérifier chaque dimension séparément, et non d’accepter une étiquette unique comme « conteneurisé » ou « basé sur microVM » comme réponse complète.

Comparaison des couches d’isolation

Il existe trois principaux modèles d’isolation utilisés dans les bacs à sable d’exécution de code IA. Chacun offre une frontière différente.

Isolation par processus

L’isolation par processus utilise des primitives au niveau du système d’exploitation — espaces de noms Linux, cgroups, filtres seccomp et profils AppArmor ou SELinux — pour restreindre ce à quoi un processus peut accéder. Le bac à sable s’exécute en tant que processus sur le système d’exploitation hôte, partageant le noyau hôte.

Ce qu’elle empêche : L’accès au système de fichiers plus large, aux autres processus en dehors du bac à sable, et aux appels système explicitement bloqués par la politique seccomp.

Ce qu’elle n’empêche pas : Les exploits du noyau qui élèvent les privilèges via une vulnérabilité partagée. Un contournement de seccomp ou une vulnérabilité du noyau peut franchir la frontière de l’hôte.

Quand elle est appropriée : Pour du code à courte durée de vie, à faible risque et relativement fiable, où la rapidité de démarrage et la portabilité comptent plus qu’une frontière VM dure. Déconseillé pour exécuter du code arbitraire généré par un agent provenant d’utilisateurs externes.

Isolation par conteneur (Docker/espaces de noms)

L’isolation par conteneur étend l’isolation par processus avec un modèle d’image plus structuré, un espace de noms réseau et des montages de volumes. La plupart des implémentations de bacs à sable basées sur Docker exécutent le code à l’intérieur d’un conteneur avec une image minimale et un profil seccomp restreint.

Ce qu’elle empêche : L’accès direct au système de fichiers de l’hôte, la plupart des accès réseau aux conteneurs adjacents (lorsqu’elle est correctement configurée), un accès facile aux processus de l’hôte.

Ce qu’elle n’empêche pas : Les exploits au niveau du noyau s’appliquent toujours — les conteneurs partagent le noyau hôte. Des montages de volumes mal configurés, des profils seccomp trop larges, le mode --privileged et les sockets Docker exposés peuvent tous annuler la frontière prévue.

Quand elle est appropriée : De nombreux déploiements en production utilisent efficacement les conteneurs pour l’exécution de code IA, à condition que le profil seccomp soit strict, que l’image soit minimale, que la sortie soit restreinte et qu’aucun accès privilégié ne soit accordé. Le modèle de risque est différent de celui des microVM mais gérable avec une configuration minutieuse.

Isolation par microVM (Firecracker/gVisor)

L’isolation par microVM exécute chaque bac à sable dans une machine virtuelle légère avec son propre noyau invité, isolé de l’hôte par une frontière d’hyperviseur KVM. Firecracker est l’implémentation la plus courante ; gVisor (avec son noyau en espace utilisateur) offre un compromis différent.

Ce qu’elle empêche : Les exploits du noyau invité ne se propagent pas au noyau hôte ou aux autres invités. La surface d’attaque de l’hôte est réduite au VMM (moniteur de machine virtuelle), qui est conçu pour être minimal.

Ce qu’elle n’empêche pas : Les vulnérabilités dans le VMM lui-même (rares mais pas impossibles). Les contrôles de réseau, de paquets et de secrets résident toujours en dehors de la frontière de la VM — l’isolation par microVM ne les gère pas.

Quand elle est appropriée : Pour exécuter du code non fiable ou généré par un agent provenant d’utilisateurs externes, des environnements multi-locataires où le rayon d’explosion compte, et des charges de travail qui peuvent exécuter des commandes shell arbitraires ou des scripts d’installation de paquets.

Modèle d’isolation	Noyau hôte partagé	Séparation des locataires	Surcharge de démarrage	Risque d’évasion de l’hôte
Processus	Oui	Faible	La plus faible	Le plus élevé
Conteneur	Oui	Modérée	Faible	Moyen (dépend de la configuration)
MicroVM	Non	Forte	Modéré	Faible

Ce qui peut encore s’échapper de chaque frontière

Le modèle d’isolation traite de l’exécution de code au moment de l’exécution. Il ne traite pas automatiquement ce qui entre ou sort du bac à sable par d’autres chemins.

Réseau sortant : Les trois modèles d’isolation laissent l’accès réseau sortant à la configuration de la politique. Une sortie ouverte par défaut signifie que le code à l’intérieur du bac à sable peut atteindre Internet public, les points de terminaison de métadonnées cloud (169.254.169.254 sur AWS et GCP), les services internes sur le même réseau et des API externes arbitraires. C’est un chemin d’exfiltration de données, un chemin de récupération de secrets et un chemin de commande et de contrôle, quel que soit le modèle d’isolation.

Installations de paquets : Une commande apt install, pip install ou npm install récupère et exécute du code depuis un registre externe. Si le bac à sable autorise les installations de paquets et a une sortie ouverte, une collision de noms de paquets, une attaque de typosquattage ou une attaque de confusion de dépendances peut introduire du code malveillant qui s’exécute avec toutes les autorisations du bac à sable. La frontière d’isolation contient le rayon d’explosion mais n’empêche pas l’installation.

État partagé : Dans les déploiements multi-locataires, les caches partagés, les registres de paquets partagés, les images modèles partagées ou les montages de systèmes de fichiers partagés créent des canaux entre les locataires qui contournent la frontière d’isolation.

Secrets dans les variables d’environnement : Les variables d’environnement visibles par le processus de l’agent sont lisibles par tout code que l’agent exécute. Si une information d’identification de base de données ou une clé API se trouve dans l’environnement, elle est accessible au bac à sable et à tout ce qu’il exécute ou installe.

Contrôles de sortie et de réseau

La sortie est l’endroit où la plupart des bacs à sable ont leur plus grande lacune. L’accès Internet sortant ouvert est courant car il est pratique — les agents ont besoin d’installer des paquets, d’appeler des API et de récupérer des ressources. Mais cela crée également des risques :

Points de terminaison de métadonnées cloud : Sur une infrastructure cloud hébergée, 169.254.169.254 (et son équivalent IPv6) fournit des métadonnées d’instance, y compris les informations d’identification IAM. Le code à l’intérieur d’un bac à sable avec une sortie ouverte peut atteindre ce point de terminaison et récupérer les informations d’identification de l’hôte sous-jacent.

Exfiltration basée sur DNS : Même si HTTP est bloqué, les requêtes DNS sortantes peuvent être utilisées pour exfiltrer des données en les encodant dans des recherches de domaine. Le blocage DNS nécessite un filtrage au niveau du résolveur, pas seulement le blocage de TCP/UDP 53 vers des serveurs externes.

Services internes : Si le bac à sable s’exécute sur un segment de réseau privé, une sortie ouverte peut permettre l’accès à des bases de données internes, des panneaux d’administration et des API qui ne sont pas destinés à être accessibles depuis le code de l’agent.

Contrôles à évaluer :

Contrôle	Ce qu’il empêche	Ce qu’il faut vérifier
Sortie par défaut refusée	Connexions sortantes vers des destinations non listées	Bloque-t-il également le DNS ainsi que le TCP/UDP ?
Sortie basée sur une liste d’autorisation	Connexions vers des domaines non approuvés	La liste d’autorisation est-elle configurable par le client ?
Blocage des points de terminaison de métadonnées	Récupération des informations d’identification cloud via 169.254.169.254	Les métadonnées IPv6 sont-elles également bloquées ?
Proxy de sortie	Journalisation et inspection de tout le trafic sortant	Le journal du proxy est-il accessible ?
Filtrage DNS	Exfiltration basée sur DNS et résolution de noms interne	Quel résolveur est utilisé à l’intérieur du bac à sable ?

Il n’existe pas de politique de sortie universellement correcte. Certaines charges de travail d’agents ont réellement besoin d’un accès Internet large pour être utiles. Le point clé est que la politique soit délibérée et vérifiable, et non ouverte par défaut parce qu’elle n’a jamais été configurée.

Gestion des secrets

Les secrets dans les bacs à sable d’agents IA suivent les mêmes principes que les secrets dans tout système logiciel, avec une contrainte supplémentaire : l’agent peut exécuter du code qui lit, enregistre ou transmet l’environnement sans intention du développeur.

Portée : Montez uniquement les informations d’identification dont le bac à sable a réellement besoin pour la tâche en cours. Un bac à sable exécutant une tâche de codage n’a pas besoin des informations d’identification de la base de données de production. Un bac à sable évaluant les sorties du modèle n’a pas besoin de la clé API d’un service de facturation.

Durée de vie : Les informations d’identification à courte durée de vie sont nettement plus sûres que celles à longue durée de vie. Si une information d’identification fuit à l’intérieur d’un bac à sable, un TTL court limite la fenêtre d’exposition. De nombreux systèmes IAM cloud prennent en charge les jetons à courte durée de vie qui expirent en quelques minutes ou heures.

Méthode d’injection : Les variables d’environnement sont la méthode d’injection la plus courante et la plus accessible à tout code du processus. Les secrets qui peuvent être injectés via des montages de systèmes de fichiers, montés à un chemin que l’agent n’a pas besoin de parcourir, ou récupérés dynamiquement uniquement lorsque l’outil spécifique qui en a besoin s’exécute, sont plus contraints qu’un ensemble de variables d’environnement général.

Rédaction : Les secrets doivent être masqués dans stdout, stderr, les charges utiles de réponse des outils, le contexte visible par le modèle et les journaux d’audit. Un agent qui fait écho à son environnement, appelle env ou transmet un jeton à un appel API défaillant peut divulguer des informations d’identification dans des journaux qui sont ensuite stockés ou visibles par les opérateurs.

Limites de ressources et risque de déni de service

Un bac à sable sans limites de ressources est vulnérable aux charges de travail d’agents qui épuisent le CPU, la mémoire, le disque ou la bande passante réseau — que ce soit par du code incontrôlé, une boucle infinie, une fuite de mémoire dans un paquet installé, ou une tentative délibérée de perturber les charges de travail adjacentes.

Contrôles des ressources à vérifier :

• Limites CPU : Le plafonnement ou les limites strictes par session empêchent une session de monopoliser la capacité de l’hôte.
• Limites mémoire : Les politiques de kill OOM doivent terminer la session du bac à sable, pas le processus hôte.
• Quotas disque : Les limites d’écriture par session empêchent une session de remplir le stockage partagé.
• Délai d’exécution : Les sessions qui dépassent une limite de temps murale doivent être terminées proprement, pas laissées en cours d’exécution.
• Limites de débit réseau : Les limites de bande passante sortante peuvent contraindre l’exfiltration même lorsque la politique de sortie autorise la destination.
• Limites de processus simultanés : Les agents qui fourchent agressivement ou engendrent des processus d’arrière-plan peuvent épuiser les emplacements de la table des processus.

Les violations des limites de ressources méritent également d’être journalisées. Une session qui atteint systématiquement le plafonnement CPU ou le kill OOM lors de tâches qui devraient être légères est un signal qui mérite d’être investigué.

Visibilité d’audit

Les contrôles d’isolation réduisent le rayon d’explosion lorsque quelque chose tourne mal. Les journaux d’audit sont ce qui vous permet de découvrir que quelque chose a mal tourné et de reconstituer ce qui s’est passé.

Pour les bacs à sable d’agents IA spécifiquement, une couverture d’audit utile comprend :

• Exécution de processus : Chaque commande exécutée, avec la liste complète des arguments, l’UID et le processus parent. Sans listes d’arguments, curl et python dans un journal ne sont pas significatifs.
• Accès au système de fichiers : Lectures et écritures sur des chemins sensibles. Les écritures et suppressions sont une priorité plus élevée que les lectures pour la plupart des modèles de menace.
• Réseau sortant : Destinations, protocoles, requêtes DNS et octets transférés. La journalisation des requêtes DNS est souvent absente mais importante.
• Installations de paquets : Gestionnaire de paquets, nom du paquet, version, registre source et hachage.
• Cycle de vie de la session : Événements de création, pause, reprise, terminaison et nettoyage avec codes de raison.
• Événements de limite de ressources : Kills OOM, plafonnement CPU, terminaison par délai d’attente.

Le mécanisme de collecte compte autant que la couverture. Les journaux générés à l’intérieur du processus du bac à sable peuvent être supprimés ou modifiés par un agent suffisamment privilégié. La collecte au niveau du noyau (via auditd, eBPF ou instrumentation d’hyperviseur) est générée en dessous de la couche applicative, là où l’agent n’a aucun accès en écriture.

Questions à poser à tout fournisseur ou projet de bac à sable

Utilisez cette liste de contrôle lors de l’évaluation d’un service de bac à sable géré ou d’un framework de bac à sable open source. Pour une comparaison côte à côte de la manière dont les principaux fournisseurs répondent à ces questions, consultez Meilleurs bacs à sable pour agents IA en 2026 ou le guide d’évaluation E2B et Daytona.

Isolation

• Chaque session d’agent a-t-elle son propre environnement isolé, ou les sessions sont-elles regroupées sur des environnements d’exécution partagés ?
• Quel modèle d’isolation est utilisé : processus, conteneur ou microVM ?
• Le noyau invité est-il partagé avec l’hôte ?

Réseau et sortie

• La sortie est-elle par défaut ouverte ou par défaut refusée ?
• La politique de sortie peut-elle être configurée par locataire ou par session ?
• Le point de terminaison de métadonnées cloud (169.254.169.254) est-il bloqué ?
• Comment le DNS est-il géré à l’intérieur du bac à sable ?

Installations de paquets

• Les installations de paquets sont-elles autorisées par défaut ?
• Les installations peuvent-elles être limitées à des registres approuvés ?
• Les événements d’installation sont-ils journalisés avec la source et le hachage ?

Secrets

• Comment les informations d’identification sont-elles injectées dans le bac à sable ?
• Les informations d’identification peuvent-elles être limitées à l’outil ou à la tâche spécifique qui en a besoin ?
• Les secrets sont-ils masqués dans les journaux et les sorties visibles par le modèle ?

Limites de ressources

• Des limites de CPU, mémoire, disque et délai d’attente sont-elles appliquées ?
• Que se passe-t-il lorsqu’une limite est atteinte — plafonnement, kill ou alerte ?

Journaux d’audit

• Les journaux sont-ils générés au niveau du noyau/de l’hyperviseur ou à l’intérieur du processus du bac à sable ?
• Quelles catégories d’événements sont journalisées par défaut ?
• Les journaux peuvent-ils être exportés vers un SIEM externe ou un système d’agrégation de journaux ?
• Quelle est la politique de conservation des journaux ?

Location

• Les charges de travail de différents locataires sont-elles isolées les unes des autres ?
• Existe-t-il des caches, images ou montages partagés qui créent des canaux entre locataires ?

Où se situe Novita Agent Sandbox

Novita Agent Sandbox est conçu pour les charges de travail d’agents qui nécessitent des environnements d’exécution isolés pour le code, les fichiers, les processus et les sessions de plus longue durée. Il cible les équipes qui construisent des agents de codage, des pipelines d’évaluation, des agents d’analyse de données et des flux de travail d’agents basés sur navigateur.

Le bac à sable prend en charge les contrôles du cycle de vie des sessions, notamment la pause, la reprise et la pause automatique pour les sessions inactives. Il fournit des métriques de ressources et des journaux d’exécution au niveau de la session accessibles via l’API. Pour les équipes utilisant déjà les API de modèle Novita, il peut servir de couche d’exécution dans une architecture d’agent où le modèle planifie et appelle des outils, et le bac à sable gère l’exécution runtime dans un environnement isolé.

Lors de l’évaluation de Novita Agent Sandbox pour des cas d’utilisation sensibles à la sécurité, vérifiez le modèle d’isolation actuel, les valeurs par défaut de la politique de sortie, la couverture des journaux et la gestion des secrets dans la documentation produit avant de prendre des décisions d’architecture. Les exigences de sécurité varient considérablement selon la charge de travail — ce qui est approprié pour un pipeline d’évaluation interne peut ne pas être suffisant pour un produit multi-locataire traitant du code fourni par l’utilisateur.

Comme pour tout bac à sable, la posture de sécurité dépend à la fois des valeurs par défaut de la plateforme et de vos contrôles au niveau applicatif : comment les informations d’identification sont limitées, ce que l’agent est autorisé à demander, quels appels d’outils nécessitent une approbation humaine, et comment les journaux d’audit sont surveillés.

Limitations et ce qu’aucun bac à sable n’élimine

Aucun bac à sable n’élimine tous les risques. Comprendre ce qui reste en dehors de la frontière est aussi important que comprendre ce que la frontière fournit.

Décisions de confiance au niveau applicatif : Le bac à sable contrôle l’exécution runtime. Il ne décide pas ce que l’agent est autorisé à demander. Si votre application permet à un agent de demander une information d’identification, d’exécuter des commandes shell arbitraires ou d’appeler n’importe quelle API, le bac à sable réduit le rayon d’explosion mais n’empêche pas ces actions.

Injection par invite : Un agent qui traite du contenu non fiable — pages Web, fichiers téléchargés par l’utilisateur, réponses d’API externes — peut être manipulé via ce contenu pour entreprendre des actions qu’il ne devrait pas. C’est un problème de conception applicative, pas un problème de bac à sable. Le bac à sable peut limiter où ces actions aboutissent, mais la logique de décision réside dans votre application.

Vulnérabilités zero-day : Tous les modèles d’isolation ont des vulnérabilités connues et inconnues. L’isolation par microVM offre la frontière la plus solide dans l’utilisation actuelle en production, mais des vulnérabilités VMM existent. La défense en profondeur — combinant plusieurs contrôles plutôt que de se fier à une seule frontière — est une posture plus robuste que n’importe quel modèle d’isolation unique.

Ingénierie sociale via la sortie du modèle : Un agent peut produire une sortie qui persuade un opérateur humain d’entreprendre une action dangereuse. Les bacs à sable n’auditent pas les décisions humaines.

Risque de conformité et réglementaire : Les contrôles d’isolation traitent du risque technique. Les exigences réglementaires (RGPD, HIPAA, SOC 2, ISO 27001) traitent du traitement des données, de la conservation, de la documentation et des exigences d’audit qui s’étendent au-delà de ce qu’un bac à sable fournit au niveau de l’infrastructure.

La sécurité dans un bac à sable d’exécution de code est mieux envisagée comme un ensemble de contrôles à évaluer et configurer, et non comme une propriété que l’on acquiert en choisissant un produit. Les questions d’évaluation ci-dessus s’appliquent à toute décision concernant un bac à sable — y compris votre propre infrastructure si vous construisez plutôt que d’acheter.

FAQ

Quelle est la sécurité d’un environnement d’exécution de code IA en bac à sable par rapport à l’exécution de code sur un serveur ?

Un bac à sable bien configuré réduit considérablement le rayon d’explosion de l’exécution de code non fiable par rapport à son exécution directe sur un serveur. Il limite l’accès au système de fichiers, la portée du processus et l’accès réseau. Cependant, la différence dépend de la configuration. Un conteneur avec sortie ouverte et injection large de variables d’environnement peut être moins sûr qu’un serveur durci avec des contrôles réseau. Le modèle d’isolation est un point de départ, pas une garantie.

L’isolation par microVM signifie-t-elle qu’un bac à sable est totalement sécurisé ?

Non. L’isolation par microVM (Firecracker, basé sur KVM) fournit une frontière hôte solide que les conteneurs à noyau partagé n’ont pas. Mais elle ne contrôle pas la sortie, les secrets, les installations de paquets ou la couverture d’audit. Une microVM avec sortie ouverte et aucune collecte de journaux n’est pas « totalement sécurisée » même si la couche d’isolation est solide.

Le code généré par IA peut-il s’échapper d’un bac à sable ?

Cela dépend du modèle d’isolation et de la configuration. Les évasions de conteneurs nécessitent d’exploiter le noyau ou une mauvaise configuration ; les évasions de microVM nécessitent d’exploiter le VMM. Les deux sont possibles mais rares. Les risques plus pratiques sont l’exfiltration de données via des chemins réseau autorisés, la lecture de secrets depuis l’environnement ou l’installation de paquets malveillants via des gestionnaires de paquets non restreints.

Quel est le plus grand risque de sécurité dans la plupart des bacs à sable de code IA ?

La sortie sortante ouverte est le risque le plus souvent insuffisamment traité. De nombreux bacs à sable autorisent un accès Internet sortant sans restriction par défaut car c’est pratique pour les agents qui doivent installer des paquets et appeler des API. Cela crée des chemins pour l’exfiltration de données, le vol d’informations d’identification via les points de terminaison de métadonnées cloud et la communication de commande et de contrôle qui existent indépendamment de la force de la frontière d’isolation.

Dois-je utiliser un bac à sable géré ou construire le mien ?

Les bacs à sable gérés gèrent la complexité opérationnelle du cycle de vie des microVM ou conteneurs, de la capacité de l’hôte et de la gestion des images. Construire le vôtre vous donne plus de contrôle sur l’ensemble de la pile de politiques. Dans les deux cas, les mêmes questions d’évaluation s’appliquent : politique de sortie, gestion des secrets, couverture des journaux, limites de ressources et export d’audit. La décision construire vs. acheter est distincte de l’évaluation de sécurité.

Qu’est-ce qui rend la sécurité des bacs à sable d’agents différente de la sécurité traditionnelle d’exécution de code ?

La sécurité traditionnelle d’exécution de code suppose que vous savez approximativement quel code va s’exécuter. Les agents IA changent cela : une seule invite peut amener une session à installer des paquets, écrire des fichiers, exécuter des commandes shell, appeler des API externes et engendrer des sous-processus sans approbation explicite du développeur pour chaque étape. Cela rend la couverture d’audit plus importante (vous ne pouvez pas anticiper chaque action), les contrôles de sortie plus importants (l’agent peut atteindre des destinations auxquelles vous ne vous attendiez pas) et la limitation des secrets plus importante (l’agent a accès à tout dans son environnement).

Quelles sont les meilleures pratiques pour l’isolation des agents IA en production ?

Une liste de contrôle d’isolation pratique pour les déploiements d’agents en production : utilisez une isolation de classe microVM (Firecracker ou équivalent) plutôt que des conteneurs seuls pour le code non fiable ou fourni par l’utilisateur ; attribuez un environnement isolé par tâche ou par session utilisateur — ne partagez jamais un bac à sable entre des charges de travail non liées ; sortie par défaut refusée avec une liste d’autorisation explicite pour les destinations requises ; injectez uniquement les informations d’identification dont la tâche actuelle a besoin en utilisant des jetons à courte durée de vie ; collectez les journaux d’audit au niveau du noyau ou de l’hyperviseur, pas à l’intérieur du processus du bac à sable ; appliquez des limites de CPU, mémoire, disque et temps mural par session ; et nettoyez les sessions de manière agressive — détruisez les bacs à sable éphémères dès que la tâche est terminée. La défense en profondeur à travers tous ces contrôles offre une sécurité significativement meilleure que n’importe quelle frontière unique forte.

Que doivent évaluer les équipes de sécurité lors de l’examen des bacs à sable d’agents IA pour un déploiement en entreprise ?

L’examen de sécurité en entreprise doit couvrir six domaines : (1) Isolation — microVM ou conteneur ? Chaque session est-elle complètement isolée au niveau du système de fichiers, des processus et du réseau ? (2) Sortie — par défaut ouverte ou par défaut refusée ? La politique de sortie est-elle configurable par le client ? Le point de terminaison de métadonnées cloud (169.254.169.254) est-il bloqué ? (3) Secrets — comment les informations d’identification sont-elles injectées ? Sont-elles limitées par tâche avec des jetons à courte durée de vie ? Sont-elles nettoyées lors du démontage de la session ? (4) Audit — les journaux sont-ils générés en dessous du processus du bac à sable (niveau noyau/hyperviseur) ? Les journaux peuvent-ils être exportés vers un SIEM ? (5) Résidence des données — le BYOC ou le déploiement VPC est-il disponible pour que les charges de travail restent dans votre compte cloud ? (6) Posture de conformité — quelles certifications le fournisseur détient-il, et quel est son modèle de responsabilité partagée ? Pour les équipes ayant des exigences réglementaires, effectuez cet examen avant le déploiement en production, pas après.

Comment fonctionne l’isolation du noyau dans un bac à sable d’agent IA ?

L’isolation du noyau signifie que le code de l’agent s’exécute dans un environnement avec son propre noyau, séparé du noyau hôte par une frontière de virtualisation matérielle (KVM). Dans les bacs à sable basés sur Firecracker, chaque session démarre un noyau invité minimal à l’intérieur d’une microVM. Les processus à l’intérieur du bac à sable interagissent avec le noyau invité ; le noyau hôte n’est ni visible ni accessible depuis l’intérieur. Une vulnérabilité exploitée dans le noyau invité ne se propage pas automatiquement à l’hôte car la frontière KVM se situe entre eux. C’est l’avantage de sécurité clé par rapport à l’isolation par conteneur, où tous les conteneurs partagent le noyau hôte et une exploitation du noyau les affecte tous simultanément.

Articles recommandés

• Firecracker pour les bacs à sable d’agents IA : avantages, limites et questions d’évaluation
• Journaux d’audit pour les bacs à sable d’agents IA : ce dont les équipes de sécurité ont besoin
• Bac à sable pour code généré par IA : exigences pour les applications de production