Comment un dépôt tiers peut détourner Claude Code : 7 règles de protection

Documentation Ailoot : API, clés et configuration.

Quatre chemins documentés du texte non fiable aux actions de l’agent#

Le terme formel est « injection indirecte de prompt » : une instruction malveillante ne vient pas directement de vous, mais des données que l’agent traite pendant une tâche — un README d’un tiers, un message d’erreur, un commentaire GitHub ou une réponse d’un service externe. Vous pouvez oublier ce terme dès la fin de ce paragraphe ; à partir de maintenant, j’emploierai des mots simples.

Quatre exemples de recherche présentés ci-dessous :

1. Un dépôt à l’apparence inoffensive peut se transformer en shell inversé.
2. Le titre d’une Pull Request a été montré comme pouvant détourner trois agents IA différents à la fois.
3. Un agent a été montré comme pouvant accepter un faux rapport d’erreur Sentry à la place d’un vrai.
4. Microsoft a lancé un avertissement sans détour : la description d’un outil MCP peut contrôler votre agent aussi efficacement qu’un prompt système.

Comment le README d’un dépôt inoffensif se transforme-t-il en shell inversé ?#

Le mécanisme est conçu de sorte qu’aucune étape prise isolément ne semble suspecte :

1. Vous clonez un dépôt d’apparence ordinaire et demandez à Claude Code de l’exécuter.
2. Le dépôt inclut un package Python conçu pour échouer lors de sa première utilisation.
3. Le message d’erreur suggère poliment une commande de « correction » : python3 -m axiom init.
4. La commande init exécute setup.sh.
5. Le script interroge un enregistrement DNS TXT (généralement utilisé pour des notes liées à un domaine, mais qui peut contenir n’importe quel texte). L’attaquant y place une commande encodée en base64 (un moyen de convertir n’importe quelles données en texte brut sans espaces ni caractères spéciaux) et l’envoie directement à bash.
6. La valeur de l’enregistrement DNS peut être modifiée à tout moment, ce qui donne à l’attaquant un shell inversé interactif avec vos droits d’utilisateur et l’accès à tous les secrets de la machine.

La démonstration récupérait le payload final dans DNS à l’exécution : analyser seulement les octets du dépôt ne le révélait pas. Cela ne prouve pas tout scanner ou contrôle impuissant : contenu récupéré, surveillance des processus et restrictions réseau peuvent révéler ou interrompre la chaîne. La source est une preuve de concept, pas une mesure de fréquence d’incidents.

Comment un titre de Pull Request a-t-il détourné trois agents IA différents ?#

Le rapport décrit ces chemins et réponses : c’est un historique de recherche, pas une vérification de toutes les versions actuelles :

Près de cinq mois se sont écoulés entre le premier et le dernier rapport de ce cycle de divulgation (le premier rapport sur Claude Code date du 17 octobre 2025 ; le dernier correctif de bug de GitHub Copilot, du 9 mars 2026). Changement de gravité et mesures décrites ne prouvent pas la clôture de tous les payloads possibles. Le dépôt de preuve de concept documente le chemin Claude démontré ; n’exécutez pas ses charges d’attaque sur de vrais systèmes. Ce qui vous est utile, c’est le schéma d’attaque lui-même : des données GitHub non vérifiées parviennent à l’agent, celui-ci exécute des commandes, et les secrets sont divulgués par ce même GitHub — l’attaquant n’a pas besoin d’un serveur externe.

Deux analyses suffisent pour voir le schéma : il est impossible de corriger séparément chaque nouvelle découverte ; des vulnérabilités de ce type apparaissent toutes les deux semaines. Écrire explicitement les règles de sécurité dans CLAUDE.md et settings.json, au lieu de les garder en tête, fait partie de l’ingénierie du contexte : définissez-les une fois, et elles s’appliquent automatiquement à chaque nouvelle session Claude Code, sans rappel. Trois piliers fonctionnent ensemble : clone IA + Second Brain + ingénierie du contexte — cette combinaison transforme Claude Code, d’un exécuteur qui fait confiance à tout, en un agent doté de règles explicites.

Un faux rapport d’erreur Sentry peut-il prendre le contrôle de votre agent ?#

Cette attaque ne nécessite rien d’autre qu’une clé DSN Sentry — un identifiant public que de nombreux projets incluent directement dans leur code côté client :

Le mécanisme est simple : un développeur demande à l’agent d’examiner les erreurs Sentry ouvertes ; l’agent les récupère via le serveur MCP, reçoit un événement malveillant mêlé aux événements réels et lit la commande qu’il contient comme une instruction de confiance pour corriger l’erreur — car, formellement, c’est bien la tâche qui lui a été confiée.

