Sécurité LLM pour l’IA agentique : injection, appels d’outils, résidence des données, HITL et tests

La sécurité LLM ne consiste plus seulement à bloquer les prompts dangereux. Lorsqu’un LLM devient partie intégrante d’un workflow agentique, il peut récupérer des documents, appeler des API, mettre à jour des enregistrements ou déclencher des processus métier. Cela transforme le modèle de sécurité : il ne s’agit plus de « protéger le chat », mais de « protéger le système d’actions autour du modèle ».

Si votre équipe prévoit une adoption plus large de l’IA agentique en production, la sécurité LLM doit être traitée comme une condition de mise en production, et non comme une checklist finale. Pour les équipes de l’UE et des États-Unis, cela signifie réfléchir avant le lancement à l’injection de prompts, à l’accès sécurisé aux outils, à la résidence des données, à l’auditabilité, à la supervision humaine, aux tests et à la surveillance en production.

Le risque n’est plus théorique. Le 2025 AI Index de Stanford HAI a signalé 233 incidents liés à l’IA en 2024, un niveau record et une augmentation de 56,4 % par rapport à 2023. Le 2025 Cost of a Data Breach Report d’IBM a également constaté que 13 % des organisations ont signalé des violations impliquant des modèles ou des applications d’IA ; parmi celles qui ont été compromises, 97 % ne disposaient pas de contrôles d’accès à l’IA appropriés.

Ce guide détaille les contrôles pratiques dont les équipes ont besoin pour déployer en toute sécurité des agents alimentés par des LLM.

Points clés à retenir

• La sécurité LLM couvre les prompts, les outils, les données, les journaux, les humains, les fournisseurs et la surveillance.
• L’IA agentique accroît le risque de sécurité parce qu’elle peut agir, et pas seulement générer du texte.
• L’injection de prompts nécessite des défenses en couches, et non un simple prompt système plus robuste.
• Les appels d’outils sécurisés reposent sur le moindre privilège, la validation, le sandboxing et les journaux d’audit.
• La résidence des données doit être intégrée à l’architecture pour les déploiements UE/États-Unis.
• Les contrôles HITL doivent être fondés sur le risque, auditables et réalistes sur le plan opérationnel.
• Les tests et la surveillance doivent se poursuivre après la mise en production.

Ce que signifie la sécurité LLM pour l’IA agentique

La sécurité LLM va au-delà de la sûreté des prompts

La sécurité LLM est la pratique qui consiste à protéger les systèmes alimentés par des LLM contre les fuites de données, l’injection de prompts, l’utilisation non autorisée d’outils, les sorties dangereuses et les manquements à la conformité.

Pour un chatbot simple, la sécurité peut se concentrer principalement sur les prompts, les sorties et les données utilisateur. Pour un système d’IA agentique, le périmètre est plus large. Le système peut inclure :

• Un modèle ou plusieurs modèles
• Des prompts système et des politiques
• Des pipelines RAG et des bases de données vectorielles
• Des API et des outils métier
• Une mémoire ou un contexte de session
• Des journaux et des systèmes de surveillance
• Des workflows d’approbation humaine
• Des fournisseurs tiers de modèles ou d’infrastructure

Une application LLM sécurisée n’est pas seulement un prompt sûr. C’est une architecture sécurisée autour du modèle.

Pourquoi les systèmes agentiques élèvent le niveau de risque

L’IA agentique modifie le profil de risque parce que le modèle peut influencer des actions. Au lieu de simplement répondre à une question, un agent peut :

• Rechercher dans des documents internes
• Appeler une API CRM
• Mettre à jour un ticket
• Déclencher un e-mail
• Générer du code
• Analyser des dossiers clients
• Transférer des données entre des outils
• Recommander ou exécuter des étapes de workflow

Cela signifie qu’une mauvaise instruction, un résultat de récupération non sécurisé, une permission excessive ou une couche de validation faible peut avoir un véritable impact opérationnel. Le mode de défaillance n’est plus seulement « la réponse était fausse ». Il peut devenir « la mauvaise action a été effectuée ».

Objectifs de sécurité pour les agents LLM en production

Pour les agents LLM en production, les objectifs de sécurité doivent être explicites. Au minimum, les équipes devraient viser à :

