# Liste de contrôle de sécurité des grands modèles de langage (LLM)

Utilisez cette liste avant de mettre en production une fonctionnalité fondée sur un LLM qui lit du contenu non fiable, consulte des données privées ou appelle des outils.

## 1. Périmètre du workflow

- [ ] Le responsable du workflow est identifié.
- [ ] Les actions autorisées du workflow sont documentées.
- [ ] Les actions externes, destructrices, financières, juridiques, RH ou visibles par le client sont identifiées.
- [ ] Une procédure documentée permet de désactiver rapidement le workflow.
- [ ] Le workflow prévoit un retour en arrière ou une procédure manuelle de repli.

## 2. Inventaire des entrées non fiables

- [ ] Les entrées directes de l'utilisateur sont traitées comme non fiables.
- [ ] Les documents récupérés sont traités comme des données non fiables, et non comme des instructions.
- [ ] Les sorties des outils sont traitées comme non fiables, sauf si elles sont générées à l'intérieur de la limite de confiance.
- [ ] Les PDF, images, fichiers audio, feuilles de calcul et transcriptions téléversés sont traités comme non fiables.
- [ ] Les pages web et les observations d'un agent de navigation sont traitées comme non fiables.
- [ ] Les prompts modifiables par un administrateur, les modèles de workflow, le contenu du CMS et les sources de connaissances sont examinés avant leur utilisation en production.

## 3. Périmètre des données et de la recherche

- [ ] Les secrets, les identifiants, les jetons bruts et les URL privés ne sont jamais envoyés au modèle.
- [ ] La recherche filtre selon l'organisation, l'utilisateur, le rôle et les autorisations de la source avant le classement.
- [ ] Les fragments récupérés conservent l'ID de la source, l'ID de l'organisation, la visibilité, le responsable, la version et la date d'examen.
- [ ] Le chemin de réponse peut citer ou enregistrer les ID de sources utilisés.
- [ ] Les sources obsolètes, non examinées ou à faible confiance sont exclues ou marquées.
- [ ] Les journaux masquent les données personnelles et les identifiants.

## 4. Contrat de prompt et de contexte

- [ ] Les instructions système/développeur sont versionnées et examinées comme du code.
- [ ] Le contenu non fiable est enveloppé et étiqueté comme des données.
- [ ] Le modèle est informé de ce qu'il doit faire lorsque le contenu non fiable entre en conflit avec les instructions de la tâche.
- [ ] Le modèle reçoit uniquement le contexte minimum nécessaire pour la tâche.
- [ ] Les flux de travail à haut risque utilisent une étape d'extraction étroite avant que l'agent principal n'analyse le contenu.
- [ ] Les phrases sentinelles dans les prompts servent uniquement à la détection, jamais de défense principale.

## 5. Conception des outils et des actions

- [ ] Les outils sont ciblés et propres à la tâche.
- [ ] Les outils déduisent l'utilisateur, l'organisation et le rôle du contexte d'authentification côté serveur, pas des arguments fournis par le modèle.
- [ ] Chaque outil valide les arguments avec un schéma et des règles métier.
- [ ] Chaque outil applique l'autorisation indépendamment du modèle.
- [ ] Les outils d'écriture sont idempotents autant que possible.
- [ ] Les effets secondaires externes nécessitent une approbation humaine ou des vérifications de politiques déterministes.
- [ ] Les limites de débit, les quotas et les limites de coût sont configurés.
- [ ] Les appels d'outils sont journalisés avec l'utilisateur, l'organisation, le workflow, la version du prompt, le modèle, un résumé des arguments et le résultat.

## 6. Validation des sorties

- [ ] La sortie du modèle est analysée avec un schéma strict avant d'être utilisée.
- [ ] Les champs inconnus sont rejetés lorsque le contrat doit être fermé.
- [ ] Les URL, le Markdown, le HTML, les noms de fichiers et les blocs de code sont neutralisés lorsque nécessaire.
- [ ] Les sorties ne peuvent contenir aucune catégorie de données située hors du périmètre autorisé de la tâche.
- [ ] Les réponses factuelles basées sur des sources privées nécessitent des ID de source ou des extraits de source.
- [ ] Une sortie mal formée provoque un refus sûr au lieu d'un retour au texte libre.

## 7. Tests de régression

- [ ] Test d'injection directe : l'entrée utilisateur demande au modèle d'ignorer les instructions.
- [ ] Test d'injection indirecte : le contenu récupéré demande au modèle de révéler des données ou d'appeler un outil.
- [ ] Test inter-organisations : une demande tente d'accéder aux données d'une autre organisation.
- [ ] Test d'appel d'outil non sécurisé : le modèle demande une action non disponible ou non autorisée.
- [ ] Test de sortie mal formée : des champs supplémentaires ou des valeurs d'énumération invalides sont rejetés.
- [ ] Test d'exfiltration : la sortie tente d'inclure des secrets, des données privées ou du texte de prompt.
- [ ] Test de persistance : le contenu stocké contient des instructions malveillantes qui sont plus tard récupérées.
- [ ] Test multimodal, si nécessaire : les instructions visibles par OCR ou dans une image sont traitées comme non fiables.

## 8. Supervision et réponse aux incidents

- [ ] Les tentatives d'extraction de prompt sont détectables.
- [ ] Les échecs répétés de validation peuvent déclencher une alerte.
- [ ] Une ampleur inhabituelle de recherche, un volume anormal d'appels d'outils, de destinataires sortants, de coûts ou de débit peut déclencher une alerte.
- [ ] Les tentatives d'injection de prompt peuvent être reliées à l'utilisateur, à l'organisation, au workflow, aux ID de source et aux appels d'outils.
- [ ] L'équipe sait désactiver le workflow ou chacun de ses outils.
- [ ] L'équipe sait comment révoquer les clés fournisseur et faire tourner les identifiants affectés.
- [ ] Un responsable est désigné pour décider des notifications aux clients, aux services juridiques et de sécurité, ainsi qu'aux autorités.

## Conditions de mise en production

Ne considérez pas le workflow comme prêt pour la production tant que :

- [ ] Toutes les actions aux conséquences importantes disposent d'un point de validation.
- [ ] Au moins un test avec un document adversaire a réussi.
- [ ] Au moins un essai d'accès non autorisé a échoué de manière sécurisée.
- [ ] Au moins un essai d'appel d'outil non sécurisé a échoué de manière sécurisée.
- [ ] Au moins un test de sortie mal formée a provoqué un refus sûr.
- [ ] Au moins une procédure de désactivation du workflow a été testée.