‏چرا microVM مشکل امنیت ایجنت رو حل نمی‌کنه

نویسنده (لوک هایندز) می‌گه گذاشتن یه ایجنت کدنویسی داخل یه microVM حس مسئولانه‌ای می‌ده: تو چند میلی‌ثانیه بالا میاد و از هاست ایزوله‌ست. ولی به گفتهٔ اون، «ایزوله بودن» دقیقاً همون چیزیه که برای نگرانی اصلی آدما کمترین اهمیتو داره. مشکل اینه که این روزها دو تا اصطلاح microVM و agent sandbox جوری با هم قاطی شدن که انگار یه چیزن، در حالی که این‌طوری حدود ۸۰٪ نگرانی‌های واقعی ایجنت‌ها روی میز نمی‌مونه.

یه microVM یه مرز مهمان/میزبان بهت می‌ده. سؤالی که جواب می‌ده اینه: آیا کدِ داخل این ماشین مجازی می‌تونه فرار کنه و به هاست یا بقیهٔ کاربرا آسیب بزنه؟ مدل تهدیدش یه مهمان خصمانه‌ست که می‌خواد از سخت‌افزار مجازی‌ش فرار کنه. microVMها تو این کار خیلی قوی‌ان و برای همینه که زیر پلتفرم‌های serverless که هزاران بار کاری بی‌اعتماد رو روی سخت‌افزار مشترک می‌ذارن، ازشون استفاده می‌شه.

ولی به گفتهٔ نویسنده یه agent sandbox به یه مرز دسترسی (capability boundary) نیاز داره. سؤالش فرق داره: این کد به‌جای من، با اعتبارنامه‌ها، کلیدهای SSH، فایل‌سیستم و توکن‌های کلاد من اجرا می‌شه؛ پس تهدید فرار نیست، چون از اول رو دارایی‌های باارزش نشسته. ایجنت جایی که گذاشتیش با همون سطح دسترسی خودت اجرا می‌شه و خطر همهٔ چیزیه که قانوناً می‌تونه بهش برسه.

نکته‌ای که آدما رو گیج می‌کنه اینه: تو باید یه چیزی به ایجنت بدی که روش کار کنه. ریپازیتوری‌ت، و اغلب یه سری اعتبارنامه، چون ایجنت باید branch پوش کنه یا API صدا بزنه. مثلاً git برای پوش به ssh نیاز داره و اون به کلیدهای ~/.ssh دسترسی داره. لحظه‌ای که این‌ها رو mount می‌کنی، داخل همون مرز کنار ایجنت‌ان. برای hypervisor، «ایجنت ریپو رو می‌خونه» و «ایجنت فایل .env کنار ریپو رو می‌خونه و به یه webhook بیرون می‌فرسته» یه جور رویدادن؛ هیچ‌کدوم فرار نیست چون داده از اول داخل بوده.

نویسنده تأکید می‌کنه بیشتر وقتا اصلاً مهاجمی در کار نیست. آسیبی که یه ایجنت کدنویسی می‌زنه معمولاً بدخواهانه نیست؛ دیتابیس production رو پاک می‌کنه یا یه راز رو تو یه issue عمومی می‌ذاره چون کارو اشتباه فهمیده یا یه میان‌بر بیش‌ازحد مطمئن زده. این یه پروسهٔ توانای خوش‌نیته که با دسترسی و اعتبارنامهٔ واقعی، با اطمینان اشتباه می‌کنه؛ یه شکل مسئلهٔ کاملاً متفاوت با مدل مهمان خصمانه‌ای که microVM براش طراحی شده.

مسئلهٔ عمیق‌تر واحد ایزوله‌سازیه. یه microVM یه ماژول رو در سطح دیسک و ایمیج کامل ایزوله می‌کنه؛ همه‌یا‌هیچه. هیچ راه طبیعی‌ای نیست که بگی «این بار کاری فقط src/ رو بخونه ولی secrets/ رو نه، فقط به api.github.com وصل شه و ~/.aws براش ممنوعه». این جمله در لایهٔ hypervisor بیان‌شدنی نیست، چون hypervisor داره یه ماشین مجازی رو تماشا می‌کنه، نه باز شدن فایل‌ها یا اتصال‌های خروجی رو.

جمع‌بندی صادقانهٔ نویسنده اینه که این لایه‌ها مکمل هم‌ان، نه جایگزین. ایجنتو هم تو یه microVM بذار (تا از هاست فرار نکنه) و هم دسترسی‌هاشو داخل همون VM محدود کن. یه capability sandbox مثل ابزار متن‌باز nono.sh کارهایی می‌کنه که hypervisor اصلاً سراغش نمی‌ره: تصمیم مسیر‌به‌مسیر روی فایل‌ها، تصمیم دامنه‌به‌دامنه روی شبکه، نگه نداشتن خودِ اعتبارنامه توسط ایجنت، و یه لاگ ممیزی که خودِ ایجنت نتونه توش بنویسه.

نکات کلیدی:

• microVM یه مرز مهمان/میزبانه و جلوی فرار کد از VM به هاست رو می‌گیره
• تهدید اصلی ایجنت فرار نیست؛ ایجنت با دسترسی و کلیدهای خودت اجرا می‌شه و همون داخل جعبه می‌تونه خرابکاری کنه
• بیشتر آسیب‌ها بدخواهانه نیستن؛ ایجنت خوش‌نیت با اطمینان اشتباه می‌کنه
• capability boundary تصمیم مسیر‌به‌مسیر و دامنه‌به‌دامنه می‌گیره، چیزی که hypervisor نمی‌بینه
• بهترین کار ترکیب هر دو لایه‌ست: microVM برای فرار، sandbox دسترسی برای محدود کردن دامنهٔ خسارت