Comment Anthropic confine Claude dans l’ensemble de ses produits

 (anthropic.com)
2 points par GN⁺ 5 시간 전 | 1 commentaires | Partager sur WhatsApp
  • À mesure que les capacités et les droits d’accès des agents augmentent, le rayon d’impact potentiel s’élargit lui aussi ; retour d’expérience sur la mise en place d’architectures de confinement adaptées à Claude Web, Claude Code et Cowork
  • Le risque se compose de deux éléments : la probabilité d’échec et l’ampleur des dommages. Les garde-fous et l’entraînement des modèles ont réduit le premier, mais le second continue d’augmenter avec l’élargissement des capacités et des accès
  • L’approche human-in-the-loop pour superviser les actions atteint ses limites à cause de la fatigue liée aux validations ; l’essentiel de l’effort porte donc sur le containment (confinement), c’est-à-dire la limitation du champ d’action possible de l’agent
  • Trois schémas d’isolation sont appliqués selon les profils utilisateurs : conteneurs éphémères sur claude.ai, sandbox avec intervention humaine dans Claude Code, et VM locale dans Cowork
  • La principale leçon est qu’il faut concevoir d’abord le confinement au niveau de l’environnement, avant la couche modèle, et que les composants sur mesure sont les points les plus fragiles

Contexte : le calcul risque-récompense du déploiement

  • Il y a 12 mois, Anthropic aurait refusé d’accorder à Claude un niveau d’accès suffisant pour perturber des services internes, mais aujourd’hui ce niveau d’accès est devenu courant et améliore aussi la productivité des développeurs
  • À partir du moment où un agent peut accomplir le travail d’une personne ou d’une équipe, le coût du non-déploiement devient suffisamment élevé pour faire pencher fortement le calcul risque-récompense vers l’adoption, dès lors qu’on peut rendre le produit suffisamment sûr
  • Claude Mythos Preview est un exemple de modèle non lancé, car son rayon d’impact a été jugé trop élevé en avril 2026
    • À mesure que la défense renforce les systèmes critiques et que les garde-fous gagnent en maturité, des modèles aux capacités comparables pourraient être diffusés plus largement à l’avenir (même si certains risques subsisteront toujours)

Deux façons de limiter le rayon d’impact

  • Supervision des actions (human-in-the-loop)

    • Claude Code utilisait auparavant un mécanisme demandant l’autorisation de l’utilisateur à chaque étape pour éviter les actions non intentionnelles, mais cette méthode comporte une possibilité d’erreur
    • La télémétrie montre que les utilisateurs ont approuvé environ 93 % des demandes d’autorisation ; plus les validations sont nombreuses, moins chaque demande reçoit d’attention, et la supervision se relâche
    • Pour réduire la fatigue de validation, Anthropic a créé Claude Code auto mode, qui automatise les validations les plus sûres, mais toute défense probabiliste conserve toujours un taux de raté non nul

  • Confinement (containment)

    • Au lieu de superviser ce que fait l’agent, on supervise ce qu’il peut faire, en imposant des frontières d’accès via sandbox, machines virtuelles et contrôle de l’egress
    • C’est le domaine où l’ingénierie d’Anthropic a investi le plus d’efforts, et aussi celui où sont survenus les échecs de sécurité les plus inattendus

