Comment sécuriser les applications IA B2C ?

Pour sécuriser les applications d'IA B2C, il est nécessaire de protéger trois aspects à l'échelle des consommateurs : les identités des consommateurs interagissant avec les fonctionnalités d'IA, les données sensibles partagées par les utilisateurs avec les systèmes d'IA, et les résultats produits par ces systèmes. La sécurité de l'IA B2C doit trouver un équilibre entre une protection robuste des données, une prévention de la fraude et une expérience utilisateur fluide. Le plan de contrôle de l'identité englobe l'authentification résistant au phishing, l'autorisation granulaire, la gestion du consentement et les signaux de risque en temps réel. Il s'agit d'une couche fondamentale pour intégrer la sécurité dans le cycle de vie de l'IA, en collaboration avec les contrôles des modèles, des données, des applications et de l'infrastructure, afin de maintenir la confiance des consommateurs.

Pourquoi la sécurité des applications IA B2C est différente

La sécurité de l'IA d'entreprise et celle de l'IA B2C partagent des principes fondamentaux, mais leurs modèles de menace, leur échelle et les attentes des utilisateurs diffèrent, ce qui nécessite des stratégies de sécurité distinctes. Six facteurs définissent cette différence.

• Échelle : Les applications d'IA B2C servent des millions d'identités de consommateurs, et non des milliers d'employés sous gestion. Les contrôles qui fonctionnent à l'échelle de la main-d'œuvre peuvent ne pas s'adapter efficacement à la charge des consommateurs.
• Authentification à faible friction : Les consommateurs s'attendent à une connexion sans mot de passe, à une authentification sociale et à la biométrie, plutôt qu'à des mandats d'authentification unique et à des politiques MFA imposées, comme c'est souvent le cas dans les environnements d'entreprise.
• Consentement et limitation de la finalité : GDPR, CCPA et d'autres lois sur la protection de la vie privée peuvent exiger un consentement granulaire, révocable ou d'autres bases légales pour certaines utilisations de personnalisation et de formation de modèles basées sur l'IA. La loi européenne sur l'IA impose, sur la base du risque, des obligations distinctes en matière de gouvernance, de transparence et de responsabilité selon le cas d'utilisation, nécessitant une infrastructure capable de faire respecter les limites applicables par programmation.
• L'usurpation de compte (ATO) à grande échelle : Les comptes des consommateurs sont une cible principale de l'usurpation de compte (ATO). Les fonctionnalités d'IA amplifient le rayon d'explosion. Un compte compromis peut désormais inclure le contexte de l’IA de l’utilisateur, l’historique des conversations et les données connectées à l’agent, en plus des identifiants.
• Confiance dans la marque : Un incident important d’utilisation abusive de l’IA, tel qu’un agent agissant au-delà de son autorité ou un modèle révélant les données sensibles d’un autre utilisateur, peut nuire considérablement à la confiance des consommateurs et entraîner un examen réglementaire.
• Pression réglementaire : Des cadres émergents tels que la loi européenne sur l'IA, diverses lois sur l'IA au niveau des États et des réglementations financières sectorielles imposent des exigences spécifiques à l'IA qui varient selon la juridiction et le cas d'usage, ajoutant une complexité de conformité rarement rencontrée par les déploiements d'IA internes à l'entreprise à une échelle équivalente à celle des consommateurs.

Les Trois surfaces de sécurité d'une application d'IA B2C

Chaque application d'IA B2C expose trois surfaces distinctes nécessitant des contrôles indépendants et une gouvernance unifiée via le plan de contrôle des identités.

Chaque surface renvoie à une question centrale : l'identité de ce consommateur est-elle autorisée à faire cette demande d'IA et à recevoir cette réponse ? Et cette question est principalement adressée au plan de contrôle de l'identité.

Les principaux risques de sécurité pour les applications d'IA B2C

Les risques de sécurité auxquels une application d'IA B2C est confrontée diffèrent considérablement de ceux d'un déploiement interne à l'entreprise. Le Top 10 de l'OWASP pour les applications LLM constitue une base utile, mais les réalités spécifiques au B2C déterminent la manière dont chaque risque se manifeste dans la pratique.

