Aller au contenu principal
← LokBox

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 la tâche se termine, le contexte est détruit. Cookies, état de session et jetons OAuth ne se transmettent pas entre tâches, même lorsque plusieurs membres d'un workspace travaillent en parallèle.

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.

Les jetons OAuth n'entrent jamais dans la sandbox de l'agent

Quand LokBox exécute une compétence Gmail ou Notion, le code de la compétence s'exécute dans un isolat V8 via isolated-vm 6.1.2 enveloppé dans un thread enfant worker_threads.

Le jeton OAuth Bearer n'entre jamais dans cet isolat. 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.

Même si un attaquant trouvait une faille d'échappement de sandbox dans V8, ton jeton ne serait pas exfiltré. L'exfiltration de jetons est l'un des schémas de compromission les plus fréquents dans les outils IA ; LokBox le ferme par conception.

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 affiche dans ton tableau de bord une fenêtre expliquant l'action requise. Tu effectues l'étape dans le flux en direct ou saisis un code, par exemple un OTP à 6 chiffres. L'agent reprend ensuite.

LokBox ne te demande jamais de partager tes mots de passe. Si tu ne réponds pas pendant 10 minutes, la tâche s'arrête automatiquement pour éviter les coûts inutiles.

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.

Isolation navigateur par tâche
LokBox:Oui — contexte neufBrowserbase:Partiel — sessions mutualiséesComputer Use:Non — à ta chargeMost MCP:Non — processus partagé
Jetons OAuth isolés du code agent
LokBox:Oui — injection à la couche réseauBrowserbase:Non — directement dans le codeComputer Use:Non — directement dans le codeMost MCP:Partiel — selon le serveur
Protection SSRF sur la navigation agent
LokBox:Oui — blocage IP privées + vérification DNSBrowserbase:Partiel — certains contrôlesComputer Use:Non — à ta chargeMost MCP:Partiel — selon le serveur
Pause pour CAPTCHA / 2FA
LokBox:Oui — intégréBrowserbase:Non — échec ou contournementComputer Use:Non — manuelMost MCP:Non — généralement absent
Plafond strict par tâche
LokBox:Oui — $1 par défautBrowserbase:Partiel — facturation par sessionComputer Use:Non — à ta chargeMost MCP:Non — généralement absent
Constats d'audit publics
LokBox:Oui — cette pageBrowserbase:Partiel — SOC 2 seulementComputer Use:N/AMost MCP: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 dans une seule région. Uniquement UE-Francfort. Les utilisateurs aux États-Unis voient environ 200 ms de latence de base. Le multi-région est sur la roadmap v2.
  • 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.

Tu as trouvé une vulnérabilité ?

Envoyez les détails à security@lokbox.ch Nous répondrons sous 48 heures. Avant le lancement, nous n'avons pas encore de programme bug bounty formel ; si le signalement est matériel, nous trouverons une solution juste.

Merci de ne rien publier avant confirmation et livraison d'un correctif. Fenêtre standard de divulgation responsable : 90 jours.

Dernière mise à jour le 2026-05-02.