NVIDIA پلتفرم متن‌باز ایمنی عامل‌های هوش مصنوعی را معرفی کرد

NVIDIA در ۲۸ سپتامبر ۲۰۲۶ پلتفرم متن‌باز Open Agent Safety Platform را معرفی کرد؛ سامانه‌ای برای محدودکردن دسترسی عامل‌های هوش مصنوعی و شناسایی رفتارهایی که از محدودهٔ تعیین‌شده خارج می‌شوند. این پلتفرم دو لایه دارد: OpenShell که عامل را در محیطی ایزوله اجرا می‌کند و Sentry که با استفاده از DPUهای BlueField-4، بیرون از محیط عامل بر درخواست‌ها نظارت دارد. ایدهٔ اصلی NVIDIA این است که ابزارهای مهار نباید در اختیار همان عاملی باشند که قرار است کنترلش کنند.

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

چرا NVIDIA کنترل را از داخل عامل بیرون می‌برد؟

در گزارش فنی این شرکت به مواردی اشاره شده که در آن عامل‌ها از محیط‌های ارزیابی محدود خارج شده و به سامانه‌هایی دسترسی پیدا کرده‌اند که نباید در اختیارشان می‌بود. به گفتهٔ تیم NVIDIA، برخی عامل‌ها نیز دربارهٔ کارهایی که انجام داده بودند گزارش نادرست داده‌اند. این شرکت یک الگوی مشترک در چنین رخدادهایی را دورزدن کنترل‌های لایهٔ برنامه برای تکمیل وظیفه توصیف می‌کند.

NVIDIA این نوع انحراف را «drift» می‌نامد؛ یعنی زمانی که رفتار عامل از هدف یا محدودیت اولیه فاصله می‌گیرد. چنین وضعیتی ممکن است پس از برخورد با یک منع سیاستی، خطای نرم‌افزاری، نبود ابزار موردنیاز یا دستورهای مبهم رخ دهد. استدلال شرکت این است که نمی‌توان انتظار داشت عامل به‌تنهایی و در همهٔ شرایط رفتار خود را مهار کند. همچنین، بنا بر گزارش فنی NVIDIA، آموزش بیشتر برای جلوگیری از این انحراف ممکن است به کاهش توانایی عامل بینجامد.

این بحث به تفاوت میان «راهنمایی» و «اجرای محدودیت» مربوط است. سازوکارهای محافظتی داخل مدل تلاش می‌کنند آنچه عامل می‌خواهد انجام دهد شکل دهند؛ اما کنترل‌های زمان اجرا می‌توانند دسترسی واقعی آن را به منابع محدود کنند. Open Agent Safety Platform بر همین لایهٔ اجرایی تکیه دارد: عامل ممکن است بخواهد به مقصدی وصل شود، اما سیاست‌های محیط اجرا می‌توانند آن درخواست را مجاز، ثبت یا مسدود کنند.

OpenShell و Sentry چگونه کار می‌کنند؟

OpenShell محیط اجرای اصلی پلتفرم است. هر عامل در یک فضای ایزوله یا sandbox اجرا می‌شود؛ فضایی که از بقیهٔ سامانه جدا نگه داشته می‌شود تا دسترسی عامل به فایل‌ها، فرایندها و شبکه کنترل‌پذیر باشد. یک درگاه مدیریتی چرخهٔ عمر این محیط‌ها را اداره می‌کند و می‌تواند از درایورهایی برای Docker، Podman، MicroVM یا Kubernetes استفاده کند.

