OpenClaw 2.0 اور Sigil: خودمختار AI ایجینٹس کے لیے قابل تصدیق اجازت کی تعمیر

iconOdaily
بانٹیں
AI summary iconخلاصہ
AI اور کرپٹو خبریں 30 اگست کو OpenClaw 2.0 کے جاری ہونے کے ساتھ سامنے آئیں، جس میں 16,000 سے زائد پل ریکسٹس شامل ہیں۔ جب خودمختار AI ایجنٹس حقیقی دنیا کے اثاثوں (RWA) کے خبروں کے استعمال میں توسیع کر رہے ہیں، تو imToken Sigil کا آزمائش کر رہا ہے تاکہ قابل تصدیق اجازتیں لاگو کی جا سکیں۔ یہ نظام ایجنٹس کو صارفین کے طرف سے تعریف کردہ حدود کے اندر کام کرنے دینے کے ساتھ ساتھ شفافیت اور کنٹرول برقرار رکھنے کا مقصد رکھتا ہے۔

8 اگست کو، "کریب" OpenClaw نے ورژن 2.0 جاری کیا۔

سرکاری طور پر، یہ OpenClaw کے تاریخ میں سب سے بڑا اپڈیٹ ہے، جس میں 16,000 سے زیادہ Pull Requests شامل ہیں، جو انسٹالیشن، میسجز، میموری، Skills، ماڈلز، Automations، براؤزر، نیٹو ایپس، Plugins اور سیکورٹی میکنزمز سمیت پورے پروڈکٹ اسٹیک کو چھوتا ہے۔

لیکن ان متنوع فنکشنز کی فہرست کے مقابلے میں، زیادہ اہم بات یہ ہے کہ OpenClaw 2.0 کے پیچھے ایک واضح ہوتی جا رہی ترقی کی راہ ہے: ایجینٹ اب تدریجاً حقیقی طور پر "کام کرنے" لگے ہیں۔

اسی دوران، یہ صنعت کو ایک ایسے اعتماد کے مسائل کی طرف لے جا رہا ہے جس سے بچنا ناممکن ہے: جب ایجینٹز یہ فیصلہ کرنے لگیں کہ "کیسے" کرنا ہے، تو ہم کیسے یقینی بنائیں کہ ان کی ہر اہم کارروائی صارف کے حقیقی طور پر منظور کردہ حدود کو عبور نہ کرے؟

ایک، ایجینٹ کی خود مختاری کا دوگنا مسئلہ: مکمل اختیارات دینا، یا ہر مرحلے پر تصدیق؟

گزشتہ سال، AI ایجنٹ میں سب سے واضح تبدیلی صرف بنیادی ماڈل کا ذہین ہونا نہیں تھا۔

