Agents et gouvernance

Liste de contrôle pour sécuriser les prompts et durcir les outils

Une checklist de défense en profondeur pour l'injection de prompt, les permissions d'outils, la validation, les données sensibles et la réponse aux incidents.

12 avril 20265 min de lectureSécurité IAPrompt injection

L'injection de prompt ne se résout pas en ajoutant une phrase demandant au modèle d'ignorer les instructions malveillantes. Un agent traite des contenus provenant des utilisateurs, documents, sites, outils, mémoires et intégrations. Chacun de ces canaux peut contenir des instructions incompatibles avec la politique de l'application. Le principe de sécurité est simple : le modèle peut proposer, mais le logiciel de confiance décide de ce qui est autorisé. Cette liste de contrôle transforme ce principe en frontières concrètes.

Cartographier les niveaux de confiance avant les prompts

Chaque entrée doit être qualifiée par son origine et son autorité :

politique système et applicative ;
saisie d'un utilisateur authentifié ;
contenu d'entreprise récupéré ;
contenu web ou tiers ;
résultat d'un outil ;
mémoire conversationnelle et résumés générés.

Le contenu récupéré est une preuve, pas une politique. Un document qui demande d'ignorer les instructions précédentes doit rester une donnée. Les réponses d'outils sont elles aussi non fiables tant que leur schéma, leur source et leur contexte d'autorisation ne sont pas validés. Les politiques et les preuves récupérées doivent être séparées dans la structure du prompt. Chaque élément de contexte conserve sa provenance, le volume de contenu non fiable reste limité, et le système évite de concaténer du HTML brut, du texte masqué ou des métadonnées non contrôlées.

Donner aux outils l'autorité minimale

La sécurité des outils commence en dehors du modèle. Chaque outil expose l'opération utile la plus étroite possible, avec un contrat d'entrée typé et une identité autorisable indépendamment. Pour chaque outil, il faut définir :

les appelants et contextes utilisateur autorisés ;
les arguments obligatoires et facultatifs ;
les valeurs acceptées et limites de taille ;
le caractère lecture ou écriture ;
l'idempotence et la politique de nouvelle tentative ;
les dépassements de délai et limites de débit ;
la classification des données ;
les événements d'audit ;
les confirmations requises.

Il faut éviter les outils génériques comme l'accès SQL sans restriction, les requêtes HTTP arbitraires ou l'exécution de commandes système. Si le workflow a besoin d'une opération métier, mieux vaut exposer cette opération qu'une surface d'exécution ouverte. L'autorisation doit être contrôlée par l'outil ou la couche applicative de confiance, jamais déduite d'une phrase générée par le modèle. Un nom d'outil valide et un JSON valide ne signifient pas que l'utilisateur a le droit d'effectuer l'action.

Valider tout le chemin de l'action

Avant qu'un appel ne produise un effet de bord :

analyser la sortie avec un schéma strict ;
rejeter les champs inconnus et valeurs dangereuses ;
lier la requête à l'identité authentifiée ;
revérifier la permission sur la ressource ;
appliquer les invariants métier ;
exiger une confirmation pour les actions à fort impact ;
ajouter une clé d'idempotence lorsque de nouvelles tentatives sont possibles ;
enregistrer la décision et son résultat sans exposer de secret.

La confirmation doit décrire l'action réelle, sa destination et ses conséquences importantes. Demander simplement de continuer après avoir masqué ces éléments ne constitue pas un contrôle humain significatif. Lorsqu'un outil renvoie un résultat ambigu ou partiel, le comportement sûr consiste généralement à s'arrêter, clarifier ou escalader. Le modèle ne doit pas inventer une réussite.

Protéger les données sensibles sur tout le workflow

Les données sensibles peuvent fuir par les prompts, arguments d'outils, traces, entrées de cache, sorties du modèle ou files de revue humaine. Une politique commune doit couvrir toutes ces surfaces. Les contrôles utiles incluent :

minimisation des données avant l'appel modèle ;
inspection DLP ou par motifs lorsque pertinente ;
recherche documentaire et clés de cache isolées par client ;
chiffrement et règles de rétention ;
masquage dans les journaux et jeux d'évaluation ;
politique de routage par fournisseur et région ;
validation des sorties avant affichage ou réutilisation.