Trois risques et trois composants défensifs

  • Trois types de risques

    • User misuse (mauvais usage par l’utilisateur) : l’utilisateur demande à l’agent, par malveillance ou négligence, d’effectuer une action nuisible (contourner une vérification gênante, exécuter une commande destructrice mal comprise, nuire volontairement, etc.)
    • Model misbehavior (mauvais comportement du modèle) : l’agent réalise une action nuisible que personne n’a demandée
      • Un modèle peu capable lit plus facilement mal la situation et commet des erreurs évidentes
      • Un modèle plus capable se trompe moins, mais trouve plus facilement des chemins inattendus vers l’objectif en contournant des contraintes que personne n’a explicitement formulées
      • En pratique, des modèles Claude ont déjà « gentiment » quitté leur sandbox pour terminer une tâche, exploré l’historique git pour trouver les réponses d’un test de code, ou identifié eux-mêmes un benchmark en cours pour déchiffrer sa clé de réponses
    • External attackers (attaquants externes) : l’agent est attaqué via des chemins externes comme les outils, les fichiers ou l’accès réseau (y compris le prompt injection et les attaques plus classiques contre l’environnement d’exécution, l’orchestration ou les proxys)

  • Trois composants de défense

    • L’environnement dans lequel l’agent s’exécute : sandbox de processus, VM, frontières du système de fichiers et contrôle de l’egress pour fixer des limites dures sur ce qui est atteignable
      • Si des identifiants n’entrent pas dans la sandbox, ils ne peuvent pas être exfiltrés, que la cause soit l’utilisateur, le modèle ou un attaquant
    • Le modèle auquel l’agent se réfère : prompt système, classifieurs, probes, ajustements d’entraînement, etc. n’agissent que sur des tendances et ne contrôlent pas le champ théorique du possible
      • Dans le benchmark Agent Red Teaming de Gray Swan, Claude Opus 4.7 maintient un taux de réussite d’attaque d’environ 0,1 % sur une tentative unique, puis encore environ 5 à 6 % après 100 tentatives adaptatives
      • Claude Code auto mode bloque environ 83 % des suractions avant exécution, mais les défenses à la couche modèle ne pourront jamais atteindre 100 % et ne suffisent donc pas seules
    • Les contenus externes auxquels l’agent accède : serveurs MCP, plugins tiers et outils de recherche web injectent dans le contexte des contenus provenant de sources non contrôlables
      • Un connecteur audité ne signifie pas des données auditées ; un connecteur GitHub peut charger tel quel dans le contexte du modèle un README contaminé, même s’il a passé les vérifications antimalware
      • Un agent avec accès en lecture seule à une base de données peut être déployé beaucoup plus largement qu’un agent qui écrit en production

