प्रमाणीकरण (Authentication) तुम्ही कोण आहात हे तपासते; अधिकृतता (Authorization) तुम्ही काय करू शकता हे ठरवते. AI-आधारित ॲप्लिकेशन्सची संख्या वाढत आहे, जी लॉगिनच्या वेळी एकदा वापरकर्त्याची ओळख पटवते आणि त्यानंतर उर्वरित सेशनसाठी मूळ एजंटला कोणत्याही रिसोर्सवर काम करण्याची परवानगी देते, ज्यामुळे प्रभावीपणे त्याला एक "ब्लँक चेक" (blank check) देऊन टाकले जाते. ही रचना चुकून डेटा लीक होणे, नको असलेले ईमेल जाणे किंवा अगदी डेटाबेसमध्ये विनाशकारी बदल होण्याचे दरवाजे उघडते, आणि जेव्हा एखादा AI असिस्टंट मिलीसेकंद लॅटन्सीमध्ये अनेक टूल्स वापरू शकतो, तेव्हा हा धोका अधिक वाढतो.

ही चूक वारंवार का घडते

बहुतेक AI डेव्हलपर्स लॉगिन स्क्रीनला एकमेव सुरक्षा द्वार मानतात. कोड पासवर्ड किंवा टोकनची मागणी करतो, सेशनला "authenticated" म्हणून मार्क करतो आणि त्यानंतरची कोणतीही विनंती सुरक्षित आहे असे गृहीत धरतो. पारंपारिक वेब ॲपमध्ये, मानवी वापरकर्त्याचे संथ क्लिक्स एक नैसर्गिक थ्रॉटलिंग पॉइंट (मर्यादा बिंदू) प्रदान करतात; एखादा माणूस "delete" बटण दाबण्यापूर्वी थांबेल. मात्र, एक AI एजंट काही सेकंदात डझनावारी टूल कॉल्स करू शकतो. जर प्लॅटफॉर्म फक्त "वापरकर्ता लॉगिन आहे का?" असे विचारत असेल, तर प्रत्येक कॉलला तेच अनियंत्रित अधिकार प्राप्त होतात.

याचे मूळ कारण सोयीस्करपणा आहे. टीम्स अनेकदा संपूर्ण ॲप्लिकेशनसाठी एकच दीर्घकाळ टिकणारे (long-lived) सर्व्हिस अकाउंट तयार करतात, जेणेकरून कोडला अनेक टोकन्स किंवा स्कोप्स व्यवस्थापित करावे लागणार नाहीत. त्या अकाउंटला सहसा सर्व प्रोजेक्ट्समध्ये व्यापक परवानग्या—read, write, delete—असतात. जेव्हा एखादा AI असिस्टंट त्या सेशनमध्ये चालतो, तेव्हा सध्याच्या कामासाठी त्यांची खरोखर गरज आहे की नाही, याचा विचार न करता तो आपोआप ते अधिकार प्राप्त करतो.

काय धोक्यात आहे

  • डेटा एक्सपोजर (Data exposure) – वापरकर्त्याने लॉगिन केल्यानंतर कोणताही फाईल वाचू शकणारा एजंट, चुकून गोपनीय कागदपत्रे प्रतिसादात (response) आणू शकतो, जी नंतर संस्थेबाहेर शेअर केली जाऊ शकतात.
  • अनपेक्षित कृती (Unintended actions) – सपोर्ट इंजिनिअरचा AI हेल्पर प्रोडक्शन डेटाबेसवर थेट SQL क्वेरी कार्यान्वित करू शकतो, केवळ कारण इंजिनिअरचे सेशन अजूनही सक्रिय आहे, जरी ती क्वेरी हाताळल्या जाणाऱ्या तिकीटशी संबंधित नसली तरीही.
  • नियामक अनुपालन (Regulatory compliance) – अनेक डेटा-संरक्षण नियमांनुसार प्रवेश (access) केवळ आवश्यक किमान मर्यादेपर्यंतच मर्यादित असावा लागतो. एक सर्वसमावेशक परवानगी मॉडेल (blanket permission model) या तत्त्वांचे उल्लंघन करू शकते आणि ऑडिट किंवा दंड लागू करू शकते.
  • कार्यात्मक खर्च (Operational cost) – रेकॉर्ड्स डिलीट किंवा मॉडिफाय करणाऱ्या चुकांमुळे टीम्सना बदल रिव्हर्स (roll back) करावे लागतात, मूळ कारणांचा शोध घ्यावा लागतो आणि वापरकर्त्यांचा विश्वास पुन्हा संपादन करावा लागतो—या सर्व गोष्टींमुळे वेळ आणि पैसा वाया जातो.

