एक समय के लिए चुप रहने के बाद, 'लॉबस्टर' OpenClaw ने 30 अगस्त को 2.0 संस्करण जारी किया।
आधिकारिक रूप से, यह OpenClaw के इतिहास में सबसे बड़ा अपडेट है, जिसमें 16,000 से अधिक Pull Request शामिल हैं और यह लगभग पूरे प्रोडक्ट स्टैक—इंस्टॉलेशन, मैसेजिंग, मेमोरी, Skills, मॉडल, Automations, ब्राउज़र, नेटिव ऐप्स, Plugins और सुरक्षा मैकेनिज़म—को छूता है।
लेकिन इन जटिल फीचर्स की सूची की तुलना में, अधिक महत्वपूर्ण बात यह है कि OpenClaw 2.0 के पीछे एक ऐसी तर्कसंगत विकास रेखा धीरे-धीरे स्पष्ट हो रही है: Agent अब लगातार वास्तव में "काम करने" में सक्षम हो रहे हैं।
इसी बीच, यह उद्योग को एक अपरिहार्य विश्वास के संकट की ओर ले जा रहा है: जब Agent अधिक और अधिक स्वयं 'कैसे करें' का निर्णय लेने लगता है, तो हम कैसे सुनिश्चित करें कि उसकी प्रत्येक महत्वपूर्ण क्रिया, उपयोगकर्ता द्वारा वास्तविक रूप से अधिकृत सीमा को पार न करे?
एक, एजेंट की स्वायत्तता का द्वंद्व: पूर्ण अधिकार देना, या क्रमिक स्वीकृति?
पिछले वर्ष, एआई एजेंट में सबसे स्पष्ट परिवर्तन यह नहीं है कि नींव के मॉडल बुद्धिमान हो गए हैं।
जैसे-जैसे MCP, Skills, Plugins, ब्राउज़र कंट्रोल और कोड निष्पादन जैसे बुनियादी ढांचे परिपक्व हो रहे हैं, एजेंट्स को बाहरी दुनिया को प्रभावित करने के लिए अधिक वास्तविक 'हाथ-पैर' प्राप्त हो रहे हैं, जैसे कि जानकारी बदलना, बटन दबाना, या computer use के माध्यम से सीधे ब्राउज़र को नियंत्रित करना (विस्तार से पढ़ें: Agentic AI का मोड़ आ गया? जब AI 'खुद कार्रवाई' करना सीखता है, तो Web3 की सुरक्षा सीमा कैसे पुनर्गठित होती है?)।
लेकिन समस्या ठीक यहीं से उत्पन्न होती है, वर्तमान इंटरैक्शन पैटर्न के तहत, अक्सर दो चरमों में फंस जाता है।
एक विकल्प है पूर्ण अधिकार देना, जिसमें आप सीधे अपना प्राइवेट की या एक लंबे समय तक वैध, पर्याप्त अधिकार वाला सेशन की एजेंट को सौंप देते हैं, ताकि वह स्वयं निर्णय ले और कार्रवाई करे।
इस मॉडल का स्वचालित अनुभव निश्चित रूप से सर्वोत्तम है, लेकिन जोखिम भी बहुत केंद्रित है; यदि आपको प्रॉम्प्ट इंजेक्शन, दुर्भावनापूर्ण वेबसाइट या प्रदूषण का सामना करना पड़ता है, या मॉडल स्वयं गलत बुझता है, तो त्रुटि पूरी कार्यश्रृंखला में फैल सकती है और अंततः वास्तविक कार्रवाई में बदल सकती है (विस्तार से पढ़ें: Sign केवल हस्ताक्षर नहीं: जब AI Agent आपके लिए हस्ताक्षर करता है, तो कौन नियंत्रण रखता है?)।
अंततः सामान्य इंटरनेट परिदृश्य में, यह केवल एक गलत ईमेल भेजना या एक फाइल गलती से हटाना हो सकता है, लेकिन चेन पर, एक गलत लेनदेन अक्सर अपरिवर्तनीय होता है।
दूसरा विकल्प पूरी तरह से अधिकार न देना है, जहां प्रत्येक ऑपरेशन और प्रत्येक उप-कॉल के लिए साइनेचर विंडो पॉप अप होती है और पुष्टि की मांग की जाती है, जिससे सुरक्षा बढ़ जाती है, लेकिन स्वचालन का अर्थ भी काफी कम हो जाता है।
अंततः, एक एजेंट एक उपयोगकर्ता को एक जटिल DeFi रणनीति पूरी करने में मदद करता है, जिसमें कई चरण शामिल होते हैं, और यदि प्रत्येक चरण के लिए उपयोगकर्ता को अपना फोन उठाकर एक-एक करके «अनुमोदन» करना पड़ता है, तो उपयोगकर्ता वास्तव में केवल «खुद बटन दबाने» से बदलकर एजेंट के लिए लगातार मुहर लगाने वाला «मानव मुहर लगाने वाला यंत्र» बन जाता है।
दूसरे शब्दों में, मध्यवर्ती स्वतंत्रता, एजेंट की दक्षता बढ़ाने का स्रोत है, साथ ही नए जोखिमों का भी स्रोत है।
इस दृष्टिकोण से, समस्या का मुख्य बिंदु यह नहीं है कि "एजेंट को अधिकार देना चाहिए या नहीं", बल्कि अधिकारों की सूक्ष्मता और प्रमाणीकरण तंत्र गतिशील लचीलापन रखते हैं या नहीं, क्योंकि पारंपरिक अधिकार प्रबंधन द्विआधारी होता है (या तो अनुमति दें या अस्वीकार करें), जबकि एजेंट के सामने के कार्य स्पष्ट रूप से अधिक जटिल होते हैं।
एक ही लेनदेन, 10 डॉलर और 10 लाख डॉलर के बीच अंतर है; लंबे समय तक उपयोग किए जा रहे प्रोटोकॉल के साथ बातचीत करना और अचानक एक अज्ञात स्मार्ट कॉन्ट्रैक्ट को अधिकृत करना अलग है; एक उपयोगकर्ता द्वारा स्पष्ट रूप से मांगी गई Swap पूरी करना और एजेंट द्वारा स्वयं निर्णय लेकर संपत्ति को दूसरी श्रृंखला पर स्थानांतरित करना, एक ही जोखिम स्तर के नहीं हैं।
इसलिए, जितना अधिक एजेंट स्वयं कार्य कर सकता है, उतना ही अधिक अधिकार एक साधारण स्विच नहीं हो सकता।
वास्तविक आवश्यकता एक सुरक्षा तंत्र की है जो इसे सीमा के भीतर स्वतंत्र रूप से चलने दे और सीमा पार करने पर स्वचालित रूप से रोक दे।
द्वितीय, एक «सत्यापित» रक्षा कैसे बनाएं जो स्वायत्त एजेंट के लिए हो?
वास्तव में, OpenClaw ने इस समस्या को नजरअंदाज नहीं किया है।
यह वर्तमान में बहुस्तरीय अधिकार प्रणाली प्रदान करता है, जैसे कि प्लगइन विशिष्ट कार्रवाई के निष्पादन से पहले रोक सकते हैं और उपयोगकर्ता की पुष्टि मांग सकते हैं, होस्ट कमांड के मामले में, अलग Exec Approvals और Allowlist आदि भी होते हैं।
एजेंट को सभी उपकरणों और अधिकारों को एक साथ देने की तुलना में यह एक बड़ी प्रगति है। लेकिन जब एजेंट वास्तविक भुगतान, ट्रेडिंग और संपत्ति प्रबंधन के संदर्भ में प्रवेश करता है, तो एक अधिक सूक्ष्म समस्या उत्पन्न होती है: किसी क्षमता का उपयोग करने की अनुमति देना और किसी विशिष्ट कार्रवाई को पूरा करने के लिए एजेंट को अधिकृत करना, वास्तव में एक ही बात नहीं है।
जैसे एजेंट को ब्राउज़र का उपयोग करने की अनुमति देना इस बात का अर्थ नहीं है कि इसे किसी भी वेबसाइट पर किसी भी चीज़ को खरीदने की अनुमति दी जाए; एजेंट को ईमेल बॉक्स तक पहुँचने की अनुमति देना इस बात का अर्थ नहीं है कि यह आपके नाम पर किसी को भी ईमेल भेज सकता है; इसी तरह, एजेंट को वॉलेट का उपयोग करने की अनुमति देना भी इस बात का अर्थ नहीं है कि यह किसी भी पते पर कोई भी राशि भेज सकता है।
इसलिए, एजेंट युग की अधिकार प्रणाली को दो अलग-अलग समस्याओं को अलग करने की आवश्यकता हो सकती है। एक क्षमता अधिकार है, जिसमें यह तय होता है कि एजेंट के पास ब्राउज़र, टर्मिनल, ईमेल या वॉलेट का उपयोग करने की अनुमति है या नहीं। दूसरा, अधिक विशिष्ट कार्रवाई की अनुमति है, जैसे कि इस क्षण में, यह जो कार्रवाई करने की तैयारी कर रहा है, क्या वास्तव में उपयोगकर्ता द्वारा इसके लिए अनुमति दी गई है?
कैसे एजेंट को स्पष्ट सीमाओं के भीतर पूरी तरह से स्वचालित किया जाए, जबकि वास्तविक रूप से सीमा पार करने पर निर्णय लेने का अधिकार फिर से उपयोगकर्ता को सौंपा जाए?
यही कारण है कि imToken Sigil का अन्वेषण कर रहा है। इसका केंद्र एजेंट को एक पारंपरिक 「अनुमोदन डायलॉग बॉक्स」 जोड़ना नहीं है, बल्कि यह है कि उपयोगकर्ता और एजेंट के बीच एक स्पष्ट रूप से सीमित सुरक्षा बाधा बनाने के लिए सत्यापित हस्ताक्षर और सूक्ष्म अधिकार नियंत्रण का प्रयास किया जाए।
एक बहुत महत्वपूर्ण सिद्धांत यह है कि "जो आप देखते हैं, वही आप हस्ताक्षर करते हैं", आप जो देखते हैं, उसी को हस्ताक्षर करें।
सरल शब्दों में, उपयोगकर्ता Agent को एक निश्चित सीमा तक अधिकार प्रदान कर सकते हैं ताकि निम्न जोखिम वाले और निर्धारित रणनीति के अनुकूल कार्य स्वचालित रूप से पूरे हो सकें; जब कोई कार्रवाई धनराशि सीमा, अज्ञात प्रोटोकॉल या अन्य महत्वपूर्ण अधिकार सीमाओं को स्पर्श करती है, तो निष्पादन रोक दिया जाएगा और विशिष्ट अनुरोध को उपयोगकर्ता की पुष्टि के लिए वापस भेज दिया जाएगा।
इससे अधिक महत्वपूर्ण बात यह है कि यह पुष्टि केवल एक अस्पष्ट “एजेंट लेनदेन निष्पादित करने के लिए तैयार है, क्या आप सहमत हैं?” के रूप में नहीं होनी चाहिए; उपयोगकर्ता को वास्तव में इस संचालन में वास्तविक रूप से बदलने वाले महत्वपूर्ण पैरामीटर देखने की आवश्यकता है: कौन सा संपत्ति उपयोग किया जा रहा है, राशि कितनी है, इंटरैक्शन किससे हो रहा है, और अंततः क्या निष्पादित किया जा रहा है।
केवल तभी एक पुष्टि वास्तविक अर्थ रखती है जब उपयोगकर्ता द्वारा देखा गया सामग्री, उपयोगकर्ता द्वारा अनुमति दी गई सामग्री और प्रणाली द्वारा अंततः निष्पादित सामग्री एक से मेल खाती हो।
Sigil इस बिंदु के चारों ओर, पासकी, जैविक पहचान, एकल स्वीकृति, छोटी समय सीमा और अनुरोध पैरामीटर बाइंडिंग जैसे तंत्रों का उपयोग करने का प्रयास करता है, ताकि महत्वपूर्ण अधिकार न केवल उपयोगकर्ता द्वारा समझे जा सकें, बल्कि प्रणाली द्वारा सत्यापित भी किए जा सकें।
इसका अर्थ है कि एक अधिकृति केवल यह नहीं है कि “किसी ने पुष्टि की”, बल्कि यह भी बता सकती है कि किसने अनुमति दी, क्या अनुमति दी गई, और अंततः जो कार्रवाई हुई, क्या वही थी जो तब देखी गई थी।
इस दृष्टिकोण से, सिगिल वास्तव में इस बात को हल करना चाहता है कि "एजेंट को कम काम कैसे करना चाहिए।"
Exactly the opposite.
यह यह सुनिश्चित करने की कोशिश करता है कि एजेंट उपयोगकर्ता के अंतिम नियंत्रण को न लेते हुए, अधिक कार्य कर सके (विस्तार से पढ़ें: अंधेरे में 'Yes' पर क्लिक करने से लेकर स्पष्टता के साथ हस्ताक्षर करने तक: Sigil AI एजेंट के लिए कैसे सुरक्षा बाध्यता जोड़ता है?)।
तीन, संपत्ति प्रबंधन से एजेंट प्रबंधन तक
अगर दृष्टिकोण को थोड़ा और पीछे खींचा जाए, तो यह पता चलता है कि यह वास्तव में वॉलेट की ओर से एक भूमिका में परिवर्तन है।
ईथरियम के जन्म के बाद से, imToken वॉलेट ने दो महत्वपूर्ण पीढ़ियों को अनुभव किया है: 1.0 पीढ़ी, जहां एकल निजी कुंजी का प्रबंधन किया जाता था, और 2.0 पीढ़ी, जहां खाता अमूर्तीकरण (AA) के माध्यम से अंतरक्रिया का अनुभव बेहतर बनाया गया है।
OpenClaw 2.0 जैसे स्वायत्त एजेंट्स के व्यापक उपयोग के साथ, वॉलेट अब तीसरी पीढ़ी के विकास की ओर बढ़ रहे हैं और उपयोगकर्ताओं को अपने स्वायत्त रूप से निर्णय लेने वाले, निरंतर कार्यरत एजेंट्स के प्रबंधन में अधिक सहायता प्रदान करने की आवश्यकता है।
यही कारण है कि पिछले समय में वॉलेट उद्योग द्वारा इकट्ठा की गई स्व्हीट की प्रबंधन, डिजिटल हस्ताक्षर, पहचान प्रमाणीकरण और अधिकारों के पृथक्करण की क्षमताएँ, एजेंट युग में नए अर्थ प्राप्त कर सकती हैं।
क्योंकि ये तकनीकें सतही रूप से “एक ऑन-चेन लेनदेन को सुरक्षित रूप से कैसे हस्ताक्षरित किया जाए” को हल करने की कोशिश कर रही हैं, लेकिन इनके पीछे एक अधिक सामान्य समस्या सुलझाई जा रही है: कैसे साबित किया जाए कि कोई कार्रवाई, किसी संस्था के वास्तविक अधिकार से हुई है।
आज, इस कार्रवाई में 1 ETH ट्रांसफर करना सम्मिलित हो सकता है। भविष्य में, यह एक ईमेल भेजना, एक फ़ाइल बदलना, किसी डिजिटल पहचान का उपयोग करना, किसी सेवा को खरीदना, या एजेंट को अगले सप्ताह एक निश्चित स्वचालित रणनीति को लगातार निष्पादित करने की अनुमति देना भी हो सकता है।
ये व्यवहार आवश्यक रूप से सभी ब्लॉकचेन पर नहीं होते, लेकिन नींव का संबंध बहुत समान है, जिसमें एजेंट उपयोगकर्ता के नाम पर उपयोगकर्ता की एक क्षमता को कॉल कर रहा है।
इसलिए, सिगिल का अर्थ केवल क्रिप्टो तक ही सीमित नहीं हो सकता।
जब OpenClaw, Hermes और अधिक एजेंट्स व्यक्तिगत उपकरणों या क्लाउड वातावरणों पर चल रहे हों और ईमेल, तत्काल संचार, कैलेंडर, फाइलें, ब्राउज़र, टर्मिनल और भुगतान उपकरणों से जुड़ने लगें, तो “इस कार्रवाई को वास्तव में उपयोगकर्ता द्वारा अनुमति दी गई है, इसका प्रमाण कैसे दिया जाए?” एक बढ़ती हुई सामान्य समस्या बन जाएगी।
इसलिए सिगिल भविष्य में लेन-देन के अलावा डेटा एक्सेस, पहचान उपयोग, फाइल संशोधन, सामग्री प्रकाशन, सेवा खरीद और स्वचालित कार्यों तक विस्तारित हो सकता है।
सामान्य तौर पर, imToken और OpenClaw के संयुक्त अन्वेषण के रूप में, Sigil imToken द्वारा पिछले दशक में स्व-नियंत्रित, वॉलेट और डिजिटल हस्ताक्षर के क्षेत्र में जमा की गई अनुभव को स्वतंत्र Agent के वास्तविक कार्यान्वयन वातावरण में प्रवेश के नए चरण में लाने का प्रयास करता है।
यह एजेंट का स्थान नहीं लेता है, और वॉलेट का विकल्प नहीं है।
यह दोनों के बीच खड़ा है।