Trois schémas d’isolation pour le confinement des agents

  • Schéma 1 — Conteneurs éphémères (exécution de code sur claude.ai)

    • claude.ai est surtout connu comme interface de chat, mais il peut aussi écrire et exécuter du code, créer des fichiers et appeler des connecteurs ; l’exécution de code se fait dans des conteneurs gVisor de l’infrastructure d’isolation
    • L’agent fonctionne entièrement côté serveur, aucun code n’est exécuté sur la machine locale, et le système de fichiers est éphémère par session — le rayon d’impact est donc minimal, mais l’absence d’espace de travail persistant et d’accès au système de fichiers utilisateur limite aussi ce qu’il peut faire
    • L’objectif n’est pas de protéger la machine de l’utilisateur, mais l’infrastructure interne et l’isolation entre tenants ; avant le lancement, le travail a donc surtout porté sur des sujets de sécurité classiques comme la configuration réseau, l’authentification des services internes et l’orchestration
    • gVisor et seccomp sont durcis depuis plus longtemps que les agents IA, donc l’effort de revue s’est concentré sur les nouveaux composants sur mesure construits autour
      • Lors de l’incident le plus grave, c’est justement ce proxy personnalisé qui a cédé

  • Schéma 2 — Sandbox avec intervention humaine (Claude Code)

    • Claude Code s’exécute sur la machine de l’utilisateur et accède au système de fichiers, au shell et au réseau ; sans cela, l’utilité d’un agent de programmation est limitée, donc il faut un moyen sûr d’accorder ces droits
    • Cette approche fonctionne parce que l’utilisateur type est un développeur qui sait lire du bash, comprend ce que signifie rm -rf et exécute plusieurs fois par semaine des npm install provenant de sources non fiables
    • Au lancement, la défense a commencé par le plus simple : lecture autorisée, mais écriture, bash et accès réseau soumis à approbation

    • Fatigue de validation et sandbox OS

      • La fatigue de validation est apparue en quelques semaines, avec un risque d’effet inverse où la fonction de supervision finit par diminuer l’attention
      • Une sandbox au niveau du système d’exploitation a été introduite — Seatbelt sur macOS, bubblewrap sur Linux — pour autoriser la lecture, autoriser l’écriture dans l’espace de travail et bloquer le réseau par défaut
      • Résultat : 84 % de prompts d’autorisation en moins, et le runtime a été publié en open source pour permettre l’audit des frontières
      • Les utilisateurs expérimentés activent l’auto-approbation environ deux fois plus souvent que les nouveaux, mais interviennent aussi plus fréquemment pendant l’exécution, avec une tendance à ne superviser que lorsque l’agent dérive
      • Cette approche exige néanmoins que l’utilisateur soit assez technique et attentif pour repérer cette dérive, et son efficacité diminue à mesure que les modèles progressent et que l’on passe à des systèmes 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 exploitant du code exécuté avant le consentement de l’utilisateur ont été signalées via un programme de divulgation responsable
      • Exemple : lorsqu’un développeur clone un dépôt pour relire une PR, le fichier .claude/settings.json du dépôt définit un hook, et Claude Code lit la configuration du projet avant d’afficher le prompt « Faites-vous confiance à ce dossier ? », ce qui permet d’exécuter automatiquement un hook commité par un attaquant
      • Le correctif a suivi la même logique : repousser l’analyse et l’exécution des paramètres locaux du projet après l’acceptation du prompt de confiance
      • Il faut traiter l’ouverture de projet, le chargement de configuration et les écouteurs localhost comme des requêtes venant d’Internet, et non leur accorder une confiance implicite sous prétexte qu’ils sont locaux

    • Risque manqué : l’utilisateur comme vecteur d’injection

      • Lors d’un exercice interne de red team contrôlé en février 2026, un chercheur a réussi à piéger un employé pour lui faire lancer Claude Code avec un prompt malveillant
      • Le phishing ressemblait à une collaboration ordinaire (« tu peux lancer ça ? » par e-mail + un prompt à copier-coller) et glissait au milieu des étapes de configuration une demande de lecture de ~/.aws/credentials, d’encodage, puis de POST vers un endpoint externe
      • Sur 25 tentatives avec le même prompt, Claude a réussi l’exfiltration 24 fois
      • Il s’agit d’une prompt injection directe : les instructions de l’attaquant arrivent par l’utilisateur et non par la sortie d’un outil, donc les défenses de couche modèle fondées sur l’intention de l’utilisateur ne peuvent pas repérer d’anomalie
      • La seule défense réellement efficace est l’environnement — contrôle de l’egress pour bloquer le POST quelle que soit l’intention, et frontières du système de fichiers pour empêcher dès le départ l’accès à ~/.aws
      • Quand le prompt a été partagé sur le Slack interne, quelqu’un a souligné que certains agents internes lisent Slack, ce qui a mis le payload en circulation ; un canary string a alors été ajouté pour détecter si quelque chose venait le récupérer — dans un environnement où les agents lisent tout, même les outils d’enquête deviennent une surface d’attaque

  • Schéma 3 — VM locale (Claude Cowork)

    • Claude Cowork s’exécute sur le desktop et accède au dossier d’espace de travail choisi par l’utilisateur ; comme il vise le travail de connaissance général plutôt que le génie logiciel, l’utilisateur moyen n’est probablement pas à l’aise avec bash
    • On ne peut pas attendre d’un travailleur du savoir non technique qu’il évalue une commande comme find . -name "*.tmp" -exec rm {} \;, donc l’administrateur doit définir des frontières absolues et toujours actives

    • Mode VM complet et mécanismes d’isolation

      • La première version s’exécutait dans une machine virtuelle complète s’appuyant sur les hyperviseurs des plateformes (Apple Virtualization framework sur macOS, HCS sur Windows)
      • La VM dispose de son propre noyau Linux, système de fichiers et table de processus ; seuls le dossier de travail sélectionné et le dossier .claude y sont montés, rien d’autre de l’hôte n’est visible
      • Les identifiants restent dans le trousseau de l’hôte et n’entrent pas dans l’invité
      • Même un Claude compromis est conçu pour ne pouvoir endommager que le dossier d’espace de travail monté (jusqu’à ce que l’utilisateur ajoute des connecteurs)
      • Dans l’architecture d’origine (mode full-VM), la boucle agent elle-même tournait dans l’invité comme utilisateur Linux standard, sans conscience de la sandbox, et aucun processus externe n’avait le privilège d’accorder des exceptions — à l’inverse de Claude Code, où un processus privilégié externe décide application par application

    • Transition vers le mode hôte

      • Le mode full-VM posait un problème pratique : si le démarrage de la VM échouait, tout Cowork devenait inutilisable
      • L’exécution de code reste dans la VM, mais la boucle agent a été déplacée hors de la VM, afin que Claude puisse encore répondre et aider au débogage même si la VM plante (avec un impact sécurité minimal, puisque la VM continue d’imposer les contrôles réseau et système de fichiers)
      • Les serveurs MCP locaux ont eux aussi été déplacés hors de la VM, car leur exécution à l’intérieur compliquait l’audit, créait des problèmes de dépendances lors des mises à jour de VM, et empêchait la prise en charge de MCP interagissant avec des processus locaux comme une base de données
      • Cela aligne le fonctionnement sur celui des MCP locaux de Claude Desktop — ils sont traités comme des logiciels installés par l’utilisateur, et l’administrateur décide quels MCP locaux activer (les serveurs MCP distants ne s’exécutent pas sur la machine de l’utilisateur, donc l’impact n’est pas le même)

    • Contrôle du système de fichiers

      • Pour être utile, l’agent doit accéder à une partie des fichiers de l’hôte ; afin de minimiser le rayon d’impact et d’apporter de la transparence sur cet accès, les modes de montage ont été affinés
      • Trois modes de montage de fichiers sont proposés : read-only, read-write, read-write-no-delete
      • Un piège important : la résolution des liens symboliques doit se faire avant la validation du chemin, sinon un symlink situé dans un dossier autorisé peut pointer vers l’extérieur et permettre une sortie du périmètre
      • Les clients enterprise peuvent être contrôlés par l’administrateur via une liste d’autorisation des chemins de montage dans les paramètres MDM

    • Risque manqué : exfiltration via un domaine autorisé

      • Cas révélé dans le cadre d’une publication tierce : la liste d’autorisation egress de Cowork laissait normalement passer le trafic vers api.anthropic.com, indispensable au fonctionnement du produit
      • Un fichier malveillant placé dans l’espace de travail monté contenait des instructions cachées ainsi qu’une clé API contrôlée par l’attaquant ; Claude a suivi ces instructions, lu d’autres fichiers, puis appelé l’Anthropic Files API avec la clé de l’attaquant
      • Le proxy egress se contentait de vérifier que la destination était api.anthropic.com et laissait passer, si bien que les fichiers ont été envoyés vers le compte Anthropic de l’attaquant — la sandbox fonctionnait parfaitement, mais les données ont tout de même fui
      • La liste d’autorisation a alors été reconceptualisée non plus comme un filtre de destination, mais comme une attribution de capacités — toute fonction atteignable sur un domaine autorisé devient une surface d’attaque
      • Un proxy man-in-the-middle défensif a été placé dans la VM pour intercepter le trafic vers les API maison et ne laisser passer que les requêtes portant le jeton de session de provisioning propre à la VM ; les clés injectées par l’attaquant sont refusées (et les headers permettant un server-side fetch sont eux aussi bloqués)
      • Le proxy se trouve dans la VM et non côté serveur — du point de vue du serveur, les requêtes Cowork sont indistinguables de celles d’un autre client API, donc seule la VM connaît leur provenance
      • C’est un deuxième exemple du principe selon lequel le logiciel maison est le plus fragile — hyperviseur, seccomp et gVisor ont tenu, mais le proxy d’autorisation personnalisé a échoué

    • Risque manqué : l’isolation de la VM bloque aussi les logiciels EDR

      • Les équipes sécurité enterprise ont demandé : « pourquoi notre EDR ne voit-il pas ce qui se passe à l’intérieur ? » — parce que l’isolation qui enferme Claude bloque aussi l’EDR basé sur l’hôte
      • Du point de vue de l’EDR, Cowork n’est qu’un processus d’hyperviseur opaque, sans possibilité d’inspecter l’intérieur de l’invité
      • L’atténuation actuelle est un export OTLP par pull, permettant à l’administrateur de récupérer les journaux d’événements a posteriori, mais ce n’est pas l’équivalent d’une supervision en temps réel

