Sécurité et confidentialité

Comment gérer les clés, quelles données éviter d’envoyer et quelles sont les limites de ce service.

Gestion des clés

• Les clés ne sont affichées intégralement qu’une seule fois. Stockez-les dans un gestionnaire de secrets ou une variable d’environnement.
• Utilisez une clé par service ou par machine pour permettre une révocation ciblée.
• La révocation prend effet immédiatement.
• Ne placez jamais de clé dans du JavaScript côté client, un binaire mobile ou un dépôt public. Tout ce qui est distribué à un utilisateur est public.
• Si une clé est divulguée, révoquez-la d’abord et enquêtez ensuite.

Données à éviter d’envoyer

Cette passerelle tierce se situe entre vous et le fournisseur en amont. Traitez-la comme un prestataire de traitement externe :

• N’envoyez pas de données que votre contrat vous interdit de partager avec un sous-traitant ultérieur.
• N’envoyez pas de données réglementées — dossiers médicaux, numéros de carte de paiement, identifiants officiels — sans fondement juridique pour le faire.
• Masquez les secrets avant d’envoyer des journaux ou des fichiers de configuration à un modèle. Les agents qui lisent des fichiers entiers liront sans hésiter votre .env.

Injection de prompt

Tout contenu lu par le modèle peut tenter de lui donner des instructions : pages web, fichiers, résultats d’outils, commentaires de tickets. Les conséquences dépendent de ce que le modèle peut *faire* ; limitez donc ses possibilités d’action :

• Attribuez aux outils de base de données un rôle en lecture seule.
• Limitez les autorisations des tokens API au strict nécessaire.
• Exigez une approbation humaine pour les actions irréversibles.
• Ne faites jamais eval sur la sortie du modèle et n’exécutez jamais de SQL généré via une connexion autorisant l’écriture.

Transport

Tout le trafic utilise HTTPS. Refusez le protocole HTTP non chiffré dans la configuration de votre client ; une URL de base telle que http:// enverrait votre clé en clair.