Guardrails programmatiques pour assistant IA de production

Un assistant fondé sur l’intelligence artificielle (IA) ne devient pas sûr parce qu’un prompt système lui demande poliment de l’être. Les garde-fous programmatiques doivent contrôler les entrées, les données consultées, les outils exécutés et les sorties, avec des décisions vérifiables hors du modèle de langage.

→ Lire l’explication complète de la marmotte

Frontière de confiance entre modèle et mécanismes de contrôle

Un grand modèle de langage, ou LLM (Large Language Model), produit du texte probable à partir d’un contexte. Il ne rend pas une décision de sécurité. Lui confier une autorisation, une validation de conformité ou une limite métier revient à faire voter un perroquet sur un plan de reprise d’activité. Le perroquet peut avoir raison, mais cette propriété ne se supervise pas.

Le compromis central est net : imposer des contrôles externes réduit la latitude du modèle et augmente la latence, le coût de développement et le taux de refus. En échange, l’architecture obtient des décisions déterministes, auditables et révocables. En production, ce compromis doit être accepté sans hésiter pour toute action ayant un effet externe, toute donnée sensible ou toute réponse destinée à un utilisateur non supervisé.

Le prompt système conserve un rôle : fixer le ton, la mission, le format et les limites conversationnelles. Il ne doit jamais porter seul une règle dont la violation provoque une fuite, une dépense, une suppression ou une élévation de privilèges. Une injection de prompt consiste précisément à fournir au modèle une instruction concurrente, souvent cachée dans un document, une page web ou un message utilisateur. Le modèle ne distingue pas de manière fiable une donnée à résumer d’une instruction à exécuter.

La frontière de confiance doit donc être dessinée explicitement :

Le contenu utilisateur, les documents et les résultats de recherche sont non fiables.
Le LLM est non fiable pour appliquer une politique de sécurité.
Le moteur de politiques, le gestionnaire d’identités et les connecteurs d’outils constituent le plan de contrôle.
Les systèmes métiers restent propriétaires de l’autorisation finale.

Cette séparation rejoint les principes d’IAM et des identités. Un jeton d’accès porté par une session ne prouve pas qu’une action est permise dans le contexte courant. Il prouve seulement qu’une identité a été authentifiée selon certaines conditions. L’autorisation doit être recalculée pour chaque action sensible, avec l’identité, le tenant, la ressource, le type d’opération et le niveau de risque.

Les garde-fous doivent être placés avant et après le modèle. Avant : limiter la taille, le type et la provenance des entrées, classifier les données, retirer les secrets et sélectionner les sources autorisées. Après : valider la structure de sortie, détecter les données interdites, vérifier les références et bloquer les appels d’outils non conformes. Entre les deux : ne jamais laisser le modèle appeler directement une interface métier.

Chaîne de décision et appels d’outils sous contrôle

Une architecture exploitable sépare l’orchestrateur, le moteur de politiques et les adaptateurs d’outils. L’orchestrateur maintient l’état de conversation et construit le contexte. Le moteur de politiques décide si une opération est autorisée. L’adaptateur applique ensuite cette décision avec des identifiants techniques à privilèges minimaux. Le LLM ne reçoit jamais un secret permettant d’outrepasser cette chaîne.

Chaque outil doit exposer un contrat étroit. Préférer creer_ticket(service, priorite, resume) à un connecteur générique capable d’exécuter une requête arbitraire. Préférer lire_statut_deploiement(application) à une console capable de lancer n’importe quelle commande. Une interface large transforme le modèle en opérateur d’infrastructure imprévisible, avec une orthographe variable et une confiance déconcertante.

L’appel d’outil doit être traité comme une transaction de sécurité :

valider un schéma strict, y compris les valeurs autorisées et les longueurs ;
résoudre les identifiants côté serveur, jamais depuis un nom libre fourni par le modèle ;
vérifier la politique sur l’action réelle, pas sur l’intention déclarée ;
demander une approbation humaine pour les opérations destructrices ou financières ;
journaliser la décision, les paramètres normalisés, le résultat et l’identité ayant validé ;
appliquer un délai maximal et une limite de tentatives par conversation.

Une approbation humaine ne doit pas afficher un pavé de texte généré. Elle doit présenter l’action finale, sa cible, son impact, les paramètres résolus et le motif de la demande. Approuver « supprimer les ressources inutilisées » n’a aucune valeur opérationnelle. Approuver « supprimer le compte de service batch-archive et révoquer ses jetons actifs » en a une.