गहाळ असलेली पायरी: प्रत्येक कृतीसाठी अधिकृतता (per-action authorization)

अधिकृतता केवळ मुख्य प्रवेशद्वारावरच नाही, तर सिस्टममधील प्रत्येक "दरवाजा" जवळ तपासली पाहिजे. प्रश्न "हा कोण आहे?" वरून बदलून "या विशिष्ट रिसोर्सवर ही विशिष्ट कृती आताच्या आता केली जाऊ शकते का?" असा झाला पाहिजे. ही तपासणी लागू करण्यासाठी पूर्ण रिडिझाइनची गरज नाही; फक्त एका सिंगल सेशन फ्लॅगकडून अल्पायुषी, स्कोप केलेल्या टोकन्सकडे (short-lived, scoped tokens) वळण्याची गरज आहे.

प्रत्यक्ष व्यवहारात हे कसे कार्य करते

  1. परिभाषित स्कोपसह टोकनची विनंती करा – जेव्हा AI एजंटला टूल कॉल करण्याची आवश्यकता असते, तेव्हा तो प्रथम एक असे टोकन मिळवतो ज्यामध्ये आवश्यक असलेल्या नेमक्या परवानग्यांची यादी असते (उदा. read:ticket, execute:sql_query).
  2. प्रत्येक कॉलसाठी टोकनची वैधता तपासा – टूल चालण्यापूर्वी, सर्व्हिस तपासते की टोकनमध्ये आवश्यक स्कोप समाविष्ट आहे आणि टोकनची मुदत संपलेली नाही.
  3. रिसोर्सचा स्कोपशी मेळ घाला – जर विनंती एखाद्या विशिष्ट प्रोजेक्ट किंवा डेटाबेससाठी असेल, तर टोकनने स्पष्टपणे त्या आयडेंटिफायरला प्रवेश दिला पाहिजे.
  4. नाकारा किंवा परवानगी द्या – जर कोणतीही तपासणी अयशस्वी झाली, तर कॉल नाकारला जातो आणि एजंटला एरर मिळतो जो तो वापरकर्त्याला दाखवू शकतो.

कोडमधील फरक सरळ आहे. एक "चुकीचा" दृष्टिकोन असा असू शकतो:

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 सारखे स्कोप्स एनकोड करणारे अल्पायुषी ॲक्सेस टोकन्स जारी करून, डेव्हलपर्स पडताळणीची पायरी पूर्ण करण्यासाठी अस्तित्वात असलेल्या लायब्ररींवर अवलंबून राहू शकतात.

नवीन Rich Authorization Requests (RFC 9396) ही कल्पना अधिक विस्तारते, ज्यामुळे क्लायंटला आधीच स्थिर यादी परिभाषित करण्याऐवजी रनटाइममध्ये सूक्ष्म (granular) परवानग्यांची विनंती करण्याची परवानगी मिळते. जेव्हा AI वर्कफ्लोला वापरकर्त्याच्या हेतूवर आधारित क्षणात क्षमता वाढवण्याची किंवा कमी करण्याची आवश्यकता असते, तेव्हा ही लवचिकता उपयुक्त ठरते.