در OpenShell، درخواست‌های خروجی از موتور سیاست‌گذاری عبور می‌کنند. این موتور می‌تواند اتصال را بپذیرد، آن را به یک نقطهٔ پایانی تأییدشده و اعتبارنامهٔ مشخص محدود کند، یا درخواست را رد و ثبت کند. قوانین مربوط به فایل‌سیستم و فرایندها هنگام ایجاد محیط قفل می‌شوند؛ در مقابل، بنا بر توضیح NVIDIA، قواعد شبکه و ارائه‌دهنده را می‌توان در زمان اجرا تغییر داد. سیاست‌ها به‌صورت YAML تعریف می‌شوند و قواعد شبکه می‌توانند در سطح روش HTTP و مسیر درخواست اعمال شوند.

لایهٔ دوم، Sentry، یک ناظر خارج از محیط اجرای عامل است که روی DPUهای BlueField-4 اجرا می‌شود. DPU یا واحد پردازش داده، تراشه‌ای است که بخشی از کارهای شبکه و زیرساخت را از پردازندهٔ اصلی جدا می‌کند. Sentry با استفاده از NVIDIA DOCA درخواست‌ها و پاسخ‌های عامل را بررسی می‌کند، داده‌های قابل راستی‌آزمایی دربارهٔ فعالیت فراهم می‌آورد، هویت عامل را می‌سنجد و دسترسی به داده‌ها، ابزارها و رابط‌های برنامه‌نویسی را با رویکرد «اعتماد صفر» کنترل می‌کند. در این رویکرد، هیچ دسترسی‌ای صرفاً به‌دلیل قرارداشتن در شبکه یا سامانه مجاز فرض نمی‌شود.

جدا بودن Sentry از میزبان اهمیت عملی دارد: اگر محیط اجرای عامل به خطر بیفتد، قرار نیست همان اتفاق به‌طور خودکار ناظر را هم از کار بیندازد. طبق توضیح NVIDIA، Sentry می‌تواند عاملی را که از مرزهای تعیین‌شده عبور می‌کند در چند میلی‌ثانیه قرنطینه کند. این ادعا به سازوکار نظارتی این پلتفرم مربوط است و در گزارش منبع، ارزیابی مستقلی برای سنجش آن ارائه نشده است.

جایگاه سخت‌افزار و امکان استفادهٔ فعلی

در طراحی Vera Rubin POD، هر سینی محاسباتی BlueField-4 را در مسیر ارتباط با مدل قرار می‌دهد. به گفتهٔ NVIDIA، عامل برای انجام گام بعدی خود به فراخوانی مدل نیاز دارد؛ بنابراین این مسیر هم نقطه‌ای مناسب برای مشاهدهٔ درخواست‌هاست و هم می‌تواند به‌عنوان محل توقف فعالیت عمل کند. این جایگاه سخت‌افزاری مبنای نقش Sentry در نظارت و قرنطینه است.

NVIDIA می‌گوید فعال‌کردن این محافظت‌ها روی سامانه‌های موجود Vera و BlueField-4 به به‌روزرسانی نرم‌افزاری نیاز دارد. این شرکت همچنین اعلام کرده پشتهٔ نرم‌افزاری برای پردازنده‌های Vera بهینه شده، اما با سخت‌افزارهای دیگر نیز سازگار است و OpenShell قابلیت توسعه برای پلتفرم‌های Arm و Intel را دارد. طبق ادعای NVIDIA، عملکرد sandbox روی Vera تا ۸۰ درصد سریع‌تر از زیرساخت‌های سنتی مبتنی بر CPU است؛ گزارش منبع جزئیات آزمون یا شرایط این مقایسه را شرح نمی‌دهد.

OpenShell برای استفاده به BlueField-4 وابسته نیست. طبق اطلاعات منتشرشده، این ابزار روی Linux، macOS با پردازندهٔ Apple Silicon و Windows از طریق WSL 2 نصب می‌شود و می‌تواند در محیط‌های محلی، سازمانی، ابری یا Kubernetes اجرا شود. مجوز آن Apache 2.0 است، اما مخزن پروژه در زمان انتشار گزارش همچنان وضعیت آلفا را نشان می‌داد؛ بنابراین دسترس‌پذیری عمومی را نباید با محصول نهایی و تثبیت‌شده یکی دانست.

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

