Anthropic open-source srt : le sandbox de Claude Code impose ses restrictions au niveau OS, sans conteneur, sous Apache 2.0

Anthropic open-source srt : le sandbox de Claude Code impose ses restrictions au niveau OS, sans conteneur, sous Apache 2.0

🔎 La brique de sécurité qu'Anthropic gardait pour elle vient de changer de mains

Le 24 octobre 2026, Anthropic a ouvert le coffre. Sandbox-runtime (srt), le moteur de sandboxing développé pour Claude Code, est désormais public sous licence Apache 2.0, installable via le package npm @anthropic-ai/sandbox-runtime. L'annonce a circulé le jour même via AIWeekly, et le dépôt GitHub porte une étiquette sans détour : Beta Research Preview.

Le timing n'a rien d'anodin. Les agents de code disposent d'un shell et d'un accès réseau. Sans périmètre, chaque prompt de permission est un frein, et chaque "allow" cliqué par habitude est un risque. Pendant que NVIDIA pousse l'enforcement au niveau noyau et que Google isole chaque agent dans une microVM matérielle, Anthropic choisit une troisième voie : restreindre filesystem, réseau et sockets UNIX directement via les primitives de l'OS, sans un seul conteneur.

Ma lecture est simple : avec la distribution npm, une licence permissive et la base d'utilisateurs de Claude Code, Anthropic vient de jouer son valet sur LA question qui comptera pour les développeurs en 2027 — le sandbox OS peut-il devenir le standard de fait des agents autonomes, à la place de Docker ?

L'essentiel

• Anthropic open-source sandbox-runtime (srt) le 24 octobre 2026 sous Apache 2.0 (analyse MarkTechPost). C'est une research preview, pas un produit généralisé.
• srt restreint fichiers, réseau et sockets UNIX au niveau de l'OS : sandbox-exec sur macOS, bubblewrap sur Linux, filtrage réseau par proxy. Zéro conteneur.
• Toute tentative d'accès restreint renvoie EPERM et est journalisée, avec logs de violations en temps réel sur macOS.
• Windows (alpha) : compte local dédié srt-sandbox, filtres Windows Filtering Platform, token write-restricted et ACL NTFS.
• En interne, le sandboxed bash tool de Claude Code a réduit de 84 % les prompts de permission (Anthropic).
• Cas d'usage documenté par Anthropic : sandboxer un serveur MCP en drop-in.
• La course est déjà lancée : forkd (100 microVM en ~200 ms), NVIDIA OpenShell, Google Agent Compute Engine.

Outils recommandés

Ce qu'Anthropic a réellement open source (et pourquoi ce n'est pas anodin)

Anthropic ne publie pas une démo : c'est le runtime complet qui tourne en production dans Claude Code, distributed en Beta Research Preview. Le README du dépôt précise qu'il a été développé pour Claude Code, mais la licence Apache 2.0 et le package npm autonome disent autre chose : ce code n'appartient plus à un seul produit.

Le point le plus intéressant vient de l'analyse de MarkTechPost : srt n'est pas lié à Claude Code. Vous pouvez sandboxer n'importe quel processus, agent ou serveur MCP avec. C'est une brique générique, pas une feature.

Ce n'est pas non plus un coup isolé. Le même mois, Alphabet open-sourçait toute sa stack robotique sous Apache 2.0 à ROSCon 2026. La stratégie des grands labs converge : donner la couche d'infrastructure pour poser le standard, plutôt que la garder fermée et perdre la distribution.

Mon avis : la licence Apache 2.0 est le vrai signal. Ce n'est pas "regardez notre code", c'est "branchez le nôtre". La différence entre les deux, c'est un écosystème.

La mécanique : restreindre fichiers, réseau et sockets sans un seul conteneur

srt s'appuie sur ce que votre OS sait déjà faire. Sur macOS, il utilise sandbox-exec, le mécanisme de confinement natif d'Apple. Sur Linux, bubblewrap. Dans les deux cas, aucune image à builder, aucun daemon à lancer, aucun conteneur à démarrer.

