Concevoir une authentification sécurisée des appelants pour les agents vocaux

Agents vocaux évoluent rapidement, passant de simples systèmes répondant aux FAQ à des systèmes capables d’agir, qui modifient des comptes, traitent des transactions et accèdent à des données clients sensibles. Cette évolution soulève un défi majeur : comment authentifier l’identité d’un appelant dans un système d’IA conversationnelle où les méthodes de vérification visuelle traditionnelles n’existent pas ?

Lorsqu’un agent vocal peut mettre à jour des abonnements, consulter des soldes de compte ou initier des remboursements, il doit authentifier les appelants avec la même rigueur qu’un centre d’appels humain, mais au cours d’une interaction entièrement vocale. Contrairement aux agents humains qui suivent les politiques de l’entreprise, les agents IA nécessitent une authentification déterministe, fondée sur des outils et indépendante du jugement du LLM.

Cet article présente des modèles d’authentification éprouvés issus de notre travail d’ingénieurs de déploiement sur le terrain dans des déploiements en entreprise. Nous couvrons cinq approches clés, de l’authentification fondée sur les sessions pour les widgets intégrés aux méthodes propres à la téléphonie et à la vérification par OTP, et expliquons comment les implémenter grâce au contrôle déterministe des workflows sur la plateforme ElevenLabs.

Surtout, nous montrerons pourquoi l’authentification ne peut pas reposer sur l’inférence conversationnelle. Elle doit au contraire s’appuyer sur des sous-agents isolés, une vérification fondée sur des outils et un routage conditionnel des workflows, afin que seuls les utilisateurs authentifiés accèdent aux opérations privilégiées.

En résumé

• L’authentification des appelants pour les agents vocaux doit être déterministe et fondée sur des outils ; elle ne peut pas être laissée à l’inférence conversationnelle du LLM.
• L’authentification par l’application hôte transmet les données de session existantes à l’agent, afin que les utilisateurs déjà connectés n’aient jamais à s’authentifier de nouveau.
• L’authentification fondée sur les connaissances vérifie les informations fournies par l’appelant, telles qu’un numéro de compte ou une date de naissance, par rapport à un système backend via un appel d’outil côté serveur.
• Les déploiements téléphoniques peuvent utiliser des variables dynamiques système, comme l’identifiant de l’appelant, pour authentifier silencieusement l’utilisateur. Cette méthode doit toutefois être associée à un second facteur, car l’identifiant de l’appelant peut être usurpé ou partagé.
• La vérification par code à usage unique envoie un code par SMS ou email et le valide via un service backend.

Les fondations architecturales d’une authentification déterministe

Pour garantir que seuls les utilisateurs authentifiés puissent accéder aux informations relatives aux comptes, nous recommandons une séparation stricte des environnements et des accès au moyen des workflows ElevenLabs. L’authentification doit toujours être implémentée à l’aide d’un appel d’outil renvoyant un résultat booléen de réussite ou d’échec, configuré comme outil de répartition dans le générateur de workflows ElevenLabs.

En liant directement la condition de transfert au résultat de l’appel d’outil, le sous-agent ayant accès aux données du compte n’est accessible qu’après une authentification réussie et reste entièrement isolé des utilisateurs non authentifiés. L’authentification est ainsi déterministe, ne dépend pas d’une décision du LLM et empêche toute progression vers les nœuds en aval sans identité vérifiée.

Les expressions de transfert constituent une autre méthode de transfert fiable. Elles font référence à des variables dynamiques mises à jour par les résultats des appels d’outil.

Exemple d’implémentation

Vérifiez l’utilisateur dans Salesforce (appel d’outil). En cas de réussite, récupérez les données de transaction client depuis Salesforce (autre appel d’outil), puis transférez l’utilisateur vers un sous-agent chargé d’utiliser ces données pour communiquer avec le client et effectuer d’autres actions si nécessaire.

Méthodes d’authentification de l’identité utilisateur

