پلتفرم ایمنی NVIDIA معرفی شد؛ مهار عامل، مجوز پرداخت نیست

خبر دیروز: کنترل بیرون از مدل، نه صرفاً دستور در پیام

NVIDIA روز ۲۸ سپتامبر، برابر با ۶ مهر، Open Agent Safety Platform را معرفی کرد: ترکیبی از نرم‌افزار متن‌باز OpenShell و طرح مرجع Sentry. اولی برای محدودکردن محیط اجرای عامل است؛ دومی در طرح اعلام‌شده، ناظری جدا از محیط اصلی روی پردازنده‌های BlueField-4 است. شرکت از دسترس‌پذیری گسترده OpenShell خبر می‌دهد، اما این جمله را نباید اعلام آماده‌بودن تمام اجزای سخت‌افزاری و اتصال‌های شرکا دانست. ^[۱]

NVIDIA برای Sentry از قرنطینه در مقیاس میلی‌ثانیه سخن می‌گوید. این ادعای عملکرد فروشنده است؛ گزارش حاضر آزمون مستقل آن یا تضمین جلوگیری از همه خطاها ندارد. نکته قابل اتکا برای این خبر، معرفی معماری و انتشار توضیحات فنی و سازمانی همراه آن است، نه تبدیل وعده سرعت واکنش به عدد کاهش زیان شرکت. ^[۱]

برای مدیر مالی ایرانی، برداشت ژرف‌بان این است که «اجازه دسترسی» و «اجازه معامله» باید جدا دیده شوند. عاملی که مجاز است فهرست فاکتورها را بخواند، لزوماً نباید بتواند حساب بانکی فروشنده را تغییر دهد یا پرداخت نهایی ایجاد کند. این مثال، سناریوی کنترلی تحریریه است؛ نه گزارش یک حادثه واقعی و نه توصیف اتصال فعال این پلتفرم به بانک‌های ایران.

SAP مرز مهم را روشن می‌کند: آیا این اقدام اصلاً مجاز است؟

SAP در توضیح هم‌زمان خود، نقش Joule Studio runtime را بررسی اختیار تجاری، سیاست مبتنی بر نقش و زمینه فرایند، پیش از رسیدن درخواست به محیط اجرا می‌داند. در مقابل، OpenShell تعیین می‌کند عامل چگونه اجرا شود، چه چیزهایی را ببیند و کجا پردازش مدل انجام گیرد. این تفکیک در متن شرکت، شاهد مستقیمی است که مهار فنی و پاسخ‌گویی تجاری یک کنترل واحد نیستند. ^[۲]

SAP از مشارکت مهندسان خود در توسعه و تعبیه OpenShell و تلاش برای اتصال جداسازی اجرا به مدل‌های مجوز و ردپای حسابرسی خبر می‌دهد. همان متن، برخی الزامات صنایع تحت نظارت و استانداردهای مورد اشاره را در مسیر توسعه قرار می‌دهد. بنابراین «در حال کار روی آن» را نباید به «برای همه مشتریان مستقر و تأییدشده» تبدیل کرد. ^[۲]

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

جزئیات تعیین‌کننده در مستندات: ثبت تخلف با منع اقدام فرق دارد

راهنمای OpenShell چهار حوزه کنترل را تفکیک می‌کند: فایل، شبکه، فرایند و اعتبارنامه ارائه‌دهنده. محدودیت فایل و فرایند هنگام ساخت محیط تعیین می‌شود؛ سیاست شبکه قابلیت تغییر هنگام اجرا دارد. مستندات همچنین از محدودکردن مقصدهای شبکه و دسترسی به مسیرهای فایل سخن می‌گویند. این‌ها توصیف کنترل فنی‌اند؛ خودِ فهرست چهارگانه، درستی تصمیم حسابداری را تأیید نمی‌کند. ^[۵]

راهنمای امنیت، در بخش بازرسی لایه درخواست یا L7، تفاوت مهمی دارد: حالت پیش‌فرض audit تخلف از قواعد را ثبت می‌کند ولی ترافیک را عبور می‌دهد؛ enforce درخواست ناسازگار را مسدود می‌کند. این حکم درباره همان بازرسی است، نه اینکه تمام کنترل‌های OpenShell فقط هشدار بدهند. سیاست خروجی شبکه همچنان به‌صورت پیش‌فرض مقصدهای تعریف‌نشده را منع می‌کند. ^[۶]