Tenet indique que les contrôles de ses environnements n’ont pas alerté. Cela ne prouve pas une absence universelle de traces : journaux d’agent et d’outils, télémétrie du poste et réseau peuvent enregistrer les actions. L’entrée vient de télémétrie externe, puis dépend des outils et droits effectifs.

Comment les métadonnées MCP peuvent-elles influencer l’agent ?#

La formulation de Microsoft est la plus précise que j’aie trouvée sur le sujet :

Cette technique, appelée empoisonnement d’outil, consiste à cacher une instruction dans la description d’un outil anodin pour amener l’agent à agir en conséquence.

L’observation de MCPTox selon laquelle certains modèles plus capables peuvent être plus sensibles appartient à ce benchmark ; ce n’est pas une loi universelle ni une mesure de protection de votre installation.

Qu’ont en commun ces attaques, et que peut manquer la détection ?#

La conclusion s’applique aux quatre découvertes : on ne peut pas se fier au fait que « le code semble normal » — chaque étape prise individuellement est effectivement inoffensive. Limitez les capacités effectives et inspectez les actions proposées ; détection et confinement visent différentes étapes.

Quelles protections Claude Code possède-t-il déjà, et pourquoi ne suffisent-elles pas ?#

Anthropic reconnaît directement le problème dans sa documentation, au lieu de le dissimuler :

Selon la documentation, l’agent analyse l’ensemble du prompt pour repérer les instructions suspectes, n’approuve pas automatiquement curl et wget, garde le contenu Web dans une fenêtre de contexte distincte pour éviter de le mélanger au contexte principal, et demande une confirmation de confiance la première fois que vous le lancez dans une nouvelle base de code ou que vous connectez un nouveau serveur MCP.

Mais Anthropic énonce sans détour une réserve importante :

Si vous avez déjà lancé Claude Code avec --dangerously-skip-permissions par irritation, pour qu’il « arrête de poser des questions », vous avez désactivé précisément les mécanismes qui auraient pu arrêter les quatre attaques évoquées plus haut. Je laisse délibérément cette option désactivée, même lorsque Claude Code repose la question pour la dixième fois au cours d’une session : c’est agaçant, mais ces questions forment la frontière entre « l’agent a lu un texte suspect » et « l’agent l’a exécuté ». Pour une personne qui ne programme pas, une configuration raisonnable consiste à utiliser le mode d’autorisation standard (default ou acceptEdits) avec la sandbox activée : les modifications ordinaires de fichiers s’effectuent sans question supplémentaire, tandis que les commandes du terminal ne peuvent physiquement pas sortir de la sandbox, même si l’agent a été piégé.

Comment activer le mode sandbox et combler la lacune qu’il laisse ouverte par défaut ?#

Pour l’activer définitivement dans tous les projets, apportez une modification à ~/.claude/settings.json :

{
  "sandbox": { "enabled": true }
}

Par défaut, les commandes dans la sandbox ne peuvent écrire que dans le répertoire de travail du projet et le répertoire temporaire de la session. L’accès réseau passe par un proxy : aucun domaine n’est autorisé à l’avance, et Claude Code demande confirmation lorsqu’il contacte un nouveau domaine pour la première fois. Anthropic indique que cela réduit fortement les demandes d’autorisation — de 84 % selon les mesures internes de l’entreprise — car la sandbox traite elle-même certains cas sûrs au lieu de vous demander confirmation à chaque fois.

La lacune des paramètres standard : par défaut, la sandbox restreint l’écriture, mais n’empêche pas la lecture de fichiers tels que ~/.aws/credentials et ~/.ssh. Ces fichiers et variables d’environnement peuvent être ciblés dans des attaques par injection. Comblez cette lacune en ajoutant un bloc distinct dans le même fichier :

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

L’idée est que, même si le shell inversé de la première analyse s’ouvre dans la sandbox, ces variables et fichiers sont physiquement retirés de l’environnement du processus avant son démarrage : il ne reste rien à voler.

Quelles règles permissions.deny ajouter dès aujourd’hui ?#

Un ensemble minimal pour une personne qui ne programme pas et qui couvre d’un coup les principales cibles des quatre attaques :

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/credentials)",
      "Read(.env)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(sudo *)"
    ]
  }
}

Selon la documentation de Claude Code, les règles deny ont toujours priorité sur les règles allow. Ainsi, même si vous (ou l’agent lui-même) autorisez accidentellement un accès plus large ailleurs, une règle deny précise s’applique en premier. Cette priorité vise les requêtes d’outil correspondantes. Elle ne prouve pas qu’un secret est inaccessible à tout sous-processus ou outil ; imposez aussi des restrictions de fichiers et d’environnement.

