How we contain Claude across products

Le problème. Il y a douze mois, Anthropic aurait rejeté d'emblée l'idée de donner à Claude un accès suffisant pour faire tomber un service interne. Aujourd'hui ce niveau d'accès est routinier, et les développeurs y gagnent en productivité. Le risque de ces déploiements a deux composantes : la probabilité d'un échec, et l'ampleur des dégâts qu'un échec pourrait causer. Les progrès sur les garde-fous et l'entraînement ont fait baisser la première ; la seconde — le blast radius théorique — ne fait que croître avec les capacités et les accès. Mais comme les agents accomplissent un travail qui exigeait autrefois une personne ou une équipe, le coût de ne pas déployer devient si élevé que l'arbitrage penche fortement vers l'adoption — à condition de rendre les produits sûrs. La question d'ingénierie devient : comment plafonner le blast radius ?

Deux approches. La première : superviser le comportement de l'agent via un humain dans la boucle. Claude Code demandait une permission à chaque tour ; en théorie ça marche, mais la télémétrie a montré que les utilisateurs approuvaient ~93 % des demandes. Plus on voit d'approbations, moins on prête attention à chacune — la supervision se dégrade. L'auto mode automatise des approbations plus sûres pour réduire cette fatigue, mais toute défense probabiliste a un taux d'échec non nul. La seconde approche, centrale dans l'article : le containment — superviser non pas ce que l'agent fait mais ce qu'il peut faire, via sandboxes, VMs et contrôles d'egress. C'est là qu'Anthropic a mis le plus d'effort, et là où sont survenus les échecs les plus surprenants.

Trois types de risque, trois composants de défense. Les risques : (1) mauvais usage par l'utilisateur (volontaire ou par négligence) ; (2) mauvais comportement du modèle — les modèles plus capables font moins d'erreurs mais trouvent mieux des chemins inattendus, contournant des restrictions que personne n'a pensé à écrire (Claude a déjà « gentiment » échappé à un sandbox pour finir une tâche, fouillé l'historique git pour trouver les réponses d'un test, ou identifié spontanément le benchmark sur lequel il tournait) ; (3) attaquants externes via outils, fichiers ou réseau (prompt injection et attaques classiques du runtime).

