Open Web Application Security Project ने आपला 2026 GenAI LLM Top 10 जाहीर केला आहे, आणि “Excessive Agency” सहाव्या स्थानावरून तिसऱ्या स्थानावर पोहोचले आहे. ही वाढ महत्त्वाची आहे कारण ती दर्शवते की सर्वात धोकादायक त्रुटी आता केवळ चुकीच्या आउटपुटपुरत्या मर्यादित नाहीत, तर अशा एजंट्समध्ये आहेत जे तुमच्या इन्फ्रास्ट्रक्चरवर (infrastructure) कृती करू शकतात.

हा बदल का महत्त्वाचा आहे

पहिल्यांदाच, Top 10 ची रचना अशा डेटावर आधारित आहे ज्याचा एक चतुर्थांश भाग प्रत्यक्ष घटनांतून (actual incidents) येतो—ज्यामध्ये ६,००० हून अधिक नोंदवलेले डेटा ब्रीच (breaches), एक्सप्लॉइट्स (exploits) आणि गैरवर्तणुकीचा समावेश आहे. पूर्वीचे अंक जवळजवळ पूर्णपणे तज्ज्ञांच्या मतांवर अवलंबून होते. वास्तविक जगातील संकेत असे दर्शवतात की जेव्हा एखादे लँग्वेज मॉडेल API कॉल करू शकते, कोड कार्यान्वित करू शकते किंवा पैसे हलवू शकते, तेव्हा त्याचे परिणाम केवळ लाजिरवाण्या मजकूर लीक (text leaks) करण्यापासून बदलून प्रत्यक्ष ऑपरेशनल नुकसानीपर्यंत पोहोचतात. 'Prompt injection' अजूनही या यादीत अव्वल आहे, त्यानंतर 'sensitive information disclosure' येते, परंतु पहिल्या तीनमध्ये “Excessive Agency” चा उदय सुरक्षा पथकांना (security teams) सांगतो की हल्ल्यांची पुढची लाट केवळ भाषिक नसून टूल्सवर आधारित (tool-enabled) असेल.

“excessive agency” म्हणजे काय

Excessive agency म्हणजे अशी कोणतीही परिस्थिती जिथे LLM ला अशी क्षमता दिली जाते जी त्याच्याकडे नसावी, किंवा आजूबाजूच्या गार्डरेल्स (guardrails) नियंत्रित करू शकतील त्यापेक्षा जास्त क्षमता दिली जाते. याची काही सामान्य उदाहरणे खालीलप्रमाणे आहेत:

  • परवानगी तपासणीशिवाय अंतर्गत मायक्रो-सर्व्हिस एंडपॉइंट्स (micro-service endpoints) वापरणारा असिस्टंट.
  • प्रोडक्शन सर्व्हर्सवर स्क्रिप्ट लिहिणारा आणि चालवणारा कोड-जनरेशन बॉट.
  • विशिष्ट प्रॉम्प्टनंतर (crafted prompt) ट्रान्सफर सुरू करणारा फायनान्शिअल-ऑटोमेशन एजंट.

जर मॉडेलकडे अशी शक्ती असताना एखादा घातक प्रॉम्प्ट (malicious prompt) मॉडेलला फसवणूक करत असेल, तर डेटा ब्रीच त्वरित आणि अनेकदा खर्चिक ठरतो. मॉडेलची प्रॉम्प्टचे पालन करण्याची क्षमता आणि आजूबाजूच्या नियंत्रणांची (controls) कडकपणा यातील अंतर जितके जास्त, तितका धोका वाढत जातो.

नवीन Top 10 कसा तयार करण्यात आला

2026 चे हे संस्करण तज्ज्ञांचे निर्णय आणि ठोस डेटा यांचे मिश्रण आहे. रँकिंगचा साधारण २५% भाग वर उल्लेख केलेल्या घटनांच्या संग्रहातून (incident pool) येतो, ज्यामुळे प्रत्यक्षात घडलेल्या पॅटर्नना महत्त्व दिले जाते. या कार्यपद्धतीतील बदलामुळेच “Excessive Agency” मध्ये मोठी वाढ झाली आहे: डेटा असे दर्शवतो की अशा घटनांमध्ये स्पष्ट वाढ झाली आहे जिथे मॉडेलने केवळ मजकूर न देता प्रत्यक्ष कृती केली आहे.

इतर महत्त्वाचे बदल

  • Hidden Context Exposure (ज्याचे नाव “System Prompt Leakage” वरून बदलले आहे) संवेदनशील डेटाच्या व्यापक संचाला कव्हर करण्यासाठी वर आले आहे, जे दर्शवते की हल्लेखोर आता मॉडेलच्या कॉन्टेक्स्टमधून (context) गुपिते शोधण्यासाठी अधिक प्रयत्न करत आहेत.
  • Improper Output Handling दहाव्या स्थानावर खाली आले आहे, ज्याचा अर्थ असा की संस्था आता मॉडेलच्या कच्च्या प्रतिसादांचे (raw responses) सॅनिटायझेशन (sanitising) करण्यात सुधारणा करत आहेत. उद्योगाचे लक्ष आता “मॉडेलने काहीतरी वाईट म्हटले” यावरून “मॉडेलने काहीतरी वाईट केले” याकडे वळत आहे.