Claude Code propose aussi un mode auto, dans lequel un modèle de classification distinct vérifie les actions avant leur exécution — ce n’est pas le même modèle que celui qui converse avec vous. Par défaut, il bloque notamment le schéma « télécharger du code et l’exécuter immédiatement » (curl | bash). Anthropic avertit explicitement qu’il s’agit d’un mode de recherche qui réduit le nombre de demandes, mais ne garantit pas la sécurité à lui seul : considérez-le comme une couche supplémentaire, et non comme un remplacement de la sandbox et de permissions.deny.

Comment vérifier un dépôt et un serveur MCP avant de les confier à votre agent ?#

Pour les dépôts, voici une courte liste de vérification avant de les confier à l’agent :

1. Ne passez pas directement à l’installation depuis un lien reçu dans un e-mail, un article ou un avis provenant d’une source inconnue.
2. Si l’installation produit une erreur accompagnée de l’instruction « exécuter la commande X pour corriger le problème », vérifiez ce que fait réellement X avant d’autoriser Claude Code à l’exécuter. L’instruction semblait tout à fait habituelle — c’était justement le but.
3. Vérifiez l’ancienneté du dépôt et l’historique de ses commits, pas seulement le nombre d’étoiles : il est facile d’attribuer de fausses étoiles à des dépôts nouvellement créés.
4. Si le dépôt ne vous est pas familier, effectuez l’installation dans une machine virtuelle, et non sur votre ordinateur de travail avec de vraies clés. C’est la recommandation directe d’Anthropic pour travailler avec des services externes.

La position d’Anthropic sur les serveurs MCP est clairement énoncée :

Cela signifie que la vérification des serveurs MCP tiers vous incombe, et non à la plateforme sur laquelle vous les avez installés. Certaines équipes — principalement des startups spécialisées en sécurité — développent déjà des outils pour cela : des scanners de configuration MCP qui repèrent les descriptions empoisonnées et le « pinning » des outils, qui enregistre le hash de la description lors de la première installation et signale tout changement ultérieur. Ces technologies sont récentes ; il est donc trop tôt pour s’y fier comme unique protection. Elles méritent toutefois d’être suivies, surtout si vous connectez des serveurs MCP à la production. Pour ces connexions, vous pouvez épingler chaque version de package et enregistrer l’empreinte des descriptions d’outils dans un journal d’audit.

7 règles de protection : la liste de vérification du jour#

1. Activez le mode sandbox (/sandbox ou "sandbox": {"enabled": true} dans ~/.claude/settings.json) et ajoutez un bloc credentials qui empêche la lecture de ~/.ssh et de ~/.aws/credentials.
2. Ajoutez des règles permissions.deny pour la lecture des fichiers secrets et les commandes bash dangereuses (curl, wget, sudo) : une règle deny a toujours priorité sur une règle allow.
3. N’utilisez jamais --dangerously-skip-permissions avec du code tiers ou non vérifié : cette option désactive toutes les protections à la fois, y compris celles qui auraient pu arrêter précisément ces attaques.
4. Ne laissez pas Claude Code exécuter automatiquement une commande de « correction » provenant d’un message d’erreur : vérifiez d’abord ce qu’elle fait réellement.
5. Installez des serveurs MCP uniquement à partir de sources auxquelles vous faites confiance, et rappelez-vous qu’Anthropic ne vérifie pas leur sécurité à votre place.
6. Séparez les sessions selon leurs autorisations : l’une travaille avec vos données personnelles et ne voit aucune donnée externe ; une deuxième examine les e-mails, dépôts et tickets d’autres personnes, mais n’a pas accès aux secrets ; une troisième publie à l’extérieur — et uniquement ce que vous avez personnellement approuvé. Je maintiens cette séparation stricte dans mes propres projets : une session qui a accès aux clés de paiement ne lit jamais des tickets ou dépôts externes quelconques, et une session qui analyse le code d’autres personnes ne voit aucun secret. Ne mélangez pas ces rôles dans un même chat.
7. Maintenez Claude Code et les scripts d’automatisation connectés à jour : la plupart des lacunes évoquées ici avaient déjà été corrigées par des correctifs au moment de la publication de ce guide, et les nouvelles sont corrigées de la même manière.

Que faire ensuite#

Aucune de ces couches n’offre de garantie : Anthropic reconnaît elle-même franchement qu’aucune protection n’assure une immunité complète. Je ne m’attends pas à ce que Claude Code reconnaisse de lui-même un piège dans un message d’erreur ou un commentaire d’issue. Pour moi, la sandbox et permissions.deny font partie de la gestion du contexte de projet : ce que l’agent voit, ce qu’il considère par défaut comme fiable et ce qui se passe lorsqu’il commet une erreur.

Si vous avez besoin d’accéder aux réseaux neuronaux via Ailoot, découvrez Ailoot.