• Empêcher l’accès non autorisé aux données
• Empêcher les fuites de données sensibles
• Empêcher l’utilisation dangereuse ou non autorisée d’outils
• Maintenir des journaux d’audit pour les actions importantes
• Appliquer une approbation humaine aux workflows à haut risque
• Détecter tôt les comportements anormaux
• Prendre en charge la réponse aux incidents et le rollback
• Garder les changements de modèles, de prompts et d’outils traçables

Ces objectifs aident les équipes sécurité, produit et ingénierie à évaluer si un agent est prêt pour la production.

Modèle de menace : où les agents LLM échouent en production

La modélisation des menaces donne aux équipes une façon pratique de comprendre comment un agent LLM peut échouer avant que ces défaillances n’affectent les clients, les employés ou des données réglementées.

Le rapport 2025 d’IBM a révélé que 60 % des incidents de sécurité liés à l’IA ont entraîné une compromission des données et que 31 % ont provoqué une perturbation opérationnelle. Pour l’IA agentique, ces chiffres comptent parce qu’un agent compromis peut affecter à la fois l’exposition des informations et la continuité des processus métier.

Risques de confidentialité

Les risques de confidentialité surviennent lorsque des informations sensibles sont exposées au mauvais utilisateur, outil, fournisseur, journal ou système en aval.

Exemples courants :

• Des données personnelles incluses inutilement dans les prompts
• Des secrets ou identifiants apparaissant dans les journaux
• Une récupération RAG exposant des documents auxquels un utilisateur ne devrait pas accéder
• Des sorties de modèle révélant des instructions système cachées
• Des paramètres fournisseur conservant des prompts sensibles plus longtemps que prévu
• Des données internes envoyées à des services externes sans approbation claire

Le contrôle pratique commence par la classification des données. Les équipes doivent savoir à quelles données l’agent peut accéder, où ces données sont traitées et qui peut voir la sortie.

Risques d’intégrité

Les risques d’intégrité surviennent lorsque le comportement, le raisonnement ou les actions de l’agent sont manipulés.

Dans les systèmes LLM, le risque d’intégrité apparaît souvent sous forme d’injection de prompts. Dans les systèmes agentiques, il peut aller plus loin :

• Un document malveillant dit à l’agent d’ignorer les instructions précédentes.
• Une réponse d’outil contient du texte que le modèle traite comme une nouvelle commande.
• Un utilisateur trompe l’agent pour lui faire appeler une fonction non autorisée.
• L’agent modifie un enregistrement sur la base d’informations non vérifiées.
• Un résultat RAG modifie le chemin de décision de l’agent.

Les contrôles d’intégrité doivent se concentrer sur la séparation des instructions de confiance et du contenu non fiable, la validation des appels d’outils et l’application de contrôles de politique avant les actions sensibles.

Risques de disponibilité et de coûts

Les agents LLM peuvent aussi créer des problèmes de disponibilité et de coûts. Par exemple :

• Un agent entre dans une boucle répétée.
• Les appels d’outils augmentent de façon inattendue.
• L’utilisation de tokens dépasse le budget.
• Une panne de modèle ou de fournisseur interrompt un workflow.
• Une entrée mal formée provoque des tentatives répétées.
• Une étape à forte latence bloque un processus métier.

On parle parfois de « denial of wallet » lorsque l’utilisation excessive du modèle crée des coûts inattendus. Les agents en production ont besoin de limites de débit, de délais d’expiration, de limites de nouvelles tentatives, de contrôles budgétaires et d’alertes.

Risques de conformité

Pour les déploiements UE/États-Unis, le risque de conformité provient souvent d’une gestion des données floue et d’une gouvernance faible.

Exemples :

• Aucun flux de données documenté
• Région de traitement incertaine
• Paramètres de rétention faibles pour les prompts et les journaux
• Aucune piste d’audit pour les actions à haut risque
• Aucune supervision humaine pour les workflows sensibles
• Aucun examen des fournisseurs/sous-traitants
• Aucun plan de réponse aux incidents pour les défaillances liées à l’IA

Les équipes sécurité et conformité doivent examiner ces risques avant le lancement, et non après que l’agent est déjà intégré aux workflows métier.

Contrôles contre l’injection de prompts et l’injection indirecte

Injection directe de prompts

L’injection directe de prompts se produit lorsqu’un utilisateur tente intentionnellement de manipuler les instructions du modèle. L’utilisateur peut demander au modèle d’ignorer les règles système, de révéler un contexte caché, de contourner des politiques ou d’effectuer des actions en dehors de son périmètre autorisé.

