میں نے اپنے خاندان کے مالی معاملات تک ایک AI agent کی رسائی دے دی اور اسے ایک MCP server کے ذریعے مجھ سے بات کرنے کی اجازت دی۔ چند ہی منٹوں میں وہ یہ جواب دے سکتا تھا کہ "پچھلے مہینے ہم نے گروسری پر کتنا خرچ کیا؟" اور بچت (savings) میں رقم منتقل بھی کر سکتا تھا۔ اسی انٹرفیس نے اسے ایک ہی کمانڈ کے ذریعے پورے ایک سال کی ٹرانزیکشن ہسٹری مٹانے کی اجازت بھی دے دی۔ ایجنٹ کے ذریعے کال کیے جانے والے ٹولز میں موجود ایک ہارڈ کوڈڈ (hard-coded) سیفٹی چیک نے اس ڈیلیشن کو روکا—نہ کہ کسی ذہین سسٹم پرامپٹ (system prompt) نے۔
یہ مسئلہ کیوں اہم ہے
وہ AI agents جو بیرونی سروسز کو کال کرتے ہیں، اب ریسرچ ڈیمو سے نکل کر روزمرہ کے اسسٹنٹ بن رہے ہیں۔ ایک بجٹنگ بوٹ جو بینک کے SMS الرٹس پڑھتا ہے، رقم کا تجزیہ کرتا ہے، اور انہیں پرسنل فنانس ایپ میں ریکارڈ کرتا ہے، آج موجود ہے۔ یہی پیٹرن کسٹمر سپورٹ چیٹ بوٹس، کوڈ جنریشن ہیلپرز، اور سپلائی چین پلانرز کو بھی طاقت دے رہا ہے۔ ایک بار جب کوئی ایجنٹ تبدیل کرنے والے (mutating) یا تباہ کن (destructive) کمانڈز جاری کرنے کے قابل ہو جاتا ہے—جیسے فائل ڈیلیٹ کرنا، ڈیٹا بیس ٹیبل کو ختم کرنا، یا فنڈز کو دوبارہ مختص کرنا—تو خطرات بہت بڑھ جاتے ہیں۔ ایک غلط سمجھی گئی درخواست، ماڈل ڈرِفٹ (model-drift) کا واقعہ، یا کوئی بدنیتی پر مبنی پرامپٹ ناقابل تلافی نقصان کا باعث بن سکتا ہے۔ 2025 میں، ایک AI کوڈنگ اسسٹنٹ نے، اسے تباہ کن آپریشنز نہ چلانے کے بارے میں بتائے جانے کے باوجود، ایک پروڈکشن ڈیٹا بیس ڈیلیٹ کر دیا، جس سے کمپنی کو ہفتوں کا ڈاؤن ٹائم برداشت کرنا پڑا۔
خطرہ حقیقی ہے۔ صارفین حساس ڈیٹا اور اہم ورک فلو کے لیے AI agents پر بھروسہ کرتے ہیں۔ جب وہ بھروسہ ٹوٹتا ہے، تو اس کا استعمال رک جاتا ہے، ریگولیٹرز مداخلت کر سکتے ہیں، اور مالیاتی اثرات شدید ہو سکتے ہیں۔ بنیادی سوال یہ ہے کہ: ہم اس بات کی ضمانت کیسے دیں کہ کوئی ایجنٹ کسی حقیقی انسانی فیصلے کے بغیر کبھی بھی کوئی ناقابل تلافی عمل انجام نہ دے؟
پرامپٹ انجینئرنگ ایک جھوٹی تحفظ کی چادر ہے
ڈویلپرز اکثر سسٹم پرامپٹ کو مزید سخت کرتے ہیں، جیسے کہ "بغیر پوچھے کبھی ڈیٹا ڈیلیٹ نہ کریں" یا "بیلنس تبدیل کرنے سے پہلے ہمیشہ تصدیق کریں۔" پرامپٹ انجینئرنگ ماڈل کے رویے کو تجاویز کے ایک سیٹ کے طور پر دیکھتی ہے جن پر ماڈل عمل بھی کر سکتا ہے اور نہیں بھی۔ عملی طور پر، ماڈلز الفاظ کی پیروی کرتے ہیں جب تک کہ ٹیمپریچر سیٹنگز، ٹوکن کی حدود، یا سیاق و سباق (context) میں معمولی تبدیلی انہیں اصول چھوڑنے پر مجبور نہ کر دے۔ 2025 کے ڈیٹا بیس ڈیلیشن کے واقعے نے ثابت کیا کہ جب ماڈل کی اندرونی منطق (reasoning) الگ سمت میں چلی جائے تو ایک واضح ہدایت کو بھی نظر انداز کیا جا سکتا ہے۔
نثر کی سطح کی پابندیاں (Prose-level constraints) دیکھ بھال کے مسائل بھی پیدا کرتی ہیں۔ ہر نیا ٹول، ورژن اپ ڈیٹ، یا لینگویج ماڈل کی تبدیلی پرامپٹ ٹیکسٹ کے نئے آڈٹ کا تقاضا کرتی ہے۔ انسانی جائزہ لینے والوں کو قدرتی زبان کے طویل بلاکس پڑھنے، ان کی تشریح کرنے اور اس امید پر رہنا پڑتا ہے کہ ماڈل ان کا احترام کرے گا۔ اس کا نتیجہ ایک کمزور حفاظتی جال کے طور پر نکلتا ہے جو حقیقی دنیا کے استعمال میں ٹوٹ جاتا ہے۔
حفاظت کو پرامپٹ سے ٹول تک منتقل کرنا
ایک زیادہ قابل اعتماد طریقہ یہ ہے کہ حفاظت وہاں نافذ کی جائے جہاں AI عمل کرتا ہے—یعنی خود ٹول میں۔ اپنے تجربے میں، میں نے Lester نامی ایک بجٹنگ ایجنٹ بنایا۔ ورک فلو کچھ اس طرح تھا:
- ایک فون ایپ آنے والے بینک SMS پیغامات کو محفوظ کرتی ہے۔
- ایک ہلکا پھلکا، مقامی طور پر ہوسٹ شدہ لینگویج ماڈل ٹرانزیکشن کی رقم اور مرچنٹ کا نام نکالتا ہے۔
- Lester ایک API کال کے ذریعے اس ریکارڈ کو بجٹنگ ایپ میں لکھتا ہے۔
Lester کے نقطہ نظر سے یہ تینوں مراحل صرف پڑھنے کے لیے (read-only) تھے: وہ صرف ڈیٹا جمع (add) کر سکتا تھا، موجودہ اندراجات کو کبھی ڈیلیٹ یا تبدیل نہیں کر سکتا تھا۔ سسٹم بالکل درست کام کر رہا تھا جب تک کہ میں نے ایک MCP (Multi-Channel Prompt) سرور کا استعمال کرتے ہوئے وائس انٹرفیس شامل نہیں کیا، جس نے مجھے یہ پوچھنے کی اجازت دی کہ "پچھلے مہینے ہم نے گروسری پر کتنا خرچ کیا؟" یا "بچت میں رقم منتقل کریں۔" MCP سرور ایک بروکر کے طور پر کام کرتا ہے، جو ایجنٹ کو ٹولز کا ایک سیٹ (add-transaction, query-spending, transfer-funds, delete-history) فراہم کرتا ہے۔
اصل کنفیگریشن میں ہر ٹول کے ساتھ یکساں سلوک کیا جاتا تھا۔ وہی اینڈ پوائنٹ جس نے گروسری کی لائن شامل کی تھی، اس نے ڈیلیٹ کمانڈ کو بھی قبول کر لیا جو پورے ایک سال کے ریکارڈ کو مٹا سکتی تھی۔ اگر ماڈل ڈرِفٹ ہو جاتا، درخواست غلط سن لیتا، یا صارف نے "delete last" کے بجائے "delete all" ٹائپ کر دیا، تو Lester بغیر کسی ہچکچاہٹ کے اس پر عمل کر دیتا۔
اس سے بچنے کے لیے، میں نے تین سادہ اصولوں کے ساتھ ٹول لیئر کو دوبارہ ترتیب دیا:
- Read-only ٹولز فوری طور پر عمل کرتے ہیں۔ کوئی بھی چیز جو صرف معلومات حاصل کرتی ہے—جیسے بیلنس چیک کرنا، خرچ کا خلاصہ، یا ٹرانزیکشن کی查询—اس کے لیے انسانی تصدیق کی ضرورت نہیں ہے۔ ریڈ-اونلی کال کا خطرہ نہ ہونے کے برابر ہے۔
- Mutating ٹولز عمل کرنے سے پہلے ارادے کا اعلان کرتے ہیں۔ وہ آپریشنز جو حالت (state) کو تبدیل کرتے ہیں لیکن واپسی کے قابل (reversible) ہیں—جیسے ٹرانزیکشن کا اضافہ کرنا، کیٹیگری کو اپ ڈیٹ کرنا—ایجنٹ کے ایک مختصر "ارادے" (intent) کے پیغام (مثلاً "Adding grocery transaction") بھیجنے کے بعد آگے بڑھتے ہیں۔ سسٹم اس ارادے کو لاگ کرتا ہے اور آڈٹ کے لیے صارف کے سامنے پیش کر سکتا ہے، لیکن یہ عمل کو روکتا نہیں ہے۔
- Destructive ٹولز واضح ٹوکن کے بغیر چلنے سے انکار کر دیتے ہیں۔ وہ کمانڈز جو ڈیٹا کو ڈیلیٹ، ٹرنیکیٹ (truncate)، یا ناقابل تلافی بناتی ہیں، ٹول کی سطح پر بلاک کر دی جاتی ہیں۔ جب Lester ڈیلیٹ کی درخواست جاری کرتا ہے، تو ٹول ایک انکار کا پی لوڈ (refusal payload) واپس کرتا ہے جس میں وہ درست ڈیٹا شامل ہوتا ہے جسے وہ ڈیلیٹ کرتا، اور ایک انسانی تیار کردہ ٹوکن کی درخواست ہوتی ہے۔ ایجنٹ کو پھر ایک دوسرے مرحلے کی تصدیق کا پی لوڈ فراہم کرنا ہوتا ہے جس میں
confirm: trueاور ٹوکن شامل ہو۔ اس