AI ایجنٹس اب صرف چیٹ ونڈوز تک محدود نہیں رہے بلکہ وہ میٹنگز بک کرتے ہیں، کسٹمر ریکارڈز اپ ڈیٹ کرتے ہیں، اندرونی ڈیٹا بیسز سے معلومات حاصل کرتے ہیں، اور مالیاتی لین دین (financial transactions) شروع کرتے ہیں۔ مشیر (advisor) سے آپریٹر (operator) بننے کا یہ بدلاؤ خطرات کے حوالے سے سب کچھ بدل دیتا ہے۔ جب سافٹ ویئر صرف مشورہ دینا چھوڑ کر کام کرنا شروع کر دیتا ہے، تو ہر API اینڈ پوائنٹ ایک ممکنہ دروازہ بن جاتا ہے۔ روایتی سیکیورٹی ماڈلز قابلِ پیش گوئی انسانی رویوں کے گرد بنائے گئے تھے: ایک شخص لاگ ان کرتا ہے، جانی پہچانی راہوں پر کلک کرتا ہے، اور لاگ آؤٹ کر دیتا ہے۔ خود مختار ایجنٹس ان پیٹرنز پر عمل نہیں کرتے۔ وہ سیکنڈوں میں سینکڑوں کالز کے ذریعے لوپ (loop) کرتے ہیں، دوبارہ کوشش کرتے ہیں، اور مختلف شاخوں میں تقسیم ہو جاتے ہیں۔ API لیئر، جو اصل میں انسانی درخواستوں کے لیے ڈیزائن کی گئی تھی، اب مسلسل خودکار دباؤ کا سامنا کر رہی ہے۔ اگر آپ کے دفاعی نظام اب بھی گزشتہ سہ ماہی میں لکھے گئے جامد (static) قواعد پر منحصر ہیں، تو آپ ڈیٹا کے اخراج اور غیر مجاز رسائی کے لیے دروازہ کھلا چھوڑ رہے ہیں۔ آپ کو حقیقی وقت (real-time) کے دفاع کی ضرورت ہے جو ہر کال کا اس کے ہوتے ہی جائزہ لے۔
ایجنٹ کے اختیارات کو محدود کریں
ایجنٹ کی تعیناتی میں سب سے خطرناک شارٹ کٹ ایک طاقتور API key فراہم کرنا ہے۔ ایک ہی کی (key) ہر سسٹم تک تمام رسائی فراہم کرتی ہے۔ اگر کوئی حملہ آور 'پائزنڈ پرامپٹ' (poisoned prompt) یا ہائی جیک شدہ انٹیگریشن کے ذریعے ایجنٹ پر قابض ہو جاتا ہے، تو اسے پورے نظام کی چابیاں مل جاتی ہیں۔ اس صورت میں بحالی ایک ڈراؤنا خواب بن جاتی ہے کیونکہ اس کا اثر (blast radius) آپ کی ای میل سروس سے لے کر پروڈکشن ڈیٹا بیس تک ہر چیز پر پڑتا ہے۔
اس عادت کو فوری طور پر ختم کریں۔ تفویض شدہ اتھارٹی (delegated authorization) کے لیے OAuth 2.0 سے آغاز کریں۔ ایجنٹ کو ایک آزاد سپر یوزر (superuser) کے طور پر تصدیق (authenticate) نہیں کرنی چاہیے۔ اس کے بجائے، اسے ایک ایسا ٹوکن (token) استعمال کرنا چاہیے جو ایجنٹ اور اس صارف (end user) دونوں کی نمائندگی کرے۔ جب انسانی سیشن ختم ہو جائے، تو ایجنٹ کی رسائی بھی اس کے ساتھ ختم ہو جانی چاہیے۔
Token Exchange اسے عملی بناتا ہے۔ ایسے مختصر مدت کے ٹوکن جاری کریں جن کا دائرہ کار (scope) صرف وہی ہو جو ایجنٹ کو اس وقت درکار ہو۔ ایک شیڈولنگ ایجنٹ کو کیلنڈر پڑھنے اور دعوت نامے بھیجنے کی اجازت مل سکتی ہے، لیکن کیلنڈر کے ڈھانچے کو حذف کرنے یا پے رول APIs تک رسائی کی نہیں۔ اگر کوئی حملہ آور ٹوکن کو روک لیتا ہے، تو اس کے غلط استعمال کا وقت بہت محدود رہے گا۔
Context-Bound Scopes ایک اور تہہ کا اضافہ کرتے ہیں۔ ہر ٹوکن کو ڈیفالٹ کے طور پر 'صرف پڑھنے' (read-only) پر رکھیں۔ اگر ایجنٹ کو ڈیٹا لکھنے کی ضرورت ہے، جیسے کہ ریفنڈ پروسیس کرنا یا معاہدہ اپ ڈیٹ کرنا، تو انسانی منظوری کا گیٹ (approval gate) لازمی بنائیں۔ ماڈل کو کبھی بھی اکیلے یہ فیصلہ نہ کرنے دیں کہ کب رقم منتقل ہو، اکاؤنٹس تبدیل ہوں، یا ریکارڈز غائب ہوں۔ اجازت کا دائرہ کار لمحے کے مطابق ہونا چاہیے، نہ کہ زیادہ سے زیادہ (maximum) کے مطابق۔
Ephemeral Windows اس عمل کو مکمل طور پر بند کر دیتے ہیں۔ ٹوکن کی مدت کو دنوں کے بجائے منٹوں میں رکھیں۔ اگر کوئی ٹوکن کسی مختصر حملے کے دوران حاصل کر لیا جائے، تو حملہ آور کے اسے دوبارہ استعمال کرنے کی کوشش کرنے تک وہ بیکار ہو جانا چاہیے۔ اسے مسلسل گھومتے ہوئے تالے کے طور پر سمجھیں۔
ایک سیلز آٹومیشن ایجنٹ پر غور کریں جو آپ کے CRM سے لیڈ ڈیٹا پڑھتا ہے اور آپ کے میل API کے ذریعے فالو اپ ای میلز لکھتا ہے۔ ایک مستقل ایڈمن کی (admin key) کے بجائے، ایجنٹ کو آپ کے آئیڈنٹیٹی فراہم کنندہ (identity provider) سے 15 منٹ کا ٹوکن ملتا ہے۔ یہ ٹوکن CRM ریڈز اور میل سینڈز کی اجازت دیتا ہے، لیکن کانٹیکٹ ڈیلیشن اور بلنگ تک رسائی کو روک دیتا ہے۔ اگر ایجنٹ کو پورے ڈیٹا بیس کو ایکسپورٹ کرنے کی کوئی مشکوک ہدایت ملتی ہے، تو اس کا اسکوپ (scope) اس کوشش کو روک دیتا ہے۔
بالواسطہ پرامپٹ انجیکشن (Indirect Prompt Injection) کو روکیں
پرامپٹ انجیکشن اب چیٹ بوٹس کے لیے محض ایک کرتب نہیں رہا۔ ایجنٹک دور میں، یہ ای میل کے ذریعے بھیجے گئے ریموٹ کوڈ ایگزیکیوشن (remote code execution) کی طرح کام کرتا ہے۔
یہاں ایک ٹھوس منظرنامہ ہے۔ ایک ایجنٹ میٹنگز شیڈول کرنے کے لیے صارف کے ان باکس کی نگرانی کرتا ہے۔ کسی پیغام کے اندر، شاید غیر مرئی متن (invisible text) یا اٹیچمنٹ کے اندر میٹا ڈیٹا میں، ایک کمانڈ چھپی ہو سکتی ہے جیسے کہ تمام انوائسز کو کسی بیرونی ایڈریس پر فارورڈ کرنا اور اصل انوائسز کو حذف کرنا۔ ایجنٹ ای میل پڑھتا ہے، اس زہریلے متن کو ایک جائز سسٹم ہدایت سمجھ لیتا ہے، اور APIs کو کال کرنا شروع کر دیتا ہے۔ چونکہ ایجنٹ خود مجاز (authorized) ہے، اس لیے بدنیتی پر مبنی درخواستیں معمول کے چینلز کے ذریعے گزر جاتی ہیں۔ اس کا نتیجہ غیر مجاز ڈیٹا کے اخراج (data exfiltration) کی صورت میں نکلتا ہے جو کہ بالکل عام طرزِ عمل معلوم ہوتا ہے۔
آپ کا پہلا دفاع سخت ان پٹ ویلیڈیشن (input validation) ہے۔ AI جو بھی پیرامیٹر تیار کرتا ہے، اسے تب تک غیر قابلِ اعتماد سمجھیں جب تک کہ اس کا ثبوت نہ مل جائے۔ اپنے API گیٹ وے پر JSON-schema ویلیڈیشن چلائیں۔ اگر ایجنٹ کسی کسٹمر ریکارڈ کی درخواست کرتا ہے، تو گیٹ وے کو اس بات کی تصدیق کرنی چاہیے کہ پے لوڈ (payload) میں صرف ایک متوقع آئیڈنٹیفائر ہے، نہ کہ کوئی وائلڈ کارڈ یا غیر معمولی طور پر بڑا بیچ ریکوسٹ۔ کسی بھی غلط، ضرورت سے زیادہ بڑے، یا مصنوعی طور پر عجیب و غریب چیز کو اپنے بیک اینڈ تک پہنچنے سے پہلے ہی مسترد کر دیں۔
دوسرا، رسپانس پاتھ پر ڈیٹا ایکسفلیٹریشن (data exfiltration) فلٹرز لگائیں۔ AI تک پہنچنے سے پہلے API رسپانسز کا معائنہ کیا جانا چاہیے۔ ایسے پیٹرنز تلاش کریں جو سیکرٹس (secrets)، آتھنٹیکیشن ٹوکنز، یا بڑی مقدار میں ذاتی معلومات سے مطابقت رکھتے ہوں۔ اگر کوئی CRM کوئری ایک کے بجائے دس ہزار ریکارڈز واپس کرتی ہے، تو اسے بلاک کر دیں۔ اگر پے لوڈ میں کوئی اندرونی API کی (key) موجود ہے، تو اسے ریڈیکٹ (redact) کر دیں۔ ایجنٹ کو اپنا کام کرنے کے لیے خام سیکرٹس کی ضرورت نہیں ہے، اور آؤٹ باؤنڈ چینلز کو چوری شدہ ڈیٹا کی اسمگلنگ کے راستے نہیں بننا چاہیے۔
تیسرا، ڈومین وائٹ لسٹنگ (domain whitelisting) نافذ کریں۔ ایجنٹ کو آپ کی کیلنڈر سروس، آپ کے پیمنٹ پروسیسر، اور آپ کے اندرونی انوینٹری سسٹم کے ساتھ رابطہ کرنے کی ضرورت ہوتی ہے۔ اسے کسی بھی غیر متعلقہ فائل شیئرنگ سائٹس، پیسٹ بورڈ سروسز، یا غیر ملکی کلاؤڈ اسٹوریج اینڈ پوائنٹس سے بات کرنے کی ضرورت نہیں ہے۔ آؤٹ باؤنڈ DNS ریزولوشن اور HTTP درخواستوں کو ایک واضح الاؤ لسٹ (allow-list) تک محدود رکھیں۔ اگر کوئی حملہ آور ایجنٹ کو ڈیٹا کہیں اور بھیجنے کے لیے دھوکہ بھی دے دے، تب بھی نیٹ ورک لیئر محض کنکشن سے انکار کر دے گی۔
زیرو ٹرسٹ آرکیٹیکچرز (Zero-Trust Architectures) بنائیں
زیرو ٹرسٹ کوئی ایسی پروڈکٹ نہیں ہے جسے آپ انسٹال کریں۔ یہ ایک ڈیزائن فلسفہ ہے جو ایک مفروضے پر مبنی ہے: ایجنٹ پہلے ہی کمپرومائزڈ (compromised) ہو چکا ہے۔ اسی کے مطابق عمل کریں۔
اس کا مطلب ہے شناخت کو مکمل طور پر الگ کرنا۔ انسانی صارف اور ایجنٹ ایک ہی ہستی نہیں ہیں، چاہے ایجنٹ صارف کی جانب سے کام کر رہا ہو۔ ایجنٹ کے لیے الگ سروس شناختیں برقرار رکھیں، جو انسانی SSO سیشن سے مختلف ہوں۔ آپ کے آڈٹ لاگز میں دونوں شناختیں ساتھ ساتھ ریکارڈ ہونی چاہئیں۔ جب کچھ غلط ہوتا ہے، تو آپ