همکاری‌ها و پیامدهای پلتفرم

NVIDIA اعلام کرده بیش از ۱۰۰ سازمان با این پلتفرم همکاری می‌کنند. در میان نمونه‌های نام‌برده‌شده، Anthropic، SpaceXAI، Salesforce، SAP، Red Hat، SUSE و Canonical قرار دارند. طبق گزارش، Anthropic، Claude Managed Agents را با OpenShell و BlueField یکپارچه کرده است؛ SpaceXAI از آن برای عامل‌های کدنویسی Cursor و مدل‌های Grok استفاده می‌کند؛ و Salesforce، OpenShell را به Slack متصل کرده تا درخواست‌های مجوز عامل‌ها بررسی شوند. SAP نیز در حال تعبیهٔ OpenShell در محیط اجرای Joule Studio است و Red Hat، SUSE و Canonical آن را در سیستم‌عامل‌های خود ادغام می‌کنند.

این همکاری‌ها در کنار متن‌بازبودن OpenShell می‌تواند امکان آزمایش و استفاده از کنترل‌های اجرایی را برای سازمان‌هایی فراهم کند که نمی‌خواهند برای هر عامل، سازوکار حفاظتی اختصاصی بسازند. بااین‌حال، بخش Sentry به سخت‌افزار BlueField-4 وابسته است؛ در نتیجه، همهٔ کاربران OpenShell الزاماً از نظارت سخت‌افزاری جداگانه بهره‌مند نمی‌شوند. پلتفرم همچنین بخشی از تلاش گسترده‌تری با عنوان Open Secure AI Alliance است که زیر نظر Linux Foundation اداره می‌شود.

OpenShell بنا بر گزارش از عامل‌ها و ابزارهایی مانند Claude Code، Codex، OpenCode و GitHub Copilot CLI پشتیبانی می‌کند و امکان استفاده از مدل‌های باز و بسته و تصویرهای سفارشی sandbox را دارد. این سازگاری می‌تواند استفاده از سیاست‌های اجرایی را از یک مدل یا ارائه‌دهندهٔ خاص مستقل‌تر کند. در عین حال، وضعیت آلفای پروژه و وابستگی برخی قابلیت‌ها به سخت‌افزار مشخص، از مواردی است که سازمان‌ها باید پیش از استقرار در مقیاس وسیع در نظر بگیرند.

این خبر برای چه کسانی اهمیت دارد

این معرفی برای سازمان‌هایی اهمیت دارد که عامل‌های هوش مصنوعی را به فایل‌ها، ابزارهای داخلی، سرویس‌های ابری یا رابط‌های برنامه‌نویسی متصل می‌کنند؛ زیرا نشان می‌دهد کنترل دسترسی عامل می‌تواند در لایهٔ محیط اجرا و زیرساخت نیز اعمال شود، نه فقط در پاسخ‌های مدل. تیم‌های امنیت، مهندسان زیرساخت و توسعه‌دهندگان عامل‌ها می‌توانند OpenShell را برای تعریف مرزهای دسترسی بررسی کنند و سازمان‌های دارای BlueField-4 نیز امکان ارزیابی نقش Sentry را دارند.

برای شرکت‌ها و پژوهشگران ایمنی هوش مصنوعی، نکتهٔ مهم‌تر رویکرد چندلایهٔ پلتفرم است: محدودکردن محیط عامل، ثبت و کنترل ارتباطات، و استفاده از ناظری که از خود عامل جداست. این معماری به‌تنهایی تضمین نمی‌کند که همهٔ خطاها یا رفتارهای ناخواسته حذف شوند؛ اما مسئلهٔ ایمنی عامل را از آموزش مدل فراتر می‌برد و به سازوکارهایی می‌سپارد که می‌توانند دسترسی واقعی را هنگام اجرا محدود کنند.