La sécurité du bac à sable (sandbox) d’un agent IA dépend de l’endroit où le code s’exécute et des accès que vous lui accordez. Une microVM fournit à la charge de travail son propre noyau invité, ce qui renforce une des frontières d’isolation. Avant de confier à un agent du code source privé ou un rapport de vulnérabilité non fiable, vous devez encore vérifier, preuves à l’appui, que ses fichiers, ses accès réseau, ses identifiants, ses outils externes et les résultats qu’il renvoie respectent les limites de la tâche.

Commencez par une question concrète avant toute validation : **que peut lire, modifier ou contacter cette exécution, et quels résultats peut-elle amener votre équipe à accepter ?** Consignez la réponse pour la configuration que vous utiliserez réellement. Le schéma d’architecture d’un produit aide à comprendre sa conception ; votre tâche nécessite aussi une politique d’accès et un moyen de vérifier qu’elle est respectée.

## Ce qu’une microVM change

Une microVM sépare le noyau de la charge de travail de celui de l’hôte. La frontière d’exécution diffère donc de celle d’un conteneur partageant le noyau de l’hôte, mais la configuration de l’hôte et les ressources volontairement partagées restent déterminantes. La [présentation des bacs à sable pour agents de Vercel](https://vercel.com/i/agent-sandbox) explique cette séparation ainsi que les restrictions portant sur les fichiers, le réseau et les identifiants.

Dans son article d’architecture du 4 novembre, [Replit décrit son passage aux microVM avec Cloud Hypervisor](https://frontier.replit.com/sandbox-engine-microvms-part-1/), les conteneurs s’exécutant à l’intérieur des systèmes invités. Replit décrit également un moniteur de machines virtuelles non privilégié, un filtrage réseau appliqué hors du système invité pour les bacs à sable soumis à une politique de trafic sortant, et des intermédiaires d’authentification pour les connecteurs gérés. Il s’agit de protections distinctes dans la description de Replit, sans que cela prouve que chaque requête ou chaque secret fourni par l’utilisateur bénéficie de la même protection.

Une [démonstration distincte de PWN Research sur Firecracker](https://pwn.ai/blog/firecracker-escape) montre pourquoi les conditions de lancement doivent accompagner les affirmations de sécurité. Le chercheur a utilisé Firecracker v1.16.1 lancé en tant que root sans jailer, en s’appuyant sur une primitive d’accès à la mémoire de l’hôte obtenue au préalable. Cette démonstration ne montre pas une évasion depuis un déploiement de production durci, ni depuis l’environnement Cloud Hypervisor de Replit. Les [recommandations de Firecracker pour les hôtes de production](https://github.com/firecracker-microvm/firecracker/blob/main/docs/prod-host-setup.md) préconisent une exécution non privilégiée et le confinement ; elles ne permettent pas d’établir qu’un jailer bloquerait nécessairement l’accès mémoire sous-jacent.

Si vous évaluez une offre, demandez quel environnement d’exécution, quels privilèges et quelles intégrations avec l’hôte votre charge de travail utilise réellement. Conservez ces réponses avec la version et la configuration que vous validez.

## Recensez les passerelles que vous ouvrez volontairement

Un agent exécuté dans un bac à sable peut causer des dommages par les accès que vous lui accordez intentionnellement. Examinez ces passerelles même lorsque la frontière d’exécution fonctionne comme prévu.

Le [modèle de sécurité des bacs à sable locaux de Docker](https://docs.docker.com/ai/sandboxes/security/) en explicite plusieurs : montages directs de l’espace de travail, transmission des identifiants par un proxy, accès à la signature SSH et serveurs MCP externes. Docker avertit que les modifications de l’espace de travail peuvent changer les chemins d’exécution utilisés en développement et que les serveurs MCP locaux utilisant stdio s’exécutent sur l’hôte. Ce sont des voies d’intégration à évaluer dans cette configuration locale, pas la preuve d’une évasion de machine virtuelle.

Examinez quatre questions :

- **Fichiers :** l’agent voit-il un instantané jetable du code source, ou peut-il modifier la copie de travail que vous compilerez et exécuterez ensuite ? Incluez les hooks, la configuration de compilation et les instructions dans la revue des modifications renvoyées.
- **Réseau :** quelles destinations, quels chemins et quelles opérations sont autorisés ? Un point d’accès d’inférence approuvé reçoit les données que vous lui envoyez. Une liste d’autorisation ne suffit pas, à elle seule, à rendre cette divulgation acceptable.
- **Identifiants :** que peut faire l’agent avec les droits disponibles ? Un intermédiaire peut masquer la clé API brute tout en permettant des appels authentifiés aux effets importants. L’accès à un socket de signature mérite lui aussi une décision explicite.
- **Outils :** où chaque outil s’exécute-t-il, et sous quelle identité ? Un processus sur l’hôte ou une API distante exige sa propre frontière d’autorisation.

Incluez l’état persistant dans cet inventaire. Les caches partagés, les instantanés enregistrés et les instructions réutilisables de l’agent peuvent propager des modifications aux tâches suivantes. Déterminez qui est responsable de chaque artefact conservé et comment recréer une exécution propre avant de supposer qu’une nouvelle session repart d’un état sain.

## Exigez des preuves pour chaque frontière

Validez une configuration précise au moyen de vérifications reproductibles. Le tableau ci-dessous propose un dossier de validation, synthétisé à partir des frontières de sécurité décrites plus haut. Il ne rend pas compte de tests que nous aurions effectués sur ces fournisseurs.

Utilisez des secrets factices, des environnements jetables et des points d’accès que vous contrôlez. Vous n’avez besoin ni d’un exploit actif ni d’exfiltrer des données réelles pour vérifier que les accès interdits par la politique sont bien refusés.

| Frontière | Preuves à conserver | Si la vérification échoue |
|---|---|---|
| Exécution | Environnement d’exécution et version, unité d’isolation, privilèges sur l’hôte et intégrations avec celui-ci. Confirmez l’absence de privilèges inutiles ou d’accès au socket Docker de l’hôte. | Suspendez la validation pour des données réelles. Supprimez la passerelle ou remplacez l’environnement, puis refaites le test. |
| Fichiers | Montages et permissions effectifs ; refus d’accès à un fichier factice sur l’hôte ; copie de travail distincte pour les résultats. | Recréez l’environnement avec un partage plus restreint. Examinez les modifications de l’état partagé avant toute réutilisation. |
| Réseau | Politique du pare-feu ou du proxy externe ; requête bloquée vers une destination contrôlée ; requêtes d’inférence et MCP autorisées réussies. Recommencez après un redémarrage. | Arrêtez l’exécution. Rétablissez le filtrage hors de la charge de travail avant de charger le code source. |
| Identifiants | Cible et expiration du jeton ; politique de l’intermédiaire par chemin et par action ; refus d’une opération non autorisée avec une identité de test. Incluez l’accès à la signature. | Réduisez ou retirez les droits. Invalidez les identifiants exposés et examinez leur utilisation réelle. |
| Outils externes | Inventaire des outils, lieu d’exécution, identité utilisée et opérations autorisées ; rejet d’une requête visant une autre ressource. | Désactivez l’outil et corrigez l’autorisation côté serveur. |
| Persistance | Inventaire des instantanés, caches et instructions partagées ; vérification d’une exécution propre au moyen d’un marqueur inoffensif. | Écartez l’état suspect, restaurez des données d’entrée fiables et retestez les tâches concernées. |
| Résultats | Champs acceptés et identité de la ressource ; rejet des identifiants falsifiés ; refus des champs supplémentaires non autorisés ou prévention de leur stockage ; comportement lors d’envois répétés ; relecteur désigné. | Mettez les résultats en quarantaine et corrigez la frontière de réception avant de réessayer. |

Joignez à la validation la révision de la politique et les résultats des vérifications. La mention « réseau restreint » est moins utile qu’un relevé précisant quelle requête a été bloquée, quelle requête autorisée a réussi et quelle configuration a produit ces deux résultats.

La réussite des vérifications démontre le fonctionnement des protections testées à cette révision. Elle ne prouve ni que toutes les injections de prompt échouent, ni que chaque opération autorisée est sûre, ni qu’aucune vulnérabilité d’évasion n’existe. Répétez les vérifications concernées lorsque vous modifiez un montage, un outil, une politique de jetons, l’environnement d’exécution ou une image persistante.

## Testez un scénario de triage de rapport

Prenons une équipe **hypothétique** qui prépare un agent à lire un dépôt privé et un rapport de vulnérabilité soumis. L’exercice de validation doit suivre cette tâche de bout en bout, y compris le résultat renvoyé.

1. **Préparez des données d’entrée jetables.** Utilisez un instantané du code source et un exemple de rapport contenant des jetons factices. Gardez les identifiants de production et les vrais rapports hors de l’environnement.
2. **Ajoutez un témoin d’injection inoffensif.** Insérez dans le rapport d’exemple des instructions demandant à l’agent de contacter une destination contrôlée par l’équipe mais interdite par la politique. Consignez le refus attendu avant de lancer l’exercice.
3. **Vérifiez à la fois le refus et le travail utile.** Laissez accessibles les voies légitimes d’inférence et de transmission du résultat du rapport. Une exécution sans aucun accès réseau ne démontre pas que le flux de travail prévu fonctionne.
4. **Examinez ce qui revient.** Conservez le journal de la requête refusée, la configuration effective de l’environnement d’exécution et les références du rapport, du commit et du pipeline. Vérifiez que le service destinataire rejette un résultat visant un autre rapport et refuse les champs supplémentaires non autorisés ou empêche leur stockage.
5. **Définissez explicitement la décision en cas d’échec.** Si la requête interdite aboutit, arrêtez avant de connecter de vrais rapports. Corrigez la politique et répétez l’exercice. Si un service autorisé reçoit des données qu’il ne devrait pas recevoir, revoyez les données d’entrée et restreignez, selon le cas, les chemins ou les actions autorisés pour ce service.

Pour démontrer que la politique bloque le chemin testé, le journal doit montrer à la fois la tentative de requête du témoin et son refus par la politique. Si l’agent ignore l’instruction et ne tente aucune requête, cela ne démontre pas le fonctionnement du filtrage réseau. Ce test ne permet pas d’établir que toutes les instructions malveillantes seront contenues. De même, un résultat bien formé peut contenir une conclusion erronée : la validation technique doit donc laisser place au jugement humain.

Si vous enquêtez déjà sur un accès suspecté, la tâche a changé. Utilisez un [processus de triage des tentatives d’accès d’agents](/blog/ai-agent-probes-security-triage) pour préserver les preuves et évaluer ce qui s’est passé avant de revenir aux vérifications préalables à la validation.

## Gardez le résultat consultatif et limité à son périmètre

L’application destinataire a besoin de sa propre frontière de sécurité, même lorsque l’exécution est bien isolée. Elle doit savoir à quelle ressource une exécution se rattache, ce qu’elle peut écrire et qui examine ses conclusions.

Le [triage de Kit avec accès au code](/docs/code-aware-ai-triage) illustre cette séparation. Vous exploitez l’environnement d’exécution et ses restrictions de trafic sortant ; Kit délimite les échanges liés au rapport et reçoit des résultats à titre consultatif. Kit déclenche le pipeline que vous avez configuré. Il ne crée pas de microVM et ne configure ni ne vérifie en continu votre pare-feu.

Le [guide d’isolement réseau de l’agent de triage](/docs/triage-agent-airgap) décrit un exécuteur GitLab autogéré, exploité par le client, avec un blocage de tout trafic sortant imposé par l’environnement et un proxy qui valide les jetons et n’autorise que les chemins d’inférence et MCP de Kit. Considérez-le comme un guide de mise en œuvre à configurer et à tester. Un pipeline CI externe ne devient pas isolé du réseau simplement parce qu’il s’exécute hors de Kit, et les variables masquées restent accessibles au code qui les reçoit à l’exécution.

Côté Kit, un jeton signé identifie une exécution de triage ainsi que son rapport et l’espace client auquel il appartient. Ce jeton expire au bout d’une heure et permet la lecture du rapport, l’ajout de preuves et l’envoi des résultats. Les champs de résultat acceptés sont limités, et la finalisation bloque toute écriture ultérieure. Cette protection en écriture ne signifie pas que la lecture du rapport cesse nécessairement dès la finalisation ; l’expiration du jeton constitue une limite distincte.

L’évaluation renvoyée reste consultative et soumise à une revue humaine. Utilisez le [guide de configuration de l’agent de triage](/docs/set-up-triage-agent) pour mettre en place le flux de travail, puis conservez un dossier de validation pour l’environnement que vous fournissez. Vous devez obtenir une exécution aux limites définies, des preuves conservées, une condition d’arrêt claire et un relecteur qui décide de la suite.