Pour un chatbot de base, l’injection directe peut produire une réponse dangereuse ou incorrecte. Pour un agent IA, elle peut entraîner une mauvaise utilisation des outils, une exposition de données ou une exécution non autorisée de workflow.

L’OWASP répertorie Prompt Injection comme un risque majeur pour les applications LLM dans son OWASP Top 10 for LLM Applications. C’est pourquoi les tests d’injection doivent faire partie du processus de mise en production de tout workflow LLM qui traite des données sensibles ou des actions métier.

Injection indirecte de prompts

L’injection indirecte de prompts se produit lorsque des instructions malveillantes sont cachées dans le contenu lu par l’agent. Ce contenu peut provenir de :

• Pages web
• E-mails
• Fichiers téléversés
• PDF
• Tickets
• Transcriptions de chat
• Résultats RAG
• Réponses d’outils
• Documents partagés

C’est particulièrement important pour l’IA agentique, car les agents consomment souvent du contenu externe ou semi-fiable avant de décider de l’action suivante.

Pourquoi l’injection indirecte est dangereuse pour les agents

L’injection indirecte est dangereuse parce que l’instruction malveillante ne vient pas directement de l’utilisateur. Elle apparaît dans les données que l’agent a été chargé de traiter.

Par exemple, un agent peut lire un ticket d’assistance qui inclut des instructions cachées lui demandant de divulguer une politique interne, de modifier un champ de priorité ou d’appeler un autre outil. Si le système traite le contenu récupéré comme une instruction de confiance, l’agent peut la suivre.

Le principe fondamental est simple : le contenu externe doit être traité comme des données, et non comme une autorité.

Contrôles défensifs

L’atténuation de l’injection de prompts doit utiliser des contrôles en couches :

• Séparer les instructions système du contenu utilisateur et des outils.
• Traiter les documents récupérés comme des données non fiables.
• Utiliser des listes d’outils autorisés plutôt qu’un accès ouvert à tous les outils.
• Valider les arguments des outils côté serveur.
• Exiger des sorties structurées pour les appels d’outils.
• Ajouter des contrôles de politique avant les actions sensibles.
• Limiter les permissions de l’agent par rôle et par workflow.
• Assainir ou isoler le contenu externe avant utilisation.
• Ajouter des portes d’approbation pour les actions à fort impact.
• Surveiller les schémas de prompts suspects et les tentatives bloquées.

Aucun contrôle unique ne suffit. Un prompt système robuste aide, mais il ne doit pas être la seule frontière de sécurité.

Sur quoi ne pas compter seul

Les équipes doivent éviter de s’appuyer uniquement sur :

• Un prompt système générique du type « ne pas enfreindre les règles »
• Des filtres par mots-clés
• Une revue manuelle sans journaux
• Un seul paramètre de sûreté du modèle
• La confiance accordée à tout le contenu RAG
• L’octroi de permissions API larges à l’agent
• L’hypothèse que les utilisateurs n’essaieront pas d’entrées adversariales

La sécurité LLM doit partir du principe que les prompts, le contenu récupéré et les sorties d’outils peuvent être manipulés.

Appels d’outils sécurisés et accès selon le moindre privilège

Pourquoi les appels d’outils changent le modèle de sécurité

Les appels d’outils constituent l’une des plus grandes différences entre un chatbot LLM classique et un système d’IA agentique.

Un chatbot produit du texte. Un agent doté d’outils peut créer des effets de bord. Il peut rechercher dans une base de données, envoyer un e-mail, mettre à jour un champ CRM, créer un ticket d’assistance, exécuter un script ou déclencher un workflow interne.

Cela signifie que la sortie du modèle devient une action système potentielle. Les contrôles de sécurité doivent protéger la couche d’action, pas seulement la couche de texte.

Risques courants des appels d’outils en production

Les risques courants incluent :

• L’agent appelle un outil auquel il ne devrait pas accéder.
• L’agent envoie des données sensibles au mauvais outil.
• L’agent utilise les bons outils avec des arguments dangereux.
• L’agent répète les appels d’outils et crée des problèmes de coûts ou de disponibilité.
• Une réponse d’outil contient des instructions malveillantes.
• Un outil dispose de permissions plus larges que celles requises par le workflow.
• Des secrets sont exposés au modèle via des prompts ou des sorties d’outils.
• Une action d’outil ne peut pas être retracée jusqu’à un utilisateur, un agent ou une approbation.