جیسے جیسے MCP، Skills، Plugins، براؤزر کنٹرول اور کوڈ ایکزیکشن جیسی بنیادی ڈھانچہ کی ترقی ہوتی جا رہی ہے، ایجینٹس کو باہری دنیا پر اثر ڈالنے کے لیے مزید زیادہ "ہاتھ اور پاؤں" حاصل ہو رہے ہیں، جیسے معلومات تبدیل کرنا، بٹن دبانا، یا computer use کے ذریعے براؤزر کو براہ راست کنٹرول کرنا (مزید مطالعہ کے لیے Agentic AI کا موڑ آ گیا؟ جب AI "خود کام کرنے" کا طریقہ سیکھ لے، تو Web3 کی حفاظتی سرحدیں کیسے دوبارہ تعمیر کی جائیں؟

لیکن مسئلہ بالکل یہیں پر ہے کہ موجودہ تعامل کے نمونوں کے تحت، اکثر دو انتہائی صورتوں میں پھنس جاتے ہیں۔

ایک طریقہ یہ ہے کہ پوری اختیارات دے دیں اور صرف نجی کلید یا ایک لمبے عرصے تک درست، کافی طور پر بڑی اجازت والی سیشن کلید کو ایجنٹ کو دے دیں تاکہ وہ خود فیصلہ کرے اور عمل کرے۔

اس موڈ کا خودکار تجربہ بالکل بہتر ہے، لیکن خطرہ بھی بہت مرکزی ہے؛ اگر کوئی پرومپٹ انجیکشن، بری ویب سائٹ یا ماحولیاتی آلودگی ہو جائے، یا ماڈل خود سمجھنے میں غلطی کرے، تو غلطی پورے انجام دینے والے سلسلے میں منتقل ہو سکتی ہے اور آخرکار حقیقی عمل بن جاتی ہے (مزید پڑھیں: Sign صرف سائن نہیں: جب AI Agent آپ کے لیے سائن کرے، تو کون کنٹرول رکھتا ہے؟)

بالآخر، عام انٹرنیٹ کے مناظر میں، یہ صرف ایک غلط ای میل بھیجنا یا ایک فائل غلط حذف کرنا ہو سکتی ہے، لیکن زنجیر پر، ایک غلط ٹرانزیکشن اکثر غیر قابل واپسی ہوتی ہے۔

دوسرا طریقہ مکمل طور پر اختیارات نہ دینا ہے، جس میں ہر آپریشن اور ہر سب کال کے لیے سائنیچر کی تصدیق کے لیے ونڈو ظاہر ہوتی ہے، جس سے سیکیورٹی بڑھ جاتی ہے لیکن آٹومیشن کا مقصد بھی کافی حد تک کم ہو جاتا ہے۔

کیونکہ ایک ایجینٹ صارف کو ایک پیچیدہ DeFi حکمت عملی مکمل کرنے میں مدد کرتا ہے، جس میں کئی مراحل شامل ہوتے ہیں، اگر ہر مرحلے کے لیے صارف کو اپنا فون اٹھا کر الگ الگ "Approve" کرنا پڑے، تو صارف اصل میں صرف "خود بٹن دبانے" سے "ایجینٹ کے لیے لگاتار دستخط کرنے والی انسانی تصدیق مشین" بن جاتا ہے۔

دوسرے الفاظ میں، درمیانی درجہ آزادی، ایجینٹ کی کارکردگی کا ذریعہ ہے اور ساتھ ہی نئے خطرات کا بھی ذریعہ ہے۔

اس نقطہ نظر سے، مسئلہ صرف ایجینٹ کو اختیارات دینے کے بارے میں نہیں ہے، بلکہ اجازت کی درجہ بندی اور تصدیق کے نظام کی ڈائنامک لچک کے بارے میں ہے، کیونکہ روایتی اجازت کی مدیریت دوسری ہوتی ہے (یا تو اجازت دی جاتی ہے یا مسترد کر دی جاتی ہے)، جبکہ ایجینٹ کے سامنے کام واضح طور پر زیادہ پیچیدہ ہوتے ہیں۔

ایک ہی لین دین کے لیے، 10 امریکی ڈالر اور 100,000 امریکی ڈالر کا فرق ہے؛ لمبے عرصے تک استعمال ہونے والے پروٹوکول کے ساتھ تعامل کرنا اور اچانک ایک ناشناخت شدہ معاہدے کو اجازت دینا مختلف ہے؛ صارف کی واضح درخواست پر ایک Swap مکمل کرنا اور ایجنٹ کا خود سے فیصلہ کرنا کہ اثاثوں کو دوسری چین پر منتقل کیا جائے، دونوں کا خطرہ کا درجہ ایک جیسا نہیں ہے۔

اس لیے، جتنا زیادہ ایجینٹ خودمختارانہ کام کرے، اس کے اختیارات صرف ایک سادہ سوئچ نہیں ہونے چاہئیں۔

جو ضرورت ہے، وہ ایک محفوظ نظام ہے جو اسے سرحد کے اندر آزادانہ حرکت کرنے دے اور جب وہ سرحد عبور کرے تو خودکار طور پر رک جائے۔

دوسری بات: ایک "قابل تصدیق" دفاع کیسے بنائیں جو خود مختار ایجنٹ کے لیے ہو؟

اصل میں، اوپنکلاؤ نے اس مسئلے کو نظرانداز نہیں کیا ہے۔

اس کے پاس اب بہت سے سطحی دستورات کا نظام ہے، جیسے پلگ ان کسی خاص عمل کو انجام دینے سے پہلے روک سکتے ہیں اور صارف کی تصدیق مانگ سکتے ہیں، جبکہ ہوسٹ کمانڈس کے معاملے میں الگ Exec Approvals اور Allowlist جیسے فیچرز بھی شامل ہیں۔

ایک ایجنٹ کو تمام اوزار اور اختیارات ایک ساتھ دینے کے بجائے، یہ ایک بڑا قدم آگے ہے۔ لیکن جب ایجنٹ حقیقی ادائیگی، ٹریڈنگ اور اثاثہ پ्रबंधن کے مناظر میں داخل ہوتا ہے، تو ایک زیادہ تفصیلی مسئلہ پیدا ہوتا ہے: کسی صلاحیت کا استعمال کرنے کی اجازت دینا اور کسی خاص کارروائی کو مکمل کرنے کا اختیار دینا، اصل میں ایک ہی بات نہیں ہے۔

جیسے ایجنٹ کو براؤزر استعمال کرنے کی اجازت دینا اس کی اجازت نہیں دیتا کہ وہ کسی بھی ویب سائٹ پر کچھ بھی خریدے؛ ایجنٹ کو ای میل باکس تک رسائی دینا اس کی اجازت نہیں دیتا کہ وہ آپ کے نام پر کسی بھی شخص کو ای میل بھیجے؛ اسی طرح، ایجنٹ کو والٹ کو فون کرنے کی اجازت دینا بھی اس بات کی اجازت نہیں دے سکتا کہ وہ کسی بھی پتے پر کوئی بھی رقم بھیج دے۔

اس لیے، ایجینٹ کے دور کے اجازت نظام کو دو مختلف مسائل کو الگ کرنا ہوگا۔ ایک صلاحیت کی اجازت ہے، یعنی ایجینٹ کے پاس براؤزر، ٹرمینل، ای میل یا والٹ استعمال کرنے کی صلاحیت ہے یا نہیں؟ دوسرا، زیادہ خاص عمل کی اجازت ہے، جیسے کہ ابھی، یہ جو کام وہ کرنے جا رہا ہے، کیا واقعی صارف نے اسے اجازت دی ہے؟

اس طرح کیسے ممکن ہو کہ ایجنٹ واضح حدود کے اندر مکمل طور پر خودکار ہو، اور جب واقعی حد عبور کرے تو فیصلہ کرنے کا اختیار دوبارہ صارف کو واپس کر دیا جائے؟

یہی وجہ ہے کہ imToken Sigil کی تلاش کر رہا ہے۔ اس کا مرکزی مقصد Agent کو روایتی طور پر ایک "تائید کا پاپ اپ" شامل کرنا نہیں، بلکہ قابل تصدیق دستخط اور باریک تر اجازتوں کے ذریعے صارف اور Agent کے درمیان واضح طور پر محدود ایک سیکورٹی گارڈ رکھنا ہے۔

ایک اہم اصول یہ ہے کہ "جو دیکھتے ہو، اسی پر دستخط کریں"۔

بس اس کا مطلب یہ ہے کہ صارفین Agent کو پہلے سے کچھ دائرہ کار کی اجازت دے سکتے ہیں تاکہ کم خطرے والے، مقررہ حکمت عملی کے مطابق اقدامات خودکار طور پر مکمل ہو جائیں؛ جب کوئی آپریشن رقم کی حد، ناپر familiar پروٹوکول یا دیگر اہم اجازت کی سرحدوں کو چھوتا ہے، تو اسے روک دیا جائے اور درخواست کو صارف کی تصدیق کے لیے واپس بھیج دیا جائے۔

زیادہ اہم بات یہ ہے کہ یہ تصدیق صرف ایک اندھیری سی عبارت "ایجنٹ ٹریڈ کرنے کے لیے تیار ہے، کیا آپ متفق ہیں؟" نہیں ہونی چاہیے؛ صارفین کو واقعی اس آپریشن میں تبدیل ہونے والے اہم پیرامیٹرز دکھائے جانے چاہئیں: کون سا اثاثہ استعمال ہو رہا ہے، رقم کتنی ہے، تعامل کون سا ہے، اور آخرکار کیا عمل کیا جا رہا ہے۔

صرف اسی صورت میں ایک تصدیق حقیقی طور پر معنی رکھتی ہے جب صارف دیکھتا ہے، صارف کی اجازت دی جاتی ہے، اور نظام آخر میں انجام دیتا ہے۔

سگل اس نقطہ کے ارد گرد، پاسکی، بائیومیٹرک، ایک مرتبہ کے دستخط، مختصر مدت کی درخواست اور درخواست پیرامیٹرز کے بائنڈنگ جیسے مکینزمز کا استعمال بھی کرتا ہے تاکہ اہم اختیارات صرف صارفین کے لیے سمجھنے کے بجائے، سسٹم کی تصدیق بھی ہو سکے۔

اس کا مطلب یہ ہے کہ ایک اجازت صرف اس بات تک محدود نہیں کہ "کسی نے تصدیق کی" بلکہ اس سے آگے بڑھ کر یہ بھی بتایا جا سکتا ہے کہ کس نے منظور کیا، کیا منظور کیا، اور آخرکار جو عمل ہوا، وہی تھا جسے اصل میں دیکھا گیا تھا۔

اس منظر سے، سِجِل کا حقیقی مقصد "ایجینٹ کو کم کام کرنے کے لیے کیسے کہیں" نہیں ہے۔

بالکل اس کے برعکس۔

اس کا مقصد یہ ہے کہ ایجینٹ صارف کے آخری کنٹرول کو نہ لے کر، اسے زیادہ کام کرنے کی اجازت دی جائے (مزید پڑھیں: سیفٹی گارڈ کے طور پر Sigil: AI ایجینٹ کے لیے "Yes" کے بے سبب دباؤ سے لے کر جان بوجھ کر دستخط تک

تین: اثاثوں کے انتظام سے ایجنٹ کے انتظام تک

اگر نظر کو ایک قدم مزید پیچھے کیا جائے، تو یہ پتہ چلتا ہے کہ یہ حقیقت میں والٹ کی طرف سے سامنا کی جا رہی ایک کردار کی تبدیلی ہے۔

ایتھریم کے ظہور کے بعد، imToken والٹ نے دو اہم دوروں کو براہ راست محسوس کیا اور دیکھا: 1.0 دور، جہاں صرف ایک منفرد انفرادی کلید کا انتظام کیا جاتا تھا، اور 2.0 دور، جہاں اکاؤنٹ ایبسترکشن (AA) کے ذریعے انٹرایکشن کا تجربہ بہتر بنایا گیا۔

آزاد ایجینٹس جیسے OpenClaw 2.0 کے عام ہونے کے ساتھ، والٹ ضروری طور پر تیسری نسل کی ترقی کی طرف بڑھ رہا ہے، جسے صارفین کو ایک ایک کر کے خود فیصلہ کرنے والے، مستقل کام کرنے والے ایجینٹس کے انتظام میں مدد کرنے کی ضرورت ہے۔

یہی وجہ ہے کہ پچھلے زمانے میں والٹ صنعت کی طرف سے جمع کی گئی نجی کلید کی منتقلی، ڈیجیٹل دستخط، شناخت کی تصدیق اور اجازتوں کی علیحدگی کی صلاحیتیں، ایجنٹ کے دور میں نئے معنی رکھنے لگیں گی۔

کیونکہ یہ ٹیکنالوجیاں سطحی طور پر "ایک آن لائن ٹرانزیکشن کو محفوظ طریقے سے دستخط کرنے کا طریقہ" کو حل کر رہی ہیں، لیکن ان کے پیچھے اصل میں ایک زیادہ عام مسئلہ ہے: کسی ایکٹ کو کسی خاص طرف کی حقیقی اجازت سے منسلک کرنے کا طریقہ کیسے ثابت کیا جائے؟

آج، یہ کارروائی 1 ETH نکالنے کی ہو سکتی ہے۔ مستقبل میں، یہ ایک ای میل بھیجنا، ایک فائل تبدیل کرنا، کسی ڈیجیٹل شناخت کا استعمال کرنا، کسی سروس کو خریدنا، یا ایجنٹ کو اگلے ہفتے تک کسی خاص آٹومیٹڈ حکمت عملی کو جاری رکھنے کی اجازت دینا بھی ہو سکتی ہے۔

یہ سرگرمیاں ضروری طور پر بلاکچین پر نہیں ہوتیں، لیکن بنیادی تعلق بہت مشابہ ہے، یعنی ایجنٹ صارح کے نام پر صارح کی ایک صلاحیت کو فراہم کر رہا ہے۔

اس لیے، سجیل کا مطلب ضروری طور پر صرف کریپٹو تک محدود نہیں ہے۔

جب OpenClaw، Hermes اور دیگر ایجینٹس جو ذاتی ڈیوائسز یا کلاؤڈ ماحول میں چل رہے ہیں، میل، فوری میسج، کیلنڈر، فائلز، براؤزر، ٹرمینل اور ادائیگی کے ٹولز سے جُڑنے لگیں گے، تو "یہ ثابت کرنا کہ اس کارروائی کو صارف نے حقیقی طور پر اجازت دی ہے" ایک عام مسئلہ بن جائے گا۔

اس لیے سجیل مستقبل میں آن چین ٹریڈنگ سے لے کر ڈیٹا تک رسائی، شناخت کا استعمال، فائل میں تبدیلی، مواد کا اشاعت، سروس خریداری اور آٹومیٹڈ کاموں تک پھیل سکتا ہے۔

مکمل طور پر، ایم ٹوکن اور اوپن کلو کے مشترکہ تجربے کے طور پر، سیجیل ایم ٹوکن کے گزشتہ دہے کے تجربے کو خود مالکانہ، والٹ اور ڈیجیٹل دستخط کے شعبوں میں خود مختار ایجنٹ کے حقیقی انجام کے ماحول میں داخل ہونے کے نئے مرحلے میں لانے کی کوشش کرتا ہے۔

یہ ایجنٹ کی جگہ نہیں لیتا اور ویلٹ کو بھی نہیں بدلتا۔

یہ دونوں کے درمیان کھڑا ہے۔

اعلان دستبرداری: اس صفحہ پر معلومات تیسرے فریق سے حاصل کی گئی ہوں گی اور یہ ضروری نہیں کہ KuCoin کے خیالات یا خیالات کی عکاسی کرے۔ یہ مواد کسی بھی قسم کی نمائندگی یا وارنٹی کے بغیر صرف عام معلوماتی مقاصد کے لیے فراہم کیا گیا ہے، اور نہ ہی اسے مالی یا سرمایہ کاری کے مشورے کے طور پر سمجھا جائے گا۔ KuCoin کسی غلطی یا کوتاہی کے لیے، یا اس معلومات کے استعمال کے نتیجے میں کسی بھی نتائج کے لیے ذمہ دار نہیں ہوگا۔ ڈیجیٹل اثاثوں میں سرمایہ کاری خطرناک ہو سکتی ہے۔ براہ کرم اپنے مالی حالات کی بنیاد پر کسی پروڈکٹ کے خطرات اور اپنے خطرے کی برداشت کا بغور جائزہ لیں۔ مزید معلومات کے لیے، براہ کرم ہماری استعمال کی شرائط اور خطرے کا انکشاف دیکھیں۔