Le réseau suit une logique différente : tout le trafic passe par un proxy qui applique la liste d'hôtes autorisés et termine le TLS. Les sockets UNIX, souvent oubliés des sandbox "maison", sont eux aussi restreints. Un processus sandboxé ne peut joindre que ce que l'allowlist autorise explicitement.

Et le comportement en cas de violation est sans ambiguïté : le système renvoie EPERM au processus fautif et journalise l'incident. Pas de silent failure, pas d'exception silencieuse — un refus traçable.

Anthropic précise sur son blog engineering que ce runtime peut sandboxer des processus, des agents et des serveurs MCP "sans l'overhead d'un conteneur". C'est le cœur de la proposition.

Pourquoi pas Docker, justement ?

Docker isole bien, mais il ajoute de la friction : images à maintenir, volumes à monter, réseau à configurer. Pour le cas d'usage dominant — un process, une policy, sur la machine du dev — c'est de l'artillerie lourde. srt mise sur l'inverse : une policy déclarative, appliquée par le noyau, instantanée.

Windows (alpha) : un compte srt-sandbox, des filtres WFP et des ACL NTFS

Sur Windows, srt change complètement d'approche, faute d'équivalent natif à sandbox-exec ou bubblewrap. Le processus sandboxé tourne sous un compte local dédié, srt-sandbox, créé à l'installation.

Les détails d'implémentation, documentés sur le package npm et par Ry Walker, méritent le détour :

• Mot de passe aléatoire, chiffré via DPAPI — personne ne le connaît, pas même vous.
• Un filtre Windows Filtering Platform indexé sur le SID du compte, qui filtre le réseau par identité du processus, pas par port.
• Un token write-restricted, complété d'ACEs explicites sur l'arbre de travail.
• Le tout en une seule étape d'installation elevated, ce qui est remarquablement propre pour Windows.

Mon avis : Windows est historiquement le parent pauvre des outils dev. Là, l'ingénierie est réelle et le modèle par compte utilisateur est solide. Mais restons lucides : c'est une alpha. Ne basez rien de critique dessus avant une stabilisation.

-84 % de prompts de permission : ce que change le secure-by-default

Le chiffre qui retiendra l'attention des équipes : le sandboxed bash tool supprime les prompts de permission, et Anthropic mesure -84 % de prompts en interne (source). Concrètement, votre agent propulsé par Claude Sonnet 4.6 ou Claude Opus 4.7 n'interrompt plus le workflow pour chaque commande.

La philosophie est du secure-by-default assumé : par défaut, on ne donne que les trous explicitement demandés. Rien n'est ouvert d'office. L'allowlist décrit précisément ce que l'agent a le droit de toucher — fichiers, hôtes réseau — et tout le reste est refusé avec journalisation.

Deux mécanismes complètent le dispositif. Le masquage de credentials, qui empêche les secrets de fuiter dans le contexte de l'agent. Et les logs de violations en temps réel sur macOS, qui transforment chaque refus EPERM en signal exploitable pour ajuster la policy.

Pourquoi c'est décisif : la fatigue de permission est ce qui tue l'adoption réelle des agents. Chaque clic "allow" mécanique est une décision de sécurité qui n'en est plus une. Supprimer 84 % des prompts tout en gardant un périmètre strict, c'est attaquer le vrai problème, pas le symptôme. Tous les agents de code — de Cursor à Cline, voir notre sélection des meilleurs outils IA pour le code — vont devoir répondre à cette même question.

Le cas d'usage sous-estimé : sandboxer les serveurs MCP

La documentation du package npm cite un cas d'usage précis : sandboxer un serveur MCP. C'est peut-être la partie la plus importante de l'annonce, et personne n'en parle.

Un serveur MCP détient typiquement des tokens d'API, accède au filesystem et parle au réseau. C'est exactement le composant que tout le monde branche sans le confiner — un binaire tiers, souvent open source, avec vos credentials et une surface d'attaque réseau. Avec srt, le confinement devient un drop-in : vous lancez le serveur sous sandbox, vous restreignez ses fichiers et ses hôtes, et vous obtenez des EPERM journalisés à la moindre tentative hors périmètre.

