‏MXC: سندباکس بومی مایکروسافت برای کد ایجنت‌ها

وقتی یه ایجنت تصمیم می‌گیره کد اجرا کنه، اون کد کجا اجرا می‌شه و به چی دسترسی داره؟ نویسنده می‌گه هر فروشنده‌ی ایجنت کدنویسی الان یه جواب برای این سؤال داره: Codex CLI از OpenAI با ابزارهای بومی سیستم‌عامل (مثل Seatbelt مک و Landlock لینوکس) ایزوله می‌کنه، Claude Cowork از Anthropic ایجنت رو تو یه VM کامل لینوکس می‌ذاره، و سرویس‌های میزبانی‌شده مثل GKE Agent Sandbox گوگل کار رو تو VM یا کانتینر می‌پیچن. ولی تا حالا هیچ سازنده‌ی سیستم‌عاملی یه راه‌حل بومی نداده بود.

تو Build 2026، مایکروسافت پروژه‌ی MXC (مخفف Microsoft eXecution Container) رو با لایسنس MIT اوپن‌سورس کرد؛ به گفته‌ی خودشون «یه سیستم سندباکس برای اجرای کد ناامن — خروجی مدل، پلاگین، ابزار — روی ویندوز، لینوکس و مک». نویسنده می‌گه این بار برخلاف معمول لازم نبوده چیزی رو مهندسی معکوس کنن، چون همه‌چیز رو خود مایکروسافت گذاشته جلوی چشم. یه نکته‌ی مهم هم اینه که README خودش گفته این نسخه preview اولیه‌ست و فعلاً هیچ پروفایلی نباید به‌عنوان مرز امنیتی واقعی در نظر گرفته بشه.

اگه قاب ایجنتی رو کنار بذاریم، MXC در اصل سه‌تا چیزه: یه باینری بومی واحد (مثلاً wxc-exec.exe روی ویندوز)، یه فایل کانفیگ JSON نسخه‌دار که دستور و پالیسی (مسیرهای فقط-خواندنی/خواندنی-نوشتنی/ممنوع، وضعیت شبکه، محدودیت‌های UI) رو توصیف می‌کنه، و یه SDK تایپ‌اسکریپتی که این کانفیگ‌ها رو می‌سازه. باینری کانفیگ رو می‌خونه، یه بک‌اند مهارسازی انتخاب می‌کنه، پالیسی رو به زبون بومی اون بک‌اند ترجمه می‌کنه و دستورو اجرا می‌کنه.

انتخاب بک‌اند با یه match ساده روی فیلد containment انجام می‌شه و ده گزینه داره. مهم‌ترینش processcontainerـه که پیش‌فرض و تنها بک‌اند پایدار روی ویندوزه و موقع اجرا به یکی از سه لایه‌ی ایزوله‌سازی می‌رسه. بقیه — مثل Windows Sandbox، میکرو-VM روی WSL2، Hyperlight و Seatbelt مک — همه آزمایشی هستن. روی لینوکس هم bubblewrap پیش‌فرض و پایداره.

بک‌اند پیش‌فرض همه‌چی رو با یه هویت امنیتی شروع می‌کنه: با CreateAppContainerProfile یه پروفایل ثبت می‌کنه و یه package SID پایدار می‌گیره، طوری که یه اسم کانتینر همیشه به یه principal ثابت برسه. این SID لنگرگاه همه‌چیزه — هم قوانین فایروال و هم ACEهای فایل‌سیستم بهش هدف‌گیری می‌شن. AppContainerها عملاً با هیچ دسترسی‌ای شروع می‌شن و capabilityها بهشون دسترسی خاص می‌دن:

let mut capabilities_to_add: Vec<String> = request.policy.capabilities.clone();
capabilities_to_add.push("AgenticAppContainer".to_string());

نویسنده توضیح می‌ده که محدودیت‌های بیشتری هم لایه‌لایه روی همین فرایند سوار می‌شن: حالت LPAC برای کم‌کردن سطح دسترسی، غیرفعال‌کردن فراخوانی‌های سیستمی Win32k برای بستن سطح حمله‌ی win32k.sys، و محدودیت‌های UI مثل دسترسی به کلیپ‌بورد و دسکتاپ که از طریق یه Job Object اعمال می‌شن. نکته‌ی ظریف اینه که فرایند فرزند معلق (suspended) ساخته می‌شه و فقط بعد از وصل‌شدن Job Object از حالت تعلیق درمیاد، پس محدودیت‌ها قبل از اولین دستور کد اجرا می‌شن.

برای فایل‌سیستم سه لایه وجود داره: لایه‌ی اول کل کار رو با یه فراخوانی به API بومی سیستم‌عامل می‌سپره، لایه‌ی دوم از یه بروکر به اسم Brokered File System استفاده می‌کنه که دسترسی فایل رو موقع اجرا میانجی‌گری می‌کنه، و لایه‌ی سوم مستقیم روی هر آبجکت NTFS میزبان یه ACE مهر می‌زنه. شبکه هم از طریق Windows Firewall کنترل می‌شه و نکته‌ی کلیدیش اینه که هر قانون با SetLocalAppPackageId به همون package SID گره می‌خوره، پس فقط روی ترافیک همون پکیج سندباکس‌شده اعمال می‌شه نه کل ماشین.

نکات کلیدی:

• MXC ابزار بومی و اوپن‌سورس (لایسنس MIT) مایکروسافت برای اجرای کد ناامن مدل‌ها و ابزارها تو سندباکسه و روی ویندوز، لینوکس و مک کار می‌کنه
• ساختارش سه‌تا چیزه: یه باینری بومی، یه پالیسی JSON و یه SDK تایپ‌اسکریپتی؛ خود باینری بک‌اند مناسبو انتخاب و پالیسی رو ترجمه می‌کنه
• ده بک‌اند مهارسازی داره؛ processcontainer روی ویندوز و bubblewrap روی لینوکس پایدارن، بقیه آزمایشی
• بک‌اند ویندوز با package SID پایدار، capabilityها، قفل Win32k و Job Object، محدودیت‌ها رو قبل از اجرای اولین دستور فعال می‌کنه
• خود مایکروسافت تأکید کرده این نسخه preview اولیه‌ست و فعلاً نباید پروفایل‌هاشو مرز امنیتی واقعی دونست