آپ کا اے آئی پر مبنی اسسٹنٹ تقریباً 99 فیصد وقت اپنی ہدایات پر عمل کرتا ہے، لیکن وہ رہ جانے والا 1 فیصد وہ جگہ ہے جہاں حملہ آور وار کرتے ہیں۔ ایک تیار کردہ پرامپٹ کے ذریعے، ایک بدنیتی پر مبنی صارف ماڈل کو ایسے فنکشنز چلانے پر مجبور کر سکتا ہے جنہیں اسے نہیں چلانا چاہیے، جس سے ڈیٹا چوری ہو سکتا ہے یا خصوصی اقدامات کیے جا سکتے ہیں۔ اس کا حل مزید شائستہ الفاظ نہیں ہے—بلکہ اس خامی کو اتھارائزیشن (اجازت) کے مسئلے کے طور پر دیکھنا اور خطرناک ٹولز کو ماڈل کی پہنچ سے دور کرنا ہے۔
پرامپٹ انجیکشن صرف الفاظ کا مسئلہ کیوں نہیں ہے
ڈویلپرز اکثر ایجنٹس کو بڑے حروف (all-caps) میں وارننگ، نمبروں والی ہدایات، یا "ایڈمن فنکشنز کو کال نہ کریں" جیسے جملوں کے ذریعے محفوظ بنانے کی کوشش کرتے ہیں۔ یہ دفاع اس مفروضے پر مبنی ہے کہ ماڈل اس جملے کی تعمیل کرے گا جو کہتا ہے "X نہ کریں۔" عملی طور پر، ماڈل کو درخواست کو دوبارہ ترتیب دے کر، کوئی مختلف کردار ادا کر کے، یا صرف اضافی سیاق و سباق (context) شامل کر کے ہدایت کو نظر انداز کرنے پر آمادہ کیا جا سکتا ہے۔ انگریزی کی حدود پر بحث کی جا سکتی ہے؛ حملہ آور کا پرامپٹ لامحدود ہے اور اسے آزمانے میں کوئی خرچ نہیں آتا۔
اصل کمزوری اس ٹول لسٹ میں ہے جو ایجنٹ کو ملتی ہے۔ جب پرامپٹ اسکیما میں ایسا فنکشن شامل ہو جو ایڈمن حقوق دیتا ہو، تو ماڈل کے پاس اس طاقت تک پہنچنے کا نقشہ موجود ہوتا ہے۔ اگرچہ پرامپٹ میں لکھا ہو کہ "گاہکوں کے لیے اسے استعمال نہ کریں،" پھر بھی ماڈل کو اسے کال کرنے پر آمادہ کیا جا سکتا ہے کیونکہ وہ فنکشن اس کے ایگزیکیوشن انوائرمنٹ میں موجود ہے۔ لہذا مسئلہ اتھارائزیشن کا خلا ہے: سسٹم ایک ایسے کالر کو خصوصی صلاحیتیں فراہم کر رہا ہے جس کے پاس ان کا کوئی حق نہیں ہے۔
رسائی کو محدود کر کے ایجنٹس کو محفوظ بنانا
اس خلا کو ختم کرنے کا سادہ ترین طریقہ ماڈل کو ان ٹولز تک رسائی دینا بند کرنا ہے جنہیں استعمال کرنے کا اسے اختیار نہیں ہے۔ ٹول لسٹ کو ایک API key کی طرح سمجھیں: اگر کی (key) موجود نہیں ہے، تو کال نہیں ہو سکتی۔ کوئی بھی چالاک الفاظ اس فنکشن کو نہیں بلا سکتے جو موجودہ سیاق و سباق میں موجود ہی نہ ہو۔
غلط طریقہ
Prompt: “You are an assistant. Do not use the adminDeleteUser function for regular customers.”
ماڈل اب بھی اپنے ٹول باکس میں adminDeleteUser دیکھتا ہے اور اسے استعمال کرنے کے لیے دھوکہ دیا جا سکتا ہے۔
صحیح طریقہ
Prompt schema for a regular customer: { “functions”: [ “searchCatalog”, “placeOrder” ] }
adminDeleteUser کبھی ظاہر نہیں ہوتا، اس لیے ماڈل کے پاس اسے کال کرنے کا کوئی راستہ نہیں ہوتا ہے۔
ڈویلپرز کے لیے تین عملی اصول
- ہر درخواست کے مطابق ٹول لسٹ بنائیں – فنکشن کی فہرست کو تصدیق شدہ کالر کی اجازت (permissions) کی بنیاد پر متحرک (dynamically) طور پر تیار کریں۔ ایک عام صارف کو صرف وہی فنکشن نظر آتے ہیں جن کی انہیں ضرورت ہوتی ہے؛ ایک ایڈمن کو مکمل سیٹ نظر آتا ہے۔
- فیل کلوزڈ (Fail closed) – اگر صارف کی شناخت کی تصدیق نہیں کی جا سکتی، تو عام "تمام ٹولز دستیاب ہیں" کے بجائے ایک خالی فہرست واپس کریں۔ یہ اس بات کو یقینی بناتا ہے کہ کوئی غیر تصدیق شدہ درخواست کبھی غیر متوقع طاقت حاصل نہ کر سکے۔
- شیئرڈ اسٹیٹ (Shared state) سے بچیں – ٹول کی تعریفوں کو کیش (cache) کرتے وقت، کبھی بھی صارف سے متعلقہ ڈیٹا کو کسی شیئرڈ آبجیکٹ پر نہ لکھیں۔ copy-on-write یا فی سیشن کاپیز کا استعمال کریں تاکہ ایک صارف کی اجازت دوسرے کی درخواست میں شامل نہ ہو سکے۔
اگر ایک عام صارف کو پیش کیا جانے والا اسکیما ایڈمن کو دکھائے جانے والے اسکیما جیسا ہی ہے، تو سیکیورٹی کی حد اب بھی پرامپٹ ٹیکسٹ ہے، اور پرامپٹس سیکیورٹی کا کوئی قابل اعتماد ذریعہ نہیں ہیں۔
ہمیں یہاں تک کیسے لایا گیا
پرامپٹ انجیکشن اس وقت سامنے آیا جب ڈویلپرز نے لارج لینگویج ماڈلز (LLMs) کو پروڈکشن ورک فلو میں لگانا شروع کیا جس میں ماڈل کے لیے بیرونی APIs کو کال کرنا، کوڈ چلانا، یا ڈیٹا بیس میں ترمیم کرنا ضروری تھا۔ ماڈل کی "سوچ" (reasoning) ایک پرامپٹ کے ذریعے رہنمائی حاصل کرتی ہے جس میں دستیاب ٹولز کی فہرست بھی شامل ہوتی ہے۔ ابتدائی پروٹو ٹائپس نے یہ فرض کر لیا تھا کہ ماڈل قدرتی زبان کے اصول جیسے کہ "نان ایڈمنز کے ریکارڈ ڈیلیٹ نہ کریں" کی تعمیل کرے گا۔ حملہ آوروں نے جلد ہی یہ ثابت کر دیا کہ چند اضافی جملے ان اصولوں کو نظر انداز کر سکتے ہیں، جس سے ماڈل وہی ڈیلیٹ فنکشن کال کرنے پر مجبور ہو جاتا ہے۔
کمیونٹی کا پہلا ردعمل پرامپٹ کی زبان کو سخت کرنا، "X کبھی نہ کریں" جیسے جملے شامل کرنا، یا regex فلٹرز لگانا تھا جو مشکوک ٹوکنز کو ہٹا دیتے ہیں۔ ان اقدامات نے حادثاتی غلط استعمال کو تو کم کر دیا لیکن اس پر عزم رکھنے والے حملہ آور کو نہیں روک سکے جو محض درخواست کو نئے انداز میں لکھ سکتا تھا۔ بنیادی وجہ—غیر معتبر کالر کو خصوصی فنکشنز فراہم کرنا—وہی رہی۔
کون جیتتا ہے، کون ہارتا ہے
وہ ادارے جو ہر درخواست کے مطابق ٹول اسکوپنگ (tool scoping) اپناتے ہیں انہیں ایک واضح اور قابل عمل حد حاصل ہوتی ہے۔ ان کے ایجنٹس کو اس خوف کے بغیر بڑے پیمانے پر استعمال کیا جا سکتا ہے کہ کوئی ایک غلط پرامپٹ ایڈمن کی صلاحیتوں کو کھول دے گا۔ کمپلائنس ٹیمیں آڈٹ ٹریل کو بھی پسند کرتی ہیں: ماڈل کو بھیجی جانے والی فنکشنز کی فہرست ایک ٹھوس دستاویز ہے جسے لاگ کیا جا سکتا ہے اور اس کا جائزہ لیا جا سکتا ہے۔
وہ ڈویلپرز جو صرف پرامپٹ پر منحصر حفاظتی اقدامات پر بھروسہ کرتے ہیں انہیں مسلسل بدلتے ہوئے خطرات کا سامنا رہتا ہے۔ ان کے ایجنٹس ٹیسٹنگ میں تو فعال نظر آ سکتے ہیں لیکن اصل دنیا میں ان کے ساتھ سمجھوتہ کیا جا سکتا ہے، جس سے ڈیٹا کی چوری، غیر مجاز لین دین، یا کمپلائنس کی خلاف ورزی ہو سکتی ہے۔ ڈیٹا کی چوری کا نقصان ایک متحرک ٹول لسٹ بنانے کی کوشش سے کہیں زیادہ ہے۔
مخالف دلیل: “بہتر پرامپٹس ہی کافی ہیں”
کچھ لوگوں کا یہ استدلال ہے کہ مناسب instruction engineering—جیسے کہ layered prompts، system messages، اور reinforcement learning from human feedback—کے ذریعے ماڈل کو "do not" کی شرائط پر عمل کرنے کے لیے تیار کیا جا سکتا ہے۔ حقیقت یہ ہے کہ language models probabilistic generators ہیں؛ وہ سب سے زیادہ ممکنہ تسلسل کا وزن کرتے ہیں، نہ کہ کسی سخت security rule کا۔ باریک بینی سے تیار کردہ guardrails کے باوجود، ایک نیا اندازِ بیان (novel phrasing) بچ نکل سکتا ہے، خاص طور پر جب حملہ آور بغیر کسی لاگت کے بار بار کوشش کر سکتا ہو۔ Guardrails شور (noise) کو کم کرنے کے لیے مفید ہیں لیکن انہیں دفاع کی واحد لائن نہیں ہونا چاہیے۔
آگے کیا دیکھنا ہے
- ایسے frameworks جو tool scoping کو first-class API کے طور پر پیش کرتے ہیں – ایسی نئی libraries کی توقع کریں جو آپ کو per-user capabilities متعین کرنے اور prompt تیار ہونے سے پہلے function list کو خودکار طور پر prune کرنے کی اجازت دیتی ہیں۔
- معیاری "function manifests" – صنعتی گروپس ایک ایسا JSON schema متعین کر سکتے ہیں جو public اور privileged functions کو الگ کرتا ہے، جس سے request-specific manifests تیار کرنا آسان ہو جاتا ہے۔
- Runtime enforcement – کچھ platforms sandboxed execution کے ساتھ تجربات کر رہے ہیں جو caller کے token کو پکارے گئے function کے خلاف چیک کرتا ہے، جس سے prompt scoping سے ہٹ کر دفاع کی دوسری تہہ شامل ہو جاتی ہے۔
حاصلِ کلام واضح ہے: prompt injection کو authorization flaw کے طور پر دیکھیں۔ ماڈل کے toolbox سے غیر مجاز tools کو ہٹا کر، آپ اس attack surface کو ختم کر دیتے ہیں جس کا فائدہ اٹھانے کی کوشش ایک چالاک انداز میں لکھا گیا prompt کرتا ہے۔ Prompts رویے کی رہنمائی کر سکتے ہیں؛ وہ مناسب access control کا نعم البدل نہیں ہو سکتے۔