1. Usurpation de compte (ATO) de comptes utilisant l'IA : Aujourd'hui, l'ATO peut accorder à un attaquant le contexte de l'IA de la victime, l'historique des conversations et la capacité d'exécuter des actions par le biais d'agents intégrés, et pas seulement les identifiants du compte.
2. Injection d'invites par l'intermédiaire de l'utilisateur : Le contenu soumis par les consommateurs peut manipuler le comportement du modèle et, si les contrôles sont faibles, peut amener l'application d'IA à tenter des actions involontaires ou à révéler des informations restreintes.
3. Fuite de données sensibles dans les résultats générés : Sans une isolation stricte du contexte, les systèmes d'IA risquent de révéler les données d'un utilisateur dans la réponse d'un autre utilisateur.
4. Comptes synthétiques et abus de bots : les bots peuvent exploiter les niveaux d'IA gratuits à grande échelle, en gonflant les coûts d'infrastructure, en dégradant potentiellement l'analytique, en abusant des quotas ou en corrompant les boucles de feedback dans lesquelles les interactions des utilisateurs influencent l'optimisation. Lorsque ces interactions alimentent les données d'apprentissage, l'abus de bot peut dégénérer en empoisonnement de données.
5. Consentement et violations de la vie privée : L’utilisation des données des consommateurs pour l’entraînement à l’IA sans un enregistrement de consentement durable et révocable peut exposer l’organisation à des risques réglementaires et de réputation.
6. Agents d'IA disposant d'autorisations excessives et agissant au nom des consommateurs : Lorsqu'un agent dispose de plus d'autorité que l'utilisateur qui l'a invoqué, un fossé d'autorité s'ouvre, créant une voie pour une élévation des privilèges que les organisations peuvent résoudre grâce à une conception axée sur l'identité.
7. Intégrations d'IA de tiers non sécurisées : les risques liés à la chaîne logistique dans les SDK et API d'IA peuvent introduire des vulnérabilités qui contournent les contrôles de sécurité internes.

Comment sécuriser les applications d'IA B2C : un cadre méthodique étape par étape

Commencez par une forte identité client

Avant de sécuriser l'IA, sécurisez l'identité qui l'appelle. L'authentification sans mot de passe, y compris les passkeys et WebAuthn, peut contribuer à réduire le vol d'identifiants, l'un des principaux facteurs de l'usurpation de compte (ATO) des consommateurs. L'authentification multifacteur (AMF) basée sur le risque ajoute une couche de friction proportionnelle à la sensibilité de l'action demandée, afin que les interactions de routine restent fluides, tandis que les actions d'IA à haut risque déclenchent une vérification supplémentaire. Bot Detection et les défenses contre le credential stuffing au niveau du terminal d'authentification peuvent contribuer à protéger le périmètre dont dépendent tous les contrôles en aval.

Appliquer FGA aux fonctionnalités de l'IA

L’IA ne doit jamais se comporter comme un compte de service à privilèges élevés disposant d’un large accès aux données. Les modèles n'étant pas conscients de l'existence d'une autorisation native, l' autorisation fine (FGA) doit être appliquée à la frontière de l'extraction et de l'appel d'outil, et non au sein du modèle lui-même. Appliquée à ces points d'application, la FGA aide à réduire le risque que l'IA récupère des documents ou des enregistrements au-delà de ce que l'utilisateur authentifié est autorisé à consulter. Cette sécurité des données au niveau de l'objet peut aider à prévenir les fuites de données entre utilisateurs dans les flux de recherche pilotés par l’IA. Des droits hiérarchisés régissent l'accès aux fonctionnalités des plans gratuits, payants et conçu pour les entreprises. L’autorisation est évaluée au cas par cas, conformément à un modèle d’accès Zero Trust qui ne suppose aucune confiance implicite entre les identités et les ressources.

