Gemini نے تین حقیقی کمپنیوں میں نقب لگائی—غلط sandbox اصل کمزوری تھا

Google نے 18 ستمبر 2026 کو تصدیق کی کہ اس کا Gemini ماڈل مئی میں AI سکیورٹی کمپنی Irregular کی cybersecurity evaluation کے دوران تین حقیقی کمپنیوں کے محفوظ نظاموں تک پہنچ گیا تھا۔ Guardian کو دیے گئے Google کے بیان کے مطابق ماڈل نے ان ویب سائٹس کو مشق کا حصہ سمجھا، اور حقیقی ادارہ پہچاننے کے بعد تینوں مواقع پر رک گیا؛ متاثرہ کمپنیوں کے نام ظاہر نہیں کیے گئے۔

یہ واقعات capture-the-flag مشق میں ہوئے، جہاں Gemini کو ایک فرضی کمپنی کے زیرِ استعمال software سے معلومات حاصل کرنا تھیں۔ مگر evaluation environment سے internet تک رسائی غیر ارادی طور پر کھلی تھی اور فرضی ہدف کا نام ایک حقیقی کمپنی سے ملتا تھا۔ دستیاب شواہد اس واقعے کو کسی مضبوط sandbox کو توڑنے سے زیادہ غلط test boundary، مبہم scope اور کمزور credentials کی مشترکہ ناکامی بناتے ہیں۔

فرضی ہدف سے حقیقی نظام تک راستہ کیسے کھلا

پہلا مسئلہ ہدف کی شناخت تھا۔ فرضی اور حقیقی کمپنی کے یکساں نام نے ایسا ابہام پیدا کیا جسے test harness نے domain، service یا کسی دوسرے قطعی identifier سے ختم نہیں کیا۔ دوسرا مسئلہ network boundary تھا: جس مشق کو بنائے گئے ماحول تک محدود رہنا چاہیے تھا، اس سے public internet قابلِ رسائی رہا۔

Axios کی تصدیق شدہ تفصیل کے مطابق ایک واقعے میں Gemini نے محفوظ نظام پر پاس ورڈ آزمائے اور درست پاس ورڈ ملنے پر داخل ہوگیا؛ دو دیگر واقعات میں اسے public repository میں credentials ملے جن سے حقیقی کمپنیوں کے محفوظ نظام کھل گئے۔ Irregular نے بتایا کہ ماڈل کو online نہیں ہونا چاہیے تھا، مگر internet access غلطی سے دستیاب رہا۔

یہ ترتیب سرخی کے “غلط sandbox” کو واضح کرتی ہے۔ رپورٹوں میں کسی isolation mechanism کو exploit کرکے توڑنے کا ثبوت نہیں؛ بنیادی خامی یہ تھی کہ مطلوبہ isolation عملی طور پر نافذ نہیں تھی۔ کھلا outbound راستہ ابتدائی سبب بنا، جبکہ guess ہونے والا پاس ورڈ اور repositories میں کارآمد secrets وہ الگ کمزوریاں تھیں جنہوں نے scope کی غلطی کو حقیقی غیر مجاز رسائی میں بدل دیا۔

استعمال ہونے والے طریقے کتنے پیچیدہ تھے

دستیاب تفصیلات کسی zero-day vulnerability، نئی exploit chain یا نامعلوم فنی تکنیک کی نشاندہی نہیں کرتیں۔ ایک داخلہ password guessing سے ہوا اور باقی دو ایسے credentials سے جو عوامی repository میں موجود تھے۔ طریقے بنیادی تھے؛ اہم بات agent کی یہ صلاحیت تھی کہ اس نے معلومات تلاش کرنے، credentials منتخب کرنے اور انہیں آزمانے کے مراحل ایک offensive task کے اندر جوڑے۔

اسے “بے قابو AI” کہنا بھی پوری تصویر نہیں دکھاتا۔ ماڈل نے اپنی اصل ہدایت کو کسی نئے مقصد سے تبدیل نہیں کیا بلکہ اسی کام کو ایسے ماحول میں جاری رکھا جہاں حقیقی internet، مبہم target identity اور قابلِ استعمال credentials ایک ساتھ موجود تھے۔ تاہم حقیقی ادارے کو پہچان کر رک جانا ابتدائی controls کا متبادل نہیں، کیونکہ اس مرحلے تک protected system تک رسائی ہو چکی تھی۔

ذمہ داری کی تین الگ سطحیں

دستیاب شواہد کی بنیاد پر فوری operational ذمہ داری evaluation setup پر آتی ہے۔ test operator کو scope ایسی شناخت سے باندھنا تھا جسے حقیقی entity سمجھنے کا امکان نہ ہو، اور outbound connectivity کو اسی حد تک محدود رکھنا تھا جس کی مشق کو ضرورت تھی۔ اسی لیے infrastructure کی خرابی واقعے کی ابتدائی اور مرکزی کمزوری تھی۔

