Solution d'identité basée sur l'IA agentique

En effet, les procédures traditionnelles de KYC/IDV ne répondent correctement qu’à une seule question : l’identité de cette personne a-t-elle été vérifiée lors de la création du compte ? Elles ne permettent pas de déterminer de manière fiable qui ou quoi agit actuellement, si cet acteur est toujours sous le contrôle du client, ni si le comportement actuel correspond à une utilisation légitime. Cette lacune devient dangereuse lorsque des agents IA, des automatisations scriptées et des fraudes assistées par des humains peuvent tous opérer derrière un compte préalablement vérifié. Pour un vice-président chargé de la sécurité des produits ou un responsable de l’identité, le véritable enjeu n’est pas de remplacer le KYC, mais de l’étendre vers un modèle continu de « Know Your Actor » (Connaissez votre acteur). Il faut des contrôles qui classifient le type d’acteur en temps réel, détectent le passage d’un comportement humain à un comportement automatisé, distinguent l’automatisation déléguée de l’activité hostile des bots, et appliquent des politiques différentes lors de la connexion, des modifications de compte, des paiements, des retraits et des procédures de récupération. Le problème majeur est que la fraude se produit désormais après l’inscription, et non plus uniquement au moment de celle-ci.

Vous ne résoudrez pas ce problème avec un seul indicateur. L’approche pratique consiste à recourir à une classification par couches. Commencez par la vérification d’identité lors de l’inscription, puis ajoutez des indicateurs au niveau de la session, tels que les données sur l’appareil, les indicateurs relatifs au navigateur et à l’émulateur, la vélocité, les schémas de navigation, l’entropie d’interaction, la biométrie comportementale, les caractéristiques d’utilisation des API et le contexte de la transaction. Pour les cas d’utilisation approuvés impliquant des agents IA, exigez des mécanismes de délégation explicites tels que l’autorisation par jeton, les autorisations limitées à un périmètre précis, les délais d’expiration et les contraintes au niveau des actions. En cas d’automatisation suspecte, recherchez les schémas que les humains ne parviennent pas à reproduire de manière cohérente à grande échelle : synchronisation très régulière, parcours de navigation anormaux, réutilisation distribuée d’appareils, comportements de relecture, séquences d’interaction sans friction, ou incohérences entre l’identité déclarée et le comportement observé. L’objectif n’est pas de soumettre tout le monde à la même rigueur. Il s’agit de classer le parcours par niveau de risque afin que les utilisateurs à faible risque soient autorisés à passer avec un minimum de friction, que les agents délégués connus opèrent dans le respect de la politique, et que les acteurs inconnus ou évasifs soient soumis à un contrôle renforcé, à une limitation de débit ou bloqués.

Une architecture efficace comporte cinq couches. Premièrement, la vérification de l’identité : vérification des documents, données biométriques, contrôles dans les bases de données, filtrage des sanctions et tout contrôle KYC/KYB requis. Deuxièmement, la détection des acteurs : déterminer si la session en cours semble être menée par un humain, pilotée par un bot, assistée par un agent ou hybride. Troisièmement, les risques comportementaux et contextuels : évaluer la fiabilité de l'appareil, la réputation du réseau, la géovélocité, les anomalies comportementales, l'intégrité de la session, l'intention de la transaction et les tendances historiques du compte. Quatrièmement, l'orchestration des politiques : appliquer des règles et des modèles qui déterminent quand autoriser, renforcer les contrôles, limiter l'accès, exiger un nouveau consentement ou faire appel à un examen manuel. Cinquièmement, l’auditabilité : consigner quels signaux ont été utilisés, comment la décision a été prise, quelles autorisations existaient et pourquoi une action a été approuvée ou refusée. Cela est important car le problème réside rarement dans l’absence d’un seul contrôle. Il s’agit plutôt d’un manque d’orchestration entre les contrôles. Si vos équipes ne sont pas en mesure d’expliquer la classification des acteurs, l’autorité déléguée et la logique de renforcement à chaque étape du parcours, cela signifie que votre architecture est encore optimisée pour un monde exclusivement humain.