Gérer le consentement tout au long du cycle de vie de l'IA

Le consentement est une exigence dynamique, pas une case à cocher statique. Tout au long du cycle de vie de l'IA, les données des consommateurs peuvent être utilisées pour la personnalisation, la récupération en temps réel et l'amélioration des modèles. Chaque utilisation nécessite un consentement granulaire et révocable, lié à l'identité spécifique d'un consommateur et enregistré sous forme de document vérifiable. Le plan de contrôle des identités peut associer des enregistrements de consentement à chaque identité de consommateur, de sorte que, si un utilisateur consent à recevoir des recommandations personnalisées mais refuse l'entraînement au modèle, le pipeline de données peut contribuer à faire respecter ces limites de manière programmatique. Les droits des personnes concernées, y compris l'accès, la suppression et la portabilité, doivent être respectés dans tous les systèmes d'IA connectés, conformément au RGPD, au CCPA et aux réglementations émergentes spécifiques à l'IA.

Veuillez protéger les données sensibles dans les invites et les sorties

Les informations sensibles, y compris les informations financières et les PII, doivent être expurgées ou tokenisées avant d'atteindre la couche d'inférence lorsqu'elles ne sont pas nécessaires à la tâche autorisée de l'utilisateur. Lorsque des données sensibles sont nécessaires pour répondre à une demande légitime et autorisée (par exemple, un utilisateur posant des questions sur son propre compte), les contrôles doivent se concentrer sur le fait de s'assurer que les données sont limitées à l'utilisateur demandeur et ne sont pas conservées dans un contexte partagé.

Des garde-fous par utilisateur sur les sorties générées permettent d'éviter que l'IA ne divulgue des informations qu'un utilisateur n'est pas autorisé à recevoir. 

L'injection d'invite reste un problème non résolu sans prévention fiable et efficace, de sorte que les défenses doivent supposer que certaines tentatives réussiront. Des mesures de réduction des risques à plusieurs niveaux (par exemple, l’analyse du contenu, l’exécution limitée des outils, le sandboxing et l’application des politiques au niveau du plan de contrôle de l’identité) permettent de limiter le rayon d’action en garantissant que même une invite injectée avec succès ne peut pas amener l’IA à dépasser le champ d’application autorisé de l’utilisateur qui l’invoque. 

L'isolation des tenants au niveau de l'infrastructure et l'isolation du contexte par utilisateur au niveau de l'application répondent à des risques distincts : la première empêche les fuites entre clients au niveau de l'infrastructure, tandis que la seconde empêche les fuites entre utilisateurs par le biais de caches partagés, de magasins d'intégration ou de contextes de conversation conservés au sein d'un seul tenant. Ces deux éléments sont nécessaires pour réduire sensiblement l’exposition des données des utilisateurs croisés à la surface de sortie.

Des agents d'IA sécurisés agissant au nom des consommateurs

Les agents d’IA qui exécutent des tâches pour le compte de consommateurs sont des identités non humaines (INH) et devraient être régis par un modèle de délégation qui lie les actions de l’agent au contexte vérifié de l’utilisateur invoquant et à ses autorisations limitées. Les agents ne doivent pas disposer d'un accès permanent ni agir sous leur propre autorité lorsqu'ils exécutent des tâches initiées par l'utilisateur. Les organisations peuvent utiliser l’échange de jetons OAuth 2.0 (RFC 8693) pour émettre des identifiants à durée limitée et à portée restreinte, qui transmettent le contexte vérifié de l’utilisateur humain aux systèmes en aval. Cela permet d’aligner l’autorité de l’agent sur la portée déléguée de l’utilisateur et de réduire le risque d’un comportement excessif de l’agent. Une piste d’audit complète, depuis la demande du consommateur jusqu’à la réponse du système d’IA, en passant par l’action de l’agent, soutient à la fois la résolution des incidents et la conformité réglementaire.

Surveillez les interactions de l'IA en temps réel

