La génération augmentée par la récupération d'informations offre à l'IA quelque chose que les modèles de base ne possèdent pas par eux-mêmes : un accès direct aux connaissances de l'entreprise.
Voilà sa valeur.
C'est aussi un problème de sécurité.
Un système RAG peut effectuer des recherches dans des documents, des bases de données, des plateformes de collaboration, des bases de connaissances, le stockage cloud, les applications SaaS, les bases de données vectorielles et d'autres sources d'entreprise avant de transmettre les informations récupérées à un modèle d'IA générative.
La question de la sécurité n'est plus simplement, “ Peut-on faire confiance à ce modèle ? ”
Cela devient :
“ Cet utilisateur, cette application, ce copilote ou cet agent d’IA aurait-il dû être en mesure de récupérer ces données dès le départ ? ”
Cette distinction est importante.
Une application RAG parfaitement fonctionnelle peut néanmoins provoquer un incident de sécurité si elle récupère informations sensibles pour une mauvaise identité. Une forte injection rapide La sécurité ne peut compenser un accès excessif. Une base de données vectorielle sécurisée ne garantit pas que les données qu'elle contient y soient légitimes.
La sécurité RAG démarre donc avant même que l'invite n'atteigne le modèle.
Les organisations ont besoin d'une approche globale pour Sécurité RAG tout au long du processus de récupération, depuis les données sources et l'indexation jusqu'aux magasins de vecteurs, aux identités, aux autorisations, à la récupération, aux invites, aux réponses, aux agents et aux actions en aval.
RAG Security : Points clés à retenir
- La récupération est un événement d'autorisation. Un système RAG doit récupérer les informations en fonction de leur pertinence et du fait que l'identité requérante soit autorisée à y accéder.
- La sécurité RAG ne se limite pas à l'injection rapide. Les organisations doivent également s'attaquer aux problèmes d'exposition des données sensibles, d'accès excessif, d'indexation non sécurisée, de contenu corrompu, de risque lié aux bases de données vectorielles, de fuite de données, de traçabilité et de traitement des données de sortie.
- La possibilité de recherche ne doit pas signifier l'accessibilité. L'indexation des données d'entreprise pour l'IA ne doit pas étendre silencieusement le nombre de personnes ou de systèmes pouvant y accéder.
- Le contenu récupéré ne doit pas être considéré comme fiable. Les documents, sites web, courriels, enregistrements et autres informations récupérées peuvent contenir des instructions malveillantes ou trompeuses.
- Les agents font monter les enchères. Un agent compatible RAG peut récupérer des informations sensibles puis utiliser des API, des applications et des outils pour agir en conséquence.
- La sécurité RAG nécessite un contexte de données. La sensibilité, l'identité, l'accès, la propriété, la traçabilité, la politique, l'activité et la finalité commerciale déterminent si la récupération crée un risque significatif.
Qu'est-ce que RAG Security ?
La sécurité RAG consiste à protéger les données, le processus de récupération, les identités, les autorisations, les invites, les sorties et les actions en aval impliquées lorsque les systèmes de génération augmentée par récupération utilisent des informations externes pour générer des réponses d'IA.
La génération augmentée par récupération, ou RAG, connecte un modèle d'IA générative à des informations extérieures aux données d'entraînement originales du modèle.
Un flux de travail RAG typique ressemble à ceci :
- Les données d'entreprise entrent dans un pipeline d'indexation ou d'ingestion.
- Le système traite le contenu et peut créer des intégrations.
- Une base de données indexée ou vectorielle stocke des représentations consultables.
- Un utilisateur ou un système d'IA soumet une requête.
- La couche de récupération trouve les informations pertinentes.
- L'application ajoute le contexte récupéré à l'invite du modèle.
- Le modèle génère une réponse en fonction de ce contexte.
- Une application ou un agent peut utiliser la réponse dans un autre flux de travail ou une autre action.
Chaque étape peut présenter des risques pour la sécurité.
Cela signifie que la sécurisation du seul modèle, de l'invite ou de la base de données vectorielle laisse des parties importantes de l'architecture RAG en dehors du périmètre de sécurité.
Sécurisez les données derrière RAG
Sachez ce que l'IA peut récupérer avant qu'elle n'atteigne l'invite
Découvrez les données RAG sensibles, comprenez les accès, retracez la lignée, protégez les interactions avec l'IA et réduisez l'exposition de la source à la récupération jusqu'à l'action.
Pourquoi RAG Security est bien plus qu'une simple injection rapide
Injection rapide Ce point mérite d'être souligné car les systèmes RAG traitent régulièrement du contenu externe susceptible de contenir des instructions malveillantes.
Mais l'injection rapide ne représente qu'une partie de la surface d'attaque RAG.
Prenons l'exemple d'une application RAG qui rejette parfaitement toute instruction malveillante mais récupère les documents confidentiels de la direction pour chaque employé.
L'invite de commande est sécurisée. L'accès aux données ne l'est pas.
Ou envisagez un système RAG qui respecte les autorisations mais indexe les secrets, les enregistrements obsolètes, les informations personnelles inutiles ou les données dont l'utilisation par l'IA est interdite par la politique en vigueur.
L'autorisation fonctionne. La gouvernance des données, non.
Un RAG sécurisé nécessite donc plusieurs couches :
- sécurité des données sources
- Découverte et classification des données
- Contrôles d'indexation
- Sécurité des bases de données vectorielles
- Gouvernance des identités et des accès
- Autorisation de récupération
- défenses par injection rapide
- Protection rapide et réactive
- Commandes de sortie
- Autorisations de l'agent et de l'outil
- Surveillance des activités
- Lignée et auditabilité
- Remédiation
L’objectif n’est pas simplement d’empêcher les messages inappropriés. Il s’agit d’empêcher, dès le départ, que des données inappropriées parviennent à la mauvaise interaction avec l’IA.
Le cycle de vie de la sécurité RAG
Le chemin de sécurité RAG
Protéger les données d'entreprise, de la source à la récupération et à l'exploitation
Chaque étape pose une question de sécurité différente.
La sécurité des sources pose la question de savoir si les données devraient tout simplement alimenter l'IA.
La sécurité de l'index vérifie si du contenu sensible ou restreint a été introduit dans la couche de récupération.
La gouvernance des accès s'interroge sur les identités qui ont un besoin professionnel légitime.
La sécurité de récupération demande si la requête actuelle doit renvoyer une information spécifique.
Le système de sécurité Prompt vérifie si des données sensibles ou des instructions malveillantes ont pénétré l'interaction avec l'IA.
La sécurité de l'agent demande ce que l'IA peut faire après la récupération.
La sécurité RAG est compromise lorsque les organisations traitent ces éléments comme un seul problème de contrôle.
Quels sont les principaux risques de sécurité liés aux chiffons ?
1. Exposition de données sensibles
Les systèmes RAG connectent souvent l'IA directement aux informations d'entreprise à forte valeur ajoutée.
Cela peut inclure :
- PII
- PHI
- Informations de paiement
- Identifiants et secrets
- Code source
- propriété intellectuelle
- documents juridiques
- Informations financières
- Dossiers des employés
- Données client
- Informations commerciales confidentielles
Si les équipes ignorent quelles informations sensibles alimentent l'architecture RAG, elles ne peuvent pas déterminer avec certitude quels événements de récupération présentent un risque.
Découverte et classification des données Cela devrait donc se produire avant et pendant tout le déploiement du RAG.
2. Accès excessif aux chiffons
Un utilisateur peut avoir un accès légitime à l'application RAG sans pour autant avoir un accès légitime à tout ce que l'application peut récupérer.
Cette distinction devient cruciale lorsque RAG combine des informations provenant de référentiels ayant des autorisations différentes.
Les équipes de sécurité doivent comprendre :
- Qui peut interroger le système RAG ?
- Quelle identité effectue la récupération ?
- Quelles autorisations de source s'appliquent
- Le système conserve-t-il ces autorisations après l'indexation ?
- Que ce soit les comptes de service ou identités de machines introduire un accès plus large
- Que les agents d'IA hériter de permissions excessives
L'accès à l'interface d'IA ne doit pas signifier l'accès à tous les documents sous-jacents.
3. Perte d'autorisation lors de l'indexation
Les référentiels d'entreprise contiennent déjà des contrôles d'accès.
Les architectures RAG peuvent affaiblir ces contrôles si l'indexation dissocie le contenu des permissions associées à la source.
Un fichier confidentiel, accessible uniquement à cinq employés, peut être intégré à un index partagé ou à un système de stockage vectoriel. Si le système de recherche ne reconnaît plus le contexte d'autorisation initial, un public plus large peut accéder à son contenu.
Secure RAG doit préserver ou reconstruire le contexte d'autorisation au moment de la récupération.
4. Injection indirecte rapide
Les systèmes RAG récupèrent intentionnellement du contenu que le modèle n'a pas créé et que l'utilisateur ne contrôle pas nécessairement.
Ce contenu peut contenir des instructions malveillantes.
Un attaquant peut placer des instructions dans un document, un courriel, une page Web, un ticket d'assistance, une entrée de base de connaissances ou toute autre source que le système RAG récupère ultérieurement.
Le modèle peut alors interpréter ces instructions dans le cadre de sa tâche.
C'est injection indirecte rapide.
Les organisations doivent traiter le contenu récupéré comme des données non fiables plutôt que de lui accorder automatiquement l'autorité d'instructions d'application ou de système.
5. Exposition de la base de données vectorielles
Les bases de données vectorielles et les index peuvent contenir des représentations de contenus et de métadonnées d'entreprise sensibles qui fournissent un contexte précieux pour la récupération par l'IA.
Les équipes de sécurité doivent comprendre quelles données sont stockées dans les conteneurs de sécurité, quelles informations sensibles ces conteneurs représentent, qui peut y accéder et s'ils restent soumis à une politique appropriée.
BigID peut Analyser les bases de données vectorielles pour détecter les informations sensibles et réglementées, offrant ainsi aux équipes une visibilité sur les données qui prennent en charge les charges de travail RAG.
6. Empoisonnement des données et sources non fiables
Des attaquants ou des utilisateurs non autorisés peuvent tenter d'ajouter du contenu trompeur, malveillant ou manipulé à une base de connaissances RAG.
Même sans injection immédiate, des informations erronées peuvent affecter la qualité de la récupération et les réponses du modèle.
Les organisations doivent comprendre d'où provient le contenu RAG, qui peut le modifier, si la source reste fiable et comment les équipes valident les modifications.
7. Données obsolètes ou inappropriées
La sécurité n'est pas la seule raison de contrôler le contenu RAG.
Des données obsolètes, dupliquées, inexactes, inutiles ou mal gérées peuvent produire des réponses incorrectes ou inappropriées.
Un pipeline RAG sécurisé doit également prendre en compte la qualité des données, leur conservation, leur propriété, leur finalité et leur cycle de vie.
8. Fuite de messages et de réponses sensibles
RAG peut introduire des informations sensibles dans le contexte du modèle même si l'utilisateur ne les a jamais saisies directement.
Une fois récupérées, les informations sensibles peuvent apparaître dans les invites, les réponses, les journaux, les historiques de conversation ou les applications en aval.
Protection contre les invites IA permet d'identifier les valeurs sensibles dans les invites et les réponses de l'IA, d'appliquer des politiques ciblées, de masquer les valeurs à risque et d'enquêter sur l'exposition.
9. Traçabilité des données RAG incomplète
Lorsqu'une réponse d'IA contient des informations sensibles, inexactes ou interdites, les équipes doivent comprendre d'où elle provient.
Cela nécessite une traçabilité à travers les systèmes sources, les pipelines, la récupération et les flux de travail d'IA en aval.
Traçabilité des données permet de relier les données d'IA à leur origine et fournit un contexte pour la gouvernance, l'investigation et la correction.
10. Risque RAG lié à l'agent
Le RAG prend une importance accrue lorsqu'un agent d'IA peut agir sur les informations récupérées.
Un agent peut récupérer des données client et mettre à jour un CRM. Il peut lire un document et envoyer un courriel. Il peut interroger une base de données et appeler une autre API.
Cela crée une chaîne :
Recherche → Information → Décision → Outil → Action
Si l'agent dispose de permissions excessives, une récupération inappropriée peut devenir une action inappropriée.
Gouvernance de l'accès à l'IA permet de connecter les agents, les copilotes, les applications, les identités des machines, les autorisations et les données sensibles afin que les équipes puissent identifier les cas où l'accès à l'IA dépasse les besoins légitimes de l'entreprise.
Sécurité RAG vs. Sécurité Prompt vs. Sécurité des bases de données Vector
Ces termes décrivent des problèmes connexes, mais ils ne doivent pas devenir interchangeables.
| Zone | Question de sécurité principale | Risques typiques |
|---|---|---|
| Sécurité RAG | Une identité correcte peut-elle permettre de récupérer les données correctes en toute sécurité ? | Récupération sensible, accès excessif, perte d'autorisation, contenu empoisonné, injection immédiate, fuite, utilisation en aval non sécurisée |
| Sécurité rapide | Quels contenus sensibles ou malveillants entrent et sortent des conversations avec l'IA ? | Injection d'invite, données d'invite sensibles, fuite de réponses, violations de politiques |
| Sécurité des bases de données vectorielles | Quelles données contient la couche vectorielle, et qui peut y accéder ? | Exposition de données sensibles, contrôles d'accès insuffisants, indexation inappropriée, stockage non géré, fuite de données |
Une sécurité RAG efficace nécessite les trois perspectives.
Pourquoi le contrôle d'accès RAG est important
La recherche traditionnelle demande :
“ Quel contenu correspond le mieux à cette requête ? ”
Enterprise RAG doit se poser une autre question :
“ Quel contenu correspondant cette identité peut-elle réellement récupérer ? ”
Cela fait de la récupération un événement d'autorisation.
Prenons l'exemple de deux employés qui posent la même question au même assistant d'entreprise.
L'une travaille aux ressources humaines et a un accès légitime aux dossiers de rémunération des employés. L'autre n'en a pas.
La pertinence sémantique des documents reste inchangée d'un utilisateur à l'autre.
La décision d'autorisation devrait.
Les directives RAG actuelles de Microsoft Il est recommandé d'appliquer le contrôle d'accès lors de la récupération et de considérer le contenu récupéré comme une entrée non fiable. Microsoft Azure AI Search prend également en charge les contrôles d'accès au niveau du document et l'application des autorisations lors de la requête, afin que les résultats de la recherche reflètent l'autorisation de l'identité effectuant la requête. Ces pratiques soulignent la nécessité d'associer la pertinence de la recherche à l'autorisation plutôt que de considérer les résultats de recherche comme un contexte intrinsèquement sûr.
Secure RAG devrait donc prendre en considération :
- Identité de l'utilisateur
- Identité de l'agent ou de l'application
- Autorisations de la source
- Groupes et rôles
- Sensibilité des données
- Objectif commercial
- Possession
- Politique
- droits d'accès actuels
La pertinence détermine ce que l'IA peut extraire. L'autorisation détermine ce qu'elle doit extraire.
Pourquoi l'identité se complexifie-t-elle dans RAG ?
RAG ne récupère pas toujours les données directement comme l'utilisateur humain.
Le processus de récupération peut impliquer :
- Identités des utilisateurs
- identités de l'application
- Comptes de service
- Identités des machines
- Autorisations OAuth
- Rôles cloud
- Identifiants API
- Agents d'intelligence artificielle
Cela peut créer un déséquilibre dangereux.
Un utilisateur disposant d'un accès limité peut interagir avec une application d'IA dont le compte de service backend possède un accès beaucoup plus étendu.
Si l'application RAG récupère des données en utilisant cette identité plus large sans préserver le contexte d'autorisation de l'utilisateur, l'IA peut devenir un moyen de contourner les contrôles d'accès existants.
Les équipes de sécurité doivent donc comprendre les deux qui a posé la question et quelle identité a effectivement permis de récupérer la réponse ?.
Comment sécuriser RAG : 10 bonnes pratiques
1. Identifier toutes les sources de données alimentant RAG
Inventoriez les bases de données, les systèmes de fichiers, les plateformes de collaboration, les applications SaaS, le stockage cloud, les bases de connaissances, les entrepôts de données vectorielles et les sources externes qui alimentent la récupération.
Les équipes ne peuvent pas gérer des données RAG qu'elles ne peuvent pas voir.
2. Classer les données avant l'indexation
Identifier les informations sensibles, réglementées, confidentielles, exclusives, d'identification, financières, de santé, personnelles et autres informations à haut risque avant qu'elles n'entrent dans la couche de récupération.
Utilisez la classification pour déterminer quelles données l'IA peut utiliser, lesquelles nécessitent des contrôles supplémentaires et lesquelles doivent rester en dehors du processus RAG.
3. Minimiser les données RAG
N’indexez pas une information simplement parce qu’elle existe.
Demandez-vous si le cas d'utilisation de l'IA nécessite réellement ces données.
Minimisation des données réduit le volume d'informations inutiles ou inappropriées disponibles pour les systèmes de recherche.
4. Préserver l'autorisation par la récupération
Ne supprimez pas les autorisations de source lorsque le contenu est indexé.
Appliquer le contexte d'identité et d'accès afin que la récupération respecte les besoins légitimes de l'entreprise.
Dans la mesure du possible, évaluez l'accès au moment de la requête plutôt que de supposer que chaque utilisateur RAG authentifié doit effectuer une recherche dans l'ensemble du corpus.
5. Appliquer le principe du moindre privilège aux identités RAG
Limitez les comptes de service, les applications, les API, les identités de machines, les copilotes et les agents aux informations nécessaires à leur finalité approuvée.
Un système d'IA compromis ou manipulé ne peut pas récupérer des données auxquelles son identité n'a pas accès.
6. Traiter le contenu récupéré comme non fiable
Séparez le contenu externe des instructions système et applicatives de confiance.
Documents de test, contenu web, courriels et autres sources RAG pour injection indirecte rapide scénarios.
7. Protéger les invites et les réponses
Surveillez les interactions avec l'IA afin de détecter toute information sensible saisie dans les invites ou apparaissant dans les réponses.
Appliquer les politiques, les contrôles d'accès, les procédures de rédaction et les flux de travail d'enquête le cas échéant.
8. Cartographier la lignée des données RAG
Relier les informations indexées et récupérées à des sources faisant autorité.
Lineage aide les équipes à examiner les réponses problématiques, à établir la responsabilité, à valider la provenance des données et à déterminer où des mesures correctives doivent être prises.
9. Surveiller l'accès et l'activité
Comprendre quelles identités accèdent aux données sensibles et comment ce comportement évolue au fil du temps.
Surveillance de l'activité des données ajoute un contexte d'utilisation qui peut aider les équipes à identifier les accès risqués ou inattendus à des informations sensibles.
10. Intégrer la remédiation au cycle de vie RAG
Les conclusions du RAG doivent déboucher sur des actions concrètes.
Les équipes pourraient avoir besoin de :
- Supprimer des données d'un index
- Réduire l'accès excessif
- Autorisations de source correctes
- Rédiger des informations sensibles
- Mise en quarantaine du contenu inapproprié
- Rétention des changements
- Révoquer l'accès de l'agent
- Désactiver une source de données
- Désigner un propriétaire
- Politique de mise à jour
Contrôler ce que RAG peut atteindre
Associer la récupération aux données sensibles et à l'accès légitime
Déterminez quels utilisateurs, applications, identités de machines, copilotes et agents peuvent accéder aux données sensibles de l'entreprise, puis identifiez les cas où les autorisations dépassent les besoins de l'entreprise.
Liste de contrôle de sécurité RAG
Préparation à la sécurité RAG
Votre équipe de sécurité peut-elle répondre à ces questions ?
✓ Quels référentiels et sources de données alimentent chaque système RAG ?
✓ Quelles informations sensibles ou réglementées sont extraites ?
✓ Quelles données ne doivent jamais entrer dans le pipeline RAG ?
✓ Où se trouvent les plongements lexicaux et les représentations vectorielles ?
✓ Les index préservent-ils l'autorisation source ?
✓ Quelle identité effectue la récupération ?
✓ Différents utilisateurs peuvent-ils récupérer des informations différentes en fonction de leurs droits d'accès ?
✓ Les comptes de service ou les identités machine disposent-ils d'un accès excessif ?
✓ Le contenu récupéré peut-il introduire des instructions malveillantes ?
✓ Les données sensibles récupérées peuvent-elles apparaître dans les invites ou les réponses ?
✓ Les équipes peuvent-elles retracer le contenu récupéré jusqu'à sa source ?
✓ Quels agents peuvent agir sur les informations récupérées ?
✓ Les équipes peuvent-elles surveiller l'accès aux données RAG sensibles ?
✓ Les équipes peuvent-elles supprimer des données, réduire l'accès et prouver la remédiation lorsque le risque évolue ?
Erreurs de sécurité courantes liées aux RAG
Sécuriser le modèle mais pas la couche de récupération
Les mécanismes de protection du modèle ne peuvent pas corriger les accès excessifs ou l'indexation inappropriée en amont.
En supposant que l'authentification équivaut à l'autorisation
Un utilisateur qui peut se connecter à une application RAG ne devrait pas avoir automatiquement accès à tous les documents qu'elle peut consulter.
Utilisation d'un compte de service privilégié pour chaque récupération
Une identité backend largement privilégiée peut effacer les différences significatives entre les utilisateurs, à moins que l'application ne préserve et n'applique le contexte d'autorisation.
En supposant que le magasin de vecteurs ne contienne aucune donnée sensible
Les systèmes d'intégration et l'infrastructure vectorielle font partie intégrante du programme de sécurité des données. Les équipes ont besoin de visibilité sur le contenu sous-jacent, les métadonnées et les informations sensibles représentées par la couche de recherche.
Se concentrer uniquement sur l'injection rapide
L'injection rapide est importante, mais l'exposition des données sensibles, l'accès, l'empoisonnement, la traçabilité, la qualité des données, les autorisations excessives, les fuites de données de sortie et les actions des agents le sont tout autant.
Oublier ce qui se passe après la récupération
Une réponse peut alimenter une autre application, un agent, une API, une décision ou un flux de travail.
La sécurité RAG doit assurer le suivi des données sensibles au-delà de leur simple récupération, lorsque l'IA peut utiliser ces informations pour agir.
Comment BigID contribue à sécuriser RAG
Approches BigID sécurité RAG d'entreprise à partir des données.
Le risque RAG ne dépend pas uniquement du modèle ou de la base de données vectorielles. Il dépend de Quelles données d'entreprise sont extraites, leur niveau de sensibilité, leur provenance, les identités qui peuvent y accéder, les politiques applicables et les possibilités offertes par l'IA après leur extraction.
BigID aide les organisations :
- Découvrir et classer les données RAG : Identifier les informations sensibles, réglementées, confidentielles, exclusives, personnelles, d'identification et critiques pour l'entreprise à travers les sources de données de l'entreprise et les charges de travail d'IA.
- Identifier les données sensibles dans les bases de données vectorielles : Analyser les bases de données vectorielles et identifier les informations sensibles et réglementées utilisées par les charges de travail de récupération d'IA.
- Traçabilité des données de l'IA cartographique : Connecter les données via les systèmes sources, les pipelines, la récupération, l'inférence et les flux de travail d'IA en aval.
- Accès à l'IA de gouvernance : Connectez les utilisateurs, les agents, les copilotes, les applications, les comptes de service, les identités des machines, les autorisations et les données sensibles afin d'identifier les accès excessifs.
- Protéger les invites et les réponses : Détecter les valeurs sensibles dans les conversations avec l'IA, appliquer des politiques ciblées, masquer les informations à risque, surveiller les violations et soutenir les enquêtes et les mesures correctives.
- Sécuriser les pipelines de données d'IA : Découvrir, classer, nettoyer, gouverner et contrôler les données avant leur intégration dans les flux de travail d'IA d'entraînement, de réglage, de récupération ou de production.
- Ajouter le contexte de l'activité : Comprendre comment les données sensibles sont consultées et utilisées dans les environnements d'entreprise.
- Remise en état du lecteur : Relier les résultats à la réduction des accès, à l'application des politiques, à la propriété, aux flux de travail et aux mesures correctives.
L'objectif n'est pas simplement d'améliorer les réponses de RAG. Il s'agit de garantir que l'IA récupère les données pertinentes pour la bonne identité, conformément à la politique appropriée et dans le but précis.
Connecter les points entre les données et l'IA
Sécuriser RAG en commençant par les données sous-jacentes
Découvrez comment BigID détecte les données RAG sensibles, cartographie la lignée et l'accès, protège les interactions IA, identifie les autorisations excessives, applique les politiques et pilote la remédiation au sein de l'IA d'entreprise.
FAQ sur la sécurité de RAG
Qu'est-ce que la sécurité RAG ?
La sécurité RAG protège les données, le processus de récupération, les identités, les autorisations, les invites, les sorties et les actions en aval impliquées lorsque les systèmes de génération augmentée par récupération utilisent des informations externes pour générer des réponses d'IA.
Quels sont les principaux risques de sécurité liés à RAG ?
Les principaux risques de sécurité RAG incluent l'exposition de données sensibles, l'accès excessif, la perte d'autorisation lors de l'indexation, l'injection indirecte de prompts, l'exposition de bases de données vectorielles, l'empoisonnement des données, les données obsolètes ou inappropriées, les fuites de prompts et de réponses, la traçabilité incomplète et les actions risquées des agents.
Comment le RAG crée-t-il un risque pour la sécurité des données ?
RAG connecte l'IA générative directement aux données externes lors de l'inférence. Si la couche de récupération contient des informations sensibles ou applique une autorisation faible, l'IA risque d'accéder à des informations auxquelles l'utilisateur, l'application ou l'agent demandeur ne devrait pas avoir accès.
Qu'est-ce que le contrôle d'accès RAG ?
Le contrôle d'accès RAG détermine les informations qu'un utilisateur, une application ou une identité d'IA peut consulter en fonction des autorisations, des rôles, de la sensibilité des données, des politiques et des besoins métier. Un RAG sécurisé doit associer pertinence sémantique et autorisation.
Pourquoi RAG devrait-il appliquer une autorisation au moment de la récupération ?
Différentes identités peuvent avoir des droits différents sur un même contenu. L'évaluation des autorisations lors de la récupération des données permet d'éviter qu'une interface d'IA partagée ne divulgue des informations dépassant les droits d'accès légitimes de l'identité requérante.
Qu'est-ce qu'un RAG prenant en compte les permissions ?
Le RAG prenant en compte les autorisations préserve ou évalue le contexte d'accès lors de la récupération d'informations d'entreprise afin que les utilisateurs et les systèmes d'IA ne reçoivent que le contenu auquel ils ont une autorisation légitime d'accéder.
Quel est l'effet de l'injection rapide sur le RAG ?
RAG peut récupérer des documents, des pages web, des courriels, des enregistrements ou tout autre contenu contenant des instructions malveillantes. Si l'IA interprète ces instructions comme des commandes fiables, un attaquant peut manipuler le comportement du modèle par injection indirecte d'instructions.
Les bases de données vectorielles présentent-elles un risque de sécurité RAG ?
Les bases de données vectorielles et les index peuvent contenir des informations et des métadonnées sensibles d'entreprise. Les organisations doivent comprendre quelles données elles contiennent, qui peut y accéder, comment les autorisations s'appliquent et si le contenu sensible ou réglementé doit figurer dans la couche de recherche.
Comment les agents d'IA augmentent-ils les risques de sécurité liés au RAG ?
Les agents d'IA peuvent exploiter les informations après leur récupération en appelant des API, en mettant à jour des applications, en envoyant des messages, en modifiant des enregistrements ou en déclenchant des flux de travail. Des autorisations excessives accordées aux agents peuvent donc transformer une récupération inappropriée en une action inappropriée.
Comment les organisations peuvent-elles sécuriser les systèmes RAG ?
Les organisations peuvent sécuriser RAG en découvrant et en classant les données sources, en minimisant le contenu indexé, en préservant l'autorisation lors de la récupération, en appliquant le principe du moindre privilège, en traitant le contenu récupéré comme non fiable, en protégeant les invites et les réponses, en cartographiant la lignée, en surveillant l'activité et en reliant les résultats à la correction.
Comment BigID prend-il en charge la sécurité RAG ?
BigID aide les organisations à découvrir et à classer les données RAG sensibles, à identifier les informations sensibles dans les bases de données vectorielles, à cartographier la lignée des données d'IA, à connecter les identités et les autorisations d'IA aux données, à protéger les invites et les réponses, à gouverner les pipelines d'IA, à ajouter un contexte d'activité et à piloter la remédiation dans les environnements d'IA d'entreprise.
Auteur
