Google Cloud একটি managed GKE Agent Sandbox সার্ভিস চালু করেছে, অন্যদিকে open-source kubernetes-sigs/agent-sandbox প্রজেক্টটি যেকোনো Kubernetes ক্লাস্টারে একই সক্ষমতা নিয়ে আসে। উভয়ই ডেভেলপারদের AI এজেন্টদের জন্য একটি disposable Linux container প্রদান করে, যা বাকি অবকাঠামোকে (infrastructure) অক্ষত রাখে।

কেন AI-জেনারেটেড কোডের জন্য একটি playpen প্রয়োজন

আধুনিক AI এজেন্টরা শুধু প্রশ্নের উত্তরই দেয় না। তারা স্ক্রিপ্ট লেখে, ওয়েব ব্রাউজ করে, shell command চালায় এবং এমনকি ওয়েব সার্ভিসও চালু করে। এই ক্ষমতা একটি সিকিউরিটি গ্যাপ তৈরি করে: তাদের তৈরি করা কোড ত্রুটিপূর্ণ (buggy), ক্ষতিকারক (malicious) বা অতিরিক্ত আক্রমণাত্মক হতে পারে। একটি এজেন্ট যদি অনুমতি ছাড়া rm -rf / চালায় বা কোনো ইন্টারনাল ডেটাবেসের সাথে কানেক্ট হয়, তবে তা পুরো সিস্টেমকে ঝুঁকির মুখে ফেলতে পারে।

একটি sandbox প্রতিটি এজেন্টকে তার নিজস্ব কন্টেইনারে—একটি ক্ষুদ্র, ফেলে দেওয়া যায় এমন (throw-away) ভার্চুয়াল মেশিনে—আলাদা করে রাখে। যদি এজেন্টটি ভুল আচরণ করে, তবে ক্ষতি শুধুমাত্র সেই কন্টেইনারের মধ্যেই সীমাবদ্ধ থাকে; হোস্ট এবং অন্যান্য workloads নিরাপদ থাকে। নতুন GKE অফার এবং কমিউনিটি-চালিত প্রজেক্টটি এই ধারণাকে একটি ready-to-use সার্ভিসে রূপান্তরিত করেছে।

sandbox পাওয়ার দুটি উপায়

  • GKE Agent Sandbox – Google Cloud গ্রাহকদের জন্য একটি fully managed সার্ভিস।
  • kubernetes-sigs/agent-sandbox – যেকোনো Kubernetes ক্লাস্টারের জন্য একটি open-source প্রজেক্ট।

উভয়ই একই কোর আর্কিটেকচার শেয়ার করে, যা স্ট্যান্ডার্ড Kubernetes primitives-এর ওপর ভিত্তি করে তৈরি।

সিস্টেমটি কীভাবে গঠিত হয়

Component Role
Sandbox একটি isolated container যা এজেন্টের কোড চালায়। প্রয়োজনে এর একটি stable name এবং persistent storage থাকে।
SandboxTemplate একটি blueprint যা container image এবং security policies নির্ধারণ করে—নতুন sandbox তৈরির একটি রেসিপি।
SandboxClaim একটি নির্দিষ্ট template থেকে sandbox চালু করার জন্য এজেন্ট (বা তার controller) দ্বারা ইস্যু করা একটি রিকোয়েস্ট।
SandboxWarmPool আগে থেকে তৈরি করা sandbox-এর একটি পুল যা তাৎক্ষণিকভাবে ব্যবহারের জন্য প্রস্তুত। কন্টেইনারগুলোকে 'warm' রাখলে প্রতিবার ইমেজ পুল করা এবং নতুন pod শুরু করার কারণে সৃষ্ট latency এড়ানো যায়।

যখন কোনো এজেন্টের একটি এনভায়রনমেন্ট প্রয়োজন হয়, তখন এটি একটি SandboxClaim পোস্ট করে। কন্ট্রোলার warm pool পরীক্ষা করে, একটি idle sandbox বেছে নেয় এবং সেটিকে claim-এর সাথে যুক্ত করে। যদি পুল খালি থাকে, তবে এটি template থেকে একটি নতুন sandbox তৈরি করে; অন্যথায়, এই প্রক্রিয়াটি মিলিসেকেন্ডের মধ্যে সম্পন্ন হয়।

সিকিউরিটি কন্ট্রোল (Security knobs) যা আপনি ব্যবহার করতে পারেন

  • Default-deny networking – ডিফল্টভাবে একটি sandbox ইন্টারনাল নেটওয়ার্কে পৌঁছাতে পারে না। আউটবাউন্ড বা ইনবাউন্ড কানেকশন অ্যালাউ করার জন্য আপনাকে সুনির্দিষ্ট রুলস যোগ করতে হবে, যা ইন্টারনাল সার্ভিসগুলোর আকস্মিক প্রকাশ (exposure) রোধ করে।
  • Isolation levels – আপনার রিস্ক টলারেন্স অনুযায়ী সঠিক container runtime বেছে নিন:
    • দ্রুত গতির জন্য Standard containers,
    • অতিরিক্ত user-space isolation লেয়ারের জন্য gVisor, অথবা
    • হার্ডওয়্যার-অ্যাসিস্টেড আইসোলেশনের জন্য Kata Containers, যা একটি lightweight VM-এর মতো কাজ করে।
  • SDKs – Python এবং Go ক্লায়েন্ট লাইব্রেরি ডেভেলপারদের প্রোগ্রামাটিকভাবে sandbox তৈরি, claim এবং ধ্বংস করার সুবিধা দেয়, যা AI-চালিত পাইপলাইনের কাজের সাথে সামঞ্জস্যপূর্ণ।

কারা উপকৃত হবে এবং কারা এর বিরোধিতা করতে পারে

মূল কথা (Bottom line)

AI এজেন্টদের নিজস্ব disposable Linux box প্রদান করা AI-চালিত অটোমেশনের সবচেয়ে বড় অনিশ্চয়তা দূর করে: অর্থাৎ জেনারেটেড কোড হোস্টকে ক্ষতিগ্রস্ত করার ঝুঁকি। Google Cloud-এর managed GKE Agent Sandbox এবং কমিউনিটি-চালিত kubernetes-sigs/agent-sandbox ক্লাউড-নেটিভ এবং অন-প্রেম (on-prem) উভয় এনভায়রনমেন্টের জন্যই এই আইসোলেশনকে ব্যবহারযোগ্য করে তুলেছে। যেসব প্রতিষ্ঠানকে চপলতা (agility) এবং নিরাপত্তার মধ্যে ভারসাম্য বজায় রাখতে হয়, তাদের কাছে এখন AI-জেনারেটেড কোডকে একটি sandboxed playpen-এ রাখার জন্য একটি সুনির্দিষ্ট, Kubernetes-native টুল রয়েছে।