Le problème : un sandbox, douze outils
Un agent IA typique dispose de plusieurs outils. Un accès filesystem, un accès base de données, des appels API externes, un navigateur. Chaque outil est un vecteur d'attaque potentiel.
La plupart des sandboxes actuels isolent l'agent globalement. Tous ses outils tournent dans le même conteneur, avec les mêmes permissions. Si un outil est compromis par injection de prompt, l'attaquant hérite des permissions de tous les autres outils.
L'isolation par agent ne protège pas contre la compromission d'un outil individuel. L'attaquant qui compromet l'outil A accède automatiquement aux permissions des outils B, C, D, E.
C'est le scénario le plus courant en sécurité agentique. Pas une attaque sophistiquée sur le kernel. Une injection de prompt dans un outil, qui donne accès à tout ce que l'agent peut atteindre.
L'inversion Sandlock
Sandlock inverse le principe. Au lieu d'un sandbox par agent, il crée un sandbox distinct par appel d'outil.
"Each tool invocation is independently confined, and a compromise of one tool does not grant the attacker the permissions of another."
Chaque fois qu'un agent appelle un outil, Sandlock crée un sandbox dédié pour cette invocation précise. L'outil ne voit que les fichiers et permissions déclarés dans son allowlist. Rien d'autre.
Un outil de lecture de fichiers ne peut pas toucher la base de données. Un outil d'appel API ne peut pas lire le filesystem local. Le blast radius d'une compromission est confiné par design, pas par convention.
Mécanisme : fork, Landlock, seccomp
Landlock est un mécanisme de sécurité du kernel Linux, disponible depuis la version 5.13 et étendu en 6.12 (ABI v6, Application Binary Interface version 6). Il permet à un processus de restreindre ses propres accès au filesystem sans droits root.
Sandlock utilise fork() pour créer un processus fils. Avant l'exécution de l'outil, Landlock applique une allowlist d'accès stricte. Le processus fils ne peut accéder qu'aux chemins explicitement déclarés. Seccomp (Secure Computing Mode) filtre les appels système autorisés.
- fork+Landlock : confinement en moins d'1ms
- Zéro privilège des deux côtés, côté appelant et côté sandboxé
- Pas de daemon, pas de conteneur, pas de root
- Allowlist déclarative par outil : chaque outil déclare ses chemins et permissions
Pas de service en arrière-plan. Pas de configuration réseau. Un binaire unique, sans dépendance, qui confine chaque invocation indépendamment.
Performance : moins d'1ms contre ~100ms
L'intérêt de l'approche fork+Landlock est la latence. Un agent qui appelle 50 outils en série peut confiner chaque appel sans impact mesurable.
<1ms par sandbox Sandlock (fork + Landlock)
~100ms par conteneur gVisor (démarrage conteneur)
Facteur 100x. Sur 50 appels d'outils en série, c'est la différence entre 50ms et 5 secondes.
La comparaison porte spécifiquement sur gVisor. Docker et Firecracker ne sont pas cités avec ce chiffre dans la source originale. gVisor est le runtime de conteneur le plus léger couramment utilisé pour l'isolation, ce qui rend la comparaison pertinente.
Firecracker isole au niveau microVM (machine virtuelle légère), donc au niveau agent entier. C'est une bonne option pour isoler des agents distincts, pas pour isoler chaque outil au sein d'un même agent. Ce sont des périmètres différents.
Limitations réelles
Sandlock dépend de Landlock ABI v6, disponible à partir du kernel Linux 6.12. C'est la limitation principale.
- Linux uniquement. Pas de macOS, pas de Windows.
- Kernel 6.12 minimum. Ubuntu 24.04 LTS (Long Term Support) livre le kernel 6.8 par défaut. Il faut passer à un kernel mainline récent.
- Cloud managé limité. EKS (Elastic Kubernetes Service), GKE (Google Kubernetes Engine), AKS (Azure Kubernetes Service) ne proposent pas de kernel custom par défaut. Sur VPS (Virtual Private Server) avec kernel personnalisable, c'est faisable.
- Projet jeune. 130 étoiles sur GitHub. Apache 2.0. À évaluer avant tout usage en production.
Ces limitations sont documentées par les auteurs eux-mêmes. Sandlock ne prétend pas remplacer Docker ou gVisor. Il répond à un problème différent : la granularité de l'isolation au sein d'un agent, pas entre agents.
Contexte : OWASP et moindre privilège agentique
En décembre 2025, l'OWASP (Open Worldwide Application Security Project) a publié son Top 10 pour les applications agentiques. La CSA (Cloud Security Alliance) a ensuite construit son Agentic Trust Framework en février 2026, qui opérationnalise les menaces identifiées par l'OWASP.
Le principe de moindre privilège est au centre de ces référentiels. Un composant ne doit accéder qu'aux ressources strictement nécessaires à sa fonction. Appliqué aux agents IA, cela signifie que chaque outil devrait avoir ses propres permissions, indépendantes des autres.
Sandlock est une implémentation concrète de ce principe. Pas la seule possible, mais l'une des rares qui opère au niveau de l'appel d'outil individuel plutôt qu'au niveau de l'agent entier.
Sandlock ne résout pas tous les problèmes de sécurité agentique. Il résout un problème précis : le mouvement latéral entre outils d'un même agent après compromission. C'est un projet à suivre, pas à déployer en production demain. Mais il pose la bonne question : pourquoi tous les outils d'un agent partagent-ils encore les mêmes permissions ?