Les schémas d'utilisation anormaux de l'IA sont des signaux de sécurité. La surveillance en temps réel de l'identité des consommateurs peut permettre de détecter des volumes de demandes inhabituels, des accès aux données atypiques ou des comportements de compte qui s'écartent des modèles historiques lorsque des bases de référence fiables existent. Les messages-guides, les résultats ou les actions en aval à haut risque doivent déclencher des alertes automatisées et, le cas échéant, une vérification supplémentaire, l'approbation de la transaction, ou une authentification renforcée. L'intégration de la télémétrie de sécurité de l'IA avec les systèmes de détection des fraudes et de SIEM peut aider à créer une vue unifiée des risques de sécurité liés à l'IA dans les interactions avec les consommateurs.

Intégrer la sécurité dans le cycle de vie de l'IA

La sécurité ajoutée après le lancement peut créer des lacunes structurelles. L'intégration de fonctionnalités d'IA pour la modélisation des menaces dans la phase de conception, les tests d'injection de commande et de manipulation des résultats avant la mise sur le marché, ainsi que les tests de simulation d'attaque pour les scénarios d'abus à l'échelle du consommateur, sont des pratiques de sécurité essentielles qui peuvent contribuer à réduire les risques avant le déploiement. La surveillance continue du comportement du modèle après son lancement peut aider à identifier les dérives de performance, les régressions et les schémas d'abus émergents avant qu'ils ne deviennent des vulnérabilités exploitables.

Considérations réglementaires et de conformité pour l'IA B2C

Les obligations de conformité pour les applications d’IA B2C deviennent de plus en plus nombreuses et spécifiques. La loi européenne sur l'IA impose des obligations fondées sur les risques à certains systèmes d'intelligence artificielle destinés aux consommateurs, notamment des restrictions d'utilisation, des exigences de transparence et des exigences supplémentaires pour les systèmes à haut risque, telles que la gouvernance, la documentation, la surveillance humaine et la responsabilité. Le RGPD et le CCPA régissent le consentement, les droits des personnes concernées et la protection des données dès la conception. Les réglementations relatives aux services financiers, notamment GLBA aux États-Unis et PSD2 dans l'UE, ainsi que PCI DSS pour les données de paiement, imposent des contrôles renforcés lorsqu'une application d'IA touche des informations financières ou de paiement. Les lois sur l'IA au niveau des États américains continuent d'évoluer, ajoutant une complexité juridictionnelle que les organisations opérant dans plusieurs États doivent suivre de près. Le cadre de gestion des risques liés à l’IA du NIST et le Top 10 de l’OWASP pour les applications LLM fournissent des orientations structurelles qui complètent ces exigences réglementaires.

Erreurs courantes lors de la sécurisation des applications d'IA B2C

Les équipes de sécurité qui déploient des applications d'IA orientées vers les consommateurs peuvent rencontrer des erreurs évitables :

• Ajouter la sécurité aux fonctionnalités d'IA après leur lancement plutôt que de l'intégrer dès le premier jour
• Utilisation de clés API partagées pour les services d’IA au lieu des identifiants par utilisateur ou par agent
• Permettre à l'IA d'agir avec plus d'autorité que le consommateur qui l'a invoquée
• Traiter le consentement comme une case à cocher statique, plutôt que comme un document durable, révocable et vérifiable.
• Veuillez ignorer le trafic des bots sur les fonctionnalités d'IA, car cela pourrait gonfler les coûts et altérer le comportement du modèle au fil du temps.
• S'appuyer uniquement sur le modèle pour appliquer le contrôle des accès (les décisions d'accès faisant autorité devraient être découplées du modèle et appliquées par le plan de contrôle de l'identité afin de garantir une application cohérente de la politique).

Foire aux questions (FAQ)

Comment sécuriser les applications d'IA B2C ? 

La sécurisation des applications d'IA B2C commence par une identité forte du consommateur, une FGA appliquée aux fonctionnalités de l'IA, une gestion du consentement et une surveillance en temps réel. Le plan de contrôle de l'identité relie chaque interaction de l'IA à l'identité vérifiée du consommateur, comblant ainsi l'écart entre ce que l'IA peut faire et ce que l'utilisateur est autorisé à faire.

