Bac à sable de noyau sans démon pour agents de codage IA locaux
vetto, créé par Shleder, est un bac à sable sans démon qui confine les agents de codage IA et empêche l'exécution de code non intentionnelle sur une machine de développeur. L'outil impose une isolation au niveau du noyau autour de l'activité des agents et expose des contrôles pilotés par des politiques pour l'accès au système de fichiers, au réseau et aux ressources. Il cible les développeurs de logiciels, les chercheurs en sécurité et les organisations exécutant des agents de codage autonomes qui ont besoin d'une couche de sécurité locale pour réduire les risques d'injection de prompt et d'exécution incontrôlée.
Pour quelles tâches pouvez-vous réellement l'utiliser ?
L'outil est conçu pour contenir des flux de travail agentiques qui interagissent avec l'hôte, en particulier des agents en ligne de commande qui suivent le Modèle de Contexte de Protocole (MCP) ou des interfaces similaires. Les cas d'utilisation incluent l'exécution d'agents de génération de code, d'outils de refactorisation automatisés et d'assistants scriptés tout en empêchant les écritures non intentionnelles, l'exfiltration de secrets ou les appels réseau non sollicités. Vetto s'inscrit dans la phase de développement où le code généré s'exécute sur la machine locale et nécessite une frontière de sécurité.
Quelle est la fiabilité des protections au niveau du noyau en pratique ?
Vetto applique des politiques avec des primitives du système d'exploitation : sur Linux, il utilise Landlock, des espaces de noms et seccomp-BPF ; sur macOS, il s'intègre avec Seatbelt. La conception met l'accent sur un modèle d'application des règles qui échoue de manière sécurisée et un faible coût d'exécution en appliquant des restrictions au niveau du noyau plutôt qu'en s'appuyant sur un démon de conteneur en cours d'exécution. Le support de Windows est décrit comme expérimental et correspond à un mécanisme de style AppContainer.
Quelles contrôles de politique et entrées accepte-t-il ?
La configuration des politiques est basée sur des fichiers et déclarative, utilisant TOML pour des règles granulaires. Le langage de politique couvre les racines du système de fichiers, deny-paths pour des données sensibles, des listes blanches de réseau spécifiques au domaine ou une désactivation complète du réseau, et des contraintes d'exécution telles que des délais et des limites de processus. Ces entrées permettent aux équipes de contraindre les E/S, de bloquer les emplacements secrets et de limiter les privilèges d'exécution d'un agent avant que l'agent ne s'exécute.
Est-il pratique de l'ajouter à un flux de travail de développeur ?
L'outil s'installe via des canaux de développeurs standard, par exemple un package npm global ou un tap Homebrew sur macOS, et ne nécessite pas Docker ou des privilèges root pour fonctionner. Cela réduit les changements d'infrastructure pour le développement local. L'adoption nécessite d'écrire et de tester des politiques TOML et une certaine familiarité avec les primitives de bac à sable du système d'exploitation, ce qui le rend le plus adapté aux équipes à l'aise avec les outils en ligne de commande et la rédaction de politiques.
Qui devrait l'adopter, et quoi surveiller ?
L'outil est une option pragmatique pour les développeurs et les organisations utilisant des outils agentiques tels que Claude Code, Cursor et Aider, et il est reconnu au sein de la communauté des développeurs IA pour traiter le risque agent. Conseil pratique : testez d'abord les fichiers de politique sur des projets non sensibles et gardez la révision manuelle du code pour les exécutions à haut risque ou en production afin de détecter des comportements que le bac à sable ne couvre pas.
