Qu’est-ce que les garde-fous pour les LLM ?
Les garde-fous des LLM sont des contrôles techniques qui restreignent le comportement des applications alimentées par l’IA en production. Plutôt que de modifier le modèle lui-même, les garde-fous enveloppent le modèle de politiques qui régissent ce qu’il peut voir, ce qu’il peut dire et ce qu’il peut faire à chaque demande.
Les garde-fous fonctionnent au moment de l’inférence et sont appliqués par l’application et son infrastructure environnante. Ils valident les entrées avant que les invites n’atteignent le modèle, inspectent les sorties avant que les réponses n’atteignent les utilisateurs, et contrôlent strictement l’accès aux outils, API, sources de données et ressources cloud.
Il est important de distinguer les garde-corps des autres mécanismes de sécurité apparentés :
Alignement du modèle (temps d’entraînement) : Des techniques d’alignement telles que l’apprentissage par renforcement à partir de retour humain (RLHF) façonnent le comportement de base d’un modèle pendant l’entraînement. Cela améliore la sécurité générale et l’utilité, mais c’est statique et ne tient pas compte du contexte ou des politiques de votre application.
Filtres de contenu fournisseurs (niveau service) : Les fournisseurs cloud proposent des filtres intégrés (par exemple, le filtrage de contenu Azure OpenAI ou les garde-fous Amazon Bedrock) qui bloquent de larges catégories de contenus comme les discours de haine ou la violence. Ces éléments fonctionnent au niveau API et sont volontairement génériques.
Garde-fous des LLM (niveau application) : Les garde-corps sont des contrôles que vous concevez et configurez pour faire respecter Ton Sécurité et règles commerciales. Ils peuvent varier selon l’utilisateur, le rôle, l’environnement ou le cas d’usage, et évoluent à mesure que votre application évolue.
25 agents IA. 257 attaques réelles. Qui gagne ?
De la découverte zero-day à l’escalade des privilèges cloud, nous avons testé 25 combinaisons agent-modèle sur 257 défis réels de sécurité offensive. Les résultats pourraient vous 👀 surprendre
Ces couches sont complémentaires. L’alignement assure une sécurité de base, les filtres du fournisseur bloquent les contenus nuisibles courants, et les garde-fous appliquent la sécurité et les contrôles d’accès spécifiques à chaque application.
En pratique, les garde-corps des LLM fonctionnent comme une sécurité au niveau applicatif pour les systèmes d’IA. Ils appliquent la politique d’inférence avant et après le modèle et veillent à ce que le modèle fonctionne dans les limites définies par vos identités, vos règles de gouvernance des données et les permissions cloud.
Même les LLM gérés ou « sûrs » nécessitent des garde-fous. Un modèle bien aligné peut encore être manipulé à travers injection rapide ou exposés à des permissions excessives à cause d’identités mal configurées. Les garde-fous efficaces doivent donc être superposés, conscients du contexte et étroitement intégrés à l’environnement cloud environnant.
Pourquoi les garde-fous des LLM sont essentiels à la sécurité des applications
Dans les applications modernes, les LLM ne sont plus des interfaces de chat isolées. Ils sont intégrés directement dans la logique applicative, où ils interprètent les entrées de l’utilisateur, récupèrent des données, invoquent des outils et déclenchent des actions en aval. En conséquence, les faiblesses du comportement des LLM deviennent rapidement des risques pour la sécurité des applications.
L’un des risques les plus visibles est l’injection rapide. Les attaquants peuvent manipuler les entrées pour écraser les instructions système ou extraire des comportements inattendus du modèle. Recherche montre que les taux de réussite varient largement selon l’architecture du modèle, les techniques de défense et la complexité des attaques, ce qui rend les statistiques générales moins utiles en pratique. Ce qui compte, c’est la résistance de vos garde-fous spécifiques face à des attaques réalistes en plusieurs étapes dans votre environnement.
Fuite de données est une autre préoccupation majeure. Les LLM ont souvent accès à des bases de connaissances internes, à des sources de génération augmentées par la récupération ou à des données opérationnelles sensibles. Sans contrôles de sortie forts, un modèle peut exposer des informations qui ne devraient jamais quitter le système. Une question simple comme « Que savez-vous de nos systèmes internes ? » peut conduire à une divulgation involontaire si les garde-fous sont faibles ou mal structurées.
L’appel d’outils et l’exécution des fonctions augmentent considérablement les enjeux. Lorsqu’un LLM peut déclencher des appels API, modifier des enregistrements ou interagir avec des ressources cloud, une attaque réussie peut avoir un impact concret. Si l’identité du service sous-jacente est sur-privilégiée, un agent compromis peut accéder à bien plus que prévu. L’application des permissions de privilège minimum limite par défaut le rayon d’explosion, de sorte que même les agents abusés ne peuvent pas causer de dégâts excessifs.
Il est également important de distinguer les problèmes de fiabilité des problèmes de sécurité. Les hallucinations sont un problème de fiabilité où le modèle produit des informations incorrectes. Les actions non autorisées, l’exposition des données et les abus de privilèges sont des problèmes de sécurité que les garde-fous sont conçus pour prévenir. Considérer ces risques comme le même risque conduit à des contrôles mal placés et à une fausse confiance.
En fin de compte, les garde-fous des LLM comptent car les systèmes d’IA se situent désormais sur des limites de confiance critiques. Ils traduisent les entrées non fiables en actions fiables. Sans garde-fous solides et superposés liés à l’identité, à l’accès aux données et aux permissions cloud, les applications d’IA élargissent la surface d’attaque au lieu de la contrôler.
Où s’insèrent les garde-fous des LLM dans une pile d’applications IA modernes
Les garde-fous des LLM couvrent toute la pile d’applications IA plutôt que de rester dans un seul point de contrôle. Pour comprendre comment ils fonctionnent ensemble, il est utile de considérer les garde-fous sur cinq couches : application, API, identité, données, et temps d’exécution et infrastructure.
Au Couche application, les garde-fous façonnent la manière dont les prompts et les réponses sont traités. La validation des entrées vérifie les invites utilisateur pour détecter des motifs malveillants, tandis que les politiques de réponse garantissent que les sorties respectent les règles de formatage, de sécurité et de divulgation. Beaucoup d’équipes commencent ici avec des contrôles de niveau prompt, mais ceux-ci ne couvrent qu’une part étroite du risque global.
Le Couche API régit la manière dont les applications interagissent avec les services LLM. Les garde-fous à ce niveau incluent l’authentification, l’autorisation basée sur les rôles, la limitation de débit et les limites d’utilisation des jetons. Ce sont des contrôles de sécurité web familiers, mais ils deviennent particulièrement importants pour les terminaux d’IA où une seule requête peut consommer d’importantes ressources ou déclencher des actions en aval.
Le Couche identité se concentre sur les comptes de service et les rôles que les composants alimentés par LLM utilisent pour accéder aux ressources cloud. Les garde-fous d’identité imposent un accès au minimum de privilèges afin que les agents IA ne puissent effectuer que les actions explicitement autorisées à effectuer. Lorsque les autorisations d’identité sont trop larges, les garde-fous au niveau de l’application perdent leur efficacité.
Le Couche de données contrôle quels ensembles de données, embeddings et sources de recherche un LLM peut consulter. Les garde-fous de données définissent quels modèles peuvent lire quelles données, comment les informations sensibles sont traitées, et comment la récupération est organisée par utilisateur ou rôle. Ces contrôles sont essentiels pour prévenir l’exposition involontaire de données via des pipelines d’entraînement ou une génération augmentée par la récupération.
Le Temps d’exécution et couche infrastructure couvre les environnements où les services d’IA fonctionnent, y compris les conteneurs, les services LLM gérés et les frontières réseau. Les garde-fous à cette couche incluent l’isolation réseau, la segmentation de la charge de travail et la détection de comportements anormaux à l’exécution. Ces contrôles permettent d’attraper de vraies attaques qui contournent les tests précédents.
En pratique, la propriété de ces couches est répartie entre les équipes. Les équipes applications gèrent les prompts et la logique, les équipes de plateforme gèrent les API et identités, et les équipes de sécurité cloud gèrent l’infrastructure. Les garde-corps des LLM nécessitent une coordination entre tous. La défense en profondeur ne fonctionne que lorsque les contrôles entre les couches sont alignés et appliqués de manière cohérente.
Aide-mémoire sur les meilleures pratiques de sécurité GenAI
Cet aide-mémoire fournit un aperçu pratique des 7 meilleures pratiques que vous pouvez adopter pour commencer à renforcer la posture de sécurité GenAI de votre organisation.
Types de garde-fous de base pour les LLM (et ce qu’ils protègent réellement)
La plupart des garde-fous des LLM se répartissent dans un petit nombre de catégories. Chacun protège une partie différente du système, et chacun a des limites claires. Comprendre ces limites est crucial, car aucune barrière de sécurité ne peut arrêter chaque attaque à elle seule.
Glissières d’entrée
Les garde-corps d’entrée se situent entre l’utilisateur et le modèle. Leur objectif est de détecter et de bloquer les invites malveillantes ou dangereuses avant qu’elles n’atteignent le LLM. Les techniques courantes incluent l’appariement de motifs, la classification par prompt et l’application des limites d’instruction.
Les garde-corps d’entrée peuvent arrêter les attaques évidentes, mais ils sont faciles à contourner grâce à l’encodage, à la formulation indirecte ou à des conversations sur plusieurs tours. Par conséquent, ils doivent être traités comme un filtre précoce plutôt que comme une ligne de défense principale.
Glissières de sortie
Les garde-corps de sortie inspectent les réponses du modèle avant qu’elles ne soient retournées aux utilisateurs. Ils appliquent des règles telles que la suppression des données sensibles, le blocage des sujets interdits ou l’exigence de formats de sortie structurés.
Ces contrôles aident à réduire les fuites accidentelles de données, mais ils dépendent de la précision de la détection. Des techniques d’attaque nouvelles ou une exposition subtile aux données peuvent passer inaperçues, surtout lorsque les sorties sont longues ou générées dynamiquement.
Glissières de protection pour outillage et fonction
Les garde-fous des outils et fonctions contrôlent les actions qu’un LLM peut entreprendre lorsqu’il est autorisé à appeler des API externes ou à exécuter du code. C’est là que le risque de l’IA passe du théorique à l’opérationnel.
Les contrôles efficaces incluent :
Listes d’acceptation d’action par rôle
Définissez quels outils chaque rôle peut invoquer. Le LLM d’un agent de support peut consulter la documentation ou créer des tickets, mais il ne doit jamais modifier les dossiers de facturation ni supprimer les comptes.Contrôles de politique avant exécution
Validez chaque appel d’outil avant l’exécution. Confirmez que l’utilisateur a la permission, que l’action est autorisée dans le contexte actuel, et que la requête ne viole pas les règles commerciales ni les limites de débit.Approbation humaine pour des actions à haut risque
Exiger une confirmation humaine explicite pour les opérations destructrices ou sensibles telles que la suppression de données, les transactions financières ou les modifications de privilèges.Application de la portée et des privilèges
Assurez-vous que les appels d’outils ne peuvent pas dépasser les autorisations de l’identité du service sous-jacent. Si le LLM s’exécute sous une identité en lecture seule, il ne doit pas pouvoir déclencher des opérations d’écriture, même si le modèle les suggère.Contrôles de frontière multi-agents
Lorsque plusieurs agents interagissent, imposez des limites strictes entre eux. Un agent en contact avec le client ne doit pas invoquer directement les outils administratifs appartenant à un autre agent sans autorisation et validation explicites.
Les garde-fous d’outils réduisent le risque d’abus, mais ils échouent lorsque les identités des services sont trop privilégiées. Cela rend les contrôles d’identité tout aussi importants que la logique applicative.
Protections sur l’identité et les autorisations
Les garde-fous d’identité régissent les rôles cloud et les comptes de service utilisés par les composants alimentés par les LLM. Leur objectif est de faire respecter l’accès au moindre privilège afin que les services d’IA ne puissent atteindre que les ressources dont ils ont réellement besoin.
Ces garde-corps limitent le rayon d’explosion en cas de problème, mais ils sont souvent mal configurés dans les environnements réels. Des permissions excessives peuvent saper silencieusement même des contrôles au niveau de l’application bien conçus.
Garde-corps d’accès aux données
Les garde-fous de données contrôlent les ensembles de données, les embeddings et les sources de récupération auxquels un modèle peut accéder. Ils empêchent que des informations sensibles ne soient intégrées dans des messages ou des réponses sans autorisation appropriée.
Ces contrôles dépendent de politiques précises de classification des données et d’accès. Si les données sont mal étiquetées ou si les règles d’accès sont trop larges, les garde-fous perdent leur efficacité.
Rampes de sécurité en temps de jeu
Les garde-fous en temps d’exécution surveillent ce qui se passe réellement en production. Ils analysent le comportement lors des appels API, de l’activité d’identité et de la télémétrie cloud afin de détecter les anomalies et les abus.
Détection à l’exécution Aide à détecter les contournements qui passent les contrôles antérieurs, mais il faut des références et un réglage pour réduire les faux positifs. Combinés au contexte des autorisations d’identité et de la sensibilité des données, les signaux d’exécution deviennent bien plus exploitables.
Meilleures pratiques de sécurité pour LLM [Fiche de triche]
Cette liste de contrôle de 7 pages propose des étapes pratiques et prêtes à être mises en œuvre pour vous guider dans la sécurisation des LLM tout au long de leur cycle de vie, en fonction des menaces du monde réel.
Implémentation de garde-corps LLM dans des environnements cloud
Passer d’un prototype à une application d’IA en production augmente considérablement la complexité de la mise en œuvre de garde-corps. L’endroit et la manière dont les modèles s’exécutent dans le cloud influencent directement l’efficacité de ces contrôles.
Les services LLM managés offrent des protections de base utiles, mais ils n’éliminent pas le besoin de contrôles de sécurité au niveau des applications et du cloud. Azure OpenAI prend en compte l’isolation réseau via Azure Private Link utilisant des points de terminaison privés, ainsi que des identités gérées pour l’authentification. Amazon Bedrock propose des garde-fous intégrés qui vont au-delà du simple filtrage de contenu, incluant les sujets refusés, les vérifications contextuelles de mise à la terre et la détection d’hallucinations via le raisonnement automatisé. Google Vertex AI propose des filtres de sécurité de contenu et s’intègre avec les contrôles de service VPC pour restreindre l’exfiltration de données.
Fiche de triche des bonnes pratiques de sécurité en intelligence artificielle des vertex
Découvrez la fiche de bonnes pratiques de sécurité Vertex AI, un guide pratique pour sécuriser les charges de travail IA avec des recommandations claires, des contrôles réels et des étapes concrètes que vous pouvez appliquer immédiatement.
Ces fonctionnalités gérées réduisent certaines catégories de risques, mais les décisions critiques restent la responsabilité du client. Les équipes contrôlent toujours l’exposition réseau, les permissions d’identité, les politiques d’accès aux données et les configurations de journalisation. Les contrôles cloud-native sont sécurisés comment Le service est consulté, mais ils ne répondent pas entièrement Comment le modèle se comporte Dans une application. Des risques comme l’injection rapide, la mauvaise utilisation des outils et l’abus de logique doivent toujours être gérés au niveau applicatif via des garde-foutres personnalisés.
Cela crée un Modèle de responsabilité partagée entre le fournisseur cloud et le propriétaire de l’application. Les fournisseurs sécurisent la plateforme sous-jacente et offrent des protections de base, tandis que les clients sont responsables de l’application des politiques spécifiques à chaque entreprise, de l’accès au moindre privilège et des garde-fous contextuels.
Les environnements cloud multi-locataires et partagés introduisent des risques supplémentaires. Un seul VPC mal configuré, un point d’accès d’IA accessible publiquement ou un rôle IAM trop large peuvent affaiblir silencieusement les garde-fous au niveau de l’application sans aucun changement dans la logique du modèle.
Configurations incorrectes du cloud sont un point de défaillance fréquent. Lorsque les services d’IA sont exposés à Internet ou fonctionnent sous des identités hautement privilégiées, les attaquants peuvent contourner complètement la validation des prompts et les contrôles d’outils en abusant des API cloud sous-jacentes. Dans ces scénarios, les garde-corps peuvent sembler efficaces lors des essais tout en offrant peu de protection réelle en production.
Le dérapage des glissières de sécurité est un autre défi. Les contrôles existants dans les environnements de développement ou de staging peuvent être affaiblis ou supprimés en production en raison de changements d’urgence, de nouveaux pipelines ou de mises à jour d’infrastructure. Avec le temps, cette dérive crée des brèches que les attaquants peuvent exploiter.
Maintenir des garde-fous efficaces nécessite une validation continue tout au long du cycle de vie. Les contrôles doivent être appliqués de manière cohérente du développement au déploiement et à l’exécution. L’intégration des contrôles de garde-forme dans les pipelines CI et CD permet de détecter les erreurs de configuration avant qu’elles n’atteignent la production.
La défense en profondeur ne fonctionne que lorsque les garde-fous au niveau applicatif, les permissions d’identité, les politiques d’accès aux données et les contrôles d’infrastructure restent alignés à mesure que les systèmes évoluent. Renforcement des protections cloud-native Sécurité de l’IA, mais ils ne remplacent pas le besoin de garde-corps robustes spécifiques à chaque application qui traitent directement le comportement du modèle.
Pourquoi les garde-fous des LLM échouent et comment les attaquants les contournent
Même les déploiements de garde-corps bien intentionnés échouent souvent sous la pression réelle. Comprendre comment les attaquants contournent les contrôles est essentiel pour concevoir des garde-corps qui tiennent la route en production.
L’injection prompte reste la faiblesse la plus visible. Les attaquants s’appuient rarement sur une seule invite malveillante. À la place, ils utilisent des interactions sur plusieurs tours, la manipulation des rôles et des instructions indirectes qui prennent progressivement le dessus sur l’intention du système. Les garde-fous qui n’évaluent que des consignes individuelles manquent souvent ces schémas, permettant à des comportements nuisibles d’apparaître au fil du temps.
Des campagnes de malwares réelles ont commencé à explorer comment intégrer des invites dans des charges utiles malveillantes pour alimenter le comportement à l’exécution. Par exemple, le Nul, câlin Un malware envoyait des invites codées en base64 à un LLM demandant des commandes de reconnaissance système, tentant de recueillir des informations sur l’hôte infecté. Dans ces cas, le modèle n’interagissait pas avec un utilisateur mais était invoqué depuis un environnement compromis, contournant ainsi complètement les garde-fous d’entrée orientés utilisateur.
La dépendance excessive au filtrage de sortie est un autre échec courant. Les filtres qui analysent les réponses pour le contenu interdit peuvent être contournés par l’encodage, l’obfuscation ou en déclenchant des actions nuisibles sans produire de texte manifestement dangereux. Dans de nombreux cas, les conséquences les plus dommageables surviennent lorsque le modèle exécute avec succès une action plutôt que lorsqu’il génère un langage problématique.
L’abus d’outils et de fonctions est plus subtil mais souvent plus dangereux. Dans le Compromis de l’extension développeur Amazon Q, les attaquants inséraient des invites qui demandaient explicitement à un agent IA de supprimer tous les fichiers et ressources cloud accessibles. Bien que l’attaque n’ait finalement pas réussi, elle illustre comment des acteurs malveillants expérimentent des techniques de contournement de garde-corps qui exploitent l’appel d’outils et des contextes d’exécution externes.
Les autorisations d’identité excessives compromettent souvent des barrières autrement solides. Si un LLM fonctionne sous une identité de service avec de larges permissions cloud, un attaquant qui gagne de l’influence sur le modèle peut contourner les contrôles applicatifs et interagir directement avec les API cloud. Dans ces cas, les garde-fous rapides offrent peu de protection car la véritable faiblesse réside dans la gestion de l’identité et des accès.
La dérive entre les environnements est un autre problème récurrent. Les contrôles soigneusement implémentés dans les environnements de développement ou de staging sont souvent affaiblis en production en raison de correctifs d’urgence, de nouvelles intégrations ou de modifications non documentées. Cela crée des angles morts que les attaquants peuvent exploiter bien après la fin des premières vérifications de sécurité.
L’exposition au niveau de l’infrastructure peut complètement contourner les garde-fous des applications. Pour les modèles auto-hébergés, les instances de calcul accessibles publiquement peuvent exposer des services de métadonnées d’instance ou des sources d’identifiants, permettant aux attaquants d’extraire des données sensibles et d’escalader les privilèges. Pour les services d’IA gérés, des terminaux publics mal configurés ou des contrôles réseau faibles permettent de gérer directement Abus d’API sans jamais toucher à la couche d’application.
Dans ces scénarios, un schéma cohérent se dessine. Les garde-corps sont nécessaires, mais ils ne suffisent pas à eux seuls. Les schémas réels d’utilisation abusive, comme ceux observés dans les récentes campagnes de malwares impliquant des charges utiles invoquant l’IA, montrent que les attaquants expérimentent déjà des moyens d’échapper aux défenses centrées sur les prompts. Sans le renforcement des contrôles de sécurité cloud-native qui régissent l’identité, l’accès aux données et l’exposition aux infrastructures, les garde-fous créent un faux sentiment de sécurité plutôt qu’une véritable protection.
Comment Wiz aide à sécuriser les applications d’IA au-delà des garde-fous
Les garde-fous des LLM définissent comment sont les applications d’IA supposé de se comporter, mais ils ne garantissent pas que ces contrôles fonctionnent dans de réels environnements cloud où les menaces interagissent avec les identités, les données et l’infrastructure. Wiz renforce les garde-fous en sécurisant toute la surface d’attaque IA grâce à une visibilité continue, à l’évaluation des risques et à une défense riche en contexte.
Wiz’s Gestion de la posture de sécurité de l’IA (IA-SPM) étend son sans agent CNAPP la base pour inventorier tous les agents, modèles, terminaux et services associés d’IA à travers le cloud et le SaaS. Cela inclut un Lettre de documents IA et un Vue de l’inventaire de l’agent Cela révèle où les agents s’exécutent, quels accès ils ont, et comment ils se connectent aux charges de travail sensibles et aux données. Il cartographie également les expositions aux identités et ressources réelles du cloud en utilisant le Wiz Security Graph afin que les équipes puissent voir non seulement ce qui existe, mais aussi ce qui compte.
La plateforme valide en continu les configurations sécurisées sur des services d’IA tels qu’Azure OpenAI, Amazon Bedrock et Google Vertex AI, y compris la vérification des garde-fous des fournisseurs, des politiques d’identité et des contrôles de données sensibles. Cela permet de détecter les mauvaises configurations et les protections manquantes qui auraient autrement affaibli les garde-fous d’application en production.
Enfin, Wiz corrélant l’activité d’exécution et les signaux de menace avec le contexte cloud afin de détecter les comportements suspects des agents, de tracer les chemins d’attaque potentiels et d’automatiser les actions de réponse. En reliant cela aux autorisations d’identité, à la sensibilité des données et à l’exposition de l’infrastructure, les équipes peuvent prioriser la remédiation en fonction de la véritable exploitabilité plutôt que des lacunes théoriques.