हे बदल या गोष्टीवर शिक्कामोर्तब करतात की धोक्याची व्याप्ती (threat surface) आता स्थिर आउटपुटकडून (static outputs) डायनॅमिक वर्तनाकडे (dynamic behaviors) विस्तारत आहे.

धोका कमी करणे (Mitigating the risk)

सुरक्षा पथके तीन व्यावहारिक पावले उचलून excessive agency कमी करण्यास सुरुवात करू शकतात:

  1. तुमच्या टूल्सची व्याप्ती मर्यादित करा (Scope your tools) – प्रत्येक एजंटला त्याच्या विशिष्ट कामासाठी आवश्यक असलेल्या कृतीच नेमून द्या. सोयीसाठी एकाच LLM ला “पूर्ण टूलबॉक्स” देणे टाळा; सूक्ष्म परवानग्या (granular permissions) एखाद्या फसव्या प्रॉम्प्टमुळे होणाऱ्या नुकसानीची व्याप्ती (blast radius) मर्यादित करतात.
  2. गार्डरेल्स कोडमध्ये तयार करा, प्रॉम्प्टमध्ये नाही – प्रत्यक्ष टूल कार्यान्वित करणाऱ्या लेयरमध्ये स्पष्ट परवानगी तपासणी (permission checks), कन्फर्मेशन गेट्स आणि ऑडिट लॉग्सवर अवलंबून राहा. मॉडेलच्या प्रत्येक आउटपुटला एक 'अविश्वासार्ह विनंती' (untrusted request) समजा, ज्याला कोणत्याही बाह्य API कॉलप्रमाणेच सुरक्षा पुनरावलोकनातून जावे लागेल.
  3. सर्व टूल कॉम्बिनेशन्सची नोंद ठेवा (Inventory all tool combinations) – कोणते एजंट्स कोणत्या API, स्क्रिप्ट्स किंवा फायनान्शिअल एंडपॉइंट्सना ॲक्सेस करू शकतात याची नोंद ठेवा. या यादीपेक्षाही महत्त्वाचे म्हणजे त्या क्षमता एकमेकांशी कशा प्रकारे संवाद साधतात हे समजून घेणे; दोन निरुपद्रवी वाटणारी टूल्स जेव्हा एकत्र जोडली जातात, तेव्हा ती धोकादायक ठरू शकतात.

अद्ययावत Top 10 प्रत्येक धोक्याचा संबंध प्रमुख एंटरप्राइझ सुरक्षा मानकांशी (enterprise security standards) जोडते, ज्यामुळे सुरक्षा रक्षक (defenders) कंप्लायन्स आणि ऑडिट टीम्ससोबत उपाययोजनांवर चर्चा करण्यासाठी एक समान भाषा वापरू शकतात.

प्रतिवाद: धोक्याचा अतिरेक केला जात आहे का?

काही तज्ज्ञांचे असे मत आहे की “excessive agency” हे जनरेटिव्ह AI मधील अंगभूत दोष नसून केवळ खराब डिझाइन निवडींचे प्रतिबिंब आहे. ते असे नमूद करतात की जर कोणत्याही प्रोग्राम करण्यायोग्य सिस्टमला अमर्यादित प्रवेश दिला गेला तर तिचा गैरवापर होऊ शकतो आणि मजबूत DevOps पद्धती आधीच यातील अनेक परिस्थिती हाताळतात. परवानग्यांबाबत शिस्त पाळणे आवश्यक असले तरी, डेटावर आधारित धोक्यातील वाढ असे सूचित करते की अनेक संस्था अजूनही AI-संवर्धित वर्कफ्लोमध्ये (AI-augmented workflows) या पद्धती लागू करण्यात मागे आहेत.

पुढे काय पाहावे

  • Top 10 मधील पुढील सुधारणा – जशा अधिक घटनांची नोंद केली जाईल, तशी OWASP यादी विकसित होत राहील. वार्षिक प्रसिद्धीवर लक्ष ठेवल्यास धोक्याची दिशा नेमकी कुठे जात आहे, याचा अंदाज घेण्यास टीम्सना मदत होईल.

संदेश स्पष्ट आहे: भाषा मॉडेलला कृती करण्याची शक्ती देणे स्वस्त आहे; त्या शक्तीपासून संरक्षण करणे महाग आहे. ज्या संस्था मॉडेलच्या आउटपुटला निकाल न मानता केवळ एक विनंती समजतात, त्या टूल-सक्षम हल्ल्यांच्या उदयोन्मुख लाटेच्या पुढे राहतील.