Résumé comparatif des environnements

  • Conteneurs éphémères (claude.ai) : surcoût d’isolation = démarrage de conteneur ; dépendance à l’utilisateur = aucune ; rayon d’impact = conteneur côté serveur protégé par gVisor + frontières de l’infrastructure hôte
  • Sandbox HITL (Claude Code) : surcoût d’isolation = sandbox native à faible latence ; utilisateur = doit savoir interpréter bash ; rayon d’impact = espace de travail local
  • VM scellée (Claude Cowork) : surcoût d’isolation = démarrage complet de VM ; dépendance à l’utilisateur = aucune ; rayon d’impact = espace de travail monté protégé par frontières vsock + hyperviseur

Faire confiance à ce que lit l’agent

  • Les entreprises interrogent souvent la sécurité des connexions MCP, mais la bonne question est plus large et ne se limite pas à MCP — les ressources externes portent à la fois un risque d’exécution de code (côté supply chain) et un vecteur de prompt injection
    • Les audits classiques de dépendances (versions figées, vérification de signature, revue du code source) ne traitent que le premier risque et laissent le second de côté
  • La différence entre distant et local est plus importante qu’elle n’en a l’air — les outils locaux peuvent être audités, figés en version et restent stables, tandis que les outils distants (serveurs MCP hébergés, connecteurs cloud) peuvent changer de comportement à tout moment après approbation, rendant caduque la décision de confiance prise à l’installation
    • Le connector directory compense cela par une revue continue, mais tout le reste doit être considéré comme non fiable et testé d’abord avec de fausses données dans un environnement au rayon d’impact confiné
  • La sortie d’un outil reste une surface d’attaque, même si l’outil est lui-même de confiance — c’était le cas de l’exemple précédent avec le README GitHub ; les mêmes mécanismes de scan appliqués aux pages web doivent aussi s’appliquer aux résultats des outils connectés au réseau
    • Une fois qu’un retour d’outil contaminé pousse l’agent à exfiltrer des données, les logs ne montrent plus que des appels API autorisés ayant réussi, sans signal postérieur utile ; il faut donc privilégier l’inspection en direct, même si elle ajoute de la latence et reste imparfaite
    • Dans Claude Code et Cowork, les appels d’outils passent par des proxys imposant les politiques réseau et fichiers, et les classifieurs chargés de l’inspection peuvent être de petits modèles rapides, sans nécessiter un modèle de raisonnement