Quels sont les plus grands risques de sécurité dans les applications d'IA grand public ? 

Les risques les plus importants incluent l'usurpation de compte (ATO) d'activés par l'IA, l'injection d'invites, la fuite de données sensibles dans les résultats générés, l'utilisation abusive de comptes synthétiques et de bots, ainsi que la violation du consentement. Dans chaque cas, il s'agit d'une défailllance de la consumer Identity Governance, l'IA agissant sans autorisation vérifiée liée à l'utilisateur demandeur.

En quoi la sécurité de l'IA B2C est-elle différente de la sécurité de l'IA d'entreprise ? 

La sécurité de l'IA B2C doit protéger des millions d'identités de consommateurs grâce à une authentification fluide, un consentement granulaire et des défenses anti-robots. La sécurité de l'IA d'entreprise se concentre sur les contrôles d'accès des employés et la gouvernance des données internes dans un environnement géré, axé sur l'authentification unique (SSO). Les déploiements B2C sont également directement exposés aux lois sur la protection de la vie privée des consommateurs et aux exigences de transparence spécifiques à l’IA, auxquelles l’IA interne à l’entreprise est rarement confrontée à la même échelle.

Comment éviter que l'IA ne divulgue des données sensibles à un utilisateur non autorisé ? 

Renforcer l'AGF à la limite de la recherche et de l'appel d'outil pour chaque requête, propager le contexte utilisateur vérifié dans les systèmes d'IA, et isoler le contexte par utilisateur lors de l'inférence afin d'éviter les fuites dans les caches partagés ou les magasins d'intégration. L'IA doit agir dans le cadre des autorisations déléguées au consommateur authentifié, plutôt que comme un service partagé avec un accès inutilement large aux données.

Quel rôle joue l'authentification multifactorielle dans la sécurisation des applications d'IA ? 

L'authentification multifacteur joue deux rôles distincts. Les facteurs résistant au phishing tels que les passkeys renforcent l'événement d'authentification lui-même en réduisant la probabilité de vol d'identifiants et d'usurpation de compte. Des politiques adaptatives basées sur les risques déterminent quand et comment les demandes d'authentification sont déclenchées, ce qui permet une vérification accrue des actions sensibles de l’IA tout en maintenant les interactions de routine à un faible niveau de friction. Utilisés ensemble, les facteurs résistants au phishing et les politiques adaptatives renforcent la sécurité tout en préservant l'expérience utilisateur essentielle aux applications B2C.

Comment sécuriser les agents d'IA agissant au nom des consommateurs ? 

Traitez chaque agent comme une identité non humaine régie par un modèle de délégation, délivrant des identifiants limités et de courte durée, liées au contexte de l'utilisateur qui l'invoque. Utilisez l’échange de jetons OAuth 2.0 (RFC 8693) pour transmettre ce contexte vérifié en aval, appliquer le principe du moindre privilège à chaque appel agent-API au niveau de la couche d’autorisation et maintenir une piste d’audit complète, de la demande du consommateur à la réponse de l’IA.

Sécurisez vos applications IA B2C avec Okta

À mesure que les applications d'IA orientées vers le consommateur passent du stade de projet pilote à celui de production, leur sécurisation nécessite plus que des contrôles au niveau de la couche applicative. Il faut traiter chaque identité de consommateur et chaque agent d'IA comme une identité de premier ordre, avec un accès réglementé, des actions vérifiables et des enregistrements de consentement qui résistent à un examen réglementaire. L'Okta Platform aide les organisations à déployer en toute sécurité l'IA B2C à grande échelle, en gérant les identités non humaines, en appliquant le FGA aux fonctionnalités et aux données de l'IA, et en maintenant une visibilité en temps réel sur les interactions et les workflows des consommateurs pilotés par l'IA.

En savoir plus

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. Vous trouverez des informations sur les garanties contractuelles offertes par Okta à ses clients sur le site : okta.com/agreements.