Aller au contenu
Mastering Claude

Accueil / Sécurité et données

Sécurité et données9 minApplication

Ce qu'un agent peut faire fuiter sans qu'on le lui demande

Une injection de prompt indirecte dissimule une instruction dans un contenu que l'agent lit plutôt que dans ce que vous avez tapé, un fichier généré n'a pas d'auteur qui s'engage sur son contenu, et une règle de configuration qui cible un chemin de fichier est acceptée sans erreur tout en ne bloquant rien pour l'outil qui exécute des commandes directes, alors qu'une règle qui cible le nom de cet outil bloque réellement.

Une instruction cachée dans un contenu que Claude lit, une page web récupérée par un outil, un fichier joint, une ligne de commentaire dans un dépôt, peut lui faire exécuter autre chose que ce que vous avez tapé. C'est la même injection de prompt que la leçon précédente décrit à propos d'une compétence tierce, mais sous sa forme indirecte : la source n'est plus un paquet installé, c'est n'importe quel contenu récupéré pendant la conversation.

Les protections documentées, et leur limite annoncée

La documentation officielle de Claude Code nomme plusieurs protections actives contre ce risque : un système de permission, une analyse contextuelle, l'isolation de la fenêtre de contexte pour l'outil qui récupère une page web, et une vérification de confiance au premier lancement d'un dépôt. La même page pose elle-même sa limite : ces protections réduisent significativement le risque, sans qu'aucun système reste complètement immunisé contre toute attaque.

Une règle qui se lit comme une protection et n'en est pas une

Un paramètre du fichier de configuration personnel permet de refuser l'accès à des chemins précis pour les outils qui lisent ou écrivent un fichier. Une confusion documentée publiquement montre pourquoi ce paramètre seul ne suffit pas : l'outil qui exécute des commandes directes ne vérifie, dans les règles de permission, que la présence du nom de cet outil, pas les chemins réellement contenus dans la commande tapée.

{
  "deniedPaths": ["/Users/exemple/documents-prives/**"]
}

Ce fichier s'enregistre sans erreur de syntaxe. Il bloque effectivement une lecture ou une écriture de fichier passant par les outils dédiés à cela. Il ne bloque rien du tout quand la même donnée est atteinte par une commande directe, parce que la règle cible un chemin et pas le nom de l'outil. Ce constat, rendu public, reste classé comme une limite de conception plutôt que comme une faille à corriger.

Ce qu'un fichier généré ne signe jamais

Un fichier produit automatiquement par un outil, un résumé, un graphe de connaissance, un rapport assemblé à partir de plusieurs sources, n'a pas d'auteur au sens où une personne s'engage sur son contenu. Personne ne se sent responsable de vérifier ce qu'il republie, y compris une phrase sensible qu'un outil a parcourue sans distinguer son niveau de confidentialité de celui du reste. Ce risque n'est pas propre à un produit précis : c'est le défaut général de tout outil qui assemble du contenu sans indiquer sa provenance ligne par ligne.

Figure 1

Une règle par chemin de fichier, une règle par nom d'outil

Cible un chemin de fichier
Regle : deniedPaths contient le dossier prive.
Commande tapee : cat documents-prives/contrat.txt
Resultat : le contenu du fichier s'affiche.
Cible le nom de l'outil
Regle : le nom de l'outil qui execute des commandes est refuse.
Commande tapee : cat documents-prives/contrat.txt
Resultat : commande refusee, aucune sortie.
La différence ne tient pas à la sensibilité du chemin visé mais à ce que le contrôle de permission vérifie réellement : le nom de l'outil employé, jamais les chemins contenus à l'intérieur de la commande tapée.
Calibrez vous-même

Un responsable ajoute, dans le fichier de configuration de son espace Claude, une règle qui cible le chemin de son dossier de documents privés. Le fichier s'enregistre et Claude redémarre avec cette configuration. Le lendemain, il demande à Claude de lister le contenu de ce dossier par une commande directe adressée à l'outil qui exécute des commandes.

Écrivez en une phrase ce que cette situation établit, et en une phrase ce qu'elle n'établit pas.

Ce qu’il faut retenir
  • Une instruction cachée dans un contenu récupéré pendant la conversation, page web, fichier joint, commentaire de dépôt, agit comme une consigne que Claude ne distingue pas automatiquement d'une demande tapée directement.
  • La documentation officielle annonce elle-même que ses protections réduisent le risque d'injection de prompt sans l'éliminer.
  • Une règle de configuration qui cible un chemin de fichier est acceptée sans erreur de syntaxe et ne bloque pourtant rien pour l'outil qui exécute des commandes directes, seule une règle qui cible le nom de cet outil bloque réellement.
  • Ce défaut de la règle par chemin reste classé comme limite de conception connue plutôt que comme faille corrigée, ce qui le rend valable pour toute configuration actuelle et pas seulement pour une version ancienne.
  • Un fichier assemblé automatiquement par un outil n'a pas d'auteur qui s'engage sur son contenu, ce qui explique pourquoi personne ne se sent responsable de vérifier ce qu'il republie avant de le partager plus loin.
À faire maintenant

Ouvrez votre fichier de configuration personnel, ajoutez un chemin sensible à la liste des chemins refusés, puis demandez à Claude d'accéder à ce même chemin par une commande directe plutôt que par l'outil de lecture. Notez si la commande passe ou si elle est bloquée : c'est le seul témoin qui compte, jamais la seule acceptation du fichier sans erreur.

Ce qui reste à vérifier

Ces points dépendent d’une interface ou d’une règle qui peut avoir changé depuis la rédaction. Vérifiez-les sur votre propre écran avant de vous y fier.

  • Le statut fermé et non planifié de l'avis GitHub cité dans cette leçon peut évoluer : vérifiez sur la page de l'issue si un correctif a depuis été annoncé avant de vous fier à une règle qui cible un chemin plutôt qu'un nom d'outil.
Vérifier à la source

Chaque affirmation datable de cette leçon renvoie ici au texte public qui la porte. Une source qui ne s’ouvre pas ne prouve rien.