سیکیورٹی محقق فرینک چو (Frank Chu) نے دریافت کیا کہ tl;dv—جو کہ Zoom اور Teams کے ساتھ منسلک ہونے والی ایک AI سے لیس میٹنگ نوٹ سروس ہے—نے 181,874 نجی میٹنگ ٹرانسکرپٹس (transcripts) لیک کر دیے کیونکہ Firebase کا ایک سیکیورٹی رول غائب تھا، جس کی وجہ سے کوئی بھی لاگ ان صارف تمام ریکارڈز پڑھ سکتا تھا۔ اس ڈیٹا چوری نے 35,003 ڈومینز کے 84,312 صارفین کو متاثر کیا، جو اس بات کی یاد دہانی ہے کہ کنفیگریشن کی ایک چھوٹی سی غلطی انتہائی خفیہ کارپوریٹ گفتگو کو بے نقاب کر سکتی ہے۔

ڈیٹا لیک کیسے ہوا

tl;dv اپنے نوٹس Google Firebase کے Firestore ڈیٹا بیس میں محفوظ کرتا ہے۔ Firestore میں، ڈویلپرز سیکیورٹی رولز لکھتے ہیں جو یہ فیصلہ کرتے ہیں کہ کون ہر دستاویز کو پڑھ یا لکھ سکتا ہے۔ tl;dv کے زیادہ تر کلیکشنز (collections) درست طریقے سے لاک تھے، لیکن meetings کلیکشن میں ایک ایسا رول موجود نہیں تھا جو درخواست گزار کی شناخت کی جانچ کرے۔ نتیجہ سادہ تھا: ایک بار جب صارف ایپ میں سائن ان کر لیتا، تو API سروس کے ذریعے محفوظ کردہ ہر میٹنگ دستاویز کی فہرست فراہم کر دیتا۔

اس میں کوئی پیچیدہ ایکسپلائٹ (exploit)، کوئی نقصان دہ پی لوڈ (malicious payload) یا بنیادی AI ماڈل کی خلاف ورزی شامل نہیں تھی۔ یہ کمزوری رسائی کے کنٹرول (access-control) کی ایک روایتی کوتاہی تھی—کوڈ کی ایک ایسی لائن کا نہ ہونا جسے یہ کہنا چاہیے تھا کہ "صرف مالک یا مدعو کردہ شرکاء ہی اس میٹنگ کو دیکھ سکتے ہیں۔" چونکہ وہ رول موجود نہیں تھا، اس لیے کوئی بھی تصدیق شدہ صارف دعوت نامے کی حیثیت سے قطع نظر، ہر ٹرانسکرپٹ کی فہرست بنا سکتا تھا اور اسے ڈاؤن لوڈ کر سکتا تھا۔

یہ کیوں اہم ہے

میٹنگ ٹرانسکرپٹس میں اکثر بورڈ روم کی مشاورت، پروڈکٹ روڈ میپس، قانونی مشورے اور سیلز کے مذاکرات شامل ہوتے ہیں۔ جب یہ الفاظ عوامی طور پر پڑھنے کے قابل ہو جاتے ہیں، تو حریف اس سے تزویراتی معلومات (strategic insights) حاصل کر سکتے ہیں، وکلاء کو رازداری کے وعدوں پر نظر ثانی کرنی پڑ سکتی ہے، اور ملازمین ان ٹولز پر سے اعتماد کھو دیتے ہیں جن پر وہ بھروسہ کرتے ہیں۔ لاکھوں ریکارڈز کی موجودگی اس بات کو ایک نظامی ناکامی (systemic failure) بناتی ہے جو کسی بھی ایسی تنظیم کو متاثر کر سکتی ہے جس نے tl;dv کے پرمیشن ماڈل کا باریک بینی سے جائزہ لیے بغیر اسے اپنا لیا ہو۔

ردعمل میں تاخیر

چو نے جنوری میں tl;dv کی ٹیم کو اس غائب رول کے بارے میں اطلاع دی۔ اس کا حل—یعنی مناسب ریڈ-ریسٹریشن (read-restriction) کا اضافہ اور رول سیٹ کو دوبارہ نافذ کرنا—اگست تک لاگو نہیں کیا گیا۔ دریافت اور تدارک کے درمیان چھ ماہ کا وقفہ ایسی کمزوری کے لیے غیر معمولی طور پر طویل ہے جو حساس ڈیٹا تک بلا روک ٹوک رسائی فراہم کرتی ہے۔ یہ تاخیر کمپنی کے 'vulnerability-management' کے عمل میں موجود خامیوں کو اجاگر کرتی ہے، جس میں تشخیص (triage) سے لے کر پیچ (patch) کی تعیناتی تک شامل ہے۔

AI سے چلنے والے ایجنٹس کے لیے ایک وسیع سبق

