वॉइस एजेंट्स के लिए सुरक्षित कॉलर ऑथेंटिकेशन डिज़ाइन करना
- प्रकाशित
- आखिरी बार अपडेट किया गया
सुनेंइस आर्टिकल को सुनें
वॉइस एजेंट तेज़ी से साधारण FAQ जवाब देने वाले सिस्टम से ऐसे सिस्टम में विकसित हो रहे हैं जो अकाउंट में बदलाव करते हैं, ट्रांज़ैक्शन प्रोसेस करते हैं और संवेदनशील ग्राहक डेटा एक्सेस करते हैं। यह बदलाव एक अहम चुनौती लाता है: आप किसी कॉलर की पहचान को कन्वर्सेशनल AI सिस्टम में कैसे प्रमाणित करेंगे, जहाँ पारंपरिक विज़ुअल वेरिफ़िकेशन तरीके मौजूद नहीं हैं?
जब कोई वॉइस एजेंट सब्सक्रिप्शन अपडेट कर सकता है, अकाउंट बैलेंस देख सकता है या रिफ़ंड शुरू कर सकता है, तो उसे कॉलर को उतनी ही सख्ती से प्रमाणित करना होगा जितनी मानव कॉल सेंटर करते हैं—लेकिन पूरी तरह वॉइस-आधारित बातचीत में। कंपनी की नीतियों का पालन करने वाले मानव एजेंटों के विपरीत, AI एजेंटों को ऐसे निश्चित, टूल-आधारित प्रमाणीकरण की ज़रूरत होती है जो LLM के निर्णय पर निर्भर न हो।
यह लेख एंटरप्राइज़ डिप्लॉयमेंट में Forward Deployed Engineers के तौर पर हमारे काम से मिले प्रमाणित ऑथेंटिकेशन पैटर्न बताता है। हम एम्बेडेड विजेट्स के लिए सेशन-आधारित ऑथेंटिकेशन से लेकर टेलीफोनी-विशिष्ट तरीकों और OTP वेरिफ़िकेशन तक, पाँच मुख्य तरीकों को कवर करेंगे और बताएंगे कि ElevenLabs प्लेटफ़ॉर्म पर निश्चित वर्कफ़्लो गेटिंग के साथ इन्हें कैसे लागू करें।
सबसे अहम बात, हम दिखाएंगे कि ऑथेंटिकेशन को बातचीत से निकाले गए निष्कर्ष पर क्यों नहीं छोड़ा जा सकता। इसके बजाय, इसे अलग-अलग सब-एजेंट्स, टूल-आधारित वेरिफ़िकेशन और कंडीशनल वर्कफ़्लो रूटिंग के साथ डिज़ाइन करना चाहिए, ताकि केवल प्रमाणित यूज़र ही विशेषाधिकार वाले ऑपरेशन तक पहुँच सकें।
सारांश
- वॉइस एजेंट्स के लिए कॉलर ऑथेंटिकेशन निश्चित और टूल-आधारित होना चाहिए; इसे LLM के बातचीत से निकाले गए निष्कर्ष पर नहीं छोड़ा जा सकता।
- होस्ट एप्लिकेशन ऑथेंटिकेशन मौजूदा सेशन डेटा एजेंट को भेजता है, इसलिए पहले से लॉग इन यूज़र्स को दोबारा ऑथेंटिकेट नहीं करना पड़ता।
- नॉलेज-आधारित ऑथेंटिकेशन, अकाउंट नंबर या जन्मतिथि जैसी कॉलर द्वारा दी गई जानकारी को सर्वर-साइड टूल कॉल के ज़रिए बैकएंड सिस्टम से सत्यापित करता है।
- टेलीफोनी डिप्लॉयमेंट, चुपचाप ऑथेंटिकेट करने के लिए कॉलर ID जैसे सिस्टम डायनेमिक वेरिएबल्स का इस्तेमाल कर सकते हैं, लेकिन कॉलर ID स्पूफ़ या साझा की जा सकती है, इसलिए इसे दूसरे फ़ैक्टर के साथ मिलाना चाहिए।
- वन-टाइम कोड वेरिफ़िकेशन SMS या ईमेल से कोड भेजता है और बैकएंड सर्विस के ज़रिए उसे सत्यापित करता है।
निश्चित ऑथेंटिकेशन की आर्किटेक्चरल बुनियाद
यह सुनिश्चित करने के लिए कि केवल प्रमाणित यूज़र ही अकाउंट से जुड़ी जानकारी एक्सेस कर सकें, हम ElevenLabs के वर्कफ़्लो के ज़रिए एनवायरनमेंट और एक्सेस को सख्ती से अलग रखने की सलाह देते हैं। ऑथेंटिकेशन को हमेशा boolean success या failure आउटपुट वाले टूल कॉल से लागू करना चाहिए, जिसे ElevenLabs वर्कफ़्लो बिल्डर में डिस्पैच टूल के रूप में कॉन्फ़िगर किया गया हो।
ट्रांसफ़र कंडीशन को सीधे टूल कॉल के नतीजे से जोड़ने पर, अकाउंट डेटा तक पहुँच वाला सब-एजेंट केवल सफल ऑथेंटिकेशन के बाद ही उपलब्ध होता है और गैर-प्रमाणित यूज़र्स से पूरी तरह अलग रहता है। इससे ऑथेंटिकेशन निश्चित रहता है, LLM के निर्णय पर नहीं छोड़ा जाता, और सत्यापित पहचान के बिना डाउनस्ट्रीम नोड्स तक कोई प्रगति नहीं होती।
वैकल्पिक रूप से, ट्रांसफ़र एक्सप्रेशन का इस्तेमाल भरोसेमंद ट्रांसफ़र तरीके के रूप में किया जा सकता है। ये एक्सप्रेशन उन डायनेमिक वेरिएबल्स को रेफ़र करते हैं जो टूल कॉल के नतीजों से अपडेट होते हैं।
उदाहरण इम्प्लीमेंटेशन
Salesforce में यूज़र को सत्यापित करें (टूल कॉल)। सफल होने पर Salesforce से ग्राहक का ट्रांज़ैक्शन डेटा प्राप्त करें (एक और टूल कॉल), फिर यूज़र को ऐसे सब-एजेंट पर ट्रांसफ़र करें जो इस डेटा का इस्तेमाल कर ग्राहक से बात करे और ज़रूरत पड़ने पर अन्य कार्रवाई करे।
यूज़र पहचान ऑथेंटिकेशन के तरीके
ये ऑथेंटिकेशन तरीके ElevenLabs प्लेटफ़ॉर्म में मूल रूप से उपलब्ध नहीं हैं। इन्हें सर्वर-साइड टूल्स के ज़रिए लागू किया जा सकता है, जो आपके CRM या बैकएंड/डेटाबेस के साथ इंटीग्रेट होते हैं, जहाँ ऑथेंटिकेशन डेटा स्टोर होता है।
होस्ट एप्लिकेशन ऑथेंटिकेशन
वेबसाइट में एम्बेड किए गए वॉइस एजेंट्स के लिए, होस्ट एप्लिकेशन एजेंट/विजेट को इनिशियलाइज़ करते समय डायनेमिक वेरिएबल्स के ज़रिए यूज़र सेशन डेटा (जैसे लॉग-इन स्टेटस, अकाउंट ID या सेशन टोकन) भेज सकता है। इन्हीं डायनेमिक वेरिएबल्स का इस्तेमाल करके ये वेरिएबल्स अपने-आप टूल कॉल में शामिल हो जाते हैं, जिससे एजेंट अलग ऑथेंटिकेशन की ज़रूरत के बिना इंटीग्रेटेड सिस्टम से पर्सनलाइज़्ड डेटा प्राप्त कर सकता है।
इससे सपोर्ट का अनुभव सहज बनता है, क्योंकि होस्ट एप्लिकेशन यूज़र को पहले ही सत्यापित कर चुका होता है। आप इसे कस्टम कॉन्फ़िगरेशन से सेट अप कर सकते हैं या ElevenLabs विजेट इस्तेमाल कर सकते हैं, जिसमें आप विजेट कॉन्फ़िगरेशन से रनटाइम पर वेरिएबल्स पास करते हैं (जैसे, <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>)।
पूरा सेटअप जानने के लिए डायनेमिक वेरिएबल्स डॉक्यूमेंटेशन देखें।
नॉलेज-आधारित ऑथेंटिकेशन (KBA)
वॉइस एजेंट कॉलर से ऑथेंटिकेशन डेटा देने के लिए कहता है, जैसे अकाउंट नंबर, पोस्टकोड, जन्मतिथि या सुरक्षा जवाब। एक सर्वर-साइड टूल (वेबहुक या बैकएंड कॉल) इन वैल्यू को आपके डेटाबेस (जैसे CRM या आइडेंटिटी स्टोर) से सत्यापित करता है। टूल success/failure परिणाम लौटाता है, जिसमें boolean स्टेटस (is_error) और विवरणात्मक टेक्स्ट, दोनों शामिल होते हैं।
आप इसे निश्चित वर्कफ़्लो गेटिंग से लागू कर सकते हैं: ज़रूरी जानकारी माँगने के बाद, एक टूल डिस्पैच कॉन्फ़िगर करें और वर्कफ़्लो कंडीशनल ट्रांसफ़र एज का इस्तेमाल करें जो टूल के success/failure स्टेटस के आधार पर ब्रांच करे और प्रमाणित यूज़र्स को “विशेषाधिकार वाले” एजेंट नोड्स तक रूट करे।
यह तरीका आपके फ़्रॉड रिस्क की ज़रूरतों के आधार पर, स्टैटिक सुरक्षा प्रश्नों और डायनेमिक "आउट-ऑफ़-वॉलेट" शैली के वेरिफ़िकेशन को सपोर्ट करता है।
ज़्यादा जानकारी के लिए सर्वर टूल्स और एजेंट वर्कफ़्लो डिस्पैच टूल नोड डॉक्यूमेंटेशन देखें।
सिस्टम डायनेमिक वेरिएबल्स (केवल टेलीफोनी)
फ़ोन-आधारित बातचीत (Twilio या SIP trunk के ज़रिए) में, आपके एजेंट को टेलीफोनी-विशिष्ट सिस्टम वेरिएबल्स का अपने-आप एक्सेस मिलता है, जिनमें system__caller_id (कॉलर का फ़ोन नंबर) शामिल है। बातचीत शुरू होते ही यह वेरिएबल अपने-आप भर जाता है।
आप इसे दो तरीकों से रेफ़र कर सकते हैं:
- प्रॉम्प्ट्स/मैसेज में: इन्हें डबल कर्ली ब्रेसेस से रेफ़र करें, जैसे {{system__caller_id}}, और इन्हें वास्तविक वैल्यू से बदल दिया जाएगा।
- टूल पैरामीटर्स में: इन वेरिएबल्स का इस्तेमाल करने के लिए टूल पैरामीटर्स कॉन्फ़िगर करें, ताकि प्रॉम्प्ट में इनका उल्लेख किए बिना चुपचाप ऑथेंटिकेशन हो सके।
उदाहरण के लिए, आप टूल को इस तरह कॉन्फ़िगर कर सकते हैं कि वह कॉलर ID को अपने-आप आपके CRM लुकअप एंडपॉइंट पर भेजे। इससे एजेंट बिना बताए सत्यापित कर सकता है कि इनकमिंग नंबर यूज़र ऑथेंटिकेशन के लिए ग्राहक के रजिस्टर्ड नंबर से मेल खाता है या नहीं। टूल कॉल के बजाय, ऑथेंटिकेशन को बातचीत शुरू होने से पहले चलने वाले conversation initiation webhook के रूप में भी कॉन्फ़िगर किया जा सकता है।
सुरक्षा नोट: कॉलर रिकॉर्ड में मौजूद नंबर से अलग नंबर इस्तेमाल कर सकते हैं, या स्टोर किए गए नंबर अनधिकृत लोगों की पहुँच में हो सकते हैं। इसलिए कॉलर ID-आधारित ऑथेंटिकेशन के लिए ग्राहक की पूर्व सहमति ज़रूरी होनी चाहिए या इसे अतिरिक्त ऑथेंटिकेशन तरीकों (जैसे नॉलेज-आधारित प्रश्न) के साथ मिलाना चाहिए।
ज़्यादा जानकारी के लिए सिस्टम डायनेमिक वेरिएबल्स और इनिशिएशन वेबहुक पर डॉक्यूमेंटेशन देखें।
उन्नत नॉलेज-आधारित / सुरक्षा प्रश्न ऑथेंटिकेशन
एजेंट सुरक्षा प्रश्नों का एक सेट पूछकर यूज़र को ऑथेंटिकेट कर सकता है और केवल तभी एक्सेस दे सकता है, जब कॉलर तय संख्या में सही जवाब दे। एजेंट को पहले से तय सूची (जैसे जन्मतिथि, पोस्टकोड, पालतू जानवर का नाम) से रैंडम प्रश्न चुनने और आपके डेटाबेस के लिए टूल कॉल से कॉलर के जवाबों को सत्यापित करने के लिए प्रॉम्प्ट किया जा सकता है।
ऑथेंटिकेशन टूल मौजूदा success count सहित JSON रिस्पॉन्स लौटाता है। टूल असाइनमेंट्स का इस्तेमाल करके, यह काउंट अपने-आप निकाला जाता है और किसी डायनेमिक वेरिएबल (जैसे auth_success_count) में स्टोर/अपडेट किया जाता है। हर सफल वेरिफ़िकेशन के बाद वेरिएबल बढ़ता है।
ज़रूरी संख्या में वेरिफ़िकेशन पूरे होने पर (जैसे, 3), वर्कफ़्लो एक्सप्रेशन कंडीशन डायनेमिक वेरिएबल की वैल्यू जाँचती है और विशेषाधिकार वाले सब-एजेंट नोड पर ट्रांज़िशन करती है। एक्सप्रेशन ऑथेंटिकेशन स्टेटस के आधार पर एक्सेस को निश्चित रूप से नियंत्रित करने के लिए तुलना ऑपरेटर (जैसे auth_success_count >= 3) इस्तेमाल करता है।
हमारे एज और फ़्लो कंट्रोल डॉक्यूमेंटेशन में रेफ़रेंस के लिए और जानकारी है।
वन-टाइम कोड
यह एक सार्वभौमिक तरीका है, जिसमें SMS या ईमेल के ज़रिए यूज़र के डिवाइस पर वन-टाइम कोड भेजा जाता है। एक्सेस पाने के लिए यूज़र को वेरिफ़िकेशन हेतु यह कोड एजेंट को बताना होता है।
इम्प्लीमेंटेशन वर्कफ़्लो को विस्तार से देखें:
- कोड जनरेशन: एजेंट एक डेडिकेटेड एंडपॉइंट पर सर्वर टूल कॉल से प्रक्रिया शुरू करता है। यह कार्रवाई एक सुरक्षित, वन-टाइम कोड जनरेट करती है और उसे यूज़र के पसंदीदा चैनल (SMS या ईमेल) से भेजती है।
- यूज़र प्रॉम्प्ट: एजेंट फिर यूज़र से प्राप्त कोड देने के लिए कहता है। वॉइस मोड में यूज़र कोड बोलते हैं, जिसे स्पीच टू टेक्स्ट से कैप्चर किया जाता है।
- कोड वेरिफ़िकेशन: एजेंट दूसरी टूल कॉल से यूज़र का दिया हुआ कोड बैकएंड वेरिफ़िकेशन सर्विस को भेजता है। बैकएंड सत्यापित करता है कि कोड मेल खाता है, एक्सपायर नहीं हुआ है और पहले इस्तेमाल नहीं हुआ है।
- वर्कफ़्लो रूटिंग: एजेंट वेरिफ़िकेशन रिस्पॉन्स के आधार पर नतीजे को संभालता है: सफलता: कोड सही होने पर, यूज़र को success condition के ज़रिए वर्कफ़्लो के पोस्ट-ऑथेंटिकेशन हिस्से में भेजा जाता है। विफलता: कोड गलत होने पर, एजेंट यूज़र से कोड दोबारा दर्ज करने के लिए कह सकता है या फ़ॉलबैक प्रक्रिया शुरू कर सकता है (जैसे नया कोड भेजना)।
सुरक्षा संबंधी बातें: ब्रूट-फ़ोर्स प्रयासों को रोकने के लिए rate limiting लागू करनी चाहिए, कोड का एक्सपायरी समय छोटा (3-5 मिनट) होना चाहिए और दोबारा प्रयासों को ट्रैक व सीमित करना चाहिए। वॉइस इंटरैक्शन में, कोड कैप्चर करते समय स्पीच टू टेक्स्ट की सटीकता सुनिश्चित करने के लिए कन्फ़र्मेशन प्रॉम्प्ट्स पर विचार करें।
सुरक्षित वॉइस ऑथेंटिकेशन के लिए ElevenAgents से शुरुआत करें
ये ऑथेंटिकेशन तरीके लचीले बिल्डिंग ब्लॉक्स हैं, तय समाधान नहीं। आपकी पसंद आपके खास रिस्क प्रोफ़ाइल, नियामक ज़रूरतों और यूज़र अनुभव के लक्ष्यों के अनुसार होनी चाहिए। ट्रांज़ैक्शन संभालने वाले बैंकिंग असिस्टेंट की सुरक्षा ज़रूरतें कस्टमर सर्विस बॉट से अलग होती हैं। प्लेटफ़ॉर्म की लचीलापन यह सुनिश्चित करती है कि खतरों के बदलने और ज़रूरतों के बढ़ने पर आपकी सुरक्षा रणनीति भी विकसित हो सके, और सुरक्षा व यूज़र अनुभव के बीच संतुलन बना रहे।
ElevenAgents आपको ऊपर बताए गए निश्चित वर्कफ़्लो गेटिंग, डिस्पैच टूल्स और टेलीफोनी-विशिष्ट वेरिएबल्स देता है। यानी आप ऐसा कॉलर ऑथेंटिकेशन बना सकते हैं जो कभी भी LLM के निर्णय पर निर्भर न हो।
पूरा वर्कफ़्लो बिल्डर देखने के लिए ElevenAgents प्लेटफ़ॉर्म देखें, या आज ही अपना पहला प्रमाणित वॉइस एजेंट वर्कफ़्लो बनाना शुरू करने के लिए सेल्स से संपर्क करें।