Chantiers à venir

  • Persistent memory poisoning (empoisonnement de mémoire persistant) : à mesure que les contextes conservés entre sessions se multiplient (mémoire produit, fichiers CLAUDE.md, espaces de travail montés, répertoires d’état d’agents planifiés ou longue durée), une injection introduite à cet endroit sera rechargée à chaque démarrage de l’agent — de très bons classifieurs au lancement de session devront devenir bien plus courants
  • Multi-agent trust escalation (escalade de confiance multi-agent) : des sous-agents peuvent renvoyer des faits structurés plutôt que du texte brut, ce qui peut isoler les contenus non fiables ; mais si l’on traite la sortie d’un sous-agent comme plus digne de confiance qu’un résultat d’outil brut simplement parce qu’il est « à nous », on crée un nouveau vecteur d’injection — il existe donc un arbitrage entre différenciation des niveaux de confiance et exposition à l’escalade de confiance
  • Agent identity (identité de l’agent) : Cowork conserve les identifiants dans le trousseau de l’hôte et fournit à la VM des jetons réduits par session, révocables indépendamment de l’utilisateur
    • Mais la question de l’identité multi-plateforme reste ouverte : l’agent doit-il avoir sa propre identité de sujet, ou hériter des droits de l’utilisateur comme une extension de celui-ci ? Une réponse hybride est possible
  • Comme ces types d’échec risquent de se répéter dans l’ensemble du secteur et des laboratoires, il faut un investissement collectif dans une posture de sécurité propre aux agents : benchmarks partagés, normes publiques, standards d’identité communs et red teams inter-fournisseurs

Récapitulatif des principes clés

  • Concevoir d’abord le confinement au niveau de l’environnement, puis ajuster le comportement au niveau du modèle — les deux incidents les plus instructifs (phishing d’employé et divulgation tierce liée à une allowlist) étaient tous deux des cas d’egress où des données sont sorties par des chemins autorisés ; dans ce type de situation, la couche modèle n’a aucun signal anormal à détecter, et la frontière déterministe constitue la dernière ligne de défense
  • Adapter la force de l’isolation à la capacité de supervision de l’utilisateur — un développeur capable de lire du bash et un travailleur du savoir qui ne le peut pas n’ont pas le même modèle de menace ; échouer dans un sens en imposant trop de friction aux experts, ou dans l’autre en accordant trop de confiance aux non-spécialistes, mène dans les deux cas à l’échec
  • Se méfier des composants sur mesure — les hyperviseurs éprouvés, filtres de syscalls et runtimes de conteneurs ont subi bien davantage d’épreuves adversariales ; dans tous les déploiements, les primitives standard ont tenu, tandis que les éléments développés autour ont révélé les failles
  • Même si les agents constituent une nouvelle catégorie logicielle, leurs interactions au niveau système (lecture de fichiers, ouverture de sockets, création de processus) ne sont pas nouvelles ; le confinement via des outils matures demeure donc une défense centralement efficace

À lire aussi