اس واقعے کو اکثر "AI خطرے" کے طور پر پیش کیا جاتا ہے، لیکن اس کی اصل وجہ رسائی کے کنٹرول (access-control) کی ایک روایتی غلطی ہے۔ AI ایجنٹس—خواہ وہ میٹنگز کا ٹرانسکرپشن کریں، ای میلز ڈرافٹ کریں یا دستاویزات کا خلاصہ کریں—سروس اکاؤنٹ کے اختیارات کے ساتھ کام کرتے ہیں جو انہیں اسی ڈیٹا تک رسائی دیتے ہیں جو ایک انسانی صارف کو حاصل ہوتی ہے۔ جب یہ اختیارات ضرورت سے زیادہ وسیع ہوں، تو AI کسی بھی دوسرے بیک اینڈ سروس کی طرح ڈیٹا لیک ہونے کا ذریعہ بن جاتا ہے۔

تنظیمیں آج کیا کر سکتی ہیں

  • از授权 (Authorization) لاجک کا آڈٹ کریں – اس بات کی تصدیق کریں کہ AI ٹول کے ذریعے استعمال ہونے والا ہر ڈیٹا بیس کلیکشن، API اینڈ پوائنٹ، یا کلاؤڈ اسٹوریج بکٹ 'کم از کم مراعات' (least-privilege) کے اصول پر عمل درآمد کرے۔ ان غائب یا ضرورت سے زیادہ اجازت دینے والے رولز کو تلاش کریں جیسے کہ tl;dv میں ہوا۔
  • ریکارڈنگ کا دائرہ کار محدود کریں – نوٹ لینے والے ایجنٹ کو اس طرح ترتیب دیں کہ وہ صرف وہی میٹنگز ریکارڈ کرے جن کی آپ نے واضح طور پر اجازت دی ہو۔ 'ڈیفالٹ آن ریکارڈ' سیٹنگ حملے کے خطرے کو بڑھا دیتی ہے؛ 'آپٹ ان' (opt-in) ماڈلز خطرے کو محدود رکھتے ہیں۔
  • AI ایجنٹس کو سروس اکاؤنٹس کے طور پر سمجھیں – ہر تھرڈ پارٹی AI انٹیگریشن کی فہرست بنائیں، اسے ایک مخصوص شناخت دیں، اور اسے صرف وہی اجازتیں دیں جو اسے اپنا کام کرنے کے لیے درکار ہوں۔ باقاعدگی سے غیر استعمال شدہ اکاؤنٹس کا جائزہ لیں اور انہیں ختم کریں۔
  • سیکیورٹی رولز کا اسٹریس ٹیسٹ کریں – خودکار ٹیسٹ چلائیں جو مناسب کریڈنشلز کے بغیر کلیکشنز سے ڈیٹا پڑھنے کی کوشش کریں۔ ان چیکس کو CI/CD پائپ لائنز میں شامل کریں تاکہ تعیناتی سے پہلے غائب رول کا پتہ چل سکے۔
  • واقعات کے ردعمل میں تیزی لائیں – رپورٹ شدہ کمزوریوں کو تسلیم کرنے، ان کی تشخیص کرنے اور ان کے حل (patching) کے لیے واضح ٹائم لائنز مقرر کریں۔ یہاں کی طرح چھ ماہ کا تدارک کا دورانیہ ایک انتظامی ناکامی ہے جو ایک سادہ سے بگ کے اثرات کو بڑھا سکتی ہے۔

آگے کیا نظر رکھنا ہے

وہ ادارے جو میٹنگ نوٹس، کال کے خلاصے، یا ریئل ٹائم ٹرانسکرپشن کے لیے AI اسسٹنٹ پر انحصار کرتے ہیں، انہیں دیگر کلاؤڈ نیٹیو سروسز میں اسی طرح کی غلط کنفیگریشنز کے لیے تیار رہنا چاہیے۔ جیسے جیسے AI ایجنٹس روزمرہ کے کاموں میں زیادہ شامل ہو رہے ہیں، "AI خطرے" اور "روایتی سیکیورٹی خطرے" کے درمیان فرق دھندلا رہا ہے۔ پرمیشن ریویوز پر نظر رکھیں، وینڈرز سے شفاف سیکیورٹی رول آڈٹ کا مطالبہ کریں، اور تیز رفتار پیچ سائیکلز (patch cycles) پر زور دیں تاکہ اگلے "ایک غائب رول" والے واقعے سے مزید خفیہ گفتگو لیک ہونے سے بچا جا سکے۔

حتمی نتیجہ: AI ٹولز صرف اتنے ہی محفوظ ہیں جتنے وہ access controls جو ان کے ڈیٹا کی حفاظت کرتے ہیں۔ Firestore کے ایک بھی قاعدے کی کمی نے ایک مفید نوٹ لینے والے اسسٹنٹ کو ڈیٹا کے بڑے پیمانے پر لیک ہونے کا سبب بنا دیا؛ باقاعدگی سے آزمائی گئی permissions ہی واحد قابل اعتماد دفاع ہیں۔