प्रतिवाद: साधेपणा विरुद्ध सुरक्षा

काही टीम्सचे असे म्हणणे आहे की प्रत्येक कृतीसाठी (per-action) तपासणी केल्यामुळे लॅटन्सी (latency) आणि कोडची गुंतागुंत वाढते, विशेषतः जेव्हा AI असिस्टंटला वेगाने अनेक टूल्स कॉल करावे लागतात. प्रत्येक कॉलसाठी नवीन टोकन मिळवण्याचा आणि त्याचे प्रमाणीकरण करण्याचा अतिरिक्त भार टाळण्यासाठी एकच सेशन टोकन पुरेसे असते, असे ते सुचवतात. तथापि, याचा तोटा म्हणजे गैरवापराचा धोका प्रचंड प्रमाणात वाढतो. आधुनिक टोकन-व्हॅलिडेशन सेवा मायक्रोसेकंदमध्ये काम करण्यासाठी डिझाइन केलेल्या आहेत आणि 'प्रिन्सिपल ऑफ लीस्ट प्रिव्हिलेज' (principle of least privilege) तत्त्वाशी तडजोड न करता अतिरिक्त नेटवर्क राउंड-ट्रिप बॅच किंवा कॅश (cache) केली जाऊ शकते. ज्या वातावरणात डेटाची अखंडता (data integrity) आणि अनुपालन (compliance) अत्यंत महत्त्वाचे असते, तिथे कामगिरीवर येणारा किरकोळ परिणाम धोक्यातील घटामुळे गौण ठरतो.

पुढे काय लक्ष ठेवावे

  • AI SDKs मध्ये स्कोपड टोकन्सचा (scoped tokens) अवलंब – प्रमुख AI प्लॅटफॉर्म टूलकिटमधील अपडेट्सवर लक्ष ठेवा; अनेक टूलकिट्स आता OAuth-आधारित स्कोपसाठी हेल्पर फंक्शन्स उपलब्ध करून देऊ लागले आहेत.
  • Policy-as-code फ्रेमवर्क्स – उदयोन्मुख सोल्यूशन्समुळे टीम्सना डिक्लेरेटिव्ह फाईलमध्ये ऑथोरायझेशन नियम घोषित करता येतात, जे रनटाइममध्ये आपोआप लागू होतात.
  • प्रत्येक कृतीवरील निर्णयांचे ऑडिट लॉग्स – जसजसे अधिक प्लॅटफॉर्म्स प्रत्येक ऑथोरायझेशन चेकची नोंद ठेवतील, तसतसे संस्थांना कोणत्या AI कृतींना परवानगी दिली जात आहे किंवा कोणत्या रोखल्या जात आहेत, याची स्पष्टता मिळेल, ज्यामुळे भविष्यातील पॉलिसीमध्ये सुधारणा करणे सोपे होईल.

मुख्य सारांश

लॉग-इन केलेल्या सेशनला सर्व काही करण्याची परवानगी मानणे हे अनपेक्षित परिणामांना आमंत्रण देण्यासारखे आहे. ऑथोरायझेशनचा निर्णय लॉग-इनच्या क्षणावरून प्रत्येक वैयक्तिक टूल कॉलपर्यंत नेऊन—आणि अल्पकाळ टिकणाऱ्या, स्कोपड टोकन्सचा वापर करून—AI ॲप्लिकेशन्स डेटाचे संरक्षण, नियमांचे पालन आणि महागड्या चुका टाळत असतानाच ऑटोनॉमस एजंट्सची सोय कायम ठेवू शकतात. प्रत्येक वेळी एखादी कृती करण्याचा प्रयत्न केला जातो तेव्हा योग्य प्रश्न विचारणाऱ्या सिस्टमसाठी कोडच्या अतिरिक्त ओळी ही एक छोटी किंमत आहे.