L’isolation réseau compte autant que la validation applicative. Un connecteur d’outil ne doit atteindre que les services nécessaires, depuis un segment dédié, avec des sorties réseau filtrées. Autoriser l’assistant à joindre Internet et le réseau d’administration parce qu’il faut « être agentique » est une version contemporaine du compte administrateur partagé. Le vocabulaire a changé, le trou dans la coque reste le même. Les principes de segmentation présentés dans la section réseaux s’appliquent sans poésie supplémentaire.

Exemple de politique déclarative pour un outil métier

Le moteur Open Policy Agent, ou OPA (Open Policy Agent), permet d’évaluer une politique déclarative séparée du code d’orchestration. Ce choix convient si les décisions doivent être versionnées, testées et partagées entre plusieurs assistants. Pour un unique flux sans effet externe, une validation applicative typée peut suffire. Le critère n’est pas la mode du moteur de politiques, cette espèce invasive des diagrammes d’architecture, mais la nécessité d’auditer et de faire évoluer les règles sans redéployer toute la logique conversationnelle.

L’exemple suivant refuse par défaut l’ouverture d’un ticket. Il autorise uniquement les catégories prévues, interdit les descriptions contenant un secret détectable et exige une identité disposant du rôle métier attendu.

package assistant.tools

default allow := false

# Autoriser seulement la création de tickets d'incident ou de demande.
allow if {
  input.tool == "creer_ticket"
  input.identity.roles[_] == "support_niveau_2"
  input.args.categorie in {"incident", "demande"}
  count(input.args.resume) <= 500
  not contains(lower(input.args.resume), "mot de passe")
  not contains(lower(input.args.resume), "cle privee")
}

# Renvoyer une raison exploitable par l'orchestrateur et la supervision.
deny_reason := "outil, rôle, catégorie ou contenu non autorisé" if {
  not allow
}

L’orchestrateur doit transmettre des paramètres déjà normalisés. Le modèle peut proposer une catégorie, mais le serveur doit vérifier qu’elle appartient à l’ensemble autorisé. De même, une détection par mot-clé n’est pas une stratégie de prévention des fuites : elle n’attrape ni une clé encodée, ni un secret fragmenté, ni une donnée sensible reformulée. Elle illustre le point d’insertion du contrôle, pas une protection complète.

Pour les sorties textuelles, utiliser plusieurs contrôles complémentaires : détection de motifs sensibles, classification de données, règles de confidentialité par attribut et validation de format. Une réponse contenant une adresse électronique professionnelle peut être admissible dans un annuaire interne et interdite dans une conversation publique. La politique dépend du canal, de l’identité et de la finalité, pas uniquement de la chaîne de caractères.

Surface d’attaque des guardrails et contre-mesures

Les garde-fous ajoutent leur propre surface d’attaque. Un filtre qui voit le texte utilisateur mais pas les documents récupérés laisse entrer l’injection la plus classique. Un filtre qui inspecte du texte mais pas une pièce jointe, une image ou un fichier compressé peut être contourné par changement de représentation. Les données doivent être normalisées avant inspection : décodage, extraction du texte, limitation de profondeur des archives et rejet des formats non pris en charge.

La récupération augmentée par recherche, souvent appelée RAG (Retrieval-Augmented Generation), ne rend pas une réponse vraie. Elle rend accessibles des documents sélectionnés. Un document empoisonné peut contenir une instruction hostile ou une information périmée. Séparer les champs contenu et instructions, marquer toute source comme non exécutable, filtrer les sources par autorisation et exiger des citations vérifiables. La page sur les embeddings complète ce sujet pour la recherche vectorielle, mais aucun score de similarité ne remplace une décision d’accès.

Les attaques par exfiltration cherchent à faire révéler le prompt système, l’historique, les extraits de documents ou le résultat d’un outil. La contre-mesure n’est pas seulement un refus textuel : ne pas placer dans le contexte ce qui ne doit pas sortir. Un secret injecté dans le contexte est déjà trop près de la sortie. Les clés, jetons et identifiants doivent rester dans un coffre de secrets, accessible uniquement par l’adaptateur concerné.

Les attaques de contournement exploitent aussi les différences entre garde-fous. Si le filtre d’entrée accepte une demande traduite, mais que le filtre de sortie ne comprend qu’une langue, la politique devient une barrière linguistique avec une pancarte « contourner par la gauche ». Tester les politiques avec des variantes multilingues, encodées et fragmentées, puis conserver les cas de régression.

Enfin, un garde-fou n’empêche pas une donnée source erronée, une politique métier mal écrite ou un opérateur autorisé à faire une mauvaise action. Il ne fournit ni vérité factuelle, ni responsabilité juridique, ni sécurité d’un système aval compromis. Ces garanties doivent venir de la gouvernance des données, de la séparation des rôles et des contrôles propres à chaque application.

