Un employé Anthropic reçoit un email d'un prétendu collègue, avec un prompt tout prêt. Le prompt ressemble à des instructions banales. Quelque part dedans, une ligne demande à Claude de lire les identifiants AWS de la machine, d'encoder leur contenu et de l'envoyer vers une URL externe. Sur 25 tentatives, l'agent Claude a exécuté l'exfiltration 24 fois.
Anthropic a documenté cet incident et deux autres dans un article d'ingénierie publié le 25 mai 2026. C'est un document rare : une entreprise d'IA qui rend publiques ses défaillances réelles, avec les causes et les corrections. Pour tout dirigeant qui envisage un déploiement d'agent IA en entreprise, c'est la lecture la plus directe disponible.
Claude Code en local : deux incidents, deux leçons
Claude Code s'exécute sur la machine de l'utilisateur. Il accède au système de fichiers, au shell et au réseau. C'est ce qui le rend productif pour les développeurs. C'est aussi ce qui en fait une surface d'attaque.
La première tentative de protection paraissait logique : demander une approbation à chaque action sensible. Elle a échoué. Les données d'Anthropic montrent que les utilisateurs approuvent environ 93 % des demandes de permission, avec une attention qui décroît au fil du temps. La supervision humaine, seule, ne tient pas.
Premier incident documenté : l'injection par l'utilisateur lui-même. L'employé phisé n'a pas cliqué sur un lien. Il a simplement exécuté un prompt malveillant présenté comme du travail habituel. Quand les instructions arrivent par un vecteur de confiance, les gardes-fous du modèle n'ont rien d'anormal à détecter. La seule défense qui tient est le contrôle d'egress : bloquer la requête sortante avant qu'elle parte, indépendamment de l'intention déclarée.
Deuxième incident : un fichier de configuration dans un dépôt malveillant exécutait ses hooks avant que l'utilisateur n'ait validé sa confiance dans le dossier. Claude Code chargeait cette configuration au démarrage, avant le dialogue de validation. La correction a différé toute exécution jusqu'à l'acceptation explicite.
Voilà le piège.
Ces deux cas illustrent le même principe : la couche modèle ne se substitue pas à la couche environnement. Elle filtre ce qu'elle voit d'anormal. Elle ne filtre pas ce qui lui est demandé par un vecteur qu'elle considère comme légitime.
Claude Cowork en VM : une exfiltration malgré le confinement
Claude Cowork a adopté une architecture plus stricte. L'agent tourne dans une machine virtuelle dédiée. Le workspace est monté dans la VM, les identifiants restent dans le trousseau du système hôte. La surface d'attaque est beaucoup plus réduite.
Et pourtant.
Un chercheur tiers a découvert une exfiltration via api.anthropic.com. Un fichier malveillant placé dans le workspace contenait une clé API appartenant à un attaquant. Claude, suivant les instructions du fichier, lisait d'autres contenus du workspace et les uploadait via l'API Anthropic en utilisant cette clé étrangère. Le proxy d'egress laissait passer : api.anthropic.com figurait sur la liste blanche. Les données avaient quitté le sandbox.
La leçon qu'Anthropic en tire est précise : une liste blanche de domaines n'est pas un filtre de destination. C'est une liste de capacités accordées. Autoriser un domaine, c'est autoriser tout ce que ce domaine permet de faire. La correction : un proxy à l'intérieur de la VM qui vérifie que le token utilisé est bien celui de la session en cours, et rejette toute clé étrangère.
Ce n'est pas un bug exotique. C'est le schéma classique d'une permission accordée trop large.
Ce que cela implique pour votre déploiement
Anthropic formule deux principes dans cet article que tout décideur peut retenir sans être ingénieur.
Le premier : concevoir le confinement d'abord, piloter le comportement du modèle ensuite. Les deux incidents les plus révélateurs n'ont pas pu être rattrapés par le modèle. Il n'avait rien d'anormal à détecter. Seule la couche environnement, règles d'egress, frontières filesystem, contrôles d'accès, peut poser une limite absolue sur ce qu'un agent peut atteindre.
Le second : adapter l'isolation au profil de l'utilisateur. Claude Code est déployé chez des développeurs capables d'évaluer ce qu'un agent s'apprête à exécuter. Claude Cowork cible des travailleurs non-techniques, pour qui un dialogue de permission en bash n'a aucun sens. Ce n'est pas le même risque. Ce n'est pas la même architecture.
Pour approfondir la logique de déploiement, l'article sur les Managed Agents d'Anthropic détaille comment cette infrastructure partagée répartit les responsabilités entre Anthropic et l'entreprise.
La question à poser avant tout déploiement n'est pas "quel outil". C'est : quel utilisateur, avec quelle capacité de supervision, avec quel accès accordé à l'agent.
Identifier ces paramètres prend 30 minutes. C'est exactement ce qu'un premier échange avec un spécialiste de l'écosystème Claude permet d'établir, avant tout engagement.
