《Openclaw流行下Agent 沙箱架构：从技术选择到普通人能看懂的安全故事》 Deux modes Imaginez que vous devez engager un agent de sécurité pour surveiller votre maison. Vous avez deux choix : Option 1 : L'agent de sécurité vit chez vous, mais garde sa boîte à outils verrouillée dans un coffre-fort. L'agent peut se déplacer et voir votre maison, mais il n'a pas la clé. Option 2 : L'agent de sécurité vit dans un kiosque à l'extérieur, sans rien chez vous. S'il veut prendre quoi que ce soit, il doit demander à votre majordome. La société Browser Use (qui gère des millions d'agents Web) a choisi l'option deux. Leur histoire est en fait liée à chaque personne utilisant l'IA.

Deux, Comment utiliser le navigateur Au départ, ils utilisaient la solution un : l'Agent s'exécute sur son propre serveur, le code est exécuté dans un bac à sable isolé. Ça a l'air assez sûr, non ? Mais il y a un problème : l'Agent lui-même est toujours sur le serveur, il peut voir les variables d'environnement, les clés API, les identifiants de base de données. Que se passe-t-il si l'Agent décide de "voler quelque chose" ?

Trois, Donc, ils ont réécrit toute l'architecture : • Agent complètement isolé : chaque Agent fonctionne dans sa propre micro-VM Unikraft, le démarrage prend moins d'une seconde • Plan de contrôle comme gestionnaire : toutes les communications externes (appel LLM, stockage de fichiers, facturation) passent par le plan de contrôle, qui détient tous les certificats • Sandbox totalement ignorant : l'Agent ne reçoit que trois variables d'environnement - le token de session, l'URL du plan de contrôle, l'ID de session. Pas de clés AWS, pas de certificats de base de données • Éliminabilité : l'Agent est mort ? Redémarrez-en un. L'état est perdu ? Le plan de contrôle a le contexte complet. Il n'a rien de précieux à voler et aucun état à conserver.

Quatre, Détails techniques : micro-VM Unikraft pour la production (scale-to-zero, suspendu lorsqu'inactif), conteneurs Docker pour le développement. La même image partout. Du point de vue d'une personne ordinaire : quel rapport avec moi ? Vous ne savez peut-être pas ce que sont les "micro-VM" ou les "URLs pré-signées", mais lorsque vous utilisez l'IA, vous interagissez déjà avec ce type d'architecture.

Cinq, Sentiment de sécurité : lorsque vous utilisez un service AI pour écrire du code ou rechercher des informations, vos requêtes s'exécutent en réalité dans des VM isolées. Si l'architecture est mal conçue (option un), théoriquement cet agent AI pourrait voir tous les secrets du fournisseur de services : mots de passe de base de données, clés API, données d'autres utilisateurs.

Six, Coût et vitesse : La solution deux a un coût - chaque opération nécessite un saut réseau supplémentaire. Mais par rapport au temps de réponse du LLM, ce délai est presque négligeable. Plus important encore, lorsque l'Agent est inactif, la VM est suspendue, le coût est proche de zéro. Confidentialité des données : Comment tes fichiers sont-ils stockés ? Le bac à sable demande une URL pré-signée au plan de contrôle, puis télécharge directement sur S3. Pendant tout le processus, le bac à sable n'a jamais vu la clé AWS. Tes données ne seront pas divulguées à l'Agent.

Sept, Mes réflexions : Local vs Cloud Mon setup actuel (OpenClaw + LM Studio + x-reader) est typiquement "version autonome" : • Le modèle fonctionne localement (Qwen3.5-35B sur RTX 3090) • L'Agent n'est pas isolé (car il est sur votre ordinateur) • Données entièrement locales Cela contraste avec la solution d'utilisation du navigateur : Dimensions Agent local unique (nous) Agent isolé dans le cloud (utilisation du navigateur) Confidentialité Les données ne sortent pas localement Les données sont dans le cloud, mais l'Agent n'a pas accès à la clé Sécurité Dépend de la protection locale Agent complètement isolé, rien à voler Coût Investissement matériel unique Paiement à l'utilisation (scale-to-zero) Évolutivité Limitée par le matériel local Évolutivité illimitée, plusieurs Agents en parallèle Latence Zéro latence réseau Un saut réseau supplémentaire (mais négligeable)

Huit, Mon jugement : l'avenir sera un mode hybride. • Tâches simples exécutées localement : écrire un script, rechercher des informations, organiser des fichiers, tout cela peut être fait localement, bonne confidentialité, rapidité. • Tâches complexes dans le cloud : nécessitant plusieurs agents en parallèle, traitant de grandes quantités de données, fonctionnant longtemps, c'est à ce moment-là qu'une architecture comme Browser Use est plus appropriée.

Neuf, À l'origine, il n'y a rien, d'où viendrait la poussière ? Votre Agent ne devrait avoir rien de précieux à voler, ni d'état à conserver. En d'autres termes : • Rien de précieux à voler : l'Agent ne connaît aucun secret. Il utilise des tokens pour interroger le LLM ? Ceux-ci sont fournis par le plan de contrôle, à utiliser et à jeter. Il doit stocker des fichiers ? L'URL pré-signée est temporaire, elle expire et devient invalide. • Pas besoin de conserver : l'Agent est mort ? Redémarrez-en un nouveau. Le contexte qu'il se rappelle ? La base de données du plan de contrôle a un enregistrement complet. C'est en fait l'application de l'architecture de confiance zéro à l'ère de l'IA : ne faites confiance à aucun composant, même s'il s'agit de votre propre Agent.

Dix, Comment un novice en IA devrait-il apprendre ? 1. Choix des outils IA : lorsque vous utilisez des services IA dans le cloud, demandez-vous : si cet Agent perd le contrôle, que peut-il obtenir ? Une bonne architecture devrait le rendre "totalement ignorant". 2. Sensibilisation à la vie privée : exécutez des tâches simples avec une IA locale (OpenClaw, LM Studio), sans envoyer de données sensibles dans le cloud. Pour des tâches complexes, utilisez des solutions d'isolement dans le cloud, mais sachez que les données quitteront votre local. 3. Flux de travail futur : une personne + plusieurs Agents en collaboration est la tendance (Karpathy parle de Tab→Agent→Agents parallèles→Équipes d'Agents). Mais chaque Agent doit être isolé, ne doit pas "vivre chez vous".

Onze, Le compromis entre sécurité et efficacité La solution Browser Use n'est pas parfaite : trois services supplémentaires à déployer, et chaque opération nécessite un saut réseau de plus. Mais par rapport au risque que "l'Agent vole toutes les clés", ces coûts en valent la peine. Pour nous, qui avons une configuration AI locale, la leçon est : • Scénarios simples : continuer à utiliser la solution locale (OpenClaw + LM Studio), bonne confidentialité, faible coût • Scénarios complexes : à l'avenir, il pourrait être nécessaire de se connecter à des services d'Agent isolés dans le cloud, pour que des professionnels fassent le travail de professionnels. La sécurité de l'AI n'est pas une science occulte, c'est une question de conception architecturale. Une bonne conception fait en sorte que l'Agent "n'ait rien" — pas de secrets à voler, pas d'état sur lequel se retourner.

Douze, Voilà à quoi ressemblera probablement l'infrastructure AI du futur : les agents sont jetables, le plan de contrôle est fiable, et les données des utilisateurs sont protégées. Quant à nous ? Continuons à faire fonctionner des agents locaux avec OpenClaw, et le jour où nous aurons besoin de faire fonctionner des dizaines ou des centaines en parallèle, nous envisagerons d'adopter une architecture comme Browser Use. Demain sera meilleur.