Architecture de sécurité
La sécurité n'a pas été ajoutée après coup.
Quand on construit un outil qui pilote des navigateurs pour le compte des utilisateurs, il y a deux options : supposer que rien ne se passera mal, ou supposer qu'un problème finira toujours par arriver. Nous avons choisi la deuxième. Chaque choix d'architecture dans Lokbox — sandbox, frontières d'isolation, plafonds de coûts et validation humaine — existe parce que nous avons analysé ce qui pourrait mal tourner sans lui.
Pourquoi cette page existe
En avril 2026, des chercheurs en sécurité ont publié 14 CVE touchant environ 200 000 serveurs MCP — le standard d'outillage des agents IA utilisé par Cursor, Windsurf, Claude Code, Gemini CLI et GitHub Copilot. 9 places de marché MCP sur 11 pouvaient être empoisonnées pour distribuer des outils malveillants. La réponse d'Anthropic a été « expected behavior » — le modèle de menace est fondamental dans la façon dont les agents appellent les outils.
Lokbox est construit autrement. Cette page documente les choix d'architecture concrets qui nous rendent plus sûrs que l'outil d'agent IA moyen — ainsi que les points que nous améliorons encore.
Isolation du navigateur par tâche
Chaque tâche démarre un nouveau Chromium BrowserContext via Playwright. Quand une tâche se termine, son contexte est détruit. Cette conception vise à limiter le transfert d'état de session et de jetons entre les tâches.
D'autres outils partagent une session navigateur longue durée. Lokbox traite chaque tâche comme si elle pouvait être la dernière exécutée dans ce navigateur.
Traitement des jetons OAuth hors de la sandbox de l'agent
Quand Lokbox traite une demande vers un service connecté, le code de service s'exécute dans un isolat V8 via isolated-vm 6.1.2 enveloppé dans un thread enfant worker_threads.
Le jeton OAuth Bearer est maintenu hors de cet isolat par la frontière de traitement des jetons. Il reste dans le processus hôte. Quand la compétence appelle ctx.fetch_with_oauth(...), l'hôte injecte Authorization: Bearer ... à la frontière réseau. La compétence ne voit que le corps de la réponse.
Le traitement des jetons est séparé de sorte que la frontière vise à garder le jeton hors de la sandbox. Cela réduit un vecteur d'exposition important, sans garantir l'absence de toute compromission.
L'IA marque une pause pour les CAPTCHA et la 2FA
CAPTCHA, codes à deux facteurs et murs de connexion ne sont pas contournés par l'IA. Elle appelle un outil intégré pause_for_human qui explique l'action requise dans votre tableau de bord. Vous effectuez vous-même la connexion ou la 2FA dans le navigateur en direct; l'IA ne voit pas ce que vous saisissez.
Vos identifiants et votre 2FA restent chez vous. Vous les saisissez vous-même dans le navigateur en direct; l'IA ne voit pas vos saisies.
Trois niveaux de plafonds de coûts
- Plafond par tâche : limite stricte de $1 par tâche. Empêche les boucles incontrôlées.
- Plafond quotidien par workspace : limite ce qu'un workspace peut consommer en 24 heures. Empêche un seul utilisateur d'utiliser toute la capacité.
- Plafond quotidien global : plafond strict des coûts de toute la flotte par jour UTC. Limite le pire scénario en cas d'incident de sécurité.
Comparaison
Comparaison directe avec les alternatives les plus courantes. Dernière mise à jour le 2026-05-02.
| Lokbox | Browserbase | Computer Use direct | Most MCP servers | |
|---|---|---|---|---|
| Isolation navigateur par tâche | Oui — contexte neuf | Partiel — sessions mutualisées | Non — à votre charge | Non — processus partagé |
| Jetons OAuth isolés du code agent | Oui — injection à la couche réseau | Non — directement dans le code | Non — directement dans le code | Partiel — selon le serveur |
| Protection SSRF sur la navigation agent | Oui — blocage IP privées + vérification DNS | Partiel — certains contrôles | Non — à votre charge | Partiel — selon le serveur |
| Pause pour CAPTCHA / 2FA | Oui — intégré | Non — échec ou contournement | Non — manuel | Non — généralement absent |
| Plafond strict par tâche | Oui — $1 par défaut | Partiel — facturation par session | Non — à votre charge | Non — généralement absent |
| Documentation de l'architecture de sécurité | Décrite sur cette page | Partiel — SOC 2 seulement | N/A | Non — auto-déclaré |
Ce que nous ne prétendons pas encore
Nous voulons aussi nommer les limites précisément. État au 2026-05-02 :
- Pas encore de test d'intrusion externe. Prévu pour les mois 2-3 après le lancement. Les résultats seront publiés sur cette page.
- Infrastructure suisse. L'hébergement web et applicatif fonctionne depuis Zurich, en Suisse ; les données de production subsistent également à Francfort (DE) jusqu'au 22.08.2026. Le traitement Claude utilise le profil d'inférence géographique européen distinct d'AWS Bedrock décrit dans notre politique de confidentialité.
- Pas de SOC 2 / ISO 27001. Nous ne le poursuivons pas spéculativement. Si un client nommé l'exige, nous lancerons la démarche ; d'ici là nous investissons dans l'architecture réelle.
- L'isolation locataire de la base est aujourd'hui côté application. Les frontières de workspace sont imposées dans le code applicatif. Les politiques Supabase Row-Level Security sont prévues en défense en profondeur côté base pour v2.
- L'IA dans le navigateur reste exposée par nature aux prompt injections. Quand l'IA lit une page web, un contenu malveillant peut théoriquement lui donner des instructions. Nous réduisons le risque avec des plafonds de coûts, une pause pour actions sensibles et des journaux d'audit.
Vous avez trouvé une vulnérabilité ?
Envoyez les détails à security@lokbox.ch Nous n'avons pas encore de programme bug bounty formel ; merci d'inclure suffisamment de contexte pour nous permettre d'évaluer le signalement.
Merci de coordonner toute divulgation publique avec nous après la disponibilité d'un correctif.
Dernière mise à jour le 2026-05-02.