L’OWASP souligne également Excessive Agency comme un risque majeur pour les applications LLM, en particulier pour les systèmes capables d’appeler des outils ou d’interagir avec des systèmes externes. Le problème est souvent enraciné dans une fonctionnalité excessive, des permissions excessives ou une autonomie excessive. Cela correspond directement aux agents en production disposant d’un large accès aux outils.

Accès selon le moindre privilège pour les agents LLM

Le moindre privilège signifie que l’agent ne doit disposer que des permissions dont il a besoin pour une tâche précise.

Par exemple, un agent qui rédige des réponses au support client peut avoir besoin d’un accès en lecture à l’historique des tickets, mais il n’a peut-être pas besoin de la permission d’émettre des remboursements, de supprimer des comptes ou de modifier des dossiers de facturation. Si une action est à haut risque, l’agent doit la rédiger ou la recommander, tandis qu’un humain l’approuve.

Un modèle pratique de moindre privilège doit définir :

• Quels outils l’agent peut utiliser
• Quelles opérations sont autorisées
• Quels périmètres de données sont autorisés
• Quels utilisateurs ou rôles peuvent déclencher le workflow
• Quelles actions nécessitent une approbation
• Quelles actions sont entièrement bloquées

Chaque agent doit disposer de sa propre identité de service lorsque c’est possible. Évitez de donner à un agent un accès large via un identifiant administrateur partagé.

Listes d’outils autorisés, périmètres et contrôles de politique

Les agents en production ne doivent pas choisir parmi un nombre illimité d’outils. L’accès aux outils doit être limité par liste d’autorisation et par périmètre.

Contrôles utiles :

• Listes d’outils autorisés par type d’agent
• Périmètres d’API par workflow
• Limites de débit par outil
• Contrôles de politique avant exécution
• Séparation des environnements de développement, de staging et de production
• Contrôles d’approbation pour les opérations sensibles
• Comportement de refus par défaut lorsque le contexte est ambigu

Une couche de politique peut décider si un appel d’outil est autorisé avant que l’action ne se produise. C’est particulièrement utile pour les actions impliquant des données client, un impact financier, un impact juridique, un impact de sécurité ou une communication externe.

Validation des arguments et validation des sorties

Les appels d’outils doivent utiliser des schémas structurés. L’agent ne doit pas transmettre d’arguments arbitraires en texte libre à des API sensibles.

Par exemple :

• Les identifiants doivent correspondre aux formats attendus.
• Les montants doivent rester dans les limites approuvées.
• Les destinataires d’e-mails doivent correspondre à des domaines autorisés ou à des contacts vérifiés.
• Les chemins de fichiers doivent rester dans les emplacements autorisés.
• Les appels d’outils doivent échouer de manière fermée lorsque des champs obligatoires sont manquants.

Les sorties d’outils doivent également être traitées avec prudence. Une réponse d’outil peut contenir du texte non fiable, des données mal formées ou des instructions injectées. Le modèle doit utiliser la sortie de l’outil comme des données, et non comme une nouvelle source d’autorité.

Sandboxing des outils à haut risque

Certains outils nécessitent une isolation. Exemples :

• Exécution de code
• Navigation web
• Traitement de fichiers
• Ingestion de documents
• Transformation de données
• Automatisation de workflows avec effets de bord externes

Le sandboxing aide à limiter les dommages si l’agent se comporte de manière inattendue. Selon le cas d’usage, il peut inclure des restrictions réseau, des limites du système de fichiers, des délais d’exécution, des limites mémoire, des identifiants séparés et des environnements restreints.

Gestion des secrets pour les workflows agentiques

Les secrets ne doivent pas être placés dans les prompts, le contexte du modèle ou les journaux en texte clair. Les agents ne doivent accéder aux secrets que via des services backend sécurisés.

Bonnes pratiques :

• Stocker les secrets dans un gestionnaire de secrets.
• Garder les identifiants hors des modèles de prompts.
• Expurger les secrets des journaux.
• Faire tourner régulièrement les identifiants.
• Utiliser des tokens à durée de vie courte lorsque c’est possible.
• Séparer les identifiants par environnement.
• Éviter d’exposer des clés API brutes aux sorties du modèle ou aux réponses d’outils.

Le modèle doit demander une action, mais le backend doit appliquer l’autorisation et effectuer l’opération sécurisée.

Journalisation d’audit des appels d’outils

Chaque appel d’outil important doit être journalisé. Les journaux doivent aider à répondre aux questions suivantes :

