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

Agents vocaux évoluent rapidement, passant de simples systèmes de réponse aux FAQ à des systèmes capables d'agir, 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 au moyen 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, qui ne repose pas sur le jugement d'un LLM.

Cet article présente des schémas d'authentification éprouvés, issus de notre travail de Forward Deployed Engineers sur des déploiements en entreprise. Nous aborderons cinq approches essentielles, de l'authentification par session pour les widgets intégrés aux méthodes propres à la téléphonie et à la vérification par code à usage unique, et expliquerons comment les mettre en œuvre grâce au contrôle déterministe des workflows sur la plateforme ElevenLabs.

Surtout, nous montrerons pourquoi l'authentification ne peut pas être confiée à l'inférence conversationnelle. Elle doit au contraire s'appuyer sur des sous-agents isolés, une vérification par 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 par 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 pas à s'authentifier de nouveau.
• L'authentification fondée sur les connaissances vérifie les informations fournies par l'appelant, comme 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 téléphoniques peuvent utiliser des variables dynamiques système 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 texto 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 accèdent aux informations liées aux comptes, nous recommandons une séparation stricte des environnements et des accès via les workflows d'ElevenLabs. L'authentification doit toujours être mise en œuvre au moyen 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 d'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. L'authentification est ainsi déterministe, sans être laissée à la décision d'un LLM, et toute progression vers les nœuds en aval est empêchée tant que l'identité n'est pas vérifiée.

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

Exemple de mise en œuvre

Vérifiez l'utilisateur dans Salesforce (appel d'outil). En cas de réussite, récupérez les données de transaction du client dans 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 mises 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 les données de session de l'utilisateur, telles que son statut de connexion, son identifiant de compte ou ses 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'outils à l'aide de ces mêmes variables dynamiques, 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 manière personnalisée ou utiliser le widget ElevenLabs, dans lequel vous transmettez les variables au moment de l'exécution via la configuration du widget (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 les réponses à des questions de sécurité. Un outil côté serveur, sous la forme d'un webhook ou d'un appel backend, vérifie ces valeurs dans votre base de données, par exemple votre CRM ou votre référentiel d'identité. L'outil renvoie un résultat de réussite ou d'échec comprenant à la fois un statut booléen (is_error) et un texte descriptif.

Vous pouvez mettre cela en œuvre grâce au contrôle déterministe des workflows : après avoir demandé les informations pertinentes, configurez la répartition vers un outil et utilisez des connexions de transfert conditionnel du workflow qui se divisent selon le statut de réussite ou d'échec de l'outil, en orientant 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 la vérification dynamique 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 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 accède automatiquement à des variables système propres à la téléphonie, dont 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 : faites-y référence avec 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 afin de 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 à votre point de terminaison de recherche CRM, ce qui permet à l'agent de vérifier silencieusement si le numéro entrant correspond au numéro enregistré du client pour l'authentification de l'utilisateur. Au lieu d'un appel d'outil, l'authentification peut aussi être configurée comme 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 des 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 à des méthodes d'authentification supplémentaires, par exemple des questions fondées sur les connaissances.

Pour en savoir plus, 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. Vous pouvez demander à l'agent de sélectionner des questions aléatoires 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 via un appel d'outil à votre base de données.

L'outil d'authentification renvoie une réponse JSON incluant le nombre actuel de réussites. Grâce aux affectations d'outils, 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, la variable est incrémentée.

Une fois le nombre requis de vérifications 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 connexions et le contrôle des flux contient davantage d'informations à ce sujet.

Code à usage unique

Cette méthode universelle consiste à envoyer un code à usage unique à l'appareil de l'utilisateur par texto ou email. L'utilisateur doit ensuite communiquer ce code à l'agent pour vérification afin d'obtenir l'accès.

Voici le workflow de mise en œuvre 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 via son canal de prédilection, texto ou email.
2. Demande à l'utilisateur : l'agent demande ensuite à l'utilisateur de fournir le code qu'il a reçu. En mode vocal, les utilisateurs prononcent le code à voix haute, qui est capturé par la reconnaissance vocale.
3. Vérification du code : l'agent transmet 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 workflow : l'agent traite le résultat selon la réponse de vérification. Réussite : si le code est correct, l'utilisateur est orienté vers la partie du workflow suivant l'authentification via une condition de réussite. Échec : si le code est incorrect, l'agent peut demander à l'utilisateur de le saisir à nouveau ou lancer une procédure de secours, par exemple envoyer un nouveau code.

Considérations de sécurité : mettez en place une limitation du débit pour prévenir les tentatives par force brute, définissez des délais d'expiration courts pour les codes, de 3 à 5 minutes, et suivez puis limitez les tentatives. Pour les interactions vocales, envisagez des prompts de confirmation afin de garantir la précision de la reconnaissance vocale lors de la saisie des codes.

Utilisez ElevenAgents dès aujourd'hui 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écessite un niveau de sécurité différent de celui d'un assistant bancaire qui traite des transactions. La flexibilité de la plateforme permet à votre stratégie de sécurité d'évoluer avec les menaces et les exigences, tout en conciliant 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 concevoir une authentification des appelants qui ne dépend jamais du jugement d'un LLM.

Découvrez la plateforme ElevenAgents pour accéder au générateur de workflows complet, ou nous contacter pour concevoir dès aujourd'hui votre premier workflow d'agent vocal authentifié.

FAQ sur les processus sécurisés d'authentification de l'identité des appelants