در ۲۱ سپتامبر ۲۰۲۶، ساشا ژِدلار از انویدیا در وبلاگ رسمی این شرکت نوشت که امنیت هوش مصنوعی را باید یک «مسئلهٔ مهندسی» دید؛ یعنی الزامات مشخص، کنترلهای قابلاجرا، مالک نامدار و شواهدی که نشان دهد حفاظتها کار میکنند. یک ماه پیش از آن، در ۲۱ اوت ۲۰۲۶، تیم ایمنی و امنیت انویدیا در وبلاگ توسعهدهندگان همین ایده را باز کرد و لایههای پشتهٔ ایجنت را توضیح داد. این گزارش بر پایهٔ همان دو یادداشت فنی نوشته شده است.
ایجنت هوش مصنوعی تنها متن تولید نمیکند: استدلال میکند، از ابزارها استفاده میکند و بر اساس دادهای که در مسیر کار میبیند اقدامش را تغییر میدهد. همین ویژگیها اصول کلاسیک امنیت را به شرایط تازهای میبرند.
هارنس چیست و چرا نمیتواند تضمین امنیتی بدهد
هارنس (harness) لایهای است که یک مدل را به ایجنت تبدیل میکند: حلقهٔ تصمیم، زمینه، ابزارها و نشست در همین لایه مدیریت میشوند. مدل و هارنس با هم پیشنهاد میدهند ایجنت چه کاری انجام دهد و این لایه جای طبیعی هدایت رفتار است.
اما انویدیا هشدار میدهد هر کنترلی که در این لایه ساخته شود، به رفتار مدل وابسته میماند. در هارنسهایی مثل DeepSeek Harness که با نام DSH هم آمده و بخشی از منطقشان با افزونه جایگزین میشود، لایهای که برای تغییرپذیری طراحی شده نمیتواند تضمین امنیتی پایدار بدهد. این متن انویدیا را دنبال میکند که لایهٔ هارنس را «طیفی» توصیف میکند، نه دستهای ثابت.
راهحل پیشنهادی این است که خود هارنس داخل محیط اجرای امن بالا بیاید، نه اینکه محیط اجرا را مانند یک ابزار اختیاری صدا بزند. یادداشت صریح است: کنترلی که ایجنت میتواند از فراخوانیاش سر باز زند، کنترل امنیتی مؤثر نیست.
پنج قاعدهای که تصمیم را از ایجنت جدا میکند
یادداشت فنی پنج قاعده پیشنهاد میکند تا تصمیم نهایی بیرون از دسترس ایجنت بماند و هر بار به یک شکل گرفته شود:
یک نکتهٔ ظریف در همان بخش آمده است: سیگنال ریسک مثل نمرهٔ ناهنجاری فقط میتواند اختیار را کم کند، نه زیاد. هیچ نمرهٔ اطمینانی نباید به ایجنت اجازهٔ بیشتری بدهد.
شش خطای رایجی که انویدیا شناسایی کرد
به نوشتهٔ این تیم، بیشتر پشتههای ایجنت یک نقطهضعف مشترک دارند: تصمیم مجوز میتواند از سوی خود ایجنت یا دادهٔ نامطمئنی که میخواند تأثیر بگیرد. شش نشانهٔ مشخص در یادداشت آمده است.
اول، مرزهای نامشخص که قواعد را بین دستور متنی، مدل، هارنس و زیرساخت پخش میکند. دوم، دسترسی بیش از اندازه با اعتبارنامهٔ بلندمدت که فراتر از وظیفهٔ فعلی است. سوم، استفاده از دادهٔ نامطمئن بهعنوان دستور: سند، پیام یا نتیجهٔ ابزار میتواند اقدام را منحرف کند بدون آنکه مجاز شده باشد.
چهارم، اثرهای بیرونی کنترلنشده؛ یک API مجاز میتواند داده جابهجا کند یا منابع تازه بسازد. پنجم، شکستهای زنجیرهای وقتی ایجنتها به هم سپرده میشوند و حافظه مشترک دارند. ششم، شواهد ناقص که بازسازی حادثه یا بازیابی را دشوار میکند.
چهار سطح امنیتی برای انتخاب پیش از استقرار
بخش عملی یادداشت چهار پروفایل امنیتی تعریف میکند که همه روی یک پشته و یک مرز اجرا میشوند، اما کنترلهای متفاوتی دارند. معیار انتخاب، اختیار دادهشده و پیامد احتمالی است، نه اطمینان به اینکه دادهای که ایجنت میخواند بیخطر است.
سطح جداشده برای کدنویسی پیش از تولید روی دادههای دورریختنی است: بدون اعتبارنامهٔ تولیدی، شبکهٔ محدود و ضبط نشست. سطح متصل برای پیشتولید با سرویسهای تأییدشده است: هویت کوتاهعمر، دادهٔ پوشاندهشده، سقف نرخ و هزینه و ثبت کامل.
سطح تولیدی برای تغییر در سامانهها یا دادهٔ عملیاتی است: دسترسی محدود به وظیفه، بررسی مستقل و تأیید انسانی برای اقدام پرپیامد. سطح خصمانه برای مدلهای پیشرو، اجرای بدون محافظ و آزمون تیم سرخ است: ارتباط پیشفرض مسدود، قرنطینهٔ خودکار و قویترین جداسازی.
نکتهای که یادداشت بر آن تأکید میکند این است که سطح خصمانه نباید به بهانهٔ خطرناکتر بودن، دسترسی گستردهتری بگیرد؛ دسترسی آن در عمل باید باریکتر و استثناییتر از یک ایجنت معمولی تولیدی باشد. با افزایش خطر، اختیار کوتاهعمرتر، تصمیم تازه نزدیک به هر اقدام، نظارت زندهٔ بیشتر، بازیابی سریعتر و شواهد مستقلتر لازم میشود.
شواهد لازم و معنای دقیق «امن»
یادداشت فنی سه الزام را در همهٔ سطوح ثابت نگه میدارد. ایجنت هرگز به خودش دسترسی نمیدهد و کنترل بیرون از فرایند ایجنت اجرا میشود. هر اثر پرپیامد در محدودهٔ کار باید از نقطهٔ اعمال کنترل بگذرد و بررسی در همان سامانهای انجام شود که اقدام را اجرا میکند. سیستم هم باید در نبود کنترل تازه یا در کهنه بودن آن، به حالت از پیش تأییدشدهٔ امنتر برگردد؛ در سامانههای فیزیکی و حیاتی این حالت میتواند کارکرد کنترلشده باشد، نه توقف ناگهانی.
نویسندگان به صراحت مینویسند که اجرای زیرساختی خطاناپذیر نیست: معنایش این است که سیاست تأییدشده و پیکربندی راستیآزماییشده خروجی تکرارشدنی بدهد و ایجنت نتواند انتخاب کند که آن را رعایت نکند. سیاست میتواند اشتباه باشد و نتیجهٔ بیرونی هم نامعلوم بماند؛ به همین دلیل ادعای امنیتی باید به مسیرهای دقیق پوششدادهشده محدود شود.
پیش از استقرار، تیم باید شواهدی داشته باشد که کنترلها تلاش برای گرفتن اعتبارنامهٔ فراتر از دامنه یا ارسال دادهٔ حساس به مقصد غیرمجاز را مسدود میکنند. آزمون باید تلاش برای تغییر مجوز و مختلکردن پایش را هم پوشش بدهد و پس از تغییر معنادار در مدل، ابزار یا گردشکار تکرار شود. یک مالک نامدار باید بر پایهٔ همین نتایج دربارهٔ آمادگی استقرار تصمیم بگیرد و شکست آزمون به اقدام اصلاحی برسد.
برای تیم ایرانی چه معنایی دارد
این یادداشت یک بیانیهٔ محصولی نیست؛ یک چارچوب طراحی است و OpenShell بخشی از آن را بهعنوان زماناجرای متنباز انویدیا معرفی میکند که سیاستها را بیرون از دسترس ایجنت اعمال میکند. برای تیمی که میخواهد ایجنت را روی دادهٔ مشتری یا سامانهٔ داخلی اجرا کند، کاربردیترین بخش همین پرسشهای پیش از آغاز است: کدام سطح را انتخاب کردهاید، کدام اقدامها تأیید انسانی لازم دارند و کدام آزمون ثابت میکند داده از مرز بیرون نمیرود.
هر سه پرسش را میتوان بدون خرید سختافزار تازه پاسخ داد. کافی است پیش از نوشتن کد، فهرست اثرهای مجاز ایجنت و نام مالک تصمیم استقرار را بنویسید. تا وقتی این دو فهرست وجود ندارد، هیچ سطح امنیتی هم قابل سنجش نیست.
بعد از خواندن مطلب بپرسید؛ پاسخ فقط از همین مقاله است.
این مطلب برایتان مفید بود؟
فرهاد محمدی خبرنگار فناوری و هوش مصنوعی فیسیت است. کار روزانهاش این است که خبر مدلهای زبانی، ابزارهای جدید و ادعاهای پرزرقوبرق شرکتها را به زبان قابلاستفاده برای مخاطب ایرانی برگرداند؛ بدون هیجان کاذب و بدون ترساندن بیدلیل.
میز کارش دو بخش است: هوش مصنوعی، و فناوری و تکنولوژی روز — نرمافزار، اینترنت و تغییراتی که روی کار و زندگی دیجیتال اثر میگذارند. قبل از نوشتن معمولاً میپرسد «برای کاربر چه فرقی میکند؟» و همان را محور مطلب میگذارد.
مینیمکس مدل M3.1 Flash را منتشر کرد؛ ایجنت و کدنویسی سریعتر با هزینهٔ ۷۰ درصد کمتر
ChatGPT حالا تبهای کروم را کنترل میکند؛ حالت Work فرم پر میکند، پیام میفرستد و فایل دانلود میکند
فیگما Specs را معرفی کرد؛ سندی برای اینکه ایجنتهای هوش مصنوعی قواعد طراحی تیم را رعایت کنند















نظرات کاربران