• Quel utilisateur a déclenché le workflow ?
• Quel agent a pris la décision ?
• Quel outil a été appelé ?
• Quelle action a été demandée ?
• L’action a-t-elle été approuvée ?
• Quel a été le résultat ?
• Des données sensibles étaient-elles impliquées ?
• L’action a-t-elle été bloquée, retentée ou annulée ?

Pour les environnements d’entreprise UE/États-Unis, l’auditabilité est souvent aussi importante que la prévention. Si quelque chose tourne mal, l’organisation doit pouvoir reconstituer ce qui s’est passé.

Résidence des données et confidentialité pour les déploiements UE/États-Unis

Commencer par une cartographie des données

La résidence des données commence par la compréhension du flux de données. Avant de choisir un fournisseur de modèle ou une architecture, les équipes doivent cartographier :

• Quelles données entrent dans le prompt
• Quelles données sont récupérées depuis les systèmes internes
• Quelles données sont envoyées aux fournisseurs de modèles
• Quelles données sont intégrées dans une base de données vectorielle
• Quelles données sont journalisées
• Combien de temps les données sont conservées
• Quelle région traite ou stocke chaque composant
• Quels fournisseurs ou sous-traitants sont impliqués

Sans cartographie des données, les revues de sécurité et de conformité deviennent de la spéculation.

IBM a également indiqué que 63 % des organisations victimes d’une violation n’avaient pas de politique de gouvernance de l’IA ou étaient encore en train d’en développer une. Pour les déploiements UE/États-Unis, cet écart de gouvernance se manifeste souvent par des flux de données flous, de faibles décisions de rétention, une revue fournisseur incomplète ou des contrôles manquants autour de l’IA fantôme.

Considérations pour l’UE

Pour les déploiements dans l’UE, les équipes doivent généralement tenir compte de principes de confidentialité tels que la minimisation des données, la limitation des finalités, le contrôle d’accès, la rétention et l’examen des transferts transfrontaliers. Les obligations spécifiques dépendent de l’organisation, du cas d’usage, du type de données et de la base juridique.

Questions pratiques d’architecture :

• Les données sensibles peuvent-elles être minimisées avant la construction du prompt ?
• L’inférence peut-elle être épinglée à une région ?
• Les journaux sont-ils stockés dans la bonne région ?
• Les embeddings sont-ils considérés comme sensibles dans ce cas d’usage ?
• Les données client peuvent-elles être exclues de l’entraînement du fournisseur ?
• Les paramètres de suppression et de rétention sont-ils configurables ?

L’interprétation juridique doit être examinée par un conseiller qualifié avant toute décision de publication ou de mise en œuvre.

Considérations pour les États-Unis

Les déploiements aux États-Unis peuvent impliquer des attentes propres au secteur selon l’industrie. Les environnements de santé, de finance, d’éducation, du secteur public et de SaaS d’entreprise ont souvent des attentes plus strictes en matière de contrôles d’accès, de journaux d’audit, de rétention et de gestion des risques fournisseurs.

Même lorsqu’une réglementation ne mentionne pas explicitement les LLM, les acheteurs peuvent attendre des contrôles de sécurité alignés sur des cadres d’entreprise tels que SOC 2 ou ISO/IEC 27001.

Modèles d’architecture pour les systèmes LLM sensibles à la résidence des données

Modèles courants :

• Points de terminaison de modèles spécifiques à une région
• Magasins vectoriels spécifiques à une région
• Réseau privé lorsque disponible
• Clés de chiffrement gérées par le client
• Masquage des données avant les appels au modèle
• Détection des données personnelles avant la construction du prompt
• Environnements UE et États-Unis séparés
• Fenêtres de rétention courtes pour les prompts et les sorties
• Niveaux de journalisation séparant les métadonnées opérationnelles du contenu sensible
• Contrôles d’accès sur les embeddings et les documents récupérés

L’objectif est de réduire les mouvements de données inutiles et de rendre les mouvements de données inévitables visibles, contrôlés et documentés.

Checklist de due diligence fournisseur

Avant d’utiliser un fournisseur LLM ou un fournisseur d’infrastructure IA, les équipes doivent demander :

• Où les données sont-elles traitées ?
• Où les données sont-elles stockées ?
• Les données client sont-elles utilisées pour l’entraînement ?
• Quels contrôles de rétention sont disponibles ?
• Quels sous-traitants sont impliqués ?
• Les contrôles de sécurité d’entreprise sont-ils pris en charge ?
• Des journaux d’audit sont-ils disponibles ?
• Les données peuvent-elles être supprimées sur demande ?
• Des options de réseau privé ou d’épinglage régional sont-elles disponibles ?
• Que se passe-t-il pendant la réponse aux incidents ?