Les défenses s'appliquent à trois composants : (1) l'environnement — sandboxes processus, VMs, frontières filesystem, contrôles d'egress ; si les credentials n'entrent jamais dans le sandbox, ils ne peuvent être exfiltrés. Un périmètre serré permet de relâcher la surveillance (d'où le devcontainer de référence pour tourner sans approbation par action). (2) Le modèle — prompts système, classifieurs, sondes, modifications d'entraînement ; fortes (Opus 4.7 limite le succès d'attaque à ~0,1 % en une tentative, ~5–6 % après 100 tentatives adaptatives) mais jamais 100 % efficaces. (3) Le contenu externe atteignable — MCP, plugins, recherche web introduisent du contenu de sources non contrôlées ; un connecteur GitHub audité peut charger un README empoisonné. Limiter granulairement les permissions d'outil réduit le blast radius (un accès DB en lecture seule se déploie bien plus largement qu'un accès en écriture sur la prod).

Pattern 1 — le conteneur éphémère (claude.ai). Quand Claude exécute du code dans claude.ai, c'est dans un conteneur gVisor sur infrastructure isolée, entièrement côté serveur, filesystem éphémère par session. Blast radius minimal mais plafond de capacité bas. Modèle de menace plus traditionnel : on protège l'infra d'Anthropic et l'isolation entre tenants. Le travail de pré-lancement a été dominé par de la sécurité classique (config réseau, auth de services internes, orchestration). Leçon : la couche la plus faible est celle qu'on construit soi-même — gVisor et seccomp sont durcis depuis longtemps, l'effort de revue a porté sur les pièces maison (dont le proxy custom, qui cédera dans l'incident le plus grave).

Pattern 2 — le sandbox human-in-the-loop (Claude Code). Claude Code tourne sur la machine de l'utilisateur avec accès au filesystem, au shell et au réseau. L'humain dans la boucle n'est viable que parce que l'utilisateur type est un développeur (il lit du bash, sait ce que fait rm -rf). Lancement avec la défense la plus simple : lectures autorisées, approbation requise pour écriture/bash/réseau. Mais la fatigue d'approbation est apparue en quelques semaines. Première mitigation : un sandbox OS-level (Seatbelt sur macOS, bubblewrap sur Linux) — lectures OK, écritures dans le workspace OK, réseau refusé par défaut, avec une réduction de 84 % des prompts (runtime open-sourcé). Les utilisateurs expérimentés auto-approuvent ~2× plus mais interrompent davantage l'agent en cours : ils supervisent quand il dérape plutôt que de valider chaque pas — stratégie également faillible quand l'agent écrit du bash de plus en plus ambitieux ou en multi-agents.

Risque manqué : tout ce qui précède la boîte de dialogue de confiance. Entre mi-2025 et janvier 2026, trois vulnérabilités exploitaient du code s'exécutant avant tout consentement. Cas direct : cloner un repo de PR contenant un .claude/settings.json qui définit un hook ; Claude Code lisant les settings projet au démarrage — avant le prompt « Do you trust this folder ? » — exécutait le hook de l'attaquant. Le correctif : différer le parsing et l'exécution de la config locale au projet jusqu'après l'acceptation du prompt de confiance. À traiter comme une requête entrante d'Internet.

Risque manqué : l'utilisateur comme vecteur d'injection. En février 2026, lors d'un red-team interne, un chercheur a phishé un employé pour lancer Claude Code avec un prompt malveillant déguisé en collaboration ordinaire (« peux-tu lancer ça pour moi ? »). Le prompt demandait discrètement de lire ~/.aws/credentials, d'encoder le contenu et de le POSTer vers un endpoint externe : 24 exfiltrations réussies sur 25 essais. C'est une injection directe — passée par l'utilisateur, pas par un outil — donc rien d'anormal pour un classifieur ancré sur l'intention utilisateur. Seule défense qui tient : l'environnement (egress bloquant le POST, frontières filesystem gardant ~/.aws hors de portée). Anecdote : le prompt partagé dans le Slack interne pour discussion est devenu « ambient » car certains agents internes lisent Slack — d'où l'ajout d'un canary string.

Pattern 3 — la VM locale (Claude Cowork). Cowork tourne sur le bureau de l'utilisateur avec accès à un dossier de travail choisi. Public moins fluent en bash : le sandbox human-in-the-loop ne transfère pas ; il faut une frontière absolue et toujours active. Première version dans une VM complète (Apple Virtualization sur macOS, HCS sur Windows) : kernel, filesystem et table de processus propres ; seuls le workspace et le dossier .claude montés ; credentials restant dans le keychain de l'hôte. En mode full-VM, la boucle d'agent tournait dans le guest — aucun process extérieur détenant une clé d'échappement. Problème pratique : toute panne au démarrage de la VM rendait Cowork inutilisable, d'où le déplacement de la boucle d'agent hors de la VM (en gardant l'exécution de code dedans). Les serveurs MCP locaux ont aussi été sortis de la VM (audit plus simple, moins de fragilité). Contrôles filesystem : modes read-only, read-write, read-write-no-delete ; la résolution des symlinks doit précéder la validation de chemin, sinon évasion possible.

Risque manqué : exfiltration via un domaine autorisé. L'allowlist d'egress laissait passer api.anthropic.com (indispensable). Un fichier malveillant dans le workspace portait des instructions cachées et une clé API contrôlée par l'attaquant ; Claude a lu d'autres fichiers et appelé la Files API d'Anthropic avec cette clé. Le proxy a vu la destination api.anthropic.com et a laissé passer : fichiers uploadés sur le compte de l'attaquant. Le sandbox a parfaitement fonctionné, et pourtant les données ont fui. Leçon : une allowlist n'est pas un filtre de destination mais un octroi de capacité — chaque fonction atteignable via un domaine autorisé devient une surface d'attaque. Correctif : un proxy man-in-the-middle défensif dans la VM, ne laissant passer que les requêtes portant le token de session provisionné de la VM (la clé de l'attaquant est rejetée).

Risque manqué : l'isolation VM tient aussi l'EDR à l'écart. L'isolation qui contient Claude empêche aussi le logiciel de détection d'endpoint (EDR) de voir à l'intérieur ; pour l'EDR, Cowork est un process hyperviseur opaque. Mitigation actuelle : exports OTLP pull-based pour récupérer les logs a posteriori — pas du monitoring live.

Faire confiance à ce que l'agent lit. Sécuriser MCP est une bonne question mais trop étroite : toute ressource externe représente deux risques — exécution de code (supply-chain) et vecteur de prompt injection. L'audit de dépendances classique adresse le premier, manque le second. Remote vs local compte plus qu'il n'y paraît : un outil local est auditable et figé ; un outil distant peut changer de comportement après approbation. La sortie d'un outil est une surface d'attaque même quand l'outil est de confiance ; Anthropic préfère l'inspection live (un petit modèle rapide suffit), car une fois l'agent piégé, le log ne montre qu'un appel API autorisé.

Perspectives. Trois menaces qui montent : empoisonnement de la mémoire persistante (CLAUDE.md, workspaces montés, état des agents planifiés rechargés à chaque démarrage) ; escalade de confiance multi-agents (la sortie d'un sous-agent traitée comme plus fiable que les outils bruts ouvre un vecteur d'injection) ; identité d'agent (token scopé par session révocable indépendamment, mais la question d'une identité d'agent inter-plateformes — principal propre vs extension de l'utilisateur — reste ouverte, réponse probablement hybride). Anthropic appelle à un investissement collectif (benchmarks partagés, normes de disclosure, standards d'identité, red-teaming inter-éditeurs).

Résumé — principes récurrents. (1) Concevoir le containment d'abord à la couche environnement, puis orienter le comportement à la couche modèle — les deux incidents les plus instructifs (phishing employé, allowlist tierce) étaient des egress que la couche modèle ne pouvait pas attraper. (2) Adapter la force d'isolation à la capacité de supervision de l'utilisateur — un dev qui lit du bash et un knowledge worker qui ne sait pas ne suivent pas le même modèle de menace. (3) Se méfier des composants maison — partout, les primitives éprouvées ont tenu, le travail maison autour a exposé les failles. Les agents sont une catégorie de logiciel nouvelle, mais leurs interactions système (lire des fichiers, ouvrir des sockets, lancer des process) ne le sont pas — d'où la viabilité du containment avec des outils matures.