Google Cloud نے ایک مینیجڈ GKE Agent Sandbox سروس متعارف کروائی ہے، جبکہ اوپن سورس kubernetes-sigs/agent-sandbox پروجیکٹ یہی صلاحیت کسی بھی Kubernetes کلسٹر کو فراہم کرتا ہے۔ یہ دونوں ڈویلپرز کو AI ایجنٹس کے لیے ایک ڈسپوزایبل (استعمال کے بعد ختم ہونے والا) Linux کنٹینر فراہم کرتے ہیں، جس سے باقی انفراسٹرکچر محفوظ رہتا ہے۔

AI سے تیار کردہ کوڈ کو 'پلے پین' (محفوظ ماحول) کی ضرورت کیوں ہے

جدید AI ایجنٹس صرف سوالات کے جوابات نہیں دیتے، بلکہ وہ اسکرپٹس لکھتے ہیں، ویب براؤز کرتے ہیں، شیل کمانڈز چلاتے ہیں اور یہاں تک کہ ویب سروسز بھی لانچ کرتے ہیں۔ یہ طاقت ایک سیکیورٹی خلا پیدا کرتی ہے: ان کا تیار کردہ کوڈ بگ والا، نقصان دہ یا حد سے زیادہ جارحانہ ہو سکتا ہے۔ ایک ایسا ایجنٹ جو rm -rf / چلائے یا بغیر اجازت کسی اندرونی ڈیٹا بیس سے جڑ جائے، وہ پورے سسٹم کو خطرے میں ڈال سکتا ہے۔

ایک سینڈ باکس (sandbox) ہر ایجنٹ کو اس کے اپنے کنٹینر میں الگ کر دیتا ہے—جو کہ ایک چھوٹا سا، عارضی ورچوئل مشین ہوتا ہے۔ اگر ایجنٹ غلط کام کرے تو نقصان اسی کنٹینر کے اندر رہتا ہے؛ ہوسٹ اور دیگر ورک لوڈز محفوظ رہتے ہیں۔ GKE کی نئی پیشکش اور کمیونٹی کے زیرِ انتظام پروجیکٹ اس تصور کو ایک تیار شدہ سروس میں بدل دیتے ہیں۔

سینڈ باکس حاصل کرنے کے دو طریقے

  • GKE Agent Sandbox – Google Cloud صارفین کے لیے ایک مکمل طور پر مینیجڈ سروس۔
  • kubernetes-sigs/agent-sandbox – کسی بھی Kubernetes کلسٹر کے لیے ایک اوپن سورس پروجیکٹ۔

دونوں کا بنیادی ڈھانچہ (architecture) ایک جیسا ہے، جو کہ معیاری Kubernetes primitives پر مبنی ہے۔

سسٹم کو کیسے ترتیب دیا گیا ہے

جز (Component) کردار (Role)
Sandbox الگ تھلگ کنٹینر جو ایجنٹ کے کوڈ کو چلاتا ہے۔ اس کا ایک مستقل نام ہوتا ہے اور ضرورت پڑنے پر مستقل اسٹوریج بھی فراہم کرتا ہے۔
SandboxTemplate ایک بلیو پرنٹ جو کنٹینر امیج اور سیکیورٹی پالیسیوں کا تعین کرتا ہے—نئے سینڈ باکسز کے لیے ایک ترکیب (recipe) کی طرح۔
SandboxClaim ایجنٹ (یا اس کے کنٹرولر) کی جانب سے کسی مخصوص ٹیمپلیٹ سے سینڈ باکس شروع کرنے کے لیے کی جانے والی درخواست۔
SandboxWarmPool پہلے سے تیار شدہ سینڈ باکسز کا ایک پول جو فوری طور پر فراہم کرنے کے لیے تیار ہوتا ہے۔ کنٹینرز کو 'وارم' (warm) رکھنے سے ہر بار امیجز ڈاؤن لوڈ کرنے اور نیا پوڈ (pod) شروع کرنے میں ہونے والی تاخیر سے بچا جا سکتا ہے۔

جب کسی ایجنٹ کو ماحول کی ضرورت ہوتی ہے، تو وہ ایک SandboxClaim بھیجتا ہے۔ کنٹرولر وارم پول کو چیک کرتا ہے، ایک فارغ سینڈ باکس کا انتخاب کرتا ہے، اور اسے کلیم (claim) کے ساتھ منسلک کر دیتا ہے۔ اگر پول خالی ہو، تو یہ ٹیمپلیٹ سے ایک نیا سینڈ باکس تیار کرتا ہے؛ ورنہ یہ عمل ملی سیکنڈز میں مکمل ہو جاتا ہے۔

سیکیورٹی کے کنٹرولز جنہیں آپ استعمال کر سکتے ہیں

  • Default-deny networking – ڈیفالٹ کے طور پر ایک سینڈ باکس انٹرنل نیٹ ورک تک رسائی حاصل نہیں کر سکتا۔ آپ کو آؤٹ باؤنڈ یا ان باؤنڈ کنکشنز کی اجازت دینے کے لیے واضح قوانین شامل کرنے ہوں گے، تاکہ اندرونی سروسز کے حادثاتی طور پر ظاہر ہونے سے بچا جا سکے۔
  • Isolation levels – ایسا کنٹینر رن ٹائم منتخب کریں جو آپ کے خطرے کے برداشت کرنے کی صلاحیت (risk tolerance) کے مطابق ہو:
    • رفتار کے لیے Standard containers،
    • اضافی یوزر سپیس آئسولیشن لیئر کے لیے gVisor، یا
    • ہارڈ ویئر اسسٹڈ آئسولیشن کے لیے Kata Containers جو ایک ہلکی پھلکی VM کی طرح کام کرتا ہے۔
  • SDKs – Python اور Go کلائنٹ لائبریریز ڈویلپرز کو پروگراماتی طور پر سینڈ باکسز بنانے، کلیم کرنے اور ختم کرنے کی اجازت دیتی ہیں، جو AI سے چلنے والے پائپ لائنز کے ورک فلو کے عین مطابق ہے۔

کس کو فائدہ ہوگا، اور کون اس کی مخالفت کر سکتا ہے

خلاصہ

AI ایجنٹس کو ان کا اپنا ڈسپوزایبل Linux باکس دینے سے AI سے چلنے والی خودکاری (automation) کا سب سے بڑا غیر یقینی عنصر ختم ہو جاتا ہے: یہ خطرہ کہ تیار کردہ کوڈ ہوسٹ کو تباہ کر دے گا۔ Google Cloud کی مینیجڈ GKE Agent Sandbox اور کمیونٹی کے زیرِ انتظام kubernetes-sigs/agent-sandbox اس آئسولیشن کو کلاؤڈ نیٹیو اور آن پریم (on-prem) دونوں ماحول کے لیے عملی بناتے ہیں۔ وہ تنظیمیں جنہیں چستی (agility) اور سیکیورٹی کے درمیان توازن برقرار رکھنے کی ضرورت ہے، اب ان کے پاس AI سے تیار کردہ کوڈ کو ایک محفوظ سینڈ باکس میں رکھنے کے لیے ایک ٹھوس، Kubernetes-native ٹول موجود ہے۔