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