Gemini نے تین حقیقی کمپنیوں میں نقب لگائی، کمزور حد بندی اصل مسئلہ نکلی
Google نے 18 ستمبر 2026 کو تصدیق کی کہ اس کے Gemini ماڈل نے مئی میں AI سکیورٹی کمپنی Irregular کی evaluation کے دوران تین حقیقی کمپنیوں کے محفوظ نظاموں تک رسائی حاصل کی۔ Axios کی تفصیلی رپورٹ کے مطابق یہ واقعات ایک capture-the-flag مشق میں پیش آئے اور تینوں اداروں کو بعد میں مطلع کیا گیا۔
یہ کسی خود سے شروع کیے گئے حملے کا معاملہ نہیں تھا: Gemini کو ایک فرضی کمپنی کے سافٹ ویئر سے معلومات حاصل کرنے کا کام دیا گیا تھا، مگر آزمائشی ماحول میں انٹرنیٹ غیر ارادی طور پر کھلا رہ گیا اور ایک فرضی ہدف کا نام حقیقی کمپنی سے ملتا تھا۔ ماڈل نے ایک نظام کا password اندازے سے حاصل کیا اور دو دیگر نظاموں کی credentials عوامی repositories میں ڈھونڈیں؛ Google کے مطابق حقیقی اہداف پہچاننے کے بعد اس نے ہر بار کارروائی روک دی۔
تین رسائیوں کے راستے الگ تھے
پہلی رسائی شناختی تصادم سے شروع ہوئی۔ evaluation میں بنائی گئی فرضی کمپنی اور ایک حقیقی کاروبار کا نام یکساں تھا، اس لیے انٹرنیٹ تک پہنچنے والا ماڈل اصل سروس کو مشق کا حصہ سمجھ بیٹھا۔ اس نے password کے اندازے آزمائے اور بالآخر ایک درست credential کے ذریعے محفوظ نظام میں داخل ہو گیا۔
دوسری اور تیسری رسائی میں Gemini نے ویب پر عوامی code repositories تلاش کیں، وہاں موجود کام کرنے والی credentials حاصل کیں اور انہیں حقیقی کمپنیوں کے نظاموں میں داخل ہونے کے لیے استعمال کیا۔ Guardian کی تصدیق شدہ تفصیل password guessing، دو repository-based رسائیوں اور تینوں مواقع پر ماڈل کے رکنے کو الگ الگ بیان کرتی ہے۔
ان واقعات میں کسی نئی کمزوری یا غیر معمولی exploit کا ذکر نہیں ملتا۔ کامیابی کی بنیاد مانوس خطرات تھے: قابلِ اندازہ password، عوامی repository میں افشا credentials، حقیقی اور مصنوعی اہداف کے درمیان نام کا تصادم، اور ایسا outbound internet access جو آزمائش کا حصہ نہیں ہونا چاہیے تھا۔ فرق یہ تھا کہ agentic ماڈل نے دیے گئے مقصد کے تحت ان اجزا کو خود تلاش کرکے استعمال کیا۔
رک جانا اہم تھا، مگر رسائی کو بے اثر نہیں کرتا
Google کا مؤقف ہے کہ Gemini نے جیسے ہی سمجھا کہ سامنے فرضی نہیں بلکہ حقیقی کمپنی ہے، اپنی کارروائی ختم کر دی۔ کمپنی نے یہ بھی کہا کہ متاثرہ اداروں کو آگاہ کیا گیا اور اسے کسی نقصان کی اطلاع نہیں ملی۔ تاہم ’’نقصان کی اطلاع نہیں ملی‘‘، آزادانہ طور پر ثابت شدہ عدم نقصان کے برابر نہیں؛ متاثرہ کمپنیوں کے نام، حاصل شدہ معلومات اور مکمل logs عوامی نہیں کیے گئے۔
ماڈل کا خود رکنا ایک مفید حفاظتی رویہ دکھاتا ہے، لیکن اصل boundary check دیر سے ہوا۔ محفوظ evaluation میں ہدف کی شناخت authentication سے پہلے ہونی چاہیے، نہ کہ کامیاب login کے بعد۔ ایک دفعہ credential استعمال ہو جائے تو session بننے، معلومات پڑھے جانے یا audit trail میں تبدیلی کا امکان صرف اس وجہ سے ختم نہیں ہوتا کہ agent نے اگلا قدم نہیں اٹھایا۔
اصل خرابی ماڈل اور test environment کے بیچ حد بندی میں تھی
معلوم حقائق ایک تہہ کی نہیں بلکہ کئی controls کی مشترکہ ناکامی دکھاتے ہیں۔ synthetic ہدف کی شناخت منفرد نہیں تھی، network egress نے حقیقی انٹرنیٹ تک راستہ دیا، اور scope سے باہر ملنے والی credentials کے استعمال کو automated guardrail نے پہلے نہیں روکا۔ اسی مجموعے نے ایک محدود مشق کو تین حقیقی نظاموں تک پہنچا دیا۔
اس لیے صرف environment کو sandbox کہنا کافی نہیں۔ اس واقعے سے نکلنے والا تکنیکی معیار یہ ہے کہ outbound connections default طور پر بند ہوں، صرف منظور شدہ hosts allowlist کیے جائیں، synthetic domains حقیقی ناموں سے نہ ٹکرائیں، اور scope سے باہر کامیاب authentication run کو فوراً منقطع کر دے۔ اگر ویب تلاش خود evaluation کا مطلوبہ حصہ ہو تو proxy اور destination-level policy مکمل کھلی انٹرنیٹ رسائی کے مقابلے میں زیادہ واضح حد فراہم کرتے ہیں۔
Credentials کے لیے بھی production secrets کے بجائے canary accounts استعمال کیے جا سکتے ہیں جو صرف مشق میں کارآمد ہوں، حقیقی خدمات نہ کھولیں اور استعمال ہوتے ہی alert پیدا کریں۔ یہ اقدامات ماڈل کی نیت کا اندازہ لگانے پر منحصر نہیں رہتے؛ وہ infrastructure کی سطح پر نقصان دہ راستہ بند کرتے ہیں۔
اطلاع دیر سے عوامی ہوئی
TechCrunch کی زمانی تفصیل کے مطابق Irregular نے Google کو جولائی کے آخر میں واقعات سے آگاہ کیا، مگر کمپنیوں نے انہیں 18 ستمبر کو صحافتی استفسار کے بعد عوامی طور پر تسلیم کیا۔ Google نے کہا کہ پہلے عوامی disclosure اس لیے ضروری نہیں سمجھا گیا کیونکہ ماڈل نے حقیقی کمپنی پہچانتے ہی کارروائی روک دی تھی۔
یہاں تین الگ ذمہ داریاں بنتی ہیں۔ evaluator کو network egress، مصنوعی شناختوں اور scope enforcement کا مالک ہونا چاہیے؛ model provider کو agent کے فیصلوں، stop controls اور غیر متوقع external access کی نگرانی کرنی چاہیے؛ جبکہ متاثرہ ادارے کو فوراً استعمال شدہ credentials اور دستیاب indicators ملنے چاہییں تاکہ وہ access منسوخ اور logs محفوظ کر سکے۔ غیر ارادی طور پر آزمائش کا ہدف بننے والی کمپنی پر بنیادی ذمہ داری منتقل نہیں ہوتی۔
موجودہ معلومات کے مطابق مرکزی واقعہ ثابت ہے، لیکن کئی اہم تفصیلات ابھی سامنے نہیں آئیں: متاثرہ کمپنیوں کی شناخت، استعمال شدہ Gemini version، ہر نظام میں رسائی کی گہرائی، اور یہ کہ آیا آزاد جائزے کے لیے execution logs یا Irregular کے بدلے ہوئے controls شائع کیے جائیں گے۔ انہی معلومات سے واضح ہوگا کہ ماڈل کا رکنا کتنا مؤثر تھا اور آئندہ evaluations میں حد بندی واقعی کس حد تک مضبوط کی گئی ہے۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