वॉइस एजेंट्स के लिए सुरक्षित कॉलर ऑथेंटिकेशन डिज़ाइन करना
- प्रकाशित
- आखिरी बार अपडेट किया गया
सुनेंइस आर्टिकल को सुनें
वॉइस एजेंट तेज़ी से साधारण FAQ जवाब देने वाले टूल से ऐसे सिस्टम में बदल रहे हैं जो अकाउंट में बदलाव करते हैं, ट्रांज़ैक्शन प्रोसेस करते हैं और संवेदनशील ग्राहक डेटा एक्सेस करते हैं। इस बदलाव के साथ एक अहम चुनौती आती है: ऐसे कन्वर्सेशनल AI सिस्टम में, जहाँ पारंपरिक विज़ुअल वेरिफ़िकेशन के तरीके मौजूद नहीं हैं, कॉलर की पहचान कैसे प्रमाणित करें?
जब कोई वॉइस एजेंट सब्सक्रिप्शन अपडेट कर सकता है, अकाउंट बैलेंस देख सकता है या रिफ़ंड शुरू कर सकता है, तो उसे कॉलर की पहचान उतनी ही सख्ती से प्रमाणित करनी चाहिए जितनी मानव कॉल सेंटर करते हैं—लेकिन पूरी तरह वॉइस-आधारित इंटरैक्शन के ज़रिए। कंपनी की नीतियाँ मानने वाले मानव एजेंटों के विपरीत, AI एजेंटों को ऐसा तयशुदा, टूल-आधारित ऑथेंटिकेशन चाहिए जो LLM के निर्णय पर निर्भर न हो।
इस लेख में हम एंटरप्राइज़ डिप्लॉयमेंट्स में Forward Deployed Engineers के रूप में अपने काम से मिले प्रमाणित ऑथेंटिकेशन पैटर्न बताते हैं। हम एम्बेडेड विजेट्स के लिए सेशन-आधारित ऑथेंटिकेशन से लेकर टेलीफोनी-विशिष्ट तरीकों और OTP वेरिफ़िकेशन तक, पाँच मुख्य तरीकों को कवर करेंगे और बताएँगे कि ElevenLabs प्लेटफ़ॉर्म पर तयशुदा वर्कफ़्लो गेटिंग के ज़रिए हर तरीके को कैसे लागू करें।
सबसे ज़रूरी बात यह है कि हम दिखाएँगे कि ऑथेंटिकेशन को बातचीत के आधार पर अनुमान लगाने के लिए नहीं छोड़ा जा सकता। इसके बजाय, इसे अलग-अलग सब-एजेंट्स, टूल-आधारित वेरिफ़िकेशन और शर्तों पर आधारित वर्कफ़्लो रूटिंग से डिज़ाइन करना होगा, ताकि सिर्फ़ प्रमाणित यूज़र ही विशेषाधिकार वाले ऑपरेशन्स तक पहुँचें।
सारांश
- वॉइस एजेंट्स के लिए कॉलर ऑथेंटिकेशन तयशुदा और टूल-आधारित होना चाहिए; इसे LLM के बातचीत से किए गए अनुमान पर नहीं छोड़ा जा सकता।
- होस्ट एप्लिकेशन ऑथेंटिकेशन मौजूदा सेशन डेटा एजेंट को भेजता है, इसलिए जो यूज़र पहले से लॉग इन हैं उन्हें दोबारा ऑथेंटिकेट नहीं करना पड़ता।
- नॉलेज-आधारित ऑथेंटिकेशन कॉलर की दी गई जानकारी, जैसे अकाउंट नंबर या जन्मतिथि, को सर्वर-साइड टूल कॉल के ज़रिए बैकएंड सिस्टम से सत्यापित करता है।
- टेलीफोनी डिप्लॉयमेंट्स कॉलर ID जैसे सिस्टम डायनामिक वेरिएबल्स का इस्तेमाल करके चुपचाप ऑथेंटिकेट कर सकते हैं, लेकिन कॉलर ID स्पूफ़ या साझा की जा सकती है, इसलिए इसे दूसरे फ़ैक्टर के साथ जोड़ना चाहिए।
- वन-टाइम कोड वेरिफ़िकेशन SMS या ईमेल से कोड भेजता है और बैकएंड सेवा के ज़रिए उसे मान्य करता है।
तयशुदा ऑथेंटिकेशन का आर्किटेक्चरल आधार
यह सुनिश्चित करने के लिए कि सिर्फ़ प्रमाणित यूज़र ही अकाउंट-संबंधी जानकारी एक्सेस कर सकें, हम ElevenLabs वर्कफ़्लो के ज़रिए एनवायरनमेंट और एक्सेस को सख्ती से अलग रखने की सलाह देते हैं। ऑथेंटिकेशन को हमेशा boolean सफलता या विफलता आउटपुट वाले टूल कॉल के ज़रिए लागू करना चाहिए, जिसे ElevenLabs वर्कफ़्लो बिल्डर में dispatch tool के रूप में कॉन्फ़िगर किया गया हो।
ट्रांसफ़र कंडीशन को सीधे टूल कॉल के नतीजे से जोड़ने पर, अकाउंट डेटा तक पहुँच वाला सब-एजेंट सिर्फ़ सफल ऑथेंटिकेशन के बाद ही उपलब्ध होता है और बिना प्रमाणित यूज़र्स से पूरी तरह अलग रहता है। इससे ऑथेंटिकेशन तयशुदा रहता है, LLM के निर्णय पर नहीं छोड़ा जाता, और सत्यापित पहचान के बिना डाउनस्ट्रीम नोड्स तक आगे बढ़ने से रोकता है।
विकल्प के तौर पर, ट्रांसफ़र एक्सप्रेशन्स को भरोसेमंद ट्रांसफ़र तरीके के रूप में इस्तेमाल किया जा सकता है। ये एक्सप्रेशन्स उन डायनामिक वेरिएबल्स का संदर्भ लेते हैं जो टूल कॉल के नतीजों से अपडेट होते हैं।
उदाहरण कार्यान्वयन
Salesforce में यूज़र को सत्यापित करें (टूल कॉल)। सफल होने पर Salesforce से ग्राहक के ट्रांज़ैक्शन डेटा को प्राप्त करें (एक और टूल कॉल), फिर यूज़र को उस सब-एजेंट पर ट्रांसफ़र करें जो इस डेटा से ग्राहक से बातचीत करता है और ज़रूरत पड़ने पर अन्य कार्रवाई करता है।
यूज़र पहचान ऑथेंटिकेशन के तरीके
ये ऑथेंटिकेशन तरीके ElevenLabs प्लेटफ़ॉर्म में मूल रूप से उपलब्ध नहीं हैं। इन्हें सर्वर-साइड टूल्स के ज़रिए लागू किया जा सकता है, जो आपके CRM या बैकएंड/डेटाबेस से जुड़ते हैं, जहाँ ऑथेंटिकेशन डेटा स्टोर होता है।
होस्ट एप्लिकेशन ऑथेंटिकेशन
वेबसाइट में एम्बेड किए गए वॉइस एजेंट्स के लिए, होस्ट एप्लिकेशन एजेंट/विजेट शुरू करते समय डायनामिक वेरिएबल्स के ज़रिए यूज़र सेशन डेटा (जैसे लॉग-इन स्टेटस, अकाउंट ID या सेशन टोकन) भेज सकता है। इन्हीं डायनामिक वेरिएबल्स का इस्तेमाल करके ये वेरिएबल्स अपने-आप टूल कॉल्स में जोड़े जाते हैं, जिससे एजेंट अलग ऑथेंटिकेशन के बिना इंटीग्रेटेड सिस्टम्स से व्यक्तिगत डेटा प्राप्त कर सकता है।
इससे सहायता का अनुभव सहज बनता है, क्योंकि होस्ट एप्लिकेशन यूज़र को पहले ही सत्यापित कर चुका होता है। आप इसे कस्टम कॉन्फ़िगरेशन से सेट अप कर सकते हैं या ElevenLabs विजेट इस्तेमाल कर सकते हैं, जिसमें विजेट कॉन्फ़िगरेशन से रनटाइम पर वेरिएबल्स पास किए जाते हैं (जैसे, <elevenlabs-convai dynamic-variables='{"user_id": "123", "account_tier": "premium"}'>)।
पूरे सेटअप के लिए डायनामिक वेरिएबल्स डॉक्यूमेंटेशन देखें।
नॉलेज-आधारित ऑथेंटिकेशन (KBA)
वॉइस एजेंट कॉलर से अकाउंट नंबर, पोस्टकोड, जन्मतिथि या सुरक्षा जवाब जैसी ऑथेंटिकेशन जानकारी देने को कहता है। सर्वर-साइड टूल (webhook या बैकएंड कॉल) इन वैल्यूज़ को आपके डेटाबेस (जैसे CRM या identity store) से सत्यापित करता है। टूल सफलता/विफलता का नतीजा देता है, जिसमें boolean स्टेटस (is_error) और वर्णनात्मक टेक्स्ट, दोनों शामिल होते हैं।
आप इसे तयशुदा वर्कफ़्लो गेटिंग के ज़रिए लागू कर सकते हैं: ज़रूरी जानकारी माँगने के बाद, टूल dispatch कॉन्फ़िगर करें और वर्कफ़्लो की conditional transfer edges का इस्तेमाल करें, जो टूल की सफलता/विफलता स्टेटस के आधार पर अलग रास्ते चुनती हैं और प्रमाणित यूज़र्स को “privileged” एजेंट नोड्स पर भेजती हैं।
आपकी फ़्रॉड जोखिम आवश्यकताओं के आधार पर, यह तरीका स्टैटिक सुरक्षा सवालों और डायनामिक "out-of-wallet" स्टाइल वेरिफ़िकेशन, दोनों को सपोर्ट करता है।
अधिक जानकारी के लिए सर्वर टूल्स और एजेंट वर्कफ़्लो dispatch tool node डॉक्यूमेंटेशन देखें।
सिस्टम डायनामिक वेरिएबल्स (केवल टेलीफोनी)
फ़ोन-आधारित बातचीत (Twilio या SIP trunk के ज़रिए) में, आपके एजेंट को टेलीफोनी-विशिष्ट सिस्टम वेरिएबल्स अपने-आप मिलते हैं, जिनमें system__caller_id (कॉलर का फ़ोन नंबर) शामिल है। बातचीत शुरू होते ही यह वेरिएबल अपने-आप भर जाता है।
आप इसका संदर्भ दो तरीकों से दे सकते हैं:
- प्रॉम्प्ट्स/मैसेज में: डबल कर्ली ब्रेसेज़ के साथ इसका संदर्भ दें, जैसे {{system__caller_id}}, और इन्हें वास्तविक वैल्यू से बदल दिया जाएगा।
- टूल पैरामीटर्स में: इन वेरिएबल्स का इस्तेमाल करने के लिए टूल पैरामीटर्स कॉन्फ़िगर करें, जिससे प्रॉम्प्ट में इनका उल्लेख किए बिना चुपचाप ऑथेंटिकेशन हो सके।
उदाहरण के लिए, आप किसी टूल को कॉलर ID अपने CRM lookup endpoint पर अपने-आप भेजने के लिए कॉन्फ़िगर कर सकते हैं। इससे एजेंट चुपचाप सत्यापित कर सकता है कि आने वाला नंबर यूज़र ऑथेंटिकेशन के लिए ग्राहक के रजिस्टर्ड नंबर से मेल खाता है या नहीं। टूल कॉल के बजाय, ऑथेंटिकेशन को conversation initiation webhook के रूप में भी कॉन्फ़िगर किया जा सकता है, जो बातचीत शुरू होने से पहले चलता है।
सुरक्षा नोट: कॉलर रिकॉर्ड में मौजूद नंबर से अलग नंबर इस्तेमाल कर सकते हैं, या स्टोर किए गए नंबर अनधिकृत लोगों की पहुँच में हो सकते हैं। इसलिए कॉलर ID-आधारित ऑथेंटिकेशन में ग्राहक की पहले से सहमति लेना ज़रूरी होना चाहिए या इसे अतिरिक्त ऑथेंटिकेशन तरीकों (जैसे नॉलेज-आधारित सवालों) के साथ जोड़ना चाहिए।
अधिक जानकारी के लिए सिस्टम डायनामिक वेरिएबल्स और Initiation webhook का डॉक्यूमेंटेशन देखें।
उन्नत नॉलेज-आधारित / सुरक्षा सवाल ऑथेंटिकेशन
एजेंट कई सुरक्षा सवाल पूछकर यूज़र को ऑथेंटिकेट कर सकता है और केवल तभी एक्सेस दे सकता है जब कॉलर तय संख्या में सवालों के सही जवाब दे। एजेंट को पहले से तय सूची (जैसे जन्मतिथि, पोस्टकोड, पालतू जानवर का नाम) में से रैंडम सवाल चुनने और आपके डेटाबेस पर टूल कॉल के ज़रिए कॉलर के जवाब सत्यापित करने के लिए प्रॉम्प्ट किया जा सकता है।
ऑथेंटिकेशन टूल मौजूदा सफलता संख्या सहित JSON रिस्पॉन्स देता है। टूल असाइनमेंट्स के ज़रिए, यह संख्या अपने-आप निकाली जाती है और किसी डायनामिक वेरिएबल (जैसे auth_success_count) में स्टोर/अपडेट की जाती है। हर सफल वेरिफ़िकेशन के बाद यह वेरिएबल बढ़ता है।
वेरिफ़िकेशन की ज़रूरी संख्या पूरी होने पर (जैसे 3), वर्कफ़्लो एक्सप्रेशन कंडीशन डायनामिक वेरिएबल की वैल्यू जाँचती है और एक privileged सब-एजेंट नोड पर ट्रांज़िशन करती है। यह एक्सप्रेशन ऑथेंटिकेशन स्टेटस के आधार पर तयशुदा ढंग से एक्सेस नियंत्रित करने के लिए comparison operators (जैसे auth_success_count >= 3) का इस्तेमाल करता है।
हमारे edges और flow control डॉक्यूमेंटेशन में आपके लिए अधिक जानकारी है।
वन-टाइम कोड
यह एक सार्वभौमिक तरीका है, जिसमें SMS या ईमेल से यूज़र के डिवाइस पर वन-टाइम कोड भेजा जाता है। एक्सेस पाने के लिए यूज़र को वेरिफ़िकेशन हेतु वह कोड एजेंट को बताना होता है।
यहाँ कार्यान्वयन वर्कफ़्लो को विस्तार से बताया गया है:
- कोड जनरेशन: एजेंट एक dedicated endpoint पर सर्वर टूल कॉल के साथ प्रक्रिया शुरू करता है। यह कार्रवाई सुरक्षित वन-टाइम कोड जनरेट करती है और यूज़र के पसंदीदा चैनल (SMS या ईमेल) से उसे भेजती है।
- यूज़र प्रॉम्प्ट: एजेंट फिर यूज़र से मिला हुआ कोड बताने को कहता है। वॉइस मोड में यूज़र कोड बोलते हैं, जिसे स्पीच टू टेक्स्ट के ज़रिए कैप्चर किया जाता है।
- कोड वेरिफ़िकेशन: एजेंट दूसरे टूल कॉल के ज़रिए यूज़र के दिए कोड को बैकएंड वेरिफ़िकेशन सेवा पर भेजता है। बैकएंड जाँचता है कि कोड मेल खाता है, उसकी समय-सीमा समाप्त नहीं हुई है और वह पहले इस्तेमाल नहीं हुआ है।
- वर्कफ़्लो रूटिंग: एजेंट वेरिफ़िकेशन रिस्पॉन्स के आधार पर नतीजे को संभालता है: सफलता: कोड सही होने पर यूज़र को सफलता कंडीशन के ज़रिए वर्कफ़्लो के पोस्ट-ऑथेंटिकेशन हिस्से में भेज दिया जाता है। विफलता: कोड गलत होने पर एजेंट यूज़र को फिर से कोड डालने के लिए कह सकता है या फ़ॉलबैक प्रक्रिया शुरू कर सकता है (जैसे नया कोड भेजना)।
सुरक्षा संबंधी बातें: ब्रूट-फ़ोर्स कोशिशें रोकने के लिए rate limiting लागू करें, कोड की एक्सपायरी अवधि कम (3–5 मिनट) रखें और दोबारा कोशिशों को ट्रैक व सीमित करें। वॉइस इंटरैक्शन में कोड कैप्चर करते समय स्पीच टू टेक्स्ट की सटीकता सुनिश्चित करने के लिए confirmation prompts पर विचार करें।
सुरक्षित वॉइस ऑथेंटिकेशन के लिए ElevenAgents के साथ शुरुआत करें
ये ऑथेंटिकेशन तरीके लचीले बिल्डिंग ब्लॉक्स हैं, निर्धारित समाधान नहीं। आपका चुनाव आपके खास जोखिम प्रोफ़ाइल, नियामक आवश्यकताओं और यूज़र अनुभव के लक्ष्यों के अनुरूप होना चाहिए। ग्राहक सेवा बॉट को ट्रांज़ैक्शन संभालने वाले बैंकिंग असिस्टेंट से अलग स्तर की सुरक्षा चाहिए। प्लेटफ़ॉर्म की लचीलापन यह सुनिश्चित करती है कि खतरों में बदलाव और आवश्यकताओं के बढ़ने पर आपकी सुरक्षा रणनीति विकसित हो सके और सुरक्षा व यूज़र अनुभव के बीच संतुलन बना रहे।
ElevenAgents आपको ऊपर बताए गए तयशुदा वर्कफ़्लो गेटिंग, dispatch tools और टेलीफोनी-विशिष्ट वेरिएबल्स देता है, ताकि आप ऐसा कॉलर ऑथेंटिकेशन बना सकें जो कभी भी LLM के निर्णय पर निर्भर न हो।
पूरा वर्कफ़्लो बिल्डर देखने के लिए ElevenAgents प्लेटफ़ॉर्म देखें या सेल्स से संपर्क करें और आज ही अपना पहला प्रमाणित वॉइस एजेंट वर्कफ़्लो बनाना शुरू करें।