Ces méthodes d’authentification ne sont pas prises en charge nativement par la plateforme ElevenLabs. Elles peuvent être implémentées via des outils côté serveur intégrés à votre CRM ou à votre backend/base de données, où les données d’authentification sont stockées.

Authentification par l’application hôte

Pour les agents vocaux intégrés à un site web, l’application hôte peut transmettre des données de session utilisateur, telles que le statut de connexion, l’identifiant de compte ou les jetons de session, via des variables dynamiques lors de l’initialisation de l’agent ou du widget. Ces variables sont automatiquement injectées dans les appels d’outil, ce qui permet à l’agent de récupérer des données personnalisées depuis des systèmes intégrés sans nécessiter d’authentification distincte.

Cela assure un parcours d’assistance fluide, car l’utilisateur a déjà été vérifié par l’application hôte. Vous pouvez le configurer de manière personnalisée ou utiliser le widget ElevenLabs, qui permet de transmettre des variables à l’exécution via sa configuration, par exemple : <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>.

Consultez la documentation sur les variables dynamiques pour connaître la configuration complète.

Authentification fondée sur les connaissances (KBA) 

L’agent vocal demande à l’appelant de fournir des données d’authentification, telles qu’un numéro de compte, un code postal, une date de naissance ou des réponses à des questions de sécurité. Un outil côté serveur, tel qu’un webhook ou un appel backend, vérifie ces valeurs par rapport à votre base de données, par exemple votre CRM ou votre référentiel d’identités. L’outil renvoie un résultat de réussite ou d’échec qui comprend un statut booléen (is_error) et un texte descriptif.

Vous pouvez l’implémenter grâce à un contrôle déterministe du workflow : après avoir demandé les informations pertinentes, configurez une répartition d’outil et utilisez des branches de transfert conditionnelles du workflow selon le statut de réussite ou d’échec de l’outil, afin d’orienter les utilisateurs authentifiés vers des nœuds d’agent « privilégiés ». 

Cette approche prend en charge les questions de sécurité statiques et les vérifications dynamiques de type « out-of-wallet », selon vos exigences en matière de risque de fraude.

Consultez la documentation sur les outils serveur et le nœud d’outil de répartition des workflows d’agents pour plus de détails.

Variables dynamiques système (téléphonie uniquement)

Pour les conversations téléphoniques, via Twilio ou un trunk SIP, votre agent a automatiquement accès à des variables système propres à la téléphonie, notamment system__caller_id, le numéro de téléphone de l’appelant. Cette variable est automatiquement renseignée au début de la conversation.

Vous pouvez y faire référence de deux manières :

1. Dans les prompts/messages : faites-y référence à l’aide d’accolades doubles, par exemple {{system__caller_id}}, et elles seront remplacées par les valeurs réelles.
2. Dans les paramètres de l’outil : configurez les paramètres de l’outil pour utiliser ces variables, ce qui permet une authentification silencieuse sans les mentionner dans le prompt.

Par exemple, vous pouvez configurer un outil pour transmettre automatiquement l’identifiant de l’appelant au point de terminaison de recherche de votre CRM. L’agent peut ainsi vérifier silencieusement si le numéro entrant correspond au numéro enregistré du client pour l’authentification utilisateur. Au lieu d’un appel d’outil, l’authentification peut aussi être configurée sous forme de webhook d’initialisation de conversation, exécuté avant le début de la conversation. 

Note de sécurité : les appelants pouvant utiliser un numéro différent de celui enregistré, ou les numéros stockés pouvant être accessibles à des personnes non autorisées, l’authentification fondée sur l’identifiant de l’appelant doit nécessiter le consentement préalable du client ou être associée à des méthodes d’authentification supplémentaires, telles que des questions fondées sur les connaissances.

Pour plus d’informations, consultez la documentation sur les variables dynamiques système et le webhook d’initialisation.

Authentification avancée fondée sur les connaissances et les questions de sécurité

