Guide du bac à sable pour agents IA
Comment faire tourner un agent IA sur votre Mac sans lui donner votre Mac
La réponse courte : donnez à l’agent une machine virtuelle, pas votre compte utilisateur. Prenez un instantané avant son démarrage, clonez une copie jetable pour tout ce en quoi vous n’avez pas confiance, et coupez le réseau quand la tâche n’en a pas besoin. Ce guide compare les options d’isolation sur Apple Silicon et déroule le flux de travail avec le serveur MCP intégré de Kyvenza.
Ce que protège réellement chaque type d’isolation
Votre propre compte utilisateur : aucune isolation
Un agent qui exécute des commandes shell sous votre identité a tout ce que vous avez : le Keychain, les clés SSH, les sessions de navigateur, les identifiants cloud et chaque fichier que vous pouvez lire. Une mauvaise commande ou une injection de prompt a la même portée que vous.
Un second utilisateur macOS : fichiers séparés, système partagé
Un compte distinct garde votre dossier personnel et votre Keychain hors de portée, mais c’est le même système d’exploitation et le même noyau. Cela aide contre les accidents, moins contre un agent à qui l’on donne des droits d’administrateur.
Un conteneur : bien pour les outils Linux, avec des réserves
Sur un Mac, les conteneurs tournent dans une machine virtuelle Linux dont ils partagent le noyau. Ils conviennent aux outils Linux sans interface, mais un dossier de l’hôte monté ou le socket Docker offre à l’agent un moyen de ressortir, et ils ne peuvent pas exécuter d’applications macOS ou Windows.
Une machine virtuelle : une frontière imposée par l’hyperviseur
L’invité est un système d’exploitation distinct. Il ne voit pas les fichiers de votre hôte tant que vous ne les partagez pas, et un instantané permet de ramener toute la machine en arrière après une mauvaise action. C’est le meilleur compromis pour des agents de code sur un seul Mac.
Une machine dédiée : la plus solide, et un second appareil
Un Mac mini de rechange apporte une séparation physique. Il coûte aussi de l’argent, demande une mise en place et ajoute un appareil à maintenir. Une VM offre l’essentiel de l’isolation sur le Mac que vous possédez déjà.
Une VM Kyvenza ou un conteneur Docker pour le travail d’un agent
Les conteneurs conviennent à beaucoup de tâches d’agent et se créent vite. Les différences qui comptent apparaissent quand l’agent a besoin d’un bureau complet, d’un invité macOS ou Windows, ou d’une frontière plus solide.
| Critère | Kyvenza | Docker container |
|---|---|---|
| Système d’exploitation invité | Linux ARM, macOS ARM ou Windows 11 ARM | Linux uniquement |
| Frontière d’isolation | Un système distinct, imposé par l’hyperviseur | Un noyau Linux partagé dans une seule machine virtuelle Docker |
| Retour arrière après une mauvaise action | Restaurer un instantané ; via MCP, un instantané est pris automatiquement avant qu’un agent démarre une VM | Reconstruire le conteneur et restaurer les volumes éventuels |
| Copie jetable | clone_vm : copie sur écriture, disponible en environ une seconde | Oui, les nouveaux conteneurs démarrent vite |
| Aucun réseau du tout | Réseau isolé ; sous Linux, l’agent invité exécute toujours des commandes et prend des captures d’écran | Oui, avec un réglage sans réseau |
| Voir l’écran | Outil screenshot sur un invité à bureau complet | Terminal uniquement, sauf à ajouter un bureau |
| Meilleur usage | Les agents qui ont besoin d’un vrai bureau ou de macOS, et les installateurs non fiables | Les outils Linux sans interface et la CI |
Ce que Kyvenza prend en charge aujourd’hui
Une liste courte et honnête — pour savoir à quoi vous attendre avant de télécharger.
Pris en charge aujourd’hui
- Mac Apple Silicon (M1, M2, M3, M4, M5)
- Windows 11 sur ARM (fournissez votre propre image Microsoft et votre propre licence)
- Ubuntu ARM (versions LTS)
- Debian ARM
- Fedora ARM
- macOS 14 Sonoma ou ultérieur comme hôte
- Backend natif du framework de virtualisation d’Apple (Virtualization framework)
Pas encore pris en charge
- Accélération GPU / 3D dans les invités Windows
- Entrée microphone et passthrough USB dans les invités Windows
- Systèmes d’exploitation invités x86 / Intel
- Virtualisation imbriquée
- Passthrough GPU
Nous listons aussi ce que nous ne pouvons pas livrer aujourd’hui, pour que vous puissiez planifier en conséquence.
Comment ça marche
Préparez une VM de base propre
Créez un invité Linux ou macOS dans Kyvenza, installez les outils dont l’agent aura besoin, puis éteignez-le. C’est votre base saine connue. N’y mettez aucun identifiant personnel.
Activez le serveur MCP et connectez votre agent
Dans Réglages, puis Automation, activez le serveur et copiez le point d’accès, qui porte déjà le jeton de votre Mac. Dans Claude Code, la connexion tient en une commande : claude mcp add --transport http kyvenza http://127.0.0.1:59800/mcp/YOUR-TOKEN. Tout client MCP qui accepte une URL fonctionne.
Cloner, exécuter, lire le résultat, supprimer
Avec les outils destructeurs activés, l’agent clone la base dans un bac à sable, y exécute l’installateur ou le script, lit la sortie et supprime le clone. Le clone est en copie sur écriture, et les suppressions vont à la Corbeille. Pour du code qui ne doit pas communiquer vers l’extérieur, réglez d’abord la VM sur le réseau isolé.
Questions fréquentes
Pas sur votre compte principal. Un agent qui peut exécuter des commandes shell sous votre identité peut lire votre Keychain, vos clés SSH et vos sessions de navigateur : une mauvaise commande ou une injection de prompt a donc la même portée que vous. Faites-le tourner dans une machine virtuelle qui ne contient aucun de vos identifiants, et prenez un instantané avant son démarrage.
Donnez à l’agent sa propre machine
Téléchargez Kyvenza, activez le serveur MCP et laissez votre agent travailler dans une VM que vous pouvez photographier par instantané et jeter. 49 $ une fois après l’essai de 7 jours.
Autres comparaisons