Les paramètres fournisseur peuvent modifier substantiellement la posture de sécurité d’un système LLM. Ils doivent être examinés avant l’utilisation en production.

Contrôles HITL : supervision humaine sans freiner la vélocité

Le HITL doit être fondé sur le risque

L’humain dans la boucle ne signifie pas que chaque action d’agent nécessite une approbation manuelle. Cela rendrait la plupart des workflows trop lents. Cela ne signifie pas non plus que chaque action doit être automatisée.

La bonne approche est fondée sur le risque. Les actions à faible risque peuvent être journalisées et surveillées. Les actions à risque moyen peuvent nécessiter un échantillonnage, des contrôles fondés sur des règles ou une approbation sous certaines conditions. Les actions à haut risque doivent exiger une revue humaine explicite.

Niveaux de risque suggérés

Niveau de risque	Exemple d’action d’agent	Contrôle suggéré
Faible	Rédaction d’un résumé interne	Journalisation uniquement
Moyen	Mise à jour d’un champ CRM non critique	Validation fondée sur des règles ou revue par échantillonnage
Élevé	Envoi d’un message destiné à un client	Approbation humaine requise
Critique	Paiements, suppression de compte, actions ayant un impact juridique ou de sécurité	Approbation humaine plus contrôle secondaire

Cette structure permet aux équipes de préserver la vélocité tout en contrôlant les décisions à fort impact.

Contrôles qui rendent le HITL prêt pour l’audit

Un workflow HITL utile doit capturer :

• Identité du réviseur
• Décision d’approbation ou de rejet
• Motif de la décision
• Recommandation initiale de l’agent
• Action finale effectuée
• État avant/après lorsque pertinent
• Horodatage
• Chemin d’escalade
• Option de rollback

Sans ces enregistrements, le HITL peut aider opérationnellement, mais échouer à soutenir un audit ou une revue d’incident.

Quand ajouter un interrupteur d’arrêt d’urgence

Un interrupteur d’arrêt d’urgence permet aux équipes d’arrêter rapidement un agent ou de désactiver des actions d’outils spécifiques.

Les équipes doivent envisager des interrupteurs d’arrêt d’urgence dans des cas tels que :

• Volume inattendu d’appels d’outils
• Échecs de validation répétés
• Tentatives d’injection suspectes
• Exposition de données sensibles
• Pics de coûts
• Panne de modèle/fournisseur
• Décisions répétées à faible confiance
• Plaintes utilisateurs anormales ou escalades du support

Un interrupteur d’arrêt d’urgence doit être testé avant le lancement. Il ne doit pas exister uniquement comme contrôle théorique.

Tester et surveiller les agents LLM avant la production

L’assurance qualité traditionnelle ne suffit pas

L’assurance qualité traditionnelle suppose un comportement principalement déterministe. Les agents LLM sont différents. Leurs sorties peuvent varier, leurs chemins de raisonnement peuvent changer et leurs actions peuvent dépendre des données récupérées, des réponses d’outils, du contexte utilisateur et des paramètres du modèle.

Cela signifie que les tests d’agents doivent inclure à la fois une évaluation fonctionnelle et une évaluation de sécurité. Un workflow peut réussir un test de parcours nominal tout en échouant face à une entrée adversariale, à des documents inhabituels, à des réponses d’outils mal formées ou à des cas de limites de permissions.

Types de tests essentiels

Un plan de test prêt pour la production doit inclure :

• Tests de réussite des tâches
• Tests d’injection de prompts
• Tests d’injection indirecte
• Tests de permissions d’outils
• Tests de validation des arguments d’outils
• Tests de fuite de données
• Tests d’accès à la récupération RAG
• Tests de workflows HITL
• Tests de régression
• Tests de coûts et de latence
• Tests de modes de défaillance
• Tests de rollback et d’interrupteur d’arrêt d’urgence

Les tests de sécurité doivent inclure des workflows métier réalistes, et pas seulement des prompts artificiels.

Construire un harnais d’évaluation

Un harnais d’évaluation aide les équipes à tester les agents de manière cohérente avant la publication. Il doit inclure :

