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

Les agents vocaux évoluent rapidement : ils ne se contentent plus de répondre à des FAQ, mais exécutent désormais des actions, modifient des comptes, traitent des transactions et accèdent à des données sensibles. Ce changement pose un défi majeur : comment authentifier l’identité d’un appelant dans un système

Lorsqu’un

Cet article présente des méthodes d’authentification éprouvées issues de notre expérience en tant qu’ingénieurs déployés sur le terrain auprès de grandes entreprises. Nous allons détailler cinq approches principales, de l’authentification basée sur la session pour les widgets intégrés aux méthodes spécifiques à la téléphonie et à la vérification par OTP, et expliquer comment les mettre en place grâce au contrôle déterministe des workflows sur la plateforme ElevenLabs.

Surtout, nous allons montrer pourquoi l’authentification ne peut pas reposer sur l’inférence conversationnelle. Elle doit être conçue avec des sous-agents isolés, une vérification par outils et un routage conditionnel du workflow pour garantir que seuls les utilisateurs authentifiés accèdent aux opérations sensibles.

Résumé

Pour garantir que seuls les utilisateurs authentifiés accèdent aux informations liées à leur compte, nous recommandons une séparation stricte des environnements et des accès via les workflows ElevenLabs. L’authentification doit toujours passer par un appel d’outil avec un résultat booléen (succès ou échec), configuré comme outil de dispatch dans le workflow builder ElevenLabs.

Les bases architecturales d’une authentification déterministe

Pour garantir que seuls les utilisateurs authentifiés accèdent aux informations liées à un compte, nous recommandons une stricte séparation des environnements et des accès via les workflows ElevenLabs. L’authentification doit toujours être mise en œuvre à l’aide d’un appel d’outil avec un résultat booléen (succès ou échec), configuré comme outil de dispatch dans le workflow builder ElevenLabs.

En reliant 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 authentification réussie et reste totalement isolé des utilisateurs non authentifiés. Cela garantit une authentification déterministe, sans décision laissée au LLM, et empêche toute progression vers les nœuds suivants sans identité vérifiée.

En alternative, des expressions de transfert peuvent servir de méthode fiable. Ces expressions font référence à des variables dynamiques mises à jour par les résultats des appels d’outils.

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

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

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

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

Authentification par l’application hôte

Documentation on Dynamic Variables:

• https://www.panel.temphost.top/docs/agents-platform/customization/personalization/dynamic-variables#pass-variables-at-runtime 

Consultez la

Authentification basée sur la connaissance (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 (webhook ou appel backend) vérifie ces informations dans votre base de données (CRM ou référentiel d’identité). L’outil retourne un résultat succès/échec comprenant un statut booléen (is_error) et un texte descriptif.

Vous pouvez mettre cela en place via un contrôle déterministe du workflow : après avoir demandé les informations nécessaires, configurez un dispatch d’outil et utilisez des conditions de transfert qui orientent les utilisateurs authentifiés vers des nœuds « privilégiés » de l’agent.

• https://www.panel.temphost.top/docs/agents-platform/customization/tools/server-tools 
• https://www.panel.temphost.top/docs/eleven-agents/customization/agent-workflows#dispatch-tool-node 

Consultez la

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

Pour les conversations téléphoniques (via Twilio ou SIP trunk), votre agent accède automatiquement à des variables système spécifiques à la téléphonie, dont system__caller_id (numéro de téléphone de l’appelant). Cette variable est renseignée automatiquement au début de la conversation.

Vous pouvez l’utiliser de deux façons :

Documentation sur les variables dynamiques système et le webhook d’initiation :

• https://www.panel.temphost.top/docs/agents-platform/customization/personalization/dynamic-variables#system-dynamic-variables 
• https://www.panel.temphost.top/docs/agents-platform/customization/personalization/twilio-personalization 

Note de sécurité :

Pour plus d’informations, consultez la documentation sur les

Authentification avancée par questions de sécurité / connaissance

L’agent peut authentifier un utilisateur en posant une série de questions de sécurité et n’accorder l’accès que si l’appelant répond correctement à un nombre prédéfini. L’agent peut sélectionner aléatoirement des questions dans une liste (date de naissance, code postal, nom de l’animal, etc.) et valider les réponses via un appel d’outil à votre base de données.

Documentation ici : https://www.panel.temphost.top/docs/eleven-agents/customization/agent-workflows#edges-and-flow-control 

Code à usage unique

Notre

Code à usage unique

1. Génération du code : l’agent lance le processus via un appel d’outil serveur vers un endpoint dédié. Cela génère un code sécurisé à usage unique et l’envoie à l’utilisateur par le canal choisi (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 capté via la reconnaissance vocale.
3. Vérification du code : l’agent envoie le code fourni à un service de vérification backend via un second appel d’outil. Le backend vérifie que le code correspond, n’a pas expiré et n’a pas déjà été utilisé.
4. Routage du workflow : l’agent gère la suite selon la réponse de vérification : Succès : si le code est correct, l’utilisateur accède à la suite du workflow via une condition de succès. Échec : si le code est incorrect, l’agent peut demander à l’utilisateur de réessayer ou lancer une procédure de secours (ex. : renvoi d’un nouveau code).

Voici le workflow de mise en œuvre détaillé :

Conclusion

Considérations de sécurité : il convient de limiter le nombre de tentatives pour éviter les attaques par force brute, de définir une durée de validité courte (3 à 5 minutes) et de suivre le nombre de tentatives. Pour les interactions vocales, prévoyez des confirmations pour garantir la fiabilité de la reconnaissance vocale lors de la saisie du code.