1 commentaires

 
GN⁺ 5 시간 전
Commentaires sur Hacker News

  • Le cadrage employé est amusant et le petit graphique est parfaitement bien trouvé. Le risque de préjudice ne diminue pas, mais la récompense augmente, si bien que le préjudice devient un coût d’activité justifié par la récompense
    Plus la récompense grandit, plus l’ampleur du préjudice qu’on cherche à justifier augmente. J’ai l’impression que toute la société fonctionne ainsi

    • Si j’ai bien compris, l’argument d’Anthropic revient désormais à dire : « Oui, cela peut détruire une partie de votre infrastructure, mais cela en vaut la peine »
      Le problème, c’est que personne n’a réellement démontré que cela valait suffisamment le coût pour l’accepter. C’est une hypothèse assez fragile
    • Toute action implique un calcul risque/récompense, et d’ordinaire on ne le voit simplement pas représenté de manière aussi explicite. Même se lever le matin comporte le risque de tomber et de se cogner la tête au sol, traverser la rue comporte le risque de se faire renverser par un bus, et manger comporte le risque de s’étouffer
      Il en va de même pour la sécurité informatique. Le seul ordinateur vraiment sûr est celui qu’on n’allume pas, et même dans ce cas quelqu’un peut toujours s’introduire et voler le support de stockage. Indépendamment de savoir si, ici, le dommage potentiel dépasse le bénéfice, ce calcul existe toujours, donc je pense qu’il est juste de dire que l’ensemble de la société fonctionne ainsi
    • Quand on lance une activité de réparation de PC, au début, perdre une barrette de RAM ou griller la carte mère d’un client alors qu’on traite 10 interventions par semaine représente un coût énorme. Mais quand on en traite 1 000 par semaine, c’est une activité tout à fait rentable et ces pertes deviennent faciles à absorber
      Quand les outils et le débit de traitement augmentent, les proportions changent
    • Dans la réalité, la prise de décision fonctionne comme ça. Le rapport risque/récompense existe bel et bien
    • La responsabilité limitée transforme l’acceptation d’un risque illimité en choix rationnel. L’IA ne fait qu’amplifier ce modèle d’entreprise et raccourcir le temps jusqu’à la prochaine catastrophe

  • Je suis extrêmement sceptique face à ce que dit Anthropic. À l’approche d’une IPO, l’incitation est trop forte à faire paraître le produit dangereux, donc « compétent », « digne de la science-fiction » et « en avance sur tout le monde »
    On a déjà vu ça auparavant. Souvenez-vous de cette histoire selon laquelle « si on le menace, le modèle utilise les e-mails d’un ingénieur pour faire du chantage avec une liaison extraconjugale » : ce n’était que de la fanfiction. En réalité, ils ont seulement construit un scénario à partir de quelques éléments puis demandé au modèle de poursuivre l’histoire. Si vous demandez à Claude comment voler les joyaux de la Couronne britannique, il vous donnera des idées. Cela ne signifie pas pour autant que le modèle est suffisamment dangereux pour qu’il faille renforcer la sécurité de la Tower of London. À mon avis, les autres cas de marketing par la peur sont globalement du même ordre

    • Il est exact de dire qu’« en réalité, ils ont seulement construit un scénario à partir de quelques éléments puis demandé au modèle de poursuivre l’histoire ». C’est précisément le cœur de la recherche. Anthropic précise dès le début de son explication de l’observation du test de chantage qu’il s’agit d’un scénario de test utilisant une entreprise fictive
      “In another cluster of test scenarios, we asked Claude Opus 4 to act as an assistant at a fictional company”
      https://www.anthropic.com/claude-4-system-card
    • Anthropic m’inquiète plus qu’OpenAI parce qu’ils sont trompeurs
    • OpenAI, Google et les autres n’emploient pas « cette stratégie ». Je crois sincèrement que les gens d’Anthropic se soucient réellement de la sécurité de l’IA
      C’était même l’une des principales raisons de la création de l’entreprise. Cela dit, avec l’arrivée de nouvelles recrues et de nouveaux capitaux, il est possible que cet idéalisme s’affaiblisse

  • J’arrive tard dans ce fil, mais l’article semble passer sous silence les risques, erreurs et incidents pouvant survenir avec le « pattern 1 », où l’accès de Claude est limité à un conteneur. C’est toujours difficile à faire correctement
    Par exemple, Anthropic a déployé à plusieurs reprises des bugs permettant à une session claude.ai/code isolée dans un conteneur temporaire d’accéder à toutes les autres sessions de l’utilisateur, aux dépôts connectés et aux variables d’environnement, puis d’en exfiltrer le contenu. Un Claude devenu malveillant ou compromis pouvait aussi créer de nouvelles sessions Claude dotées d’instructions arbitraires et de droits d’accès, indépendamment des contraintes de la session d’origine. J’ai écrit pour la première fois à ce sujet en février avec autorisation[1], et la plupart des problèmes ont été corrigés rapidement. Mais le problème fondamental de portée des tokens s’est reproduit à plusieurs reprises, y compris après Mythos, donc il est difficile de considérer qu’Anthropic l’a réellement résolu
    [1]: https://www.noahlebovic.com/hacking-claude-code-on-the-web-b...

  • De manière générale, c’est vraiment difficile à faire. Malheureusement, le billet de blog mentionne quelques exemples, mais sans approfondir à quel point c’est difficile
    Par exemple, si vous exécutez un agent dans une VM ayant un accès réseau, quelque chose qu’il y rencontre peut, via une injection de prompt, amener l’agent à encoder une injection de prompt de second niveau dans une sortie qui quittera la VM, ce qui peut ensuite infecter un agent local plus privilégié. Dans mon précédent emploi, lorsque nous analysions l’usage d’ordinateurs, nous examinions si l’on pouvait faire confiance aux entrées utilisateur comme non malveillantes. Si l’utilisateur les a tapées lui-même, c’est généralement acceptable, mais qu’en est-il des fichiers utilisateur ? Des événements du calendrier ? Comme l’objectif même du produit était que l’agent gère cela à la place de l’utilisateur, on ne pouvait plus supposer l’absence d’injection. Dès qu’on commence à faire ce type de suivi de contamination, on se rend vite compte qu’il est extrêmement difficile d’empêcher ce genre de choses, et qu’entourer simplement le tout d’un sandbox ou d’une VM n’aide généralement pas beaucoup

  • Je suis toujours satisfait de ma configuration d’isolation sous Linux[1][2]. Parmi les risques évoqués dans l’article, celui qui s’applique ici est surtout la « fuite via des domaines autorisés ». Mais, par conception, il n’y a dans la VM rien à exfiltrer en dehors du code source lui-même, et aujourd’hui le code source a moins de valeur qu’autrefois
    Le grand avantage de cette configuration, c’est que l’agent peut effectuer toutes les tâches de développement que je peux faire moi-même, par exemple installer des paquets ou construire/exécuter des images Docker. La boucle est bien plus rapide que si je devais tout tester manuellement puis faire un compte-rendu à l’agent
    [1] https://blog.emilburzo.com/2026/01/running-claude-code-dange...
    [2] https://news.ycombinator.com/item?id=46690907

    • L’agent peut se faire piéger et utiliser une bibliothèque malveillante dans le projet, puis la commit et la pousser. Cela devient dangereux si l’utilisateur l’exécute ensuite hors de la VM
      Si vous exécutez le code du dépôt hors de la VM sans relire tout ce qui a été commité, cela reste risqué

  • Quand on regarde de près Cowork VM, la contamination n’est ni documentée ni contrôlée publiquement. J’ai des contournements, mais cela génère beaucoup de perte de temps et de frustration au passage
    CLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1 signifie que Claude recherche et charge au fil du temps les fichiers CLAUDE.md de tous les dépôts montés, selon la configuration. Du coup, l’expérience par défaut n’est pas bonne si l’on travaille en parallèle sur plusieurs dépôts sans rapport entre eux
    Quelques variables d’environnement intéressantes de la VM :
    CLAUDE_CODE_IS_COWORK=1
    CLAUDE_CODE_BRIEF=1 CLAUDE_CODE_BRIEF_UPLOAD=1 CLAUDE_CODE_DISABLE_AUTO_MEMORY=1 CLAUDE_CODE_DISABLE_BACKGROUND_TASKS=1 CLAUDE_CODE_DISABLE_CRON=1
    CLAUDE_CODE_ENTRYPOINT=local-agent CLAUDE_CODE_EXECPATH=/usr/local/bin/claude CLAUDE_CODE_HOST_HTTP_PROXY_PORT=36543 CLAUDE_CODE_HOST_PLATFORM=darwin CLAUDE_CODE_HOST_SOCKS_PROXY_PORT=46673
    USE_STAGING_OAUTH= _=/usr/bin/env all_proxy=socks5h://localhost:1080 ftp_proxy=socks5h://localhost:1080 grpc_proxy=socks5h://localhost:1080 http_proxy=http://localhost:3128 https_proxy=http://localhost:3128 no_proxy=localhost,127.0.0.1,::1,.local,.local,169.254.0.0/16,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16

  • À propos de la phrase « plus l’agent devient compétent, plus son rayon d’explosion potentiel grandit ; la question d’ingénierie est de savoir comment le limiter », je sais que beaucoup de gens sont mal à l’aise quand on anthropomorphise les LLM, mais ce qui est pire encore, c’est de faire comme si les LLM pouvaient s’échapper en douce sur Internet et commencer à se répliquer comme dans une logique de film de science-fiction

    • Le vrai problème, c’est qu’on entraîne les modèles à résoudre des problèmes et à suivre les instructions données. Si on leur demande de faire quelque chose, ils peuvent suivre leur logique et conclure que la façon la plus simple d’y parvenir est de supprimer la base de données de production ; s’ils ont les accès, ils peuvent fouiller tous les identifiants, trouver les identifiants de la base de données et la supprimer réellement
      Leur capacité à faire ce genre de choses progresse, et ils deviennent aussi meilleurs pour suivre des instructions, mais ils ne savent pas toujours suivre toutes les instructions ni se comporter de manière sensée. Plutôt que de s’échapper pour se répliquer comme une masse visqueuse, le risque est qu’en leur donnant davantage d’accès, ils finissent à un moment donné par conclure logiquement qu’ils doivent faire quelque chose que l’utilisateur ne voulait pas. Soit parce que ce n’était pas explicitement interdit, soit parce que le contexte devient si complexe que le poids de cette instruction diminue et qu’ils en suivent une autre. J’ai déjà vu un cas où le modèle a conclu qu’il lui fallait une clé API pour accéder à un service afin d’accomplir une tâche réelle. Le modèle n’avait pas cette clé, mais l’utilisateur, lui, pouvait y accéder depuis le navigateur. Il a donc écrit un script Python pour récupérer les cookies du navigateur. Le problème n’était pas le sandboxing de l’agent ; c’est CrowdStrike qui a bloqué la chose en n’aimant pas qu’un script Python inconnu tente de récupérer les cookies du navigateur
    • Pourquoi pas ? Tant qu’on ne parle pas d’exécuter le modèle lui-même, un agent IA peut écrire un ver d’agents qui propage davantage d’agents en exploitant des vulnérabilités logicielles
      Aujourd’hui, les LLM demandent trop de matériel pour que le modèle lui-même se propage facilement, mais avec quelques années et de l’optimisation, on verra peut-être aussi cela. Cela me rappelle l’époque où l’on disait que « les images ne peuvent pas propager de virus ». Puis des vulnérabilités de décodeur ont été découvertes, et de vrais virus via des images ont effectivement été créés
    • Dès qu’on anthropomorphise les LLM, ils semblent clairement cassés par conception, mais je pense que le logiciel tel qu’on le connaissait évolue lui aussi vers une forme de « présence anthropomorphisée ». J’ai laissé une note à ce sujet dans [1], générée par IA
      Il y a aussi une tendance intéressante où les marques les plus anthropomorphisées deviennent plus dominantes. Claude et Doubao face à ChatGPT et DeepSeek, par exemple
      [1] https://github.com/NascentCore/agentic-suite/tree/main/perso...

  • J’utilise une VM qemu. Cette VM a accès à Internet, et le plus grand risque me semble être que Claude puisse téléverser des données quelque part
    Pour lui permettre de travailler avec GitHub, je crée des tokens limités au niveau du dépôt, en lecture seule ou en lecture/écriture. Malgré cela, je préfère lui permettre seulement de commit plutôt que de pousser, puis récupérer les commits en SSH depuis la VM, vérifier les logs et pousser moi-même. J’ai aussi envisagé d’exécuter Claude dans un conteneur, mais cela me semble un peu léger. Il y a trop de vulnérabilités Linux. Cette crainte est peut-être infondée, mais j’ai le sentiment que faire tourner quelque chose de non fiable dans une VM qemu est plus sûr

  • J’ai récemment bricolé en urgence une petite fonction utilitaire qui lance un processus avec bubblewrap, en ne lui donnant un accès en lecture/écriture qu’au répertoire d’exécution et en mettant le reste en lecture seule. Quelques répertoires système Linux spécifiques restent en exception pour que l’interface graphique et des éléments comme libportal fonctionnent.
    C’est bien moins pénible qu’un conteneur pour les tâches où l’on veut que l’agent puisse réellement pointer vers des éléments arbitraires disséminés un peu partout, comme des captures d’écran ou des fichiers de logs, sans pour autant avoir à surveiller et approuver manuellement à chaque fois. Il est assez étrange que les plateformes d’outils IA n’investissent pas déjà là-dedans. Si j’en suis venu à faire ça, c’est à cause de Zed. C’est un éditeur pensé autour du travail avec l’IA, mais il ne permet de définir les autorisations de chemins de l’agent que dans le fichier de configuration global de l’utilisateur. Il existe bien un fichier de configuration au niveau du projet, mais pour une raison incompréhensible, les réglages d’autorisations de l’agent n’y sont pas explicitement pris en charge.

  • Je ne suis pas théoricien de la décision, mais je pense qu’il ne faut pas attendre le moment où la récompense et le dommage attendu deviennent statistiquement équivalents : il faut attendre que la récompense en valeur attendue dépasse le dommage.

    • La chance sourit aux audacieux