Sécurité, secrets et données sensibles
- arrow_forwardcapable d'identifier les vecteurs de fuite de secrets dans un workflow AI-first
- arrow_forwardcapable d'établir des règles claires sur ce qu'on ne met jamais dans le contexte d'un agent
Sécurité, secrets et données sensibles
Le workflow AI-first introduit une surface d'attaque que le développement traditionnel ne connaît pas : le contexte de l'agent. Tout ce que vous mettez dans une spec, un CLAUDE.md, ou un message à l'agent est traité comme du texte et peut être loggué, mémorisé, ou transmis. La règle est simple et sans exception.
La règle cardinale
Rien de secret n'entre dans le contexte d'un agent.
Pas de clé API. Pas de mot de passe. Pas de token. Pas de contenu de fichier .env. Pas de chaîne de connexion à la base de données. Pas de données personnelles d'utilisateurs réels.
Le contexte n'est pas votre terminal. C'est du texte envoyé à un service externe.
Le contexte d'un agent est une frontière de sécurité. Ce qui entre dans le contexte peut sortir — dans les logs, dans les données d'entraînement futurs, dans une réponse mal formulée. Traitez le contexte comme un canal non chiffré : n'y mettez que ce qui pourrait être public.
Les vecteurs de fuite les plus courants
1. Le fichier .env collé dans une spec
Scénario : vous écrivez une spec pour une intégration Stripe et vous collez le fichier .env "pour que l'agent comprenne la configuration disponible". La clé Stripe est maintenant dans le contexte.
Alternative correcte : décrire les variables d'environnement par leur nom uniquement.
"L'application utilise
STRIPE_SECRET_KEY(string, disponible en environnement). Ne pas hardcoder de valeur."
2. Les données de production dans les exemples
Scénario : pour illustrer le format de données attendu, vous collez une ligne de votre table users en production. Elle contient un vrai email, un vrai nom.
Alternative correcte : fabriquer des données fictives explicitement.
"Format :
{ id: 'usr_abc123', email: 'alice@example.com', name: 'Alice Example' }(données fictives)"
3. Le schéma de base de données avec des migrations sensibles
Schémas Drizzle ou Prisma : le schéma lui-même (types, colonnes, relations) est généralement safe. Ce qui ne l'est pas : les fichiers de migration qui contiennent des données de seed réelles, ou des commentaires qui révèlent des décisions d'architecture sensibles ("cette colonne cache le fait que…").
4. L'historique git comme vecteur
Si un secret a été commité — même dans un commit que vous avez ensuite réverté — il est dans l'historique git. Si vous donnez accès à votre repo à un agent (certains workflows le font), ce secret est accessible. Révoquez immédiatement tout secret commité, même brièvement.
Règle concrète à encoder dans CLAUDE.md :
## Sécurité
- Ne jamais générer de secrets, tokens ou clés en dur dans le code
- Les variables d'environnement sont référencées par nom uniquement (ex: process.env.STRIPE_SECRET_KEY)
- Si tu as besoin d'une valeur de configuration pour générer du code, demande-moi le NOM de la variable, pas sa valeur
- Aucune donnée d'utilisateur réel dans les exemples ou fixtures de test
Quand l'agent produit du code avec un secret hardcodé
Cela arrive — l'agent "complète" un exemple avec une valeur fictive qui ressemble à une vraie clé.
Procédure :
- Ne pas commiter le fichier
- Vérifier si la valeur est une vraie clé (cherchez le format dans la doc du service)
- Si réelle : révoquer immédiatement via la console du service, même si le fichier n'a jamais quitté votre machine
- Corriger la spec pour interdire explicitement ce comportement
- Relancer l'agent
Coller un dump de base de données, même partiel, dans un contexte d'agent pour "montrer la structure des données" est une faute de sécurité grave si la table contient des données personnelles. Utilisez toujours des données fictives et anonymisées pour illustrer les formats. Les données de production restent en production.
Auditez vos specs récentes et votre CLAUDE.md actuel. Cherchez : des noms de variables qui ressemblent à des clés réelles, des exemples de données qui pourraient être réels, des références à des fichiers de configuration avec leurs valeurs. Notez ce que vous trouvez. Rédigez une section "Sécurité" pour votre CLAUDE.md qui interdit explicitement ces pratiques.
Vérifiez votre compréhension
3 questions · répondez puis validez.