29 अगस्त 2026
आपके AI एजेंट का अप्रूवल प्रॉम्प्ट असल में परमिशन की सीमा है
हर कदम पर पुष्टि माँगें, तो यूज़र पढ़ना छोड़ देते हैं। सिर्फ़ लक्ष्य पर पुष्टि लें, तो सहमति खतरनाक हद तक खुली हो जाती है। सही सीमा ठीक उस ऐक्शन पर है, जो असल दुनिया में कुछ बदल देता है।
एक यूज़र AI एजेंट से कहता है, “Q3 सैंडबॉक्स डिलीट कर दो।” एजेंट सेटिंग्स खोलता है, वर्कस्पेस ढूँढता है, और डिलीट वाले कंट्रोल तक पहुँच जाता है। अगर वह हर क्लिक के बाद पुष्टि माँगे, तो वह किसी काम का नहीं। अगर वह शुरुआती वाक्य को असीमित सहमति मान ले, तो वह लापरवाह है। अगर वह आखिर में बस “आगे बढ़ें?” पूछे, तो यूज़र अब भी नहीं जान पाता कि होगा क्या। प्रोडक्ट का मुश्किल फ़ैसला यह नहीं कि इंसान को लूप में रखें या नहीं। मुश्किल यह तय करना है कि वह लूप कहाँ से शुरू हो, इंसान असल में किस चीज़ को अप्रूव कर रहा है, और वह अप्रूवल कब मान्य नहीं रहता।
इसीलिए अप्रूवल प्रॉम्प्ट को परमिशन मॉडल का हिस्सा मानना चाहिए, न कि एजेंट बन जाने के बाद ऊपर से जोड़ी गई कोई शिष्ट-सी रुकावट।
दो गलत छोर
पहला गलत डिज़ाइन स्थिति के हर बदलाव पर पुष्टि माँगता है। बिलिंग पेज खोलें? पुष्टि करें। सालाना टैब चुनें? पुष्टि करें। कंपनी का नाम भरें? पुष्टि करें। प्रोडक्ट सावधान दिखता है, पर बार-बार आने वाले प्रॉम्प्ट यूज़र को बिना सोचे अप्रूव करने की आदत डाल देते हैं। सिस्टम ने सहमति का नाटक खड़ा कर दिया है: क्लिक ढेरों, ध्यान ज़रा-सा।
उलटा डिज़ाइन शुरुआत में बस एक बार पूछता है। “मैं वर्कस्पेस की सफ़ाई कर दूँगा। आगे बढ़ूँ?” यह तब तक कुशल लगता है, जब तक काम फैलकर रिकॉर्ड आर्काइव करने, मेंबर्स हटाने और सारांश वाला ईमेल भेजने तक नहीं पहुँच जाता। यूज़र ने एक लक्ष्य को अप्रूव किया था, हर नतीजे को नहीं। आम बोलचाल में दिया गया एक खुला निर्देश अस्थायी एडमिनिस्ट्रेटर का रोल बन गया है।
दोनों नाकामियाँ बातचीत को ऑथराइज़ेशन लेयर की तरह इस्तेमाल करने से पैदा होती हैं। इरादा तय करने में बातचीत अच्छी है। पर जो क्षमता दी जा रही है, उसे सटीक रूप से परिभाषित करने में वह कमज़ोर है।
एजेंटिक AI के फ़ेलियर मोड्स पर Microsoft का 2026 का वर्गीकरण इसी बात का सिक्योरिटी वाला पहलू साफ़ शब्दों में रखता है। वह सुझाता है: डिटरमिनिस्टिक, यानी तय नियमों से चलने वाला इंसानी रिव्यू; गंभीर असर वाले सब-ऐक्शन के लिए अलग अप्रूवल; असल टूल कॉल से बने विवरण; और अप्रूवल के ऐसे स्तर, जो इस पर टिके हों कि ऐक्शन पलटा जा सकता है या नहीं और उसके असर का दायरा (ब्लास्ट रेडियस) कितना बड़ा है। सीमा लागू करने का काम ऐप्लिकेशन का है, मॉडल का नहीं।
अगर एजेंट के स्पष्टीकरण में एक वाक्य बदलने से यह बदल सकता है कि रिव्यू दिखेगा या नहीं, तो रिव्यू की डोर शब्दों के हाथ में है। परमिशन की असली सीमा उस ऐक्शन से तय होती है, जिसे ऐप्लिकेशन एक्ज़िक्यूट करने वाला है।
बटन को नहीं, उसके असर को आँकें
टीमें अक्सर खतरनाक शब्दों की एक लिस्ट से शुरुआत करती हैं: डिलीट करें, भेजें, भुगतान करें, रद्द करें। यह काम की चीज़ है, पर बटन का टेक्स्ट कोई पॉलिसी नहीं है। “रद्द करें” से कोई डायलॉग बंद हो सकता है या कोई सब्सक्रिप्शन खत्म हो सकता है। “हटाएँ” से कोई फ़िल्टर साफ़ हो सकता है या किसी व्यक्ति का ऐक्सेस छिन सकता है। “जारी रखें” किसी खरीदारी का आखिरी कंट्रोल हो सकता है।
वर्गीकरण के लिए ऐक्शन, उसका टारगेट और आसपास की स्थिति, तीनों चाहिए। एक व्यावहारिक पॉलिसी पाँच सवालों से शुरू हो सकती है:
1. क्या यह ऐक्शन बाहर कोई असर पैदा करता है, जैसे कोई मैसेज, इनविटेशन, पोस्ट या पब्लिश हुआ बदलाव?
2. क्या इससे पैसा इधर-उधर होता है या कोई वित्तीय प्रतिबद्धता बनती है?
3. क्या इससे यह बदलता है कि डेटा तक किसकी पहुँच है या किसके पास कौन-सी परमिशन हैं?
4. क्या यह डेटा डिलीट करता है, कोई अकाउंट बंद करता है, या सब्सक्रिप्शन बदलता है?
5. अगर यह गलत निकले, तो क्या वही यूज़र इसे जल्दी और पूरी तरह पलट सकता है?
इससे “हर राइट ऑपरेशन पर पुष्टि ज़रूरी है” वाले नियम से कहीं ज़्यादा काम की सीमा बनती है।
प्रस्तावित ऐक्शन · डिफ़ॉल्ट व्यवहार · क्यों
पेज पढ़ना, सर्च करना, फ़िल्टर लगाना या टैब खोलना · आगे बढ़ें · बाहर कोई स्थायी असर नहीं
किसी गैर-संवेदनशील ड्राफ़्ट फ़ील्ड को भरना · आगे बढ़ें और ऐक्शन दिखता रहे · सबमिट करने से पहले पलटा जा सकता है
साफ़ अनडू वाली कोई लोकल प्रेफ़रेंस बदलना · आम तौर पर आगे बढ़ें · असर का दायरा छोटा, सुधारना आसान
भेजना, पब्लिश करना, इनवाइट करना, शेयर करना या ऐक्सेस बदलना · ठीक उसी ऐक्शन का रिव्यू · किसी दूसरे व्यक्ति पर असर, या कोई सीमा पार
खरीदना, अपग्रेड करना, रद्द करना, बंद करना या डिलीट करना · एक्ज़िक्यूशन से ठीक पहले रिव्यू · पैसों से जुड़ा, या पलटना मुश्किल
क्रेडेंशियल डालना या कोई रेगुलेटेड फ़ैसला लेना · यूज़र का सीधा कंट्रोल ज़रूरी, वरना मना करें · सिर्फ़ अप्रूवल मिल जाने से हर ऐक्शन सौंपने लायक नहीं हो जाता
यह एजेंट बनाने पर OpenAI की गाइड के टूल-रिस्क मॉडल के करीब है, जो टूल्स को राइट ऐक्सेस, पलटने की गुंजाइश, अकाउंट परमिशन और वित्तीय असर के आधार पर रेट करने की सलाह देती है। असली कदम इन गुणों को कोड और पॉलिसी में ढालना है, न कि मॉडल को एक और निर्देश थमा देना, जिसका वह अपने हिसाब से रचनात्मक मतलब निकाल ले।
वहीं पूछें, जहाँ असर होना है
अप्रूवल जितनी देर से हो सके उतनी देर से आना चाहिए, लेकिन बाहरी असर से पहले।
मान लीजिए अनुरोध है: “मेरा Growth सब्सक्रिप्शन रद्द कर दो।” एजेंट बिना टोके सेटिंग्स खोल सकता है, बिलिंग तक जा सकता है, और मौजूदा प्लान देख सकता है। इनमें से कोई भी कदम यूज़र को किसी चीज़ से नहीं बाँधता। काम का रिव्यू तब आता है, जब एजेंट को असली सब्सक्रिप्शन रद्द करें कंट्रोल मिल गया हो और उसे पता हो कि इसका असर किस सब्सक्रिप्शन पर पड़ेगा।
इस टाइमिंग से प्रॉम्प्ट के पास ठोस तथ्य होते हैं। वह शुरुआती अनुरोध को घुमा-फिराकर दोहराने के बजाय ऐक्शन और टारगेट का नाम ले सकता है। इससे यूज़र से ऐसा ऑपरेशन अप्रूव करवाने की नौबत भी नहीं आती, जिसे एजेंट शायद ढूँढ ही न पाए।
यहाँ एक साफ़ फ़र्क है:
– स्पष्टीकरण तब माँगा जाता है, जब इरादा किया गया ऐक्शन या टारगेट अस्पष्ट हो। अगर दो मेंबर्स का नाम Alex है, तो “Alex को हटा दो” पर सवाल पूछना ज़रूरी है।
– अप्रूवल तब माँगा जाता है, जब इरादा किया गया ऐक्शन साफ़ हो और ऐप्लिकेशन गंभीर असर वाला कोई कदम एक्ज़िक्यूट करने को तैयार हो। यह स्वीकार या अस्वीकार का एक सीमित फ़ैसला होना चाहिए।
दोनों को मिला देने से बेहद झुंझलाने वाली बातचीत बनती है। एजेंट पूछता है, “क्या आप निश्चित हैं?”, जबकि उसे अब तक पता ही नहीं कि यूज़र का मतलब किस रिकॉर्ड से था। या वह पहले अप्रूवल ले लेता है, बाद में एक अलग कन्फ़र्मेशन कंट्रोल से टकराता है, और पहले वाले जवाब को उस नए ऐक्शन की परमिशन मान लेता है।
ज़्यादा सुरक्षित क्रम है: इरादा, टारगेट तय करना, रिव्यू, एक्ज़िक्यूशन। साइट की ओर से बाद में आने वाला कन्फ़र्मेशन एक नया ऐक्शन है, जो एक्ज़िक्यूट होगा, और उस पर अलग फ़ैसला बनता है।
प्रॉम्प्ट में वही ऐक्शन दिखे, जो एक्ज़िक्यूट होगा
एजेंट कह सकता है, “मैं बस वर्कस्पेस को थोड़ा व्यवस्थित कर रहा हूँ,” जबकि उसकी अगली टूल कॉल किसी मेंबर को हटा रही हो। यह बेमेल बदनीयती से हो, प्रॉम्प्ट इंजेक्शन का नतीजा हो, या बस गलती हो, इससे फ़र्क नहीं पड़ता। अप्रूवल UI इस भरोसे पर नहीं चल सकता कि एजेंट का अपना बयान उस अधिकार का सही वर्णन करेगा, जो वह माँग रहा है।
इसके बजाय रिव्यू का टेक्स्ट एक्ज़िक्यूशन ऑब्जेक्ट से बनाएँ। वह कंट्रोल, टारगेट, चुनी गई वैल्यू, डेस्टिनेशन और संबंधित दायरा दिखाएँ, जिसे ऐप्लिकेशन तय कर चुका है। “Acme के लिए ‘अकाउंट डिलीट करें’ पर क्लिक करें” काम का है। “सफ़ाई जारी रखें” नहीं।
Microsoft का वर्गीकरण इसके कमज़ोर रूप को डिस्क्रिप्शन लॉन्ड्रिंग कहता है: एजेंट एक मासूम-सा सारांश पेश करता है, जो नीचे छिपे कहीं ज़्यादा गंभीर ऐक्शन को ढक देता है। सुझाया गया बचाव सीधा है। अप्रूवल का विवरण असली टूल कॉल या पेज कंट्रोल से बनाएँ, मॉडल के खुले टेक्स्ट से नहीं।
यह तब भी मायने रखता है, जब कोई सिस्टम पर हमला नहीं कर रहा। मॉडल बातों को समेटकर छोटा करते हैं। वे बात को सीमित करने वाले शब्द छोड़ देते हैं। वे “यह” कहकर गलत चीज़ की ओर इशारा कर देते हैं। एक्ज़िक्यूशन लेयर के पास सटीक आर्ग्युमेंट पहले से मौजूद हैं, इसलिए रिव्यू में उन्हीं का इस्तेमाल होना चाहिए।
– यह इसलिए दिखता है क्योंकि डिटरमिनिस्टिक पॉलिसी ने एक्ज़िक्यूट होने वाले ऐक्शन को वर्गीकृत किया, इसलिए नहीं कि मॉडल ने खुद पूछना ठीक समझा।
– यह ऐक्शन, टारगेट, डेस्टिनेशन और दायरे को ऐसी भाषा में बताता है, जिसे यूज़र जाँच सके।
– इसमें मना करने का असली रास्ता होता है, और यह गंभीर असर वाले कदम को किसी बैच के अंदर नहीं छिपाता।
– यह एक कोशिश को अधिकृत करता है, बाकी पूरी बातचीत को नहीं।
सहमति एक बार की हो, और स्थिति से बँधी हो
सबसे ज़्यादा नज़रअंदाज़ होने वाला सवाल यूज़र के ‘स्वीकार करें’ पर क्लिक करने के बाद आता है: उस क्लिक ने ठीक-ठीक किस चीज़ को अधिकृत किया?
मान लीजिए रिव्यू में “Q3 सैंडबॉक्स डिलीट करें” दिखा। कार्ड खुला रहते हुए पेज दोबारा रेंडर हुआ, और नीचे वाला एलिमेंट अब प्रोडक्शन वर्कस्पेस की ओर इशारा कर रहा है। या रूट बदल गया। या किसी फ़ॉर्म का प्राप्तकर्ता बदल गया। अगर अप्रूवल को approved नाम के एक बूलियन से दर्शाया जाता है, तो एजेंट ऐसी स्थिति पर ऐक्शन चला सकता है, जो यूज़र ने कभी देखी ही नहीं।
इसके बजाय अप्रूवल को पेंडिंग ऐक्शन के एक फ़िंगरप्रिंट से बाँधना चाहिए। इसमें एलिमेंट की पहचान, ऐक्शन का प्रकार, टारगेट का लेबल, डेस्टिनेशन, फ़ॉर्म की स्थिति, कंटेनर, ओरिजिन और रूट शामिल हो सकते हैं। एक्ज़िक्यूशन से ठीक पहले ऐप्लिकेशन मौजूदा ऐक्शन का मिलान रिव्यू किए गए ऐक्शन से करता है।
अगर सुरक्षा से जुड़ा कुछ भी बदला है, तो एक्ज़िक्यूशन रुक जाता है। पुराना अप्रूवल वैसे भी खर्च हो चुका होता है, इसलिए पेज के वापस पहले जैसा होने पर भी उसे दोबारा इस्तेमाल नहीं किया जा सकता। अगर एक्ज़िक्यूशन सफल होता है, तब भी वह खर्च हो जाता है। एक रिव्यू, एक कोशिश, एक बिना बदला टारगेट।
यह ज़रूरत से ज़्यादा औपचारिकता नहीं है। यह वही सिद्धांत है जो साइन की गई रिक्वेस्ट और एक बार इस्तेमाल होने वाले टोकन में लागू होता है: अधिकार संकरा हो, किसने दिया यह पता हो, और वह थोड़े समय के लिए हो। ऐप्लिकेशन लेयर पर Microsoft की गाइडेंस कहती है कि इंसानी रिव्यू को एजेंट्स को गंभीर असर वाले ऐक्शन के लिए खुद को अधिकृत करने से रोकना चाहिए, ट्रिगर कोड के ज़रिए लागू हों, और एक्ज़िक्यूशन के दौरान दखल देना संभव हो। स्थिति से बँधी सहमति ही वह तरीका है, जिससे यह सिद्धांत बदलते इंटरफ़ेस में भी टिका रहता है।
अप्रूवल सुरक्षा की एक परत है, पूरा सुरक्षा सिस्टम नहीं
अच्छी तरह डिज़ाइन किया गया प्रॉम्प्ट भी पूरे सुरक्षा मॉडल का बोझ नहीं उठा सकता। टारगेट उलझा हुआ हो, तो यूज़र किसी गलत ऐक्शन को भी अप्रूव कर सकता है। प्रॉम्प्ट इंजेक्शन रिव्यू तक पहुँचाने वाले रास्ते को बिगाड़ सकता है। कोई कॉम्प्रोमाइज़्ड पेज भ्रामक संदर्भ दिखा सकता है। कुछ काम, सहमति मिले या न मिले, एजेंट के अधिकार से बाहर ही रहने चाहिए।
OpenAI का ChatGPT agent सिस्टम कार्ड पुष्टि को मॉडल ट्रेनिंग, ऑटोमेटेड मॉनिटर, सीमित क्षमताओं और संवेदनशील संदर्भों में सक्रिय निगरानी के साथ रखता है। परतों वाली यही बनावट सोचने का सही मॉडल है। अप्रूवल गलती से होने वाले नुकसान को सीमित करता है। यह साबित नहीं करता कि उससे पहले की सोच सही थी।
बाकी सिस्टम को अब भी इनकी ज़रूरत है:
– टूल्स और डेटा तक सिर्फ़ ज़रूरत भर का (लीस्ट-प्रिविलेज) ऐक्सेस;
– वर्जित टारगेट और संवेदनशील इनपुट पर डिटरमिनिस्टिक रोक;
– कई स्टेप वाले काम के दौरान रोकने का कंट्रोल;
– हर ऐक्शन के बाद इंटरफ़ेस को नए सिरे से पढ़ना;
– सफलता का दावा करने से पहले माँगे गए नतीजे का आखिरी ऑडिट;
– ऐसे लॉग, जो यूज़र के अनुरोध, रिव्यू, एक्ज़िक्यूशन और नतीजे को आपस में जोड़ें।
आखिरी ऑडिट खास तौर पर अहम है। स्वीकृति का मतलब है, “ठीक यही ऐक्शन आज़माया जा सकता है।” इसका मतलब यह नहीं कि क्लिक काम कर गया, सही स्थिति बदली, या काम पूरा हो गया।
Barkan के लिए हमने क्या चुना
Barkan के ऐक्शन मोड में, रोज़मर्रा का नेविगेशन और इंटरफ़ेस पर पलटा जा सकने वाला काम पुष्टियों की परेड के बिना आगे बढ़ सकता है। विजेट उन ऐक्शन से पहले वहीं रुक जाता है, जिन्हें डेटा डिलीट करने, अकाउंट या सब्सक्रिप्शन बदलने, पैसों के लेन-देन, बाहरी संपर्क या ऐक्सेस बदलने की श्रेणी में रखा गया है। रिव्यू एक्ज़िक्यूशन के रास्ते में ही ट्रिगर होता है, उसे मॉडल की मर्ज़ी पर नहीं छोड़ा जाता।
स्वीकार किया गया रिव्यू मौजूदा ऐक्शन टारगेट और पेज की स्थिति से बँधा होता है, और एक्ज़िक्यूशन की पहली कोशिश में ही खर्च हो जाता है। अगर टारगेट बदल जाए, तो अप्रूवल दोबारा इस्तेमाल नहीं हो सकता। अगर वेबसाइट अपना आखिरी कन्फ़र्मेशन खोलती है, तो उस कंट्रोल का रिव्यू एक अलग ऐक्शन की तरह होता है। ऐक्शन चलने के बाद Barkan नए सिरे से रेंडर हुआ व्यू पढ़ता है, और काम पूरा होने की रिपोर्ट देने से पहले आखिरी ऑडिट के लिए एक अलग टर्न लेता है।
ये फ़ैसले रुकावट ठीक वहीं जोड़ते हैं, जहाँ हम उसे चाहते हैं। लक्ष्य न ज़्यादा से ज़्यादा ऑटोनॉमी है, न ज़्यादा से ज़्यादा सावधानी। लक्ष्य है परमिशन की ऐसी सीमा के भीतर ज़्यादा से ज़्यादा उपयोगी काम, जिसे यूज़र समझ सके।
सिर्फ़ स्वीकृति नहीं, पूरी सीमा को मापें
अकेला अप्रूवल रेट सफलता का कमज़ोर पैमाना है। 99 प्रतिशत स्वीकृति का मतलब यह हो सकता है कि एजेंट हमेशा सही है। इसका मतलब यह भी हो सकता है कि प्रॉम्प्ट इतने बार-बार और इतने धुंधले आते हैं कि यूज़र अब उन्हें पढ़ते ही नहीं।
सिस्टम को एक कंट्रोल की तरह ट्रैक करें:
– रिव्यू कवरेज: गंभीर असर वाले वे ऐक्शन, जिन्हें एक्ज़िक्यूशन से पहले रोका गया।
– बेवजह रुकावट की दर: हानिरहित ऐक्शन, जिन पर रिव्यू ट्रिगर हुआ।
– श्रेणी के हिसाब से फ़ैसलों की दर: डिलीट, पैसे, संपर्क, ऐक्सेस और अकाउंट बदलावों पर स्वीकार और अस्वीकार।
– पुरानी पड़ चुकी सहमति पर इनकार: वे कोशिशें जो इसलिए रोकी गईं, क्योंकि रिव्यू के दौरान टारगेट या स्थिति बदल गई।
– सत्यापित रूप से पूरा: अप्रूव किए गए वे ऐक्शन, जिनकी तय अंतिम स्थिति की बाद में पुष्टि हुई।
– रोकने और सुधारने का व्यवहार: वे काम, जिन्हें यूज़र्स ने गंभीर असर वाले कदम से पहले रोका या दूसरी दिशा में मोड़ा।
फिर दोनों छोरों के उदाहरण जाँचें: गंभीर असर वाले ऐक्शन, जो रिव्यू से बच निकले, और मामूली ऐक्शन, जिन्होंने यूज़र्स को परेशान किया। पॉलिसी इन दोनों समूहों को छोटा करके बेहतर होती है, हर काम को और ज़्यादा अप्रूवल की ओर धकेलकर नहीं।
अप्रूवल प्रॉम्प्ट वह पल है, जब कोई AI प्रोडक्ट एक अनुमान को अधिकार में बदल देता है। इसे परमिशन देने जितनी सख्ती से बरतें। एजेंट को पलटे जा सकने वाले काम में तेज़ी से आगे बढ़ने दें, ठीक उस गंभीर असर वाले ऐक्शन पर रोकें, दिखाएँ कि असल में क्या एक्ज़िक्यूट होगा, और हर “हाँ” को एक कोशिश के बाद खत्म हो जाने दें।
Barkan आपके प्रोडक्ट में कई स्टेप वाला काम पूरा करता है, और बड़े असर वाले ऐक्शन पर, उसके एक्ज़िक्यूट होने से ठीक पहले, रुक जाता है।
“ज़्यादातर यूज़र्स एक और जवाब नहीं चाहते। वे चाहते हैं कि कोई रास्ता दिखा दे, या काम ही कर दे। पूरा प्रोडक्ट बस इतना ही है।”
Gabriel Lancelot
को-फ़ाउंडर, Barkan