• Un ensemble versionné de cas de test
• Des résultats attendus ou des critères de scoring
• Des exemples adversariaux
• Des tâches utilisateur réalistes
• Des scénarios d’utilisation d’outils
• Des contrôles de violation de politique
• Un suivi des régressions à travers les changements de modèle ou de prompt
• Des rapports pouvant être examinés par les équipes ingénierie, sécurité et produit

Le harnais doit s’exécuter avant les versions majeures et chaque fois que les prompts, les outils, les modèles, la logique de récupération ou les règles de politique changent.

Signaux de surveillance à définir avant le lancement

La surveillance doit être conçue avant que l’agent ne soit mis en ligne. Les signaux utiles incluent :

• Fréquence des appels d’outils
• Validations échouées
• Actions bloquées
• Taux d’approbation et de rejet HITL
• Nouvelles tentatives répétées
• Anomalies de tokens et de coûts
• Pics de latence
• Détections de données sensibles
• Schémas de prompts suspects
• Accès inattendu aux données
• Plaintes utilisateurs
• Tentatives de violation de politique

Ces signaux doivent alimenter des alertes, des tableaux de bord et des workflows de réponse aux incidents.

Surveillance en production après la publication

Les tests ne s’arrêtent pas au lancement. Les agents LLM peuvent dériver à mesure que les données, les outils, les prompts, les modèles et le comportement des utilisateurs changent.

Cette vision du cycle de vie s’aligne sur le NIST AI Risk Management Framework, qui organise le travail de gestion des risques liés à l’IA autour de gouverner, cartographier, mesurer et gérer. Pour les agents LLM, cela signifie que les équipes doivent cartographier les risques avant le déploiement, mesurer le comportement au moyen d’évaluations et de surveillance, et gérer les défaillances grâce aux alertes, aux chemins de rollback et à la réponse aux incidents.

Après la publication, les équipes doivent examiner :

• Si l’agent atteint toujours ses objectifs de réussite des tâches
• Si les blocages de sécurité augmentent
• Si les réviseurs HITL contournent souvent l’agent
• Si les tendances de coûts sont stables
• Si les utilisateurs découvrent de nouveaux modes de défaillance
• Si des changements de modèle ou de fournisseur affectent le comportement

La surveillance en production transforme la sécurité LLM d’une checklist ponctuelle en une pratique opérationnelle continue.

Checklist de sécurité LLM pour déployer en toute sécurité

Contrôles d’architecture

Avant le lancement, confirmez que :

• Les flux de données sont cartographiés.
• Les classes de données sensibles sont identifiées.
• Les permissions d’outils sont documentées.
• Les contrôles d’accès RAG sont testés.
• Les paramètres du modèle et du fournisseur sont examinés.
• Les paramètres de région et de rétention sont confirmés.
• Les secrets sont maintenus hors des prompts et des journaux.
• Les environnements sont séparés.

Contrôles de sécurité

Confirmez que :

• Les défenses contre l’injection de prompts sont testées.
• Les cas d’injection indirecte sont inclus dans l’évaluation.
• Les listes d’outils autorisés sont appliquées.
• Les arguments des outils sont validés côté serveur.
• Les sorties d’outils sont traitées comme des données non fiables.
• L’accès selon le moindre privilège est appliqué.
• Les actions à haut risque sont soumises à des portes de contrôle.
• Les journaux d’audit sont activés.
• Les limites de débit et les délais d’expiration sont configurés.

Contrôles de conformité

Confirmez que :

• La rétention des données est documentée.
• La revue des fournisseurs/sous-traitants est terminée.
• La politique de supervision humaine est définie.
• Les workflows à haut risque sont auditables.
• Les contrôles d’accès sont fondés sur les rôles.
• Les étapes de réponse aux incidents sont documentées.
• Les processus de suppression et d’accès aux données sont compris.
• Les équipes juridique et conformité ont examiné les exigences pertinentes.

Contrôles de mise en production

Confirmez que :

• La suite d’évaluation est réussie.
• Les tests de régression sont terminés.
• Les cas de test de sécurité sont examinés.
• Les alertes de surveillance sont configurées.
• Le chemin de rollback est testé.
• L’interrupteur d’arrêt d’urgence est testé.
• Un responsable post-publication est désigné.
• La cadence de revue est planifiée.

Un lancement sécurisé n’est pas seulement une étape technique. C’est un engagement opérationnel.

Comment HDWEBSOFT aide les équipes à sécuriser les systèmes LLM et d’IA agentique

