چهار غول فناوری در یک فصل راهکارهای اجرای امن کدهای هوش مصنوعی را روانه بازار کرده‌اند، اما رویکرد هیچ‌کدام شبیه به دیگری نیست. Google Cloud اوایل این ماه و در جریان کنفرانس WeAreDevelopers در برلین اعلام کرد که سندباکس‌های (Sandboxes) Cloud Run را برای دسترسی عمومی منتشر کرده است. این حرکت تنها چند هفته پس از عرضه سرویس مشابه توسط AWS انجام شد و به یک پرسش بنیادین پاسخ می‌دهد: کدهایی که یک عامل هوشمند (Agent) همین حالا تولید کرده است، دقیقاً باید در کجا و چگونه اجرا شوند؟

ورود دو ابرساختار بزرگ به این عرصه، حلقه مفقوده را پر می‌کند. اکنون هر چهار سرویس‌دهنده اصلی یعنی AWS، گوگل، Microsoft Azure و Cloudflare امکان اجرای ایزوله کد را به‌عنوان یک قابلیت بومی ارائه می‌دهند؛ اما زیرساخت‌های ایزوله‌سازی و مدل‌های چرخه حیات آن‌ها تفاوت‌های معماری عمیقی با یکدیگر دارند.

چهار پلتفرم، چهار تکنولوژی متفاوت برای ایزوله‌سازی

محصولی که این شرکت‌ها می‌فروشند یک شکل است: شما یک کد نامعتبر یا تولیدشده توسط هوش مصنوعی را به آن‌ها می‌سپارید تا پلتفرم آن را در یک فضای کاملاً ایزوله از برنامه اصلی اجرا کند. با این حال، در مورد اینکه مرز امنیتی باید در کدام لایه قرار گیرد، تضادهای جدی وجود دارد:

  • Amazon Web Services: سندباکس‌های Lambda MicroVM را بر پایه تکنولوژی Firecracker بنا کرد. این روش به هر نشست یک ماشین مجازی اختصاصی با حداکثر 8 ساعت زمان اجرا و یک چرخه تعلیق و ازسرگیری می‌دهد که اطلاعات حافظه، دیسک و پردازش‌های در حال اجرا را حفظ می‌کند.
  • Google Cloud: رویکردی دوگانه را انتخاب کرد. از یک‌سو از رهگیری هسته gVisor برای سندباکس عامل GKE استفاده کرد و از سوی دیگر، با به‌روزرسانی Cloud Run یک مرز اجرای سبک و ایزوله را درون نمونه‌های (Instances) فعلی اضافه کرد.
  • Microsoft Azure: پیشگام این الگو بود. نشست‌های پویای Azure Container Apps از سال 2024 بر پایه مرزهای Hyper-V اجرا می‌شوند. مایکروسافت اعلام کرد که سرویس Copilot به‌تنهایی روزانه بیش از 400,000 نشست از این نوع را مصرف می‌کند.
  • Cloudflare: سندباکس‌های خود را بر فراز سرویس Containers ساخت. هر سندباکس در یک ماشین مجازی اختصاصی ایزوله شده و کنترل آن از طریق Workers و Durable Objects انجام می‌گیرد.
مقایسه معماری سندباکس‌های ابری در AWS، گوگل، آژور و کلودفلر

سندباکس در گوگل تبدیل به یک پرچم ساده شد

در پیاده‌سازی Cloud Run، این تغییر بسیار ملموس است. با اضافه کردن پرچم --sandbox-launcher در دستور استقرار، یک فایل باینری در مسیر کانتینر مونت شده و برنامه از طریق یک فراخوان فرعی (Subprocess) آن را اجرا می‌کند. گوگل برای این ویژگی هزینه اضافی دریافت نمی‌کند، زیرا سندباکس‌ها مستقیماً از همان پردازنده و حافظه رم درگیرِ نمونه اصلی استفاده می‌کنند. در یک آزمایش عملی، یک سرویس توانست 1000 سندباکس را با میانگین زمان 500 میلی‌ثانیه برای هر مورد، راه‌اندازی، اجرا و متوقف کند.

توسعه‌دهندگان پیش از این مجبور بودند برای مدیریت کدهای غیرقابل اعتماد، زیرساخت‌های پیچیده‌ای روی خوشه‌های کانتینری بسازند یا برای محیط‌های اجرای MicroVM شخص ثالث هزینه‌های گزاف بپردازند. عرضه سرویس‌های مدیریت‌شده توسط این چهار غول، هرچند با قیمت‌گذاری و بسته‌بندی متفاوت، شکاف بزرگی را در بازار پر کرده است.

مرزهای امنیتی جایگزین لایه‌های حاکمیتی نمی‌شوند

یک ماشین مجازی Firecracker صرفاً کدهای تولیدشده را از میزبان و سایر نشست‌ها جدا می‌کند، اما هیچ دخالتی در نحوه استفاده آن کد از اعتبارنامه‌هایی (Credentials) که توسعه‌دهنده در اختیارش قرار داده ندارد. در واقع، ایزوله‌سازی تنها یک مرز مهار (Containment Boundary) است و حل مسائل حاکمیتی دسترسی به شبکه را حل نمی‌کند. این مرز تعیین می‌کند که چقدر می‌توانید به عامل‌های هوشمند خودمختاری بدهید و ارزان‌ترین بخش از کل معادله امنیت محسوب می‌شود.

محدودیت‌های خاص هر پلتفرم نیز کاملاً پابرجا هستند. ماشین‌های مجازی AWS تنها روی پردازنده‌های Graviton در 5 منطقه جغرافیایی اجرا می‌شوند و زمان آن‌ها حداکثر 8 ساعت است. از سوی دیگر، سندباکس‌های گوگل با سرویس والد خود بر سر منابع رقابت می‌کنند و یک اسکریپت غیرقابل کنترل می‌تواند کل سرویس تولیدکننده را فلج کند.

با وجود اینکه تمامی شرکت‌های ابری حالا روی این موضوع توافق دارند که عامل‌های هوش مصنوعی نباید کدها را مستقیماً روی سیستم میزبان اجرا کنند، اما بحث و رقابت به سرعت به سمت موضوع جدیدی تغییر مسیر داده است: اینکه چه کسی و با چه ابزاری قرار است رفتار کدهای ایزوله‌شده را پس از اجرا، مدیریت و نظارت کند.