प्रमाणीकरण (Authentication) यह जाँचता है कि आप कौन हैं; प्राधिकरण (Authorization) यह तय करता है कि आप क्या कर सकते हैं। AI-संचालित एप्लिकेशनों की बढ़ती संख्या लॉगिन के समय एक बार उपयोगकर्ता की पहचान सत्यापित करती है और फिर पूरे सत्र के लिए अंतर्निहित एजेंट को किसी भी संसाधन पर कार्य करने की अनुमति दे देती है, जो प्रभावी रूप से उसे एक "ब्लैंक चेक" सौंपने जैसा है। यह डिज़ाइन अनजाने में डेटा लीक, अवांछित ईमेल, या यहाँ तक कि विनाशकारी डेटाबेस अपडेट के द्वार खोल देता है, और जोखिम तब और बढ़ जाता है जब एक AI असिस्टेंट मिलीसेकंड की लैटेंसी के साथ कई टूल्स को कॉल कर सकता है।
यह गलती बार-बार क्यों होती है
अधिकांश AI डेवलपर्स लॉगिन स्क्रीन को एकमात्र सुरक्षा द्वार मानते हैं। कोड पासवर्ड या टोकन मांगता है, सत्र को "authenticated" के रूप में चिह्नित करता है, और फिर यह मान लेता है कि उसके बाद का कोई भी अनुरोध सुरक्षित है। एक पारंपरिक वेब ऐप में, मानव उपयोगकर्ता के धीमे क्लिक एक प्राकृतिक थ्रॉटलिंग पॉइंट (throttling point) प्रदान करते हैं; एक इंसान "delete" बटन दबाने से पहले रुकता है। हालाँकि, एक AI एजेंट कुछ ही सेकंडों में दर्जनों टूल कॉल कर सकता है। यदि प्लेटफॉर्म केवल यह पूछता है "क्या उपयोगकर्ता लॉग इन है?", तो प्रत्येक कॉल को वही असीमित विशेषाधिकार विरासत में मिलते हैं।
इसका मूल कारण सुविधा है। टीमें अक्सर पूरे एप्लिकेशन के लिए एक ही लंबे समय तक चलने वाला (long-lived) सर्विस अकाउंट प्रदान करती हैं ताकि कोड को कई टोकन या स्कोप्स को मैनेज न करना पड़े। उस अकाउंट के पास आमतौर पर सभी प्रोजेक्ट्स में व्यापक अनुमतियाँ—read, write, delete—होती हैं। जब कोई AI असिस्टेंट उस सत्र के भीतर चलता है, तो वह स्वचालित रूप से उन अधिकारों को प्राप्त कर लेता है, चाहे वर्तमान कार्य के लिए वास्तव में उनकी आवश्यकता हो या न हो।
दांव पर क्या है
- डेटा एक्सपोज़र (Data exposure) – एक एजेंट जो उपयोगकर्ता के लॉग इन करने के बाद किसी भी फ़ाइल को पढ़ सकता है, अनजाने में गोपनीय दस्तावेज़ों को ऐसे रिस्पॉन्स में खींच सकता है जिसे बाद में संगठन के बाहर साझा किया जाता है।
- अनपेक्षित कार्य (Unintended actions) – एक सपोर्ट इंजीनियर का AI हेल्पर प्रोडक्शन डेटाबेस के खिलाफ सीधे SQL क्वेरी चला सकता है, सिर्फ इसलिए क्योंकि इंजीनियर का सत्र अभी भी सक्रिय है, भले ही वह क्वेरी उस टिकट से संबंधित न हो जिस पर काम किया जा रहा है।
- नियामक अनुपालन (Regulatory compliance) – कई डेटा-संरक्षण नियमों की आवश्यकता है कि एक्सेस को केवल न्यूनतम आवश्यक तक ही सीमित रखा जाए। एक व्यापक अनुमति मॉडल (blanket permission model) उन सिद्धांतों का उल्लंघन कर सकता है और ऑडिट या जुर्माने का कारण बन सकता है।
- परिचालन लागत (Operational cost) – रिकॉर्ड को डिलीट या संशोधित करने वाली गलतियाँ टीमों को परिवर्तनों को रोलबैक करने, मूल कारणों की जांच करने और उपयोगकर्ताओं के साथ विश्वास फिर से बनाने के लिए मजबूर करती हैं—इन सबमें समय और पैसा बर्बाद होता है।
छूटा हुआ कदम: प्रति-एक्शन प्राधिकरण (per-action authorization)
प्राधिकरण का मूल्यांकन सिस्टम के भीतर हर "दरवाजे" पर किया जाना चाहिए, न कि केवल मुख्य प्रवेश द्वार पर। प्रश्न "यह कौन है?" से बदलकर "क्या इस विशिष्ट संसाधन पर यह विशिष्ट कार्य अभी किया जा सकता है?" हो जाता है। उस जाँच को लागू करने के लिए पूर्ण रीडिज़ाइन की आवश्यकता नहीं है; इसके लिए केवल एक एकल सत्र फ्लैग (session flag) से अल्पकालिक, स्कोप किए गए टोकन (short-lived, scoped tokens) की ओर बढ़ने की आवश्यकता है।
व्यवहार में यह कैसे काम करता है
- एक परिभाषित स्कोप के साथ टोकन का अनुरोध करें – जब AI एजेंट को किसी टूल को कॉल करने की आवश्यकता होती है, तो वह पहले एक ऐसा टोकन प्राप्त करता है जिसमें आवश्यक सटीक अनुमतियाँ (जैसे,
read:ticket,execute:sql_query) सूचीबद्ध होती हैं। - प्रत्येक कॉल के लिए टोकन को मान्य करें – टूल चलने से पहले, सर्विस यह जाँचती है कि टोकन में आवश्यक स्कोप शामिल है और टोकन समाप्त (expire) तो नहीं हो गया है।
- संसाधन को स्कोप से मिलाएँ – यदि अनुरोध किसी विशेष प्रोजेक्ट या डेटाबेस को लक्षित करता है, तो टोकन को स्पष्ट रूप से उस पहचानकर्ता (identifier) तक पहुँच प्रदान करनी चाहिए।
- अस्वीकार करें या अनुमति दें – यदि कोई भी जाँच विफल होती है, तो कॉल को अस्वीकार कर दिया जाता है और एजेंट को एक त्रुटि (error) प्राप्त होती है जिसे वह उपयोगकर्ता को दिखा सकता है।
कोड का अंतर सीधा है। एक "गलत" दृष्टिकोण ऐसा दिख सकता है:
if session.is_authenticated():
tool.run(params)
एक "अच्छा" दृष्टिकोण जाँच का विस्तार करता है:
token = get_scoped_token(user, required_scope)
if token.is_valid() and token.allows(required_scope, resource_id):
tool.run(params)
else:
raise PermissionError
दूसरा पैटर्न कुछ लाइनें जोड़ता है लेकिन सिस्टम को हर ऑपरेशन के लिए सही प्रश्न पूछने के लिए मजबूर करता है।
मानक जो इसे आसान बनाते हैं
OAuth 2.0 स्कोप्स पहले से ही टोकन क्या कर सकता है, इसे सीमित करने का एक व्यापक रूप से अपनाया गया तरीका प्रदान करते हैं। project:1234:write या email:send जैसे स्कोप्स को एनकोड करने वाले अल्पकालिक एक्सेस टोकन जारी करके, डेवलपर्स सत्यापन चरण (verification step) को पूरा करने के लिए मौजूदा लाइब्रेरीज़ पर भरोसा कर सकते हैं।
नए Rich Authorization Requests (RFC 9396) इस विचार का विस्तार करते हैं, जिससे क्लाइंट को एक स्थिर सूची को पहले से परिभाषित करने के बजाय रनटाइम पर विस्तृत (granular) अनुमतियों का अनुरोध करने की अनुमति मिलती है। यह लचीलापन तब उपयोगी होता है जब एक AI वर्कफ़्लो को उपयोगकर्ता के इरादे के आधार पर ऑन-द-फ्लाई (on the fly) क्षमताओं को जोड़ने या हटाने की आवश्यकता हो सकती है।
प्रति-तर्क: सरलता बनाम सुरक्षा
कुछ टीमों का तर्क है कि प्रति-एक्शन (per-action) जांच से लेटेंसी और कोड की जटिलता बढ़ जाती है, विशेष रूप से तब जब AI असिस्टेंट को बहुत कम समय में कई टूल्स को कॉल करना पड़ता है। वे बताते हैं कि एक सिंगल सेशन टोकन प्रत्येक कॉल के लिए नया टोकन प्राप्त करने और उसे सत्यापित करने के ओवरहेड से बचाता है। हालांकि, इसका नुकसान दुरुपयोग का बहुत अधिक जोखिम है। आधुनिक टोकन-वैलिडेशन सेवाएं माइक्रोसेकंड में काम करने के लिए डिज़ाइन की गई हैं, और 'प्रिंसिपल ऑफ लीस्ट प्रिविलेज' (principle of least privilege) से समझौता किए बिना अतिरिक्त नेटवर्क राउंड-ट्रिप को बैच या कैश किया जा सकता है। ऐसे वातावरण में जहाँ डेटा अखंडता और अनुपालन (compliance) से समझौता नहीं किया जा सकता, वहां जोखिम में कमी के कारण प्रदर्शन की मामूली लागत गौण हो जाती है।
आगे क्या ध्यान में रखें
- AI SDKs में स्कोप किए गए (scoped) टोकन का अपनाना – प्रमुख AI प्लेटफॉर्म टूलकिट के अपडेट्स पर नज़र रखें; कई टूलकिट OAuth-आधारित स्कोप के लिए हेल्पर फंक्शन देना शुरू कर रहे हैं।
- पॉलिसी-एज़-कोड (Policy-as-code) फ्रेमवर्क – उभरते हुए समाधान टीमों को एक डिक्लेरेटिव फ़ाइल में ऑथोराइजेशन नियम घोषित करने की अनुमति देते हैं, जो रनटाइम पर स्वचालित रूप से लागू होते हैं।
- ऑडिट लॉग्स जो प्रति-एक्शन निर्णयों को सामने लाते हैं – जैसे-जैसे अधिक प्लेटफॉर्म प्रत्येक ऑथोराइजेशन चेक को रिकॉर्ड करेंगे, संगठनों को यह स्पष्टता मिलेगी कि किन AI कार्यों को अनुमति दी जा रही है या ब्लॉक किया जा रहा है, जिससे भविष्य में पॉलिसी में सुधार करने में मदद मिलेगी।
निष्कर्ष
लॉग-इन किए गए सेशन को कुछ भी करने की अनुमति मानना अनपेक्षित परिणामों का कारण बन सकता है। ऑथोराइजेशन के निर्णय को लॉगिन के क्षण से हटाकर प्रत्येक व्यक्तिगत टूल कॉल तक ले जाकर—और अल्पकालिक, स्कोप किए गए टोकन का उपयोग करके—AI एप्लिकेशन डेटा की सुरक्षा करते हुए, नियमों का पालन करते हुए और महंगी गलतियों से बचते हुए, ऑटोनॉमस एजेंटों की सुविधा बनाए रख सकते हैं। कोड की अतिरिक्त लाइनें उस सिस्टम के लिए एक छोटी सी कीमत हैं जो हर बार किसी एक्शन की कोशिश किए जाने पर सही सवाल पूछता है।