Accueil

Sécurité et données

1. 01Secrets : ne jamais les faire transiter, ne jamais les afficher en clair8 min

   Un secret collé dans une conversation, même brièvement, reste ensuite présent dans les journaux et dans toute relecture automatique de l'historique, et une commande de configuration lancée pour un motif précis peut afficher un secret voisin en clair si son filtre est trop large.

2. 02Un secret commis est brûlé : rotation immédiate, jamais la date7 min

   Un secret suivi par un dépôt se traite comme compromis à l'instant où il est écrit, pas quand quelqu'un prouve qu'il a été lu, et le remède qui atteint chaque copie est de faire tourner l'identifiant, la réécriture de l'historique venant en second et pas toujours nécessaire.

3. 03Pseudonyme et anonyme, deux choses différentes7 min

   Un numéro à la place d'un nom reste une donnée personnelle tant qu'une table de correspondance existe quelque part, ce qui peut faire du destinataire un sous-traitant selon son rôle réel, et une identité pseudonyme sur un dépôt exige sa propre configuration locale.

4. 04Auditer une compétence avant de l'installer8 min

   Auditez une compétence tierce avant de l'installer : mettez-la en quarantaine, lisez tout son contenu, passez un scanner de sécurité, et faites tourner tout secret qu'une compétence retirée a pu toucher. Le risque le plus fréquent est l'instruction cachée, presque toujours combinée à du code malveillant.

5. 05Ce qu'un agent peut faire fuiter sans qu'on le lui demande9 min

   Une instruction cachée dans un contenu que Claude lit pendant la tâche, page web, fichier ou commentaire de dépôt, peut lui faire proposer une action de sortie que vous n'avez pas demandée : c'est l'injection de prompt indirecte, que les protections documentées réduisent sans l'éliminer.

6. 06Automatisation responsable : réversible d'abord, panne signalée, correctif demandé8 min

   Une automatisation en mode Auto, Accept Edits ou Bypass Permissions exécute la plupart des suppressions au moment où la commande est atteinte, sans confirmation : construisez donc le point de contrôle humain avant la commande destructive. Une panne silencieuse ne s'annonce jamais elle-même, et un correctif bloqué se demande, il ne se note pas.

7. 07Ce qui quitte la machine, ce qu'on archive, ce qu'on ne partage jamais8 min

   Chaque requête envoie le prompt et la réponse sur le réseau et laisse une copie locale lisible en clair sur le disque : un secret collé une fois existe à deux endroits. Archivez plutôt que supprimer, car un déplacement reste annulable. Filtrez un document interne avant de l'envoyer : inventaire des données sensibles, puis relecture en lecteur hostile.

8. 08Lire suffit à exposer un secret8 min

   Une recherche de texte sur un dossier entier renvoie chaque ligne qui contient le motif, même celles d'un fichier .env caché, sans qu'aucune lecture de ce fichier n'ait été demandée. Une règle de refus Read(./.env) ne couvre pas une commande qui lit des fichiers sans les nommer, comme grep -r, ni un sous-processus qui ouvre lui-même ses fichiers.

9. 09Une garde par motif de texte n'est pas une frontière de sécurité9 min

   Une garde qui refuse un mot dans le texte d'une commande juge une écriture et non un effet : toute écriture qui évite ce mot passe, et même une liste de commandes admises à l'égalité exacte laisse passer le code qu'une commande admise lit dans un fichier que l'agent peut modifier.

10. 10Un accord général n'autorise pas un envoi précis8 min

    Un accord donné sur une méthode de travail valide la façon de procéder, pas un envoi dont le contenu n'a pas encore été montré : l'accord d'envoi nomme le texte et les destinataires, ou la catégorie d'envois qu'une autorisation durable désigne elle-même.