Mon pronostic : d'ici 2027, lancer un serveur MCP non sandboxé sera perçu comme lancer un binaire inconnu en root aujourd'hui. La brique existe désormais, gratuite et sous licence permissive. Il ne manquera que les conventions — et celles-ci se posent vite quand un acteur dominant distribue l'outil par npm.

forkd, OpenShell, Agent Compute Engine : la course au sandboxing des agents

srt n'arrive pas dans un vide technologique. Il arrive dans une course, et les concurrents méritent d'être nommés avec leurs chiffres.

forkd joue la carte microVM : un runtime de sandbox construit sur Firecracker, pensé pour le fan-out d'agents, qui fork 100 microVM en environ 200 ms et exécute un BRANCH live à 56 ms p50, avec isolation KVM par enfant, sous Apache 2.0. Nous en avons fait l'analyse complète.

NVIDIA OpenShell monte d'un étage avec un runtime ouvert pour flottes d'agents autonomes : enforcement au niveau noyau (accès fichiers, appels système, connexions réseau), vérification formelle des changements de politique avant application, et credentials injectés uniquement vers les endpoints approuvés. Il supporte Docker, Podman, Kubernetes et MicroVM.

Google Agent Compute Engine joue la carte managée : chaque agent reçoit sa propre microVM isolée matériellement, avec zéro credential durable dans le sandbox, tout le trafic passant par une frontière IPC isolée (virtio-vsock) puis un proxy externe, et le harness d'orchestration vivant entièrement hors du sandbox. Notre deep dive est ici.

Et l'écosystème open source pousse dans le même sens. OpenCode, le coding agent open source fort de 8 millions de devs et 172K étoiles GitHub, comme les agents auto-hébergeables propulsés par Qwen3-Coder-Next, le MoE 80B à 3B actifs qui rivalise avec Claude Sonnet en local via Ollama, auront tous besoin d'un sandbox. srt vient d'en fournir un, gratuit.

Ma lecture : ces projets ne se concurrencent pas, ils empilent des couches. srt pour le poste de dev, forkd et OpenShell pour les flottes, ACE pour le managé. Mais tous convergent vers le même principe : plus jamais un agent avec un accès brut au kernel, au réseau et aux credentials.

Sandbox OS ou conteneurs : quel standard pour les agents autonomes ?

Réponse directe : pour l'agent de code sur votre machine, le sandbox OS gagne déjà. Pour la flotte en production, les microVM restent reines. Docker ne disparaît pas — il recule sur un segment précis.

Jensen Huang veut enfermer les agents IA dans des conteneurs, comme les navigateurs. L'analogie est séduisante, mais elle se retourne contre lui : le navigateur a gagné avec un sandbox au niveau processus et de la site isolation, pas avec des conteneurs. srt est structurellement plus proche de ce modèle qu de Docker — et c'est précisément ce qui le rend viable pour le poste de travail.

Alors, standard de fait ? Je pense que oui, pour une raison banale : la distribution gagne les standards. npm install -g, licence Apache 2.0, base d'utilisateurs Claude Code — srt est l'option que les devs essaieront en premier, et celle qu'on essaie en premier devient celle qu'on garde.

Une réserve importante, soulevée par MarkTechPost : l'ampleur de l'allowlist est le vrai variateur de sécurité. Un allowlist trop large peut fuiter des données. Le standard de fait ne vaut que ce que valent les policies qu'on écrit dessus.

Démarrer avec srt : une ligne npm et une allowlist à dimensionner

L'installation tient en une commande :

npm install -g @anthropic-ai/sandbox-runtime

Ensuite, trois conseils qui viennent directement de la lecture des sources.

Partez d'une allowlist minimale, puis élargissez uniquement quand un EPERM apparaît. Sur macOS, les logs de violations sont disponibles en temps réel : chaque refus vous dit exactement ce dont l'agent a besoin. C'est une boucle de feedback, pas un mur.

Traitez les logs comme une spec. Chaque violation journalisée est une décision à prendre explicitement : autoriser, ou confirmer le refus. En une semaine, vous avez une policy qui reflète le comportement réel de votre agent, pas une estimation.