Considérez la délégation comme un problème d’identité et d’autorisation à part entière, et non comme une fonctionnalité supplémentaire. Si un agent IA peut agir au nom d’un utilisateur, vous devez savoir qui l’a autorisé, ce qu’il est autorisé à faire, dans quelles conditions, pour combien de temps, et comment cette autorisation peut être révoquée. Concrètement, cela implique un consentement explicite de l’utilisateur, des autorisations limitées à un périmètre précis, des limites de transactions et d’actions, une réauthentification forte pour les événements de délégation sensibles, des identifiants ou des attestations propres à chaque agent, ainsi que des pistes d’audit claires reliant chaque action d’un agent à un utilisateur vérifié et à un enregistrement d’autorisation. Vous devez également distinguer l’accès en lecture de l’accès en écriture, et les actions à faible risque de celles à haut risque. Un client peut raisonnablement autoriser un agent à collecter des données de compte, mais pas à modifier les détails de paiement ni à initier un retrait sans vérification renforcée. Le point sensible ici est la gouvernance : la plupart des équipes peuvent imaginer des expériences utiles pour les agents, mais elles ne disposent d’aucun modèle de contrôle durable permettant de prouver que ces actions ont été autorisées.

Les autorités de régulation continuent d’exiger la responsabilité, même si l’action initiale émane d’un logiciel. Votre cadre de contrôle doit préserver les résultats essentiels en matière de conformité : identité vérifiée, prise de décision fondée sur les risques, traçabilité, explicabilité et escalade justifiable. Cela implique de documenter non seulement l’identité du client, mais aussi qui ou quoi a agi en son nom, quelle autorité existait, quels signaux ont influencé la décision et si un examen humain a été déclenché. Pour les équipes chargées de la lutte contre le blanchiment d’argent, de la fraude et de la protection de la vie privée, la question n’est pas de savoir si les agents d’IA sont autorisés en théorie, mais si vous êtes en mesure de justifier les décisions en cas d’audit, de litige, d’examen d’une déclaration d’opération suspecte (SAR) ou de réclamation client. Concevez vos systèmes pour permettre la conservation des preuves, la journalisation des décisions, l’enregistrement des consentements, la gestion des versions des politiques et l’historique des actions. Si un agent modifie les informations d’un compte, transfère des fonds ou soumet des données d’onboarding, vous devez être en mesure de reconstituer la chaîne d’événements sans ambiguïté. La conformité est compromise lorsque l’identité, l’autorité et l’historique des actions ne sont pas reliés entre eux.

Le renforcement des mesures de sécurité doit être déterminé par une combinaison de facteurs : l’incertitude relative à l’acteur, la sensibilité de l’action et la gravité de l’anomalie. Il doit être déclenché lorsque la classification de l’acteur n’est pas claire, lorsque le comportement passe soudainement d’une utilisation humaine normale à des schémas de type automatisé, lorsqu’un compte de confiance tente une action à haut risque depuis un nouvel environnement, ou lorsqu’un agent délégué dépasse son champ d’action ou sa vitesse habituels. Les moments sensibles comprennent généralement la récupération de compte, les réinitialisations de mot de passe ou d’authentification multifactorielle (MFA), les modifications des modalités de versement, l’ajout de bénéficiaires, les virements importants, les retraits de cryptomonnaies, les modifications fiscales ou de profil, ainsi que tout ce qui pourrait altérer de manière irréversible la propriété ou les flux de fonds. L’erreur commise par de nombreuses équipes est de considérer l’authentification comme binaire : connecté ou non. Dans les environnements agentiques, le renforcement des mesures de sécurité doit être contextuel et progressif. Vous pouvez exiger d’abord des contrôles passifs, puis une revérification biométrique, ensuite une validation explicite de l’utilisateur, et enfin un examen humain si le risque persiste. Le bon modèle protège les actions critiques sans imposer à chaque client le même processus fastidieux.