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

Les agents vocaux évoluent rapidement : de simples assistants répondant aux FAQ, ils deviennent des systèmes capables d’exécuter des actions, de modifier des comptes, de traiter des transactions et d’accéder à des données clients sensibles. Cette évolution pose un défi majeur : comment authentifier l’identité d’un appelant dans un système d’IA conversationnelle où les méthodes traditionnelles de vérification visuelle n’existent pas ?

Lorsqu’un agent vocal peut mettre à jour des abonnements, consulter des soldes de compte ou lancer des remboursements, il doit authentifier les appelants avec la même rigueur qu’un centre d’appels humain, mais uniquement par interaction vocale. Contrairement aux agents humains qui appliquent 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 en tant qu’ingénieurs Forward Deployed dans le cadre de déploiements en entreprise. Nous couvrirons cinq approches clés, de l’authentification par session pour les widgets intégrés aux méthodes propres à la téléphonie et à la vérification par OTP, et expliquerons comment les mettre en œuvre grâce à un contrôle déterministe des flux de travail sur la plateforme ElevenLabs.

Surtout, nous montrerons pourquoi l’authentification ne peut pas reposer sur une inférence conversationnelle. Elle doit s’appuyer sur des sous-agents isolés, une vérification par outils et un routage conditionnel des flux de travail, 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 confié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 pas à se réauthentifier.
• 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, auprès d’un système backend via un appel d’outil côté serveur.
• Les déploiements de téléphonie peuvent utiliser des variables système dynamiques comme l’identifiant de l’appelant pour l’authentifier silencieusement, mais cette méthode doit ê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 e-mail et le valide via un service backend.

Les fondements architecturaux d’une authentification déterministe

Pour garantir que seuls les utilisateurs authentifiés accèdent aux informations liées à un compte, nous recommandons une séparation stricte des environnements et des accès via les flux de travail d’ElevenLabs. L’authentification doit toujours être mise en œuvre par 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 flux de travail 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 de compte n’est accessible qu’après une authentification réussie et reste entièrement isolé des utilisateurs non authentifiés. Cela garantit une authentification déterministe, qui 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 à partir des 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é des utilisateurs

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

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’ID 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 les systèmes intégrés sans nécessiter d’authentification distincte.

Cela permet un parcours d’assistance fluide, car l’utilisateur a déjà été vérifié par l’application hôte. Vous pouvez le configurer de façon personnalisée ou utiliser le widget ElevenLabs, qui permet de transmettre des variables à l’exécution dans 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 auprès de votre base de données, par exemple un CRM ou un référentiel d’identité. L’outil renvoie un résultat de réussite ou d’échec comprenant un statut booléen (is_error) et un texte descriptif.

Vous pouvez mettre cela en œuvre avec un contrôle déterministe des flux de travail : après avoir demandé les informations pertinentes, configurez une répartition d’outil et utilisez des branches de transfert conditionnel qui s’appuient sur 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 ainsi que 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 côté serveur et sur le nœud d’outil de répartition des flux de travail d’agent pour plus de détails.

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

Pour les conversations téléphoniques, via Twilio ou un trunk SIP, votre agent accède automatiquement aux 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 façons :

1. Dans les prompts/messages : utilisez des doubles accolades, par exemple {{system__caller_id}}, et elles seront remplacées par les valeurs réelles.
2. Dans les paramètres d’outil : configurez les paramètres d’outil pour utiliser ces variables et permettre 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 que le numéro entrant correspond au numéro enregistré du client pour l’authentification de l’utilisateur. Plutôt que par un appel d’outil, l’authentification peut aussi être configurée sous la forme d’un webhook d’initialisation de conversation qui s’exécute avant le début de celle-ci. 

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

Pour en savoir plus, consultez la documentation sur les variables système dynamiques 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 en n’accordant l’accès que si l’appelant répond correctement à un nombre prédéfini de questions. Vous pouvez demander à l’agent de sélectionner aléatoirement des questions dans une liste prédéfinie, par exemple la date de naissance, le code postal ou le nom d’un animal de compagnie, puis de valider les réponses de l’appelant par un appel d’outil vers votre base de données.

L’outil d’authentification renvoie une réponse JSON comprenant 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. Après chaque vérification réussie, cette variable est incrémentée.

Lorsque le nombre requis de vérifications est atteint, par exemple 3, une condition d’expression du flux de travail 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 de flux contient davantage d’informations.

Code à usage unique

Cette méthode universelle consiste à envoyer un code à usage unique à l’appareil de l’utilisateur par SMS ou e-mail. L’utilisateur doit ensuite communiquer ce code à l’agent afin de le faire vérifier et d’obtenir l’accès.

Voici le flux d’implémentation 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 génère un code sécurisé à usage unique et l’envoie à l’utilisateur via son canal préféré, SMS ou e-mail.
2. Demande à l’utilisateur : l’agent demande ensuite à l’utilisateur de fournir le code reçu. En mode vocal, l’utilisateur prononce le code à voix haute, puis celui-ci est capturé par la transcription vocale.
3. Vérification du code : l’agent envoie le code fourni par l’utilisateur à un service de vérification backend via 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 flux de travail : l’agent traite le résultat selon la réponse de vérification. Réussite : si le code est correct, l’utilisateur est dirigé vers la partie du flux de travail postérieure à l’authentification via une condition de réussite. Échec : si le code est incorrect, l’agent peut inviter l’utilisateur à le saisir de nouveau ou lancer une procédure de secours, comme l’envoi d’un nouveau code.

Considérations de sécurité : mettez en place une limitation du débit pour prévenir les tentatives par force brute, attribuez aux codes une courte durée de validité, de 3 à 5 minutes, et suivez comme limitez les tentatives de nouvelle saisie. Pour les interactions vocales, envisagez des demandes de confirmation afin de garantir la précision de la transcription vocale lors de la capture des codes.

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

Ces méthodes d’authentification sont des briques flexibles, 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’exige pas le même niveau de sécurité qu’un assistant bancaire traitant des transactions. La flexibilité de la plateforme permet à votre stratégie de sécurité d’évoluer face aux menaces et aux exigences, tout en conciliant protection et expérience utilisateur.

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

Découvrez la plateforme ElevenAgents pour accéder au générateur complet de flux de travail, ou contactez les ventes pour créer dès aujourd’hui votre premier flux de travail d’agent vocal authentifié.

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