Déployer en toute sécurité des agents alimentés par des LLM exige à la fois de l’ingénierie IA et une réflexion sécurité. Les équipes doivent concevoir des workflows, intégrer des outils, protéger les données, tester le comportement et surveiller les systèmes en production sans ralentir inutilement la livraison.

HDWEBSOFT aide les équipes à planifier, construire et sécuriser des systèmes IA avec un accompagnement d’ingénierie pratique. Si votre organisation prépare le déploiement d’un LLM ou d’une IA agentique, notre équipe peut soutenir la conception de l’architecture, la mise en œuvre de workflows IA, l’intégration d’outils, la revue de sécurité et la préparation à la production.

Découvrez nos services de développement IA pour une mise en œuvre IA sécurisée et nos services de cybersécurité pour l’évaluation de sécurité, la revue des risques et des contrôles de production renforcés.

Conclusion

La sécurité LLM ne se résume pas à un prompt, une politique ou une checklist. Pour l’IA agentique, elle doit couvrir tout le système : prompts, données récupérées, outils, permissions, journaux, approbations humaines, tests et surveillance en production.

Les équipes qui déploieront en toute sécurité seront celles qui traiteront la sécurité comme une partie de l’architecture dès le départ. Les contrôles contre l’injection de prompts, l’accès aux outils selon le moindre privilège, la planification de la résidence des données, les workflows HITL et l’évaluation continue travaillent ensemble pour réduire le risque.

Pour les environnements de production UE/États-Unis, l’objectif n’est pas seulement de rendre l’agent utile. L’objectif est de le rendre contrôlé, auditable, résilient et suffisamment sûr pour fonctionner dans de vrais workflows métier.

FAQ

Qu’est-ce que la sécurité LLM ?

La sécurité LLM consiste à protéger les systèmes alimentés par des LLM contre l’injection de prompts, les fuites de données, l’utilisation non autorisée d’outils, les sorties dangereuses et les manquements à la conformité. Pour l’IA agentique, elle inclut aussi les permissions d’outils, les journaux d’audit, les workflows HITL, les tests et la surveillance.

Pourquoi la sécurité LLM est-elle plus difficile pour les agents IA ?

La sécurité LLM est plus difficile pour les agents IA parce que les agents peuvent agir. Ils peuvent récupérer des documents, appeler des API, mettre à jour des systèmes ou déclencher des workflows. Cela signifie que la sécurité doit protéger non seulement les sorties du modèle, mais aussi les outils et les données connectés à l’agent.

Comment prévenir l’injection de prompts dans les agents LLM ?

La prévention de l’injection de prompts exige des contrôles en couches. Les équipes doivent séparer les instructions de confiance du contenu non fiable, valider les appels d’outils, appliquer l’accès selon le moindre privilège, traiter le contenu récupéré comme des données, ajouter des contrôles de politique, surveiller les schémas suspects et tester avec des cas adversariaux.

Qu’est-ce que l’injection indirecte de prompts ?

L’injection indirecte de prompts se produit lorsque des instructions malveillantes sont cachées dans le contenu lu par l’agent, comme des pages web, des e-mails, des documents, des tickets d’assistance, des PDF ou des résultats RAG. L’agent peut traiter ce contenu comme une instruction, sauf si le système est conçu pour l’isoler et le valider.

Comment sécuriser les appels d’outils pour les agents LLM ?

La sécurisation des appels d’outils exige un accès selon le moindre privilège, des API à périmètre défini, des listes d’outils autorisés, des schémas structurés, la validation côté serveur des arguments, la validation des sorties, des limites de débit, le sandboxing des outils à haut risque, la gestion des secrets et la journalisation d’audit des actions d’outils.

Quel est l’impact de la résidence des données sur les applications LLM ?

La résidence des données détermine où les prompts, les documents récupérés, les embeddings, les sorties et les journaux sont traités et stockés. Les déploiements UE/États-Unis doivent cartographier les flux de données, examiner les paramètres des fournisseurs, configurer la rétention et choisir des modèles d’architecture adaptés aux exigences de confidentialité et de conformité.

Que doivent tester les équipes avant de déployer des agents LLM ?

Les équipes doivent tester la réussite des tâches, la résistance à l’injection de prompts, les scénarios d’injection indirecte, les permissions d’outils, les fuites de données, les contrôles d’accès RAG, les flux d’approbation HITL, le comportement de régression, les alertes de surveillance, la latence, le comportement des coûts, les chemins de rollback et le comportement de l’interrupteur d’arrêt d’urgence.