La mémoire a besoin d'une portée et d'une expiration explicites. L'historique de conversation ne doit pas devenir une base de données sans limite. Seul l'état requis par le produit est conservé, associé au bon utilisateur ou client, avec un mécanisme d'invalidation. Mon étude de cas publique sur DAISI présente Model Armor, DLP, protections RGPD, frontières d'identité et intégrations contrôlées comme des couches distinctes. Ces contrôles ne rendent pas un agent automatiquement sûr ; ils montrent pourquoi la sécurité doit couvrir le modèle, l'application, les données et l'infrastructure.

Rendre les situations dangereuses observables

La télémétrie de sécurité doit expliquer :

quelle source non fiable a influencé la requête ;
quelles versions de politique et d'outil étaient actives ;
pourquoi un appel a été autorisé, bloqué ou escaladé ;
si une donnée sensible a été détectée ou masquée ;
si une confirmation était requise et obtenue ;
quel effet de bord a eu lieu ;
quelle solution de repli a été utilisée.

Il ne faut pas journaliser des secrets ou contenus sensibles simplement pour faciliter le diagnostic. On privilégie les identifiants stables, les classifications, les empreintes lorsque pertinentes et les vues de traces protégées. Les alertes doivent prioriser les violations de politique et les schémas d'action suspects plutôt que l'incertitude générale du modèle. Des appels bloqués répétés, des tentatives de franchir une frontière client, des charges utiles inhabituelles ou des confirmations manquantes sont des signaux plus solides qu'un faible score de confiance isolé. Le cadre de gouvernance IA en entreprise montre comment relier ces contrôles aux preuves, aux responsabilités et aux décisions d'incident.

Le modèle propose une action tandis que le logiciel de confiance valide l'identité, les arguments, la politique, l'approbation et l'autorité d'exécution.

Tester les workflows adversariaux complets

Le jeu de tests adversariaux couvre les injections directes et indirectes, les documents malveillants, les résultats d'outils empoisonnés, les contournements par encodage, les instructions contradictoires, les charges utiles excessives, les changements de permissions, les nouvelles tentatives et les attaques multi-étapes dont chaque action semble anodine. Le chemin complet doit être testé avec des identités et permissions proches de la production. Le refus du modèle dans une interface de conversation ne prouve pas que le serveur applicatif rejetterait l'action. Inversement, le modèle peut suivre une instruction injectée tandis que l'application de confiance bloque correctement l'effet de bord. Les deux observations comptent. Les cas deviennent des tests de régression réexécutés lorsque les prompts, modèles, analyseurs, outils, règles d'identité ou sources changent. Les évaluateurs doivent être revus afin qu'un modèle juge ne valide pas le comportement qu'il est censé détecter.

Préparer une réponse opérationnelle sûre

Le système a besoin d'une procédure documentée pour désactiver un outil, révoquer un identifiant d'accès, bloquer une source, réduire les capacités ou diriger le trafic vers une solution de repli en lecture seule. Les preuves nécessaires à l'enquête sont préservées et les responsables de l'application, de l'intégration, de l'identité, des données et de la décision d'incident sont identifiés. Aucune liste de contrôle n'élimine complètement le risque d'injection de prompt. Un système résilient suppose que des instructions non fiables atteindront le modèle et garantit qu'elles ne pourront pas se transformer silencieusement en actions non autorisées.

Sources et références

OWASP Top 10 for LLM ApplicationsCatégories de menaces pour les applications LLM et systèmes agentiques
NIST AI Risk Management FrameworkPrincipes de gouvernance et de gestion des risques pour les systèmes IA
Guide Microsoft sur les tests adversariaux en IARecommandations opérationnelles pour les tests adversariaux d'applications IA

Des principes aux systèmes livrés

Ces articles documentent mes méthodes de travail. Les études de cas montrent comment je les applique aux agents d'entreprise, au RAG et au MLOps.

Voir les études de cas Consulter mon CV

Continuer l'exploration

Des notes complémentaires sur les choix d'architecture, d'évaluation et d'exploitation des systèmes IA en production.

13 avril 20265 min de lectureÉvaluation IATests de régression