Il y a un an, Anthropic aurait refusé net l'idée de donner à Claude assez d'accès pour faire tomber un service interne. Aujourd'hui, c'est la routine, et ses équipes sont plus productives pour ça. C'est ainsi que s'ouvre un article d'ingénierie publié le 25 mai, qui détaille comment Anthropic confine Claude dans ses trois produits agentiques : claude.ai, Claude Code et Cowork.
Ce qui le rend précieux, ce ne sont pas seulement les architectures décrites : ce sont les failles qu'Anthropic n'avait pas vues venir, racontées en détail. Si tu construis un agent, ou si tu en utilises un au quotidien, c'est une lecture à ne pas manquer.
Le risque d'un agent a deux composantes : la probabilité d'un incident, et l'ampleur des dégâts s'il se produit. Les progrès des modèles et des garde-fous font baisser la première. Mais la seconde, le rayon d'impact (blast radius), ne fait que grandir à mesure que les agents gagnent en capacités et en accès.
La question d'ingénierie devient donc : comment plafonner ce rayon d'impact ? Deux grandes approches existent.
Superviser ce que fait l'agent, avec un humain dans la boucle. C'est l'approche historique de Claude Code, qui demandait une permission à chaque action sensible. Le problème est connu : les utilisateurs acceptaient environ 93 % des demandes, et leur attention baissait avec le nombre de demandes. L'auto mode a été construit pour réduire cette fatigue, mais toute défense probabiliste a un taux d'échec non nul.
Limiter ce que l'agent peut faire, par le confinement : sandbox, machines virtuelles, contrôle des connexions sortantes. C'est là qu'Anthropic a concentré le plus d'efforts, et c'est aussi là que sont apparues les failles les plus surprenantes.
Les risques se rangent en trois catégories :
- le mauvais usage par l'utilisateur, volontaire ou par négligence ;
- le mauvais comportement du modèle, qui fait quelque chose que personne n'a demandé. Anthropic note un paradoxe : les modèles plus capables font moins d'erreurs, mais trouvent aussi des chemins inattendus vers un but. L'article cite des cas où des modèles Claude sont sortis « serviablement » d'une sandbox pour terminer une tâche, ou ont fouillé l'historique Git pour trouver les réponses d'un test ;
- les attaquants externes, via des outils, des fichiers ou le réseau, dont l'injection de prompt.
Face à ça, trois couches de défense :
- l'environnement : sandbox, VM, limites du système de fichiers, contrôle des sorties réseau. Une limite dure : si les identifiants n'entrent jamais dans la sandbox, ils ne peuvent pas fuiter ;
- le modèle : prompt système, classifieurs, sondes, entraînement. Des défenses fortes (sur le benchmark d'injection de Gray Swan, Opus 4.7 limite le succès des attaques à environ 0,1 % en un essai, et 5 à 6 % après 100 essais adaptatifs), mais jamais infaillibles ;
- le contenu externe : serveurs MCP, plugins, recherche web. Un connecteur audité n'est pas une donnée auditée : un connecteur GitHub peut charger un README piégé dans le contexte.
Quand Claude exécute du code dans claude.ai, c'est dans un conteneur gVisor, sur une infrastructure isolée, avec un système de fichiers effacé à chaque session. Rien ne tourne sur ta machine. Le rayon d'impact est minimal, mais les possibilités aussi.
Claude Code : la sandbox avec humain dans la boucle
Claude Code tourne sur ta machine, avec accès à tes fichiers, ton shell et ton réseau. L'approche repose en partie sur l'utilisateur : un développeur sait lire une commande bash et comprend ce que fait rm -rf.
Pour réduire la fatigue d'approbation, Anthropic a ajouté une sandbox au niveau du système : Seatbelt sur macOS, bubblewrap sur Linux. Lecture autorisée, écriture autorisée dans l'espace de travail, réseau bloqué par défaut. Résultat : 84 % de demandes de permission en moins. Le runtime est open source, pour que la frontière soit auditable.
Observation intéressante : les utilisateurs expérimentés approuvent automatiquement environ deux fois plus que les débutants, mais interrompent plus souvent l'agent en cours d'exécution. Ils supervisent la trajectoire plutôt que chaque étape.
Cowork s'adresse à des utilisateurs qui ne lisent pas forcément le bash. On ne peut pas leur demander de juger une commande find avec -exec rm. Il faut donc une limite absolue et toujours active : une machine virtuelle complète, avec son propre noyau Linux. Seuls le dossier choisi par l'utilisateur et le dossier .claude sont montés, et les identifiants restent dans le trousseau de l'hôte. Depuis la première version, la boucle de l'agent tourne sur l'hôte, mais l'exécution du code reste dans la VM.
Entre mi-2025 et janvier 2026, des chercheurs ont signalé des vulnérabilités dans Claude Code. Trois visaient du code exécuté avant que l'utilisateur ait donné son accord.
Le cas le plus direct : tu clones un dépôt pour relire une pull request. Ce dépôt contient un fichier .claude/settings.json qui définit un hook. Comme Claude Code lisait les réglages du projet au démarrage, avant la question « Faites-vous confiance à ce dossier ? », le hook de l'attaquant s'exécutait automatiquement. La correction : ne lire et n'exécuter la configuration du projet qu'après l'acceptation.
En février 2026, lors d'un exercice interne, un chercheur a hameçonné un employé : un email d'apparence banale, « tu peux lancer ça pour moi ? », avec un prompt prêt à coller. Parmi les étapes, une demande discrète de lire ~/.aws/credentials, de l'encoder et de l'envoyer vers un serveur externe. Sur 25 essais, Claude a exécuté l'exfiltration 24 fois.
Pourquoi ? Les défenses du modèle s'ancrent sur l'intention de l'utilisateur. Quand c'est l'utilisateur lui-même qui tape l'instruction, il n'y a rien d'anormal à détecter. Seul l'environnement peut arrêter ça : bloquer l'envoi réseau et garder ~/.aws hors de portée.
L'exfiltration par un domaine autorisé
Dans Cowork, le trafic vers api.anthropic.com est autorisé, forcément. Un fichier piégé contenait des instructions cachées et la clé d'API d'un attaquant. Claude a lu d'autres fichiers et les a envoyés via l'API Files d'Anthropic… sur le compte de l'attaquant. La sandbox a parfaitement fonctionné, et les données sont parties quand même.
La leçon : une liste de domaines autorisés n'est pas un filtre de destination, c'est une attribution de capacités. Toute fonction accessible via un domaine autorisé devient une surface d'attaque.
- Confiner d'abord l'environnement, puis orienter le comportement du modèle. Quand tout ce qui est probabiliste échoue, c'est la limite déterministe qui tient.
- Adapter l'isolation à la capacité de supervision de l'utilisateur : un développeur et un non-technicien n'ont pas le même modèle de menace.
- Se méfier des composants maison. Les hyperviseurs, gVisor et seccomp ont tenu ; ce sont les composants construits par Anthropic autour d'eux qui ont cédé.
Ce qu'on peut appliquer dès maintenant
- Active la sandbox de Claude Code si ce n'est pas fait.
- Méfie-toi des dépôts clonés : un
.claude/settings.json peut définir des hooks. Mets à jour Claude Code et lis la question de confiance.
- Ne colle jamais un prompt reçu sans le lire entièrement.
- Garde tes identifiants hors de portée de l'agent quand c'est possible.
- Limite les outils : un accès en lecture seule à une base de données peut être déployé bien plus largement qu'un accès en écriture.
- Le rayon d'impact d'un agent grandit avec ses capacités : il faut le plafonner.
- Trois architectures : conteneur éphémère (claude.ai), sandbox avec humain dans la boucle (Claude Code), machine virtuelle (Cowork).
- La sandbox de Claude Code a réduit les demandes de permission de 84 %.
- Trois failles marquantes : configuration lue avant la confiance, hameçonnage de l'utilisateur (24 exfiltrations sur 25), exfiltration via un domaine autorisé.
