Les RAG (Retrieval-Augmented Generation) workflow relient les systèmes d'IA aux bases de connaissance de l’entreprise, ce qui fait de l’autorisation de récupération la décision de sécurité la plus importante dans le pipeline. Un agent disposant d'identifiants valides peut faire apparaître des documents auxquels l'utilisateur demandeur n'est pas autorisé à accéder sans déclencher les indicateurs traditionnels de contrôle des accès. Les défenses des données et des modèles sont nécessaires, mais aucune ne régit à elle seule l'autorisation d'extraction. En authentifiant les agents, en appliquant l’autorisation au moment de la requête et en propageant le contexte utilisateur à chaque étape de récupération, un écosystème de sécurité des identités ancré dans un plan de contrôle identitaire peut contribuer à sécuriser les workflows RAG.
Les trois couches de sécurité RAG
Les flux de travail RAG introduisent le risque à trois niveaux distincts. Les conseils en matière de sécurité se concentrent souvent sur deux d'entre eux.
Couche de données | Couche modèle | couche d'identités | |
Ce qu'il protège | La base de connaissances, les magasins de vecteurs et le pipeline de recherche | Entrées, sorties et comportement du LLM | Toute identité humaine et non humaine interagissant avec le workflow RAG |
Principales menaces | Empoisonnement des données, falsification des sources, fuites entre locataires et intégrations non chiffrées | Injection de commande, injection de commande indirecte, divulgation d'informations sensibles, gestion de sortie non sécurisée | Agents sur-autorisés, attaques de délégués confuses, expansion des identités non humaines (NHI), contexte utilisateur invérifiable, pistes d'audit brisées. |
Contrôles de base | Validation des sources, classification des données, chiffrement au repos et en transit, segmentation des tenants, filtrage de l'ingestion. | Assainissement des entrées, filtrage des sorties, garde-fous, validation des appels d’outils, durcissement de l’invite du système | Authentification des agents, autorisation granulaire lors de la récupération, échange de tokens OAuth 2.0, cycle de vie des identités non humaines, surveillance continue. |
Normes pertinentes | ISO 27001, SOC 2, data residency frameworks | OWASP Top 10 pour les applications LLM, NIST IA RMF | OAuth 2.0, OIDC, RFC 8693, Zero Trust Architecture (NIST SP 800-207) |
Maturité dans les conseils pour l'industrie | Bien couvert par les hyperscalers et les fournisseurs de sécurité des applications | Bien couvert par les spécialistes de la sécurité de l'IA | Mal desservis : le plan de contrôle manquant |
Si les couches de données et de modèles sont essentielles, aucune ne répond à la question centrale du RAG : cette identité, humaine ou agent, est-elle autorisée à récupérer ces informations et à agir en conséquence ? Dans de nombreux cas, l'accès technique d'un agent et les autorisations réelles de l'utilisateur demandeur sont deux choses distinctes. Cette lacune constitue le principal problème d'identité dans le domaine de la sécurité des RAG.
Le modèle de menace de sécurité RAG, mis en correspondance avec le top 10 LLM de l'OWASP
Le Top 10 de l'OWASP pour les applications LLM est un framework largement référencé pour l’identification des risques de sécurité dans les systèmes d’IA. Plusieurs des principaux risques ont une dimension identitaire directe dans les architectures RAG.
OWASP LLM risque | Manifestation du RAG | Réponse du plan de contrôle de l'identité |
LLM01 : Injection d'invite | Instructions malveillantes dans le contenu récupéré | Limites de propagation de l'identité Rayon d'explosion |
LLM02 : Divulgation d'informations sensibles | Récupération avec excès de permissions | Autorisation granulaire à la récupération |
LLM06 : Agence excessive | Des agents au champ d'application large | Gouvernance de l'identité non humaine et moindre privilège |
LLM08 : Faiblesses des vecteurs et de l'encodage | Fuite inter-tenants et attaques par inversion des embeddings | L'isolation des tenants est assurée par l'identité |
LLM10 : Consommation illimitée | Appels d'agents non authentifiés | Identités de workload authentifiées et à débit limité |
Identity Governance est un facteur crucial pour chacun de ces risques. Un agent agissant au-delà de son autorité, ou les droits d’un utilisateur laissés sans application en aval, peut transformer n’importe laquelle de ces vulnérabilités en un événement d’exposition des données.
Comment sécuriser les flux de travail RAG étape par étape
Les couches de données et de modèles disposent de guides pratiques matures. Les étapes ci-dessous se concentrent sur la couche d'identité, où la plupart des architectures RAG présentent encore des lacunes, et abordent brièvement les contrôles des données et des modèles.
1. Sécuriser la couche de données : ingestion, stockage vectoriel et récupération
La validation de la source filtre les documents d'origine douteuse avant qu'ils n'atteignent la base de données vectorielle. La classification des données étiquette le contenu en fonction du niveau de sensibilité au moment de l'ingestion, permettant ainsi de prendre des décisions d'autorisation en aval. Le filtrage des PII empêche les données personnelles identifiables d'être intégrées et indexées, réduisant ainsi l'exposition avant même que l'autorisation de récupération ne soit évaluée.
Deux menaces distinctes opèrent à ce niveau et nécessitent des défenses séparées. L’empoisonnement des données corrompt la base de connaissances lors de l’ingestion par le biais de documents sources malveillants ou falsifiés. L'injection indirecte d'invites embarque des instructions dans un contenu par ailleurs légitime afin de détourner le comportement de l'agent au moment de l'inférence ; elle est couverte au niveau du modèle à l'étape 5. Les contrôles d'identité constituent une vérification efficace en amont contre l'injection indirecte d'invites. Lorsqu'une politique d'accès restreint un document, l'agent ne le récupère jamais, quel que soit son contenu.
Dans le magasin vectoriel, le chiffrement au repos et en transit est la norme. La segmentation des tenants permet de maintenir les données isolées entre les tenants dans les architectures multitenant.
Le chiffrement et le filtrage protègent les données contre les personnes non autorisées. Ils n'empêchent pas un agent légitime de récupérer des données auxquelles l'utilisateur demandeur ne devrait pas avoir accès, conformément aux autorisations établies. Il s'agit d'une question d'autorisation.
2. Renforcer l'autorisation granulaire lors de l'extraction
Le contrôle d'accès basé sur les rôles (RBAC) à granularité limitée a été conçu pour des utilisateurs humains ayant des fonctions prévisibles. Dans un workflow RAG, le droit d’un utilisateur sur un dossier n’implique pas le droit sur tous les documents qu’il contient. Les contrôles au niveau des rôles sont trop génériques. Les contrôles des accès au niveau des documents et, dans certaines architectures à niveau d'assurance élevé, les contrôles au niveau des segments, nécessitent un modèle de politique plus granulaire. Deux approches FGA établies s'appliquent à la recherche de RAG :
- Le ReBAC (contrôle d'accès basé sur les relations) accorde l'accès en fonction de la relation de l'utilisateur avec la ressource (par exemple : l'appartenance à un projet, la propriété ou la hiérarchie organisationnelle).
- Le contrôle d'accès basé sur les attributs (ABAC) évalue les attributs de l'utilisateur, de la ressource et du contexte, ce qui est utile lorsque les décisions dépendent des étiquettes de classification des données.
Distinction importante : le filtrage des métadonnées dans le magasin de vecteurs est un point d'application de la politique (PEP), mais le point de décision de la politique (PDP) devrait se situer dans le plan de contrôle de l'identité. Le magasin de vecteurs applique les décisions prises par le moteur de politique ; il ne les prend pas. L'autorisation doit être évaluée par le récupérateur agissant avec une autorité déléguée au nom de l'utilisateur, et non pas uniquement à l'aide des identifiants du système de l'agent. L'intégration du PDP dans le PEP ou dans les identifiants propres au récupérateur est une défaillance architecturale courante.
3. Établir l'identité des agents de l'IA
Les agents d’intelligence artificielle doivent être traités comme des identités non humaines dans l’écosystème de sécurité des identités de l’entreprise. Sans Identity Governance centralisée, les pipeline RAG et les agent qui les servent peuvent proliférer au sein des équipes sans inventaire, propriété ni contrôle des accès, créant ainsi une IA fantôme. La découverte et la gestion de la posture des identités non humaines sont des conditions préalables à leur gouvernance. Vous ne pouvez pas appliquer le principe du moindre privilège aux agents que vous n’avez pas encore recensés. Chaque agent a besoin d'une identité unique, sans clés API partagées ni comptes de service aux autorisations excessives.
La manière dont un agent s'authentifie détermine l'étendue des dommages qu'un identifiant compromis peut causer. Les identifiants du client OAuth 2.0 et mTLS nécessitent toutes deux un secret ou un certificat stocké, bien qu'elles prennent toutes deux en charge la rotation. La fédération des identités pour les charges de travail élimine le besoin de secrets stockés à long terme. La plateforme émet une assertion d’identité signée, que l’agent échange contre un token d'accès à portée limitée et de courte durée. Lorsqu'elle est correctement mise en œuvre et qu'elle fait l'objet d'une rotation, chaque approche offre des propriétés de sécurité plus solides que les clés partagées ou les comptes de service permanents.
4. Propager le contexte utilisateur avec l’échange de token OAuth 2.0
Dans le cadre de la RAG agentique, le problème de l’adjoint confus se produit lorsqu’un agent disposant d’informations d’identification valides récupère des données auxquelles l’utilisateur n’est pas autorisé à accéder. L’échange de jetons OAuth 2.0 (RFC 8693) est l’une des réponses normalisées. Selon la RFC 8693, le token d'identité de l'utilisateur est le sujet et l'identité de l'agent est l'acteur, ce qui établit une chaîne de délégation vérifiable.
Cette orientation de la délégation permet d'atténuer le problème du 'confused deputy' (problème de délégation erronée). L’agent ne peut pas agir au-delà de ce que l’utilisateur est autorisé à voir. L'accès effectif est limité par les droits de l'utilisateur demandeur, et par les champs d'application autorisés de l'agent, mais jamais par l'union des deux. C'est cette contrainte qui permet de combler l'écart d'autorisation à chaque saut.
5. Défendre l'invite et la couche de sortie
L’assainissement des entrées, le filtrage des sorties, les garde-fous et la validation des appels d’outils s’appliquent à l’invite du système et à chaque point où un contenu externe entre dans la fenêtre de contexte. L'injection indirecte est le risque spécifique au RAG qu'il convient de prioriser. L'étape de récupération est un chemin autorisé par lequel un contenu non fiable peut atteindre le modèle. Le Top 10 de l’OWASP pour les applications LLM fournit des conseils d'implémentation largement adoptés pour cette couche.
6. Surveillez, enregistrez et auditez chaque action de l'agent
Chaque recherche, demande, appel d'outil et réponse doit être enregistrée avec le contexte de l'identité de l'agent (quel agent, agissant sous la délégation de qui, a accédé à quoi et quand). Les audits de conformité peuvent alors confirmer que les contrôles d'autorisation ont été appliqués, et pas seulement configurés. L'intégration SIEM/SOAR permet d'intégrer la télémétrie RAG dans le système de surveillance de la sécurité. La détection d'anomalies dans les schémas de récupération peut révéler des signes précoces de compromission des agents, notamment un accès en dehors du cadre normal, des volumes incompatibles avec les droits de l'utilisateur initiateur ou des écarts par rapport aux bases comportementales établies.
7. Appliquer Zero Trust dans l'ensemble du workflow RAG
Dans le système RAG, le Zero Trust s'exprime principalement par une autorisation tenant compte de l'identité au niveau de la couche de recherche, et pas seulement à travers les limites du réseau. Ne faites jamais confiance, vérifiez toujours, y compris les appels d’agent à agent au sein d’un même workflow. Les tokens de courte durée, l’autorisation continue et l’application de la politique à chaque saut sont l’expression opérationnelle de ce principe. La norme NIST SP 800-207 constitue une référence fondamentale pour le Zero Trust.
Quand le RAG devient agentique : quels changements pour la sécurité ?
Les sept contrôles ci-dessus s'appliquent à tout RAG workflow. Lorsque le RAG devient agentique, introduisant un raisonnement en plusieurs étapes, l'appel d'outils et la délégation d'agents en chaîne, chaque étape représente une nouvelle occasion d'aggraver les lacunes en matière d'autorisation. Le plan de contrôle de l'identité doit propager le contexte utilisateur à chaque saut, y compris lors des appels d'agent à agent et d'agent à application, et pas uniquement lors de la récupération initiale. Les modèles de délégation basés sur les standards étendent l’échange de tokens OAuth 2.0 aux appels en aval, ce qui permet de garantir qu’aucun agent de la chaîne ne dépasse les droits de l’utilisateur demandeur.
Erreurs courantes en matière de sécurité RAG
De nombreuses défaillances de sécurité RAG à fort impact sont des défaillances d'identité prévisibles qui s'aggravent discrètement.
- Traiter les autorisations de l'agent comme celles de l'utilisateur : l'agent peut avoir un accès plus large que l'utilisateur qu'il sert. Lorsque le récupérateur agit sur les identifiants de l'agent, plutôt que sur les droits de l'utilisateur, il peut renvoyer des documents que l'utilisateur n'a jamais été autorisé à consulter.
- S'appuyer sur le LLM pour appliquer le contrôle des accès : le modèle ne peut pas déterminer ce à quoi l'utilisateur est autorisé à accéder. En déplaçant cette décision dans l'invite, on la retire entièrement du plan de contrôle de l'identité.
- Les comptes de service trop étendus pour les récupérateurs : Un récupérateur disposant d'un accès permanent en lecture à l'ensemble de la base de connaissances renvoie tout ce qui est sémantiquement pertinent, quelle que soit la personne qui l'a demandé.
- Pas de piste d’audit depuis l’invite jusqu’à l’extraction et la réponse : Sans attribution à chaque étape, les événements d’exposition des données ne peuvent pas être investigués ni démontrés aux auditeurs.
- Des identifiants statiques et à longue durée de vie pour les agents : Un agent compromis disposant d'identifiants à longue durée de vie peut opérer sans être détecté pendant une période prolongée, ce qui élargit le rayon d'action d'une brèche.
Foire aux questions (FAQ)
Quel est le risque le plus important en matière de sécurité au sein du RAG ?
Dans les déploiements RAG en entreprise, le risque majeur est celui d'une récupération avec autorisations excessives, où un agent renvoie des données que l'utilisateur demandeur n'est pas habilité à consulter. De nombreuses architectures RAG sécurisent les données et le modèle, mais laissent la couche d'extraction sans protection contre les agents légitimes qui agissent au-delà des droits de l'utilisateur demandeur.
En quoi la sécurité des RAG diffère-t-elle de la sécurité des applications traditionnelles ?
RAG introduit des identités non humaines agissant de manière autonome, une couche de recherche nécessitant des décisions d'autorisation en temps réel et la propagation du contexte utilisateur à travers les chaînes d'agents. Les modèles traditionnels de contrôle des accès n'ont pas été conçus pour aucune de ces conditions.
Quel rôle joue l'identité dans la sécurité des RAG ?
L'identité est un plan de contrôle fondamental qui connecte les trois couches de la défense RAG : les données, le modèle et la récupération. Il détermine qui, qu’il s’agisse d’un humain ou d’un agent, peut récupérer quoi, sous quelle autorité déléguée, et fournit la piste d’audit pour le vérifier.
Quel est l'écart d'autorisation dans le RAG ?
L’écart d’autorisation est la différence entre ce à quoi un agent d’IA peut techniquement accéder et ce que l’utilisateur demandeur est autorisé à voir. Ce phénomène est le plus fréquent lorsque les identifiants d'un agent dépassent les autorisations de l'utilisateur. L'approche basée sur les normes combine une autorisation granulaire au niveau de la couche de récupération avec l'échange de tokens OAuth 2.0, de sorte que chaque récupération est évaluée en fonction des droits de l'utilisateur requérant plutôt que des informations d'identification de l'agent.
Comment appliquez-vous Zero Trust à un workflow RAG ?
Traitez chaque recherche, appel d’outil et interaction d’agent à agent comme non fiable jusqu’à ce qu’elle soit vérifiée. Émettre des tokens de courte durée pour chaque action. Veuillez appliquer la politique à chaque étape. L'expression pratique de Zero Trust dans les RAG est l'autorisation au niveau de la couche de récupération des données, et non la défense du périmètre.
Sécurisez les agents d'IA et les RAG à grande échelle avec Okta
Pour combler le fossé en matière d'autorisation, il est essentiel de disposer d'un plan de contrôle des identités qui connecte les identités humaines, les agents d'IA et l'autorisation de récupération dans les flux de travail RAG. L'Okta Platform aide les organisations à gérer les agents d'IA comme des identités non humaines, à appliquer une autorisation fine au niveau de la couche d'extraction, à propager le contexte de l'utilisateur à travers les workflows de l'agent et à prendre en charge une piste d'audit traçable depuis l'utilisateur demandeur jusqu'à la réponse finale de l'IA.
Le contenu de ce document revêt un caractère purement informatif et ne constitue pas des conseils d'ordre juridique ou commercial, de confidentialité, de sécurité ou de conformité.
Il pourrait ne pas refléter les normes de sécurité, de confidentialité et les réglementations les plus récentes. Pour obtenir de tels conseils, il vous revient de vous adresser à votre conseiller juridique ou à tout autre conseiller professionnel et de ne pas vous en remettre à ce document.
Okta ne formule aucune déclaration, garantie ou autre assurance concernant le contenu de ce document et décline toute responsabilité quant aux pertes ou dommages pouvant résulter de la mise en œuvre des recommandations fournies dans le présent document. Les informations sur les assurances contractuelles d’Okta à ses clients sont disponibles à l’adresse okta.com/agreements.