Exploitation, rotation et reprise des garde-fous

Chaque décision doit produire un événement structuré : identifiant de requête, identité pseudonymisée si nécessaire, version du modèle, version de la politique, outils proposés, outils autorisés, motif de refus, temps d’évaluation et empreinte des sources. Ne pas journaliser les prompts bruts par défaut. Les journaux deviennent sinon une copie de secours non chiffrée de toutes les données que le système était censé protéger. Les pratiques de gestion des données restent applicables, même si l’interface répond avec aplomb.

Les secrets d’accès aux outils doivent être spécifiques par connecteur, à durée de vie courte et rotatifs. Une clé partagée entre l’orchestrateur et tous les systèmes métiers rend la révocation globale et transforme un incident local en promenade générale. Stocker les secrets dans un gestionnaire dédié ; protéger les clés maîtresses par un HSM (Hardware Security Module) lorsque l’impact le justifie ; vérifier régulièrement que les identifiants inutilisés sont révoqués.

Versionner les politiques comme du code : revue, tests unitaires, jeux de cas d’attaque, signature des artefacts et déploiement progressif. Une modification de politique peut bloquer un processus légitime aussi sûrement qu’une erreur de pare-feu. Prévoir un mode dégradé : si le moteur de politiques est indisponible, refuser les actions à effet externe et autoriser, au plus, une réponse sans outil fondée sur des sources publiques ou déjà autorisées.

Les sauvegardes doivent couvrir les politiques, les configurations de connecteurs, les listes d’autorisation et les journaux nécessaires à l’investigation. Elles ne doivent pas restaurer automatiquement des jetons expirés ni des secrets révoqués. La reprise doit reconstruire les identifiants depuis la source d’autorité. Restaurer aveuglément un secret ancien, c’est appeler cela continuité d’activité alors qu’il s’agit d’archéologie offensive.

🐝 Ce qui arrive si on s’en passe

Sans garde-fous programmatiques, la politique de sécurité n’existe que dans une génération échantillonnée : elle change dès que le modèle, sa version ou ses paramètres de génération changent, sans revue ni test de régression, et une mise à jour du fournisseur modifie silencieusement ce qui est permis. Un refus obtenu une fois ne garantit pas le refus suivant ; un attaquant peut relancer la même demande légèrement reformulée jusqu’à obtenir l’acceptation, et le caractère probabiliste de la réponse rend ce tâtonnement peu coûteux. Après un incident, la décision ne se reproduit pas : rejouer la conversation donne une autre sortie, aucune règle versionnée ne justifie l’action exécutée, et la correction se limite à retoucher un prompt sans pouvoir démontrer que la faille est fermée ni qu’aucun usage légitime n’est cassé.

🦫 Explication de la marmotte 🍫

Un assistant IA reçoit une demande et peut chercher des informations ou déclencher des actions. Le programme ne doit pas laisser le modèle décider seul de ce qui est autorisé. Avant de transmettre une demande au modèle, le système vérifie qui la formule, quelles données cette personne peut consulter et si le contenu contient des éléments interdits. Les documents ajoutés à la demande sont traités comme suspects, car ils peuvent contenir des consignes cachées.

Le modèle prépare ensuite une réponse ou propose une action, par exemple créer un ticket ou consulter un état de service. Cette proposition n’est pas exécutée directement. Un autre programme vérifie le nom de l’action, ses paramètres, les droits de la personne et les règles de l’organisation. Si une condition manque, l’action est refusée. Pour les actions risquées, une personne doit confirmer le résultat exact avant l’exécution.

Après la réponse, le système contrôle encore ce qui va être envoyé. Il peut bloquer des informations confidentielles, un format incorrect ou une donnée provenant d’une source non autorisée. Chaque décision est enregistrée avec la règle appliquée, sans recopier inutilement des données privées.

Les mots de passe et autres secrets restent dans un stockage protégé, hors des messages envoyés au modèle. Si le contrôle des règles tombe en panne, les actions dangereuses doivent s’arrêter. Un assistant indisponible est pénible ; un assistant qui agit sans vérification est un incident en attente de café.

Pages voisines

La citent

Guardrails programmatiques pour assistant IA de production

Elle cite

Guardrails programmatiques pour assistant IA de production

Guardrails programmatiques pour assistant IA de production

Frontière de confiance entre modèle et mécanismes de contrôle

Chaîne de décision et appels d’outils sous contrôle

Exemple de politique déclarative pour un outil métier

Surface d’attaque des guardrails et contre-mesures

Exploitation, rotation et reprise des garde-fous

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines