سه سال پیش، ساتیا نادلا گفت عاملهای هوش مصنوعی میتوانند «مثل یک ویروس» در سازمانها گسترش پیدا کنند. در Microsoft Build 2026، مایکروسافت پاسخ خودش به این نگرانی را معرفی کرد: Execution Containers (MXC) — یک لایه runtime که مشخص میکند هر عامل دقیقاً به چه چیزی دسترسی دارد، و هیچ چیز بیشتر.
۱. از تهدید تا راهحل: چرخش مایکروسافت
برای فهمیدن MXC، باید زمینه تاریخی آن را بدانیم. در سال ۲۰۲۳، ساتیا نادلا در یک مصاحبه گفت نگران است که عاملهای هوش مصنوعی بتوانند مثل یک ویروس در شبکههای سازمانی گسترش پیدا کنند — دسترسیهای بیش از حد، تصمیمات خودکار در سیستمهای حساس، و بدون هیچ مکانیزم نظارتی.
این نگرانی آن زمان نظری به نظر میرسید. اما در ۲۰۲۵، با رشد انفجاری فریمورکهایی مثل OpenClaw و AutoGPT و Agents SDKهای مختلف، سازمانهای IT واقعاً با این سوال مواجه شدند: «چطور میتوانیم به یک عامل هوش مصنوعی اجازه استفاده از Microsoft 365 بدهیم بدون اینکه به همه دادههای سازمان دسترسی داشته باشد؟»
Docker و containerهای Linux پاسخ آشنایی بودند در دنیای سرور. اما برای Windows desktop و محیطهای سازمانی که نمیتوانستند یک VM لینوکسی راه بیندازند، نیاز به چیز متفاوتی بود. MXC پاسخ مایکروسافت است: یک لایه containment که بومی ویندوز است، سبک است، و با مدیریت سیاست سازمانی ادغام میشود.
۲. معماری MXC: چطور کار میکند
MXC در هستهی خود یک Policy Engine است که در سطح kernel ویندوز اعمال میشود. برخلاف مکانیزمهای قدیمیتر مثل AppLocker که فقط روی اجرای فایلهای exe کنترل میکند، MXC یک نمای جامعتر از «دسترسی» دارد:
File System Policy: مشخص میکند کدام pathها قابل خواندن، نوشتن، یا اجرا هستند. میتوانید با دقت بگویید: «عامل فقط میتواند در C:Users{user}AgentWorkspace بنویسد، میتواند C:Users{user}Documents را بخواند، و به بقیه filesystem هیچ دسترسیای ندارد.»
Network Policy: مشخص میکند عامل میتواند به کدام hostها و پورتها متصل شود. مثلاً: «فقط api.openai.com:443 و graph.microsoft.com:443 مجاز هستند. هر اتصال دیگری مسدود است.»
Registry Policy: دسترسی به registry ویندوز را کنترل میکند — میتواند به HKCUSoftwareAgentData بنویسد اما به بقیه registry نه.
Process Policy: عامل میتواند چه فرآیندهایی را اجرا کند؟ این مهمترین کنترل است — میتوانید اجرای هر فرآیندی را ممنوع کنید مگر یک allowlist مشخص.
«MXC اصل حداقل دسترسی را به عاملهای هوش مصنوعی میبرد. درست مثل اینکه به یک کارمند جدید میگویید کدام کابینتها را میتواند باز کند، نه اینکه کلید همه جا را بدهید.» — Scott Guthrie، EVP Microsoft Cloud + AI، Build 2026
پیادهسازی فنی MXC بر اساس Windows Job Objects (یک مکانیزم قدیمی اما قدرتمند ویندوز) با یک لایه policy جدید است. این به این معناست که overhead بسیار کمتر از یک VM است — مایکروسافت ادعا میکند overhead CPU کمتر از ۲٪ است در مقایسه با اجرای بدون sandbox.
۳. کانتینر بدون داکر: مزایای رویکرد ویندوز
سوال طبیعی اینجاست: چرا از Docker for Windows استفاده نکنیم؟ Docker یک راهحل شناختهشده و پرمستند است. چرا MXC؟
Docker for Windows در محیطهای desktop چند مشکل دارد که IT departments را عصبانی میکند: نیازمند WSL2 (Windows Subsystem for Linux 2)، که خودش یک لایه VM لینوکسی است — این overhead قابلتوجهی دارد. همچنین مدیریت permissionها بین container لینوکسی و filesystem ویندوزی پیچیده است و با Azure AD و Active Directory بهخوبی ادغام نمیشود. برای استقرار در مقیاس در سازمانهای بزرگ نیازمند ابزارهای مدیریت جداگانه است.
MXC این مشکلات را با رویکرد native حل میکند:
از Intune (سرویس مدیریت دستگاه Microsoft) میتوان policy های MXC را بهصورت مرکزی توزیع کرد — همان ابزاری که IT departments برای مدیریت ویندوز استفاده میکنند. هیچ ابزار جدیدی لازم نیست. Policy های MXC با Azure AD ادغام میشوند — میتوانید بگویید کاربران عضو گروه «AI Power Users» به یک policy کمتر محدود دسترسی دارند و کاربران معمولی به policy سختگیرانهتری.
اگرچه MXC در ویندوز بومی است، مایکروسافت یک معادل لینوکسی هم ارائه داده — MXC for Linux — که بر اساس seccomp و Linux namespaces کار میکند و برای Azure Container Apps قابل استفاده است.
MXC: Native Windows | Overhead کم | ادغام با Intune/Azure AD | فقط ویندوز ۱۱
Docker for Windows: کراسپلتفرم | overhead بیشتر | نیازمند WSL2 | ecosystem بزرگتر
App Container: مکانیزم قدیمی | محدودیتهای کمتر از MXC | عمدتاً برای UWP apps
Hyper-V Isolation: قویترین ایزولاسیون | overhead بالاتر | برای workloads حساس
۴. OpenClaw Companion: رابط WinUI 3
همزمان با معرفی MXC، مایکروسافت یک اپلیکیشن رسمی به نام OpenClaw Windows Companion معرفی کرد. این اپلیکیشن که با WinUI 3 (مدرنترین فریمورک UI ویندوز) ساخته شده، یک رابط گرافیکی native برای مدیریت یک instance محلی OpenClaw فراهم میکند.
این همکاری جالب است چون OpenClaw یک پروژه متنباز مستقل است و هیچ وابستگی رسمی به مایکروسافت ندارد. اما مایکروسافت تصمیم گرفت به جای ساخت فریمورک عامل رقیب، روی قابلیت اجرای امن OpenClaw روی ویندوز سرمایهگذاری کند — یک اعتراف غیرمستقیم به اینکه OpenClaw استاندارد de facto شده است.
OpenClaw Companion امکانات زیر را فراهم میکند:
مدیریت مهارتها: رابط گرافیکی برای مشاهده، فعال/غیرفعال کردن، و ویرایش SKILL.md فایلها. کاربران غیرفنی میتوانند بدون کار با terminal مهارتها را مدیریت کنند.
Policy Editor: یک ویرایشگر بصری برای ساخت policy های MXC — بدون نیاز به نوشتن YAML دستی. کاربر میتواند با checkbox ها مشخص کند عامل به کدام پوشهها و سرویسها دسترسی دارد.
Activity Log: داشبورد real-time که نشان میدهد عامل در هر لحظه چه ابزاری استفاده کرده، چه فایلی خوانده یا نوشته، و چه APIهایی فراخوانی کرده.
Skill Marketplace: ادغام با کتابخانه مهارتهای OpenClaw — میتوانید مهارتهای جامعه را مستقیماً از داخل Companion نصب کنید، با بررسی security rating هر مهارت قبل از نصب.
۵. Agent 365: اتصال به Microsoft 365
یکی از کاراییترین بخشهای OpenClaw Companion، قابلیت Agent 365 است — یک سری مهارت رسمی که با دادههای Microsoft 365 کار میکنند: Outlook، Teams، Calendar، OneDrive، و SharePoint.
مهمترین نکته: Agent 365 از Microsoft Graph API استفاده میکند و هر عملیات محدود به سطوح دسترسی تعریفشده در Azure AD است. عامل نمیتواند به هیچ دادهای دسترسی داشته باشد که کاربر انسانی به آن دسترسی ندارد.
چند مهارت Agent 365 که در Companion از همان ابتدا وجود دارند:
Email Summarizer: ایمیلهای دریافتی را خلاصه و دستهبندی میکند. میتوانید از تلگرام بخواهید «ایمیلهای مهم امروز را بده» و خلاصه Outlookتان را در تلگرام دریافت کنید.
Meeting Prep: قبل از هر جلسه Teams، اطلاعات مرتبط از OneDrive و ایمیلهای قبلی با همان شرکتکنندگان را جمعآوری و خلاصه میکند.
Action Item Tracker: پس از جلسات Teams، transcript را تحلیل میکند، action item ها را استخراج میکند، و به عنوان task در Planner یا To-Do ثبت مینماید.
۶. پیادهسازی: نوشتن سیاست MXC اول
برای توسعهدهندگانی که میخواهند MXC را در پروژههای خود استفاده کنند، مایکروسافت یک SDK ارائه داده است. یک فایل policy.yaml برای یک عامل که فقط محتوای وب میخواند و در یک پوشه خاص مینویسد به این صورت است:
در بخش filesystem، دو ورودی دارید: مسیر AgentWorkspace با دسترسی read-write و مسیر Documents با دسترسی read-only. در بخش network، فقط دو domain مجاز هستند: api.openai.com و graph.microsoft.com. در بخش process، اجرا ممنوع است مگر برای node.exe. در بخش registry، فقط HKCUSoftwareMyAgent قابل دسترسی است.
بعد از نوشتن این فایل، برای اجرای یک فرآیند با این policy از MXC SDK استفاده میکنید. هر تلاشی برای خواندن خارج از Documents یا نوشتن خارج از AgentWorkspace، یا اتصال به هر domain دیگری، در سطح kernel مسدود میشود و یک audit log ایجاد میکند.
مقایسه مکانیزمهای ایزولهسازی عاملهای AI در ویندوز
با گسترش استفاده از عاملهای هوش مصنوعی در محیطهای سازمانی، انتخاب مکانیزم containment مناسب به یک تصمیم حیاتی تبدیل شده است. هر مکانیزم نقاط قوت و ضعف خاص خود را دارد و انتخاب نادرست میتواند به مشکلات امنیتی یا عملکردی منجر شود. در ادامه چهار گزینه اصلی برای ایزولهسازی عاملهای AI در ویندوز را مقایسه میکنیم.
| مکانیزم | نوع | overhead | مدیریت سازمانی |
|---|---|---|---|
| MXC | بومی ویندوز | کمتر از ۲٪ | Intune و Azure AD |
| Docker for Windows | لینوکسی (WSL2) | متوسط تا بالا | ابزارهای جداگانه |
| App Container | بومی (قدیمی) | کم | عمدتاً برای UWP |
| Hyper-V Isolation | مجازیسازی | بالا | برای محیطهای حساس |
MXC بهترین تعادل را بین امنیت و کارایی برای سناریوهای desktop سازمانی ارائه میدهد. overhead کم (زیر ۲٪)، ادغام بومی با ابزارهای مدیریت مایکروسافت و کنترل دقیق چهارلایه بر دسترسیها، آن را به انتخاب اصلی برای استقرار عاملهای AI در محیطهای Windows 11 سازمانی تبدیل کرده است.
نتیجهگیری: MXC و آینده استقرار سازمانی عاملهای AI
MXC نشان میدهد که مایکروسافت یک چرخش استراتژیک انجام داده است: از «عاملهای AI خطرناک هستند» به «عاملهای AI میتوانند امن باشند اگر containment درست داشته باشند». این چرخش مهم است چون مایکروسافت یکی از بزرگترین فروشندگان نرمافزار سازمانی است و موضع آن بر سیاستگذاری IT در هزاران سازمان تأثیر میگذارد.
برای توسعهدهندگانی که روی ابزارهای مبتنی بر OpenClaw برای محیطهای سازمانی کار میکنند، MXC یک فرصت است: اکنون میتوانند به IT departments بگویند «عامل ما فقط به این لیست محدود از منابع دسترسی دارد، و این را میتوانید در Intune audit کنید.» این پیام بسیار قابلقبولتر از «به عامل هوش مصنوعی ما اعتماد کنید» است. و در دنیای enterprise، قابلیت audit و کنترل اغلب مهمتر از قابلیتهای خود سیستم است.
پرسشهای پرتکرار
MXC در ویندوز ۱۱ چیست؟
Microsoft Execution Containers یا MXC یک لایه امنیتی بومی ویندوز ۱۱ است که عاملهای هوش مصنوعی را در یک sandbox کنترلشده اجرا میکند. این فناوری مشخص میکند که هر عامل دقیقاً به چه فایلها، شبکه، رجیستری و فرآیندهایی دسترسی دارد و هیچ چیز بیشتر. MXC در ویندوز ۱۱ نسخه ۲۴H2 و Windows Server 2025 در دسترس است.
تفاوت MXC و Docker چیست؟
Docker نیازمند WSL2 و یک لایه VM لینوکسی است که overhead بالاتری دارد و با Azure AD و Active Directory بهخوبی ادغام نمیشود. در مقابل، MXC کاملاً بومی ویندوز است، با Intune و Azure AD ادغام میشود و overhead CPU کمتر از ۲٪ دارد. همچنین MXC مخصوص عاملهای AI طراحی شده درحالیکه Docker یک پلتفرم عمومی container است.
چگونه MXC امنیت عاملهای هوش مصنوعی را در ویندوز تأمین میکند؟
MXC از یک Policy Engine در سطح kernel استفاده میکند که چهار نوع دسترسی را کنترل میکند: فایلسیستم (کدام مسیرها قابل خواندن و نوشتن هستند)، شبکه (کدام host و پورتها مجازند)، رجیستری ویندوز و اجرای فرآیندها. سازمانها میتوانند این policy ها را از طریق Intune بهصورت مرکزی توزیع و مدیریت کنند.
OpenClaw Companion در ویندوز ۱۱ چیست؟
OpenClaw Companion یک اپلیکیشن رسمی مایکروسافت است که با WinUI 3 ساخته شده و یک رابط گرافیکی برای مدیریت نمونه محلی OpenClaw فراهم میکند. این ابزار شامل مدیریت مهارتها، یک Policy Editor بصری برای ساخت policy های MXC بدون نوشتن YAML، و یک داشبورد Activity Log برای مشاهده عملکرد لحظهای عامل است.