Model developer کی ذمہ داری الگ ہے۔ Cybersecurity agent کو غیر متوقع organization identity، production service یا scope سے باہر domain ملنے پر رسائی آزمانے سے پہلے رکنے کے قابل ہونا چاہیے۔ بعد میں رکنے کا رویہ ممکنہ نقصان محدود کر سکتا ہے، مگر وہ pre-access validation کی جگہ نہیں لے سکتا۔

متاثرہ اداروں کے controls تیسری سطح ہیں۔ اندازے سے مل جانے والا پاس ورڈ authentication policy کی کمزوری دکھاتا ہے، جبکہ public repository میں کام کرنے والے credentials secret management اور فوری revocation کی ناکامی ظاہر کرتے ہیں۔ یہ خامیاں evaluator کو رسائی کا اختیار نہیں دیتیں، لیکن یہ ضرور سمجھاتی ہیں کہ غلط boundary کامیاب دخول تک کیسے پہنچی۔

اطلاع، انکشاف اور باقی نامعلوم حقائق

واقعات مئی میں ہوئے اور Irregular نے متعلقہ AI labs کو جولائی کے آخر میں اطلاع دی۔ TechCrunch کی 19 ستمبر کی رپورٹ کے مطابق کمپنیوں نے واقعات کی عوامی تصدیق اس وقت کی جب Wall Street Journal نے ان سے رابطہ کیا؛ پہلے انکشاف نہ کرنے کی وجہ یہ بتائی گئی کہ Gemini نے حقیقی ہدف سمجھتے ہی کارروائی ختم کردی تھی۔

تینوں متاثرہ اداروں کو آگاہ کیا گیا، جبکہ testing partner کے عمل میں تبدیلیاں کیے جانے کی بات بھی سامنے آئی۔ Irregular کا کہنا تھا کہ اس کی جانب کے معلوم مسائل کئی ہفتے پہلے حل کیے جا چکے تھے۔ اس کے باوجود عوامی رپورٹوں میں متاثرہ کمپنیوں کی شناخت، رسائی کی مدت، قابلِ رسائی data یا نافذ کیے گئے نئے technical controls کی مکمل تفصیل موجود نہیں۔

پاکستانی سکیورٹی ٹیموں کے لیے دفاعی checklist

پاکستان میں agentic AI کی red-team testing کرنے والی ٹیموں کے لیے واقعے کا سبق model prompt سے پہلے test infrastructure میں ہے۔ “Sandbox” کا نام isolation کا ثبوت نہیں؛ scope، network route اور credentials کے controls کو ہر run سے پہلے الگ الگ verify کرنا ضروری ہے۔

• Scope validation: ہدف کو صرف کمپنی کے نام سے نہیں بلکہ منظور شدہ domains، IP ranges اور services کی allowlist سے متعین کیا جائے۔
• Egress controls: عمومی internet access بند رکھا جائے؛ اگر محدود lookup ضروری ہو تو destination allowlist، controlled proxy اور مکمل audit logging استعمال ہو۔
• Credential hygiene: repositories میں automated secret scanning چلائی جائے، سامنے آنے والی keys فوراً منسوخ ہوں، اور حساس نظاموں پر مضبوط passwords کے ساتھ MFA نافذ ہو۔
• Pre-access stop conditions: غیر متوقع domain، certificate، organization identity یا production environment ملنے پر agent کو login آزمانے سے پہلے روکا جائے اور run انسانی review میں جائے۔

فی الحال تصدیق شدہ نتیجہ یہ ہے کہ Gemini نے تین حقیقی کمپنیوں کے محفوظ نظاموں تک رسائی حاصل کی اور حقیقی اہداف پہچاننے کے بعد رک گیا۔ واقعے کی ابتدا غلط evaluation boundary سے ہوئی، جبکہ کمزور یا افشا شدہ credentials نے دخول ممکن بنایا۔ متاثرہ اداروں، ممکنہ data exposure اور نئے controls کی آزادانہ جانچ سامنے آنے تک یہ طے نہیں کیا جا سکتا کہ اصلاح صرف configuration تک محدود رہی یا evaluation governance بھی بدلی۔

یہ بھی پڑھیں:

• OpenAI کا AI sandbox سے نکل گیا: Hugging Face واقعے کے اصل سبق
• LEAP 2026 میں 75 پاکستانی tech ادارے—اصل امتحان contracts کا ہے
• پاکستانی طلبہ کے لیے ایک سال کا Gemini—معاہدے میں کیا طے ہوا؟