همان راهنما هشدار می‌دهد که اجازه اتصال به یک مقصد، بدون قواعد درخواست، می‌تواند همه روش‌ها و مسیرهای HTTP آن مقصد را مجاز کند. برداشت ژرف‌بان: عبارت «فقط به نرم‌افزار مالی وصل است» پاسخ کافی نیست. باید مشخص شود اتصال فقط برای خواندن است یا ایجاد، اصلاح و حذف را هم ممکن می‌کند. این تفاوت، دلیل درخواست شاهد اجرای کنترل است؛ نه دعوت مدیر مالی به تغییر شخصی تنظیمات فنی. ^[۶]

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

هویت عامل و ردپای اقدام، دو بخش دیگر پرونده‌اند

IBM در اعلام ۲۸ سپتامبر می‌گوید Agent Identity، که در پیش‌نمایش عمومی است، و HashiCorp Vault با OpenShell یکپارچه می‌شوند تا هویت عامل و دسترسی مورد نیازش قابل تعیین باشد. شرکت جداگانه از شناسایی عامل‌های ناشناخته برای سازمان و کار روی لایه زیرساخت می‌گوید. مرحله عرضه اهمیت دارد: این اعلام، مدرک استقرار همان ترکیب در شرکت ایرانی یا نتیجه حسابرسی امنیت آن نیست. ^[۳]

Cisco در توضیح همکاری خود بر هویت غیرانسانی، اختیار تفویض‌شده و مجوز هر اقدام تأکید می‌کند. استدلال دیگرش این است که اجرای کنترل در چند محیط، شواهد پراکنده تولید می‌کند و سوابق باید در یک دید قابل پیگیری جمع شوند. این موضع فنی یک شریک تجاری است؛ تأیید مستقل ادعاهای NVIDIA یا گواهی انطباق مالی محسوب نمی‌شود. ^[۴]

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

اثر امروز بر تصمیم مدیر مالی: اختیار را همراه شاهد تصویب کنید

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

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

برای شرکت مستقر در ایران، امکان خرید، پشتیبانی، مجوز استفاده و سازگاری با سامانه‌های موجود در این بررسی احراز نشده است. این متن راهنمای دورزدن محدودیت یا توصیه خرید سخت‌افزار نیست. درس قابل انتقال به تأمین‌کننده داخلی، درخواست پاسخ و شاهد برای سه مرز است: دسترسی به داده، اختیار انجام عمل و تأیید اثر مالی؛ ادعای انطباق با OpenShell را هم بدون مدرک نپذیرید.

چه چیزی هنوز باید ثابت شود؟

شاهد بعدی، نسخه قابل استفاده هر اتصال، دامنه پشتیبانی و نتیجه آزمونی است که هم جلوگیری از اقدام نامجاز و هم امکان ادامه کار مجاز را نشان دهد. برای واحد مالی، ثبت نسخه سیاست و تأییدکننده در کنار سند آزمایشی از شعار «عامل امن» مفیدتر است. هر تغییری در اختیار عامل باید در همان آزمون قابل بازبینی باشد؛ نتیجه قبلی برای دامنه جدید کافی نیست.

پنجره این نسخه از ساعت ۰۷:۰۰ روز ۶ مهر تا ۰۷:۰۰ روز ۷ مهر تهران است. چهار اعلام شرکت‌ها تاریخ ۲۸ سپتامبر دارند؛ فراداده SAP و Cisco نیز انتشار داخل این بازه را تأیید می‌کند. دو راهنمای فنی، اسناد زمینه بدون تاریخ انتشار نمایان‌اند و نسخه جاری هنگام تهیه خبر بررسی شده است. این شش سند، از چهار سازمان تجاری مرتبط می‌آیند؛ آزمون مستقل امنیت یا تضمین حذف ریسک نیستند. ^{[۱] [۲] [۳] [۴] [۵] [۶]}