Gardez le research preview à sa place. Pour un poste de dev, srt est déjà utile. Pour une flotte de production avec des données sensibles, regardez du côté des microVM — forkd ou ACE — en attendant la sortie de beta.

❌ Erreurs courantes

Erreur 1 : confondre research preview et périmètre de production

Le dépôt GitHub est explicite : Beta Research Preview. Traiter srt comme une barrière de production définitive, sans couche supplémentaire, c'est prendre un risque inutile. La solution : empiler. srt en première ligne au quotidien, microVM ou conteneur pour les charges sensibles, et une revue régulière des policies.

Erreur 2 : copier une allowlist trop large

MarkTechPost le dit crûment : un allowlist trop large peut fuiter des données. Copier la config d'un autre projet est le raccourci le plus dangereux. La solution : démarrer vide, élargir sur les EPERM observés, et réviser à chaque nouveau serveur MCP intégré.

Erreur 3 : sandboxer le processus mais laisser les credentials à portée

Le masquage de credentials de srt ne remplace pas l'hygiène. Comparez avec l'état de l'art : OpenShell n'injecte les credentials que vers les endpoints approuvés, et Google ACE maintient zéro credential durable dans le sandbox. La solution : des secrets à durée de vie courte, injectés à la demande, jamais persistés dans le périmètre.

Erreur 4 : ignorer les logs de violations

Les EPERM journalisés ne sont pas du bruit, ce sont des données de tuning gratuites. Les ignorer, c'est laisser une policy approximative en place. La solution : une revue hebdomadaire des logs pendant les premières semaines, puis au chaque changement majeur de l'agent ou de ses outils.

❓ Questions fréquentes

srt fonctionne-t-il sans Claude Code ?

Oui. Selon MarkTechPost, srt n'est pas lié à Claude Code : c'est un runtime générique qui sandboxe n'importe quel processus, agent ou serveur MCP. Le package npm s'installe indépendamment, et la licence Apache 2.0 autorise l'intégration dans vos propres outils, commercialement comme en interne.

Quelles plateformes sont supportées ?

macOS via sandbox-exec et Linux via bubblewrap constituent la base stable, avec filtrage réseau par proxy. Windows est en alpha : compte local dédié srt-sandbox, filtres Windows Filtering Platform indexés sur le SID, token write-restricted et ACL NTFS, installés en une seule étape elevated.

Un sandbox sans conteneur, est-ce vraiment isolé ?

Il s'appuie sur des primitives noyau natives — sandbox-exec, bubblewrap, WFP — avec refus EPERM et journalisation. Pour un poste de dev, c'est un niveau solide. Pour une isolation matérielle multi-tenant, les microVM comme forkd ou Agent Compute Engine restent la bonne réponse.

Peut-on sandboxer un serveur MCP avec srt ?

Oui, c'est le cas d'usage documenté dans le package npm. Le serveur tourne sous sandbox avec ses fichiers et hôtes réseau restreints, les sockets UNIX inclus. Les tentatives hors périmètre renvoient EPERM et sont journalisées, ce qui permet d'ajuster l'allowlist progressivement.

srt remplace-t-il Docker pour les agents ?

Non, c'est un complément. Docker et Kubernetes restent pertinents pour des environnements reproductibles et du déploiement. srt répond au cas "un process, une policy" sur la machine du dev, sans overhead de conteneur. Les flottes à forte isolation passeront par des microVM Firecracker.

Combien coûte srt ?

Gratuit et open source sous Apache 2.0, comme forkd et OpenShell. Le coût réel se situe ailleurs : dimensionner les allowlists correctement, surveiller les logs de violations et maintenir les policies dans le temps. La sécurité des agents devient un travail d'ingénierie continue, pas un achat.

✅ Conclusion

En open-sant srt sous Apache 2.0, Anthropic ne fait pas un cadeau à la communauté : elle installe son standard, une ligne npm à la fois, dans la course au sandboxing qui oppose déjà forkd, OpenShell et Agent Compute Engine. Testez-le sur un serveur MCP cette semaine, et suivez l'évolution de l'écosystème dans nos nouveautés IA — la question n'est plus de savoir si les agents seront sandboxés, mais par quoi.