L’agent peut authentifier un utilisateur en posant un ensemble de questions de sécurité et n’accorder l’accès que si l’appelant répond correctement à un nombre prédéfini de questions. L’agent peut être invité à sélectionner des questions aléatoires dans une liste prédéfinie, par exemple la date de naissance, le code postal ou le nom de l’animal de compagnie, puis à valider les réponses de l’appelant au moyen d’un appel d’outil vers votre base de données.

L’outil d’authentification renvoie une réponse JSON incluant le nombre actuel de vérifications réussies. Grâce aux affectations d’outil, ce nombre est automatiquement extrait et stocké ou mis à jour dans une variable dynamique, par exemple auth_success_count. La variable est incrémentée après chaque vérification réussie.

Lorsque le nombre requis de vérifications est atteint, par exemple 3, une condition d’expression du workflow vérifie la valeur de la variable dynamique et effectue la transition vers un nœud de sous-agent privilégié. L’expression utilise des opérateurs de comparaison, par exemple auth_success_count >= 3, pour contrôler l’accès de manière déterministe selon le statut d’authentification.

Notre documentation sur les branches et le contrôle des flux fournit davantage d’informations à ce sujet.

Code à usage unique

Il s’agit d’une méthode universelle qui consiste à envoyer un code à usage unique à l’appareil de l’utilisateur par SMS ou email. L’utilisateur doit ensuite communiquer ce code à l’agent pour le faire vérifier et obtenir l’accès.

Voici le workflow d’implémentation plus en détail :

1. Génération du code : l’agent lance le processus par un appel d’outil côté serveur vers un point de terminaison dédié. Cette action déclenche la génération d’un code sécurisé à usage unique et son envoi à l’utilisateur par son canal préféré, SMS ou email.
2. Demande à l’utilisateur : l’agent demande ensuite à l’utilisateur de fournir le code reçu. En mode vocal, l’utilisateur énonce le code à voix haute, qui est capturé grâce à la reconnaissance vocale.
3. Vérification du code : l’agent envoie le code fourni par l’utilisateur à un service de vérification backend au moyen d’un second appel d’outil. Le backend vérifie que le code correspond, qu’il n’a pas expiré et qu’il n’a pas déjà été utilisé.
4. Routage du workflow : l’agent gère le résultat selon la réponse de vérification. Réussite : si le code est correct, l’utilisateur est dirigé vers la partie post-authentification du workflow via une condition de réussite. Échec : si le code est incorrect, l’agent peut inviter l’utilisateur à saisir de nouveau le code ou déclencher une procédure de secours, par exemple l’envoi d’un nouveau code.

Considérations de sécurité : mettez en place une limitation du débit pour empêcher les tentatives par force brute, définissez une courte durée d’expiration des codes, de 3 à 5 minutes, et suivez puis limitez les tentatives. Pour les interactions vocales, envisagez des demandes de confirmation afin de garantir la précision de la reconnaissance vocale lors de la capture des codes.

Démarrez avec ElevenAgents pour une authentification vocale sécurisée

Ces méthodes d’authentification constituent des briques flexibles, et non des solutions prescriptives. Votre choix doit refléter votre profil de risque, vos exigences réglementaires et vos objectifs d’expérience utilisateur. Un bot de service client n’a pas les mêmes besoins de sécurité qu’un assistant bancaire traitant des transactions. La flexibilité de la plateforme permet à votre stratégie de sécurité d’évoluer avec les menaces et les exigences, tout en équilibrant protection et expérience utilisateur.

ElevenAgents vous fournit le contrôle déterministe des workflows, les outils de répartition et les variables propres à la téléphonie décrits ci-dessus. Vous pouvez ainsi créer une authentification des appelants qui ne dépend jamais du jugement du LLM.

Découvrez la plateforme ElevenAgents pour voir le générateur de workflows complet, ou réserver une démo pour commencer dès aujourd’hui à créer votre premier workflow d’agent vocal authentifié.

FAQ sur les flux d’authentification sécurisée de l’identité des appelants