OpenShell انویدیا: قرنطینهٔ ایجنت‌های هوش مصنوعی در سطح کرنل
هوش مصنوعیخلاصهٔ کامل‌تر
انویدیا در GTC 2026 پروژهٔ OpenShell رو منتشر کرد؛ یک رانتایم اوپن‌سورس که ایجنت‌های خودمختار AI رو با سیاست در سطح کرنل سندباکس می‌کنه: به چه فایل‌هایی دست بزنن، چه پروسه‌هایی اجرا کنن و ترافیکشون کجا بره. نویسندهٔ این مطلب که از تیم Tigera هست، اون رو کار مهندسی جدی‌ای می‌دونه که یک ادعای قدیمی خودشون رو تأیید می‌کنه: امنیت ایجنت به محیط تعلق داره، نه به پرامپت.
استدلال پشت این حرف ساده‌ست. بیشتر تلاش‌ها برای کنترل ایجنت‌ها یا در لایهٔ مدل انجام میشه (هم‌راستاسازی، پرامپت سیستمی) یا در لایهٔ اپلیکیشن (کتابخانه‌های گاردریل، فیلتر خروجی). هر دو یک ایراد مشترک دارن: چیزی که داره امن میشه، همون چیزیه که داره امنیت رو اعمال می‌کنه. ایجنتی که به‌قدر کافی گیج یا به‌قدر کافی آلوده باشه، می‌تونه با حرف‌زدن از دستورهای خودش رد بشه. OpenShell کنترل رو جایی می‌ذاره که ایجنت نمی‌تونه سرش چونه بزنه.
از نظر فنی، OpenShell رانتایم امن برای یک ایجنت روی یک ماشینه. با یک دستور نصب میشه و بعد ایجنت رو داخل سندباکس بالا میاری (چیزی شبیه openshell sandbox create). اون ایجنت — چه Claude Code و Codex و Cursor باشه، چه ایمیج کانتینر خودت — داخل محیطی ایزوله اجرا میشه که با یک سیاست اعلانی YAML و چهار لایه کنترل میشه.
چهار لایه این‌هان. فایل‌سیستم: کدوم مسیرها خواندنی یا نوشتنی‌ان، با Landlock و قفل‌شده موقع ساخت سندباکس. پروسه: کدوم باینری‌ها اجازهٔ اجرا دارن و کدوم syscallها در دسترس‌ان، با seccomp. شبکه: خروجی پیش‌فرض بسته‌ست و در سطح متد و مسیر HTTP رهگیری میشه. استنتاج: یک «Privacy Router» تصمیم می‌گیره هر فراخوانی به کدوم بک‌اند LLM بره تا زمینهٔ حساس روی مدل محلی بمونه؛ اعتبارنامه سر روتر جابه‌جا میشه، پس کلید واقعی API داخل سندباکس نمی‌شینه.
مدل تهدیدش هم دقیق انتخاب شده: ایجنت‌های طولانی‌مدت و خودتکامل‌یابنده که شل، اعتبارنامهٔ زنده و توانایی بازنویسی کد خودشون رو دارن — یعنی تزریق پرامپت، مهارت‌های آلودهٔ شخص ثالث، و ساب‌ایجنت‌هایی که مجوزهایی رو به ارث می‌برن که نباید. وقتی ایجنت به دیوار سیاست می‌خوره، می‌تونه تغییر سیاست پیشنهاد بده و انسان تأیید یا رد کنه. پروژه فعلاً آلفاست و روی مک، ویندوز با WSL 2 و لینوکس اجرا میشه.
نکتهٔ اصلی مقاله اینه که مستندات انویدیا صریح می‌گن OpenShell سه چیز رو پوشش نمی‌ده: حکمرانی ارتباط ایجنت با ایجنت، هویت و احراز هویت ایجنت، و الگوهای ارتباط بین سندباکس‌ها. نویسنده می‌گه این‌ها چیزی نیست که انویدیا از قلم انداخته باشه؛ مرزیه که عمداً کشیده، دقیقاً همون‌جا که ناوگان شروع میشه. OpenShell به سؤال «این ایجنت روی این ماشین چه کاری می‌تونه بکنه؟» جواب می‌ده، نه به «کدوم یکی از دویست ایجنت من سه‌شنبهٔ قبل سرور MCP پرداخت رو صدا زد، با اجازهٔ کی و با چه مدلی؟»
اینجاست که نویسنده محصول خودشون Lynx رو معرفی می‌کنه و سه الگوی یکپارچه‌سازی پیشنهاد می‌ده — با این تصریح که این‌ها معماری مرجعِ پیشنهادیه بر پایهٔ مستندات منتشرشده، نه راهنمای تست‌شده. الگوی اول: تنها خروجی مجاز سندباکس، گیت‌وی Lynx باشه. الگوی دوم: کلید API هیچ‌وقت وارد سندباکس نشه و ترافیک مدل‌های فرانتیر از گیت‌وی مرکزی بره. الگوی سوم: هویت از بدو تولد، یعنی رپری دور دستور ساخت سندباکس که ایجنت تازه رو در رجیستری ثبت کنه.
جمله‌بندی پایانی مقاله خلاصهٔ خوبیه از تقسیم کار: OpenShell ایجنت رو نگه می‌داره، Lynx ناوگان رو حکمرانی می‌کنه. نویسنده اضافه می‌کنه هنوز کسی مترجمی بین YAML سطح OpenShell و سیاست‌های سطح کلاستر نساخته، ولی لایه‌ها اون‌قدر متناظرن که این یک مسئلهٔ مهندسی به نظر می‌رسه، نه یک مسئلهٔ پژوهشی.
نکات کلیدی:
- OpenShell رانتایم اوپن‌سورس انویدیا برای سندباکس‌کردن ایجنت‌ها با سیاست سطح کرنله
- چهار لایهٔ کنترل: فایل‌سیستم (Landlock)، پروسه (seccomp)، شبکه، و مسیریابی استنتاج
- کلید API سر Privacy Router جابه‌جا میشه و داخل سندباکس نمی‌مونه
- هویت ایجنت، ارتباط ایجنت‌به‌ایجنت و ارتباط بین سندباکس‌ها عمداً خارج از دامنه‌شن
- پروژه فعلاً آلفاست و روی لینوکس، مک و ویندوز با WSL 2 کار می‌کنه
- بخش پایانی مقاله معماری پیشنهادی تیگرا برای پرکردن این شکافه، نه راهنمای تست‌شده
