امنیت ایجنتهای هوش مصنوعی فقط به پاسخ مدل محدود نیست!
امنیت ایجنتهای هوش مصنوعی زمانی جدیتر میشود که یک ایجنت فقط تولیدکننده متن نباشد؛ بلکه بتواند فایل بخواند، فرمان اجرا کند، از ابزارها استفاده کند و به سرویسهای دیگر درخواست بفرستد. در چنین شرایطی، بررسی پاسخ مدل بهتنهایی برای تأمین امنیت کافی نیست. سازمان باید مشخص کند هر ایجنت دقیقاً به چه منابعی دسترسی دارد، چه اقداماتی برای آن مجاز است و این محدودیتها چگونه در زمان اجرا اعمال میشوند.
OpenShell؛ مرز اجرای ایجنت…
در این مطلب، معماری NVIDIA OpenShell را بهعنوان نمونهای از این رویکرد بررسی میکنیم. OpenShell ایجنت را در یک محیط اجرای کنترلشده قرار میدهد و امکان تعریف سیاست برای دسترسی به فایلسیستم، اجرای فرایندها، ارتباطات شبکه و استفاده از اعتبارنامهها را فراهم میکند. در نتیجه، تصمیم ایجنت برای انجام یک کار لزوماً به معنای داشتن مجوز اجرای آن نیست.
پرسش کلیدی امنیت: اگر ایجنت اشتباه کند، فریب یک ورودی مخرب را بخورد یا از محدوده وظیفه خود خارج شود، کدام کنترل مستقل جلوی تبدیل آن تصمیم به یک اقدام غیرمجاز را میگیرد؟
چرا امنیت ایجنتهای هوش مصنوعی با امنیت چتبات فرق دارد؟
تفاوت امنیتی چتبات و ایجنت را میتوان در دو محور اصلی خلاصه کرد:
چتبات «پاسخ» میدهد؛ ایجنت «اقدام» میکند: چتبات معمولاً متنی تولید میکند و تصمیم نهایی با کاربر است؛ اما ایجنت میتواند برای رسیدن به یک هدف، ابزار انتخاب کند و چند اقدام پشتسرهم انجام دهد.
دامنه «دسترسی» تعیینکننده ریسک است: مجوزهای سیستمعامل، دسترسی به مخزن، مقصدهای مجاز شبکه و اعتبارنامههای در اختیار ایجنت مشخص میکنند هر تصمیم تا چه اندازه میتواند اثرگذار باشد.
تزریق پرامپت و تبدیل یک ورودی مخرب به اقدام غیرمجاز
ایجنت ممکن است محتوایی را از صفحه وب، سند، ایمیل یا مخزن کد بخواند. مهاجم میتواند در همین محتوای غیرقابلاعتماد، دستوری قرار دهد که ایجنت آن را بهاشتباه بخشی از وظیفه خود تلقی کند. اگر ایجنت مجوز کافی داشته باشد، نتیجه میتواند خواندن فایل حساس، اجرای فرمان یا ارسال داده به مقصدی غیرمجاز باشد.
کنترلهای سطح مدل و برنامه کاربردی برای تشخیص این ورودیها مفیدند؛ اما باید محدودیت دسترسی نیز وجود داشته باشد. اگر ایجنت اجازه اتصال به مقصد مهاجم را نداشته باشد، یک تصمیم اشتباه لزوماً به خروج اطلاعات منجر نمیشود. همین تفاوت، اهمیت کنترل در زمان اجرا را نشان میدهد.
OpenShell چگونه مرز عمل ایجنت را تعیین میکند؟
OpenShell یک محیط اجرای کنترلشده برای ایجنتها فراهم میکند. طبق مستندات NVIDIA، سیاستهای اجرایی مشخص میکنند ایجنت به چه منابعی دسترسی داشته باشد و چه عملیاتی برای آن مجاز باشد:
| حوزه کنترل | آنچه OpenShell محدود میکند |
|---|---|
| فایلسیستم | دسترسی ایجنت به فایلها و مسیرهای مشخص |
| فرایندها | اجرای فرایندها و عملیات مجاز در محیط اجرا |
| شبکه | ارتباط خروجی و مقصدهای مجاز برای اتصال |
| اعتبارنامهها | نحوه دسترسی و استفاده از Credentialهای سرویسها |
در این معماری، تصمیم ایجنت بهتنهایی کافی نیست؛ هر اقدام با سیاست محیط اجرا سنجیده میشود و تنها در صورت داشتن مجوز اجرا خواهد شد.
اختیار تصمیمگیری ایجنت باید با مجوز انجام عمل همراه باشد؛ این مجوز را سیاست اجرایی تعیین میکند.
این جداسازی به معنی بینیازی از آزمون مدل، بررسی ورودیها یا نظارت انسانی نیست. سیاست اجرایی نیز اگر بیش از حد باز تعریف شود، نمیتواند جلوی اقدامی را بگیرد که در محدوده همان مجوزهای گسترده قرار دارد.
اعتبارنامهها و دسترسی شبکه را چگونه محدود کنیم؟
برای کاهش ریسک افشای اطلاعات، ایجنت نباید بهصورت مستقیم و بدون کنترل به رمز عبور، API Key یا سایر اعتبارنامهها دسترسی داشته باشد. در OpenShell میتوان دسترسی به اعتبارنامهها و ارتباط با سرویسهای مقصد را براساس سیاستهای مشخص محدود کرد؛ با این حال، سطح حفاظت نهایی به نحوه پیکربندی محیط بستگی دارد.
برای اجرای این محدودیتها، چند اصل باید رعایت شود:
- اعتبارنامهها: فقط Credentialهای ضروری برای همان وظیفه در دسترس ایجنت باشند.
- مقصدهای شبکه: ارتباط خروجی فقط با سرویسها و دامنههای مشخص مجاز باشد.
- منابع داخلی: دسترسی به فایلها و سرویسهای غیرضروری برای ایجنت بسته بماند.
- مجوزهای موقت: دسترسیهای موقت پس از پایان کار بازبینی یا لغو شوند.
- رویدادهای امنیتی: درخواستهای ردشده ثبت شوند و امکان بررسی آنها وجود داشته باشد.
محدودیتهای سندباکس در امنیت ایجنتها
سندباکس یک مرز مهم برای اجرای ایجنت است، اما همه تهدیدها را پوشش نمیدهد. Red Hat در بررسی اجرای ایجنتها تأکید میکند که کنترل رفتار ایجنت و جداسازی زیرساخت دو لایه متفاوت با نقشهای مکمل هستند؛ بنابراین بسته به حساسیت محیط، سازمان ممکن است در کنار سیاستهای OpenShell به جداسازی قویتر بار کاری نیز نیاز داشته باشد.
موضوع مهم دیگر، همکاری میان چند ایجنت است. اگر یک ایجنت اجازه خواندن داده و ایجنت دیگری امکان ارسال اطلاعات را داشته باشد، مسیر ارتباط میان آنها باید بررسی شود؛ زیرا ارزیابی مجوز هر ایجنت بهصورت جداگانه، همیشه اثر ترکیب دسترسیها را نشان نمیدهد.
هویت و نظارت مستقل؛ دو لایه کلیدی در امنیت ایجنتها
برای کنترل بهتر رفتار ایجنتها، باید هویت، سطح اختیار و نحوه نظارت بر اقدامات آنها بهصورت شفاف مشخص باشد:
- هویت ایجنت:
باید مشخص باشد هر اقدام توسط کدام ایجنت انجام شده و آن ایجنت از طرف چه کاربر یا سامانهای اختیار گرفته است.
-
سطح مجوز:
باید مشخص باشد هر ایجنت هنگام انجام اقدام با چه سطح دسترسی و چه مجوزهای مشخصی فعالیت کرده است.
-
رویکرد NIST:
طرح مفهومی NIST، هویت و مجوزدهی ایجنتها را بخشی از امنیت ایجنتهای نرمافزاری مطرح میکند.
-
نظارت مستقل:
NVIDIA Sentry برای پایش رفتار ایجنتها خارج از محیط میزبان و ایجاد یک لایه نظارتی مستقل معرفی شده است.
-
ارزیابی سازمانی:
پیش از استقرار، قابلیتها، شرایط عملیاتی و نتایج آزمون باید در محیط واقعی خود سازمان بررسی شوند.
سازمانها امنیت ایجنتها را از کجا شروع کنند؟
پیش از دادن دسترسی عملیاتی به یک ایجنت، تیم فنی و امنیت باید این موارد را روشن کند:
| موضوع | پرسش کلیدی |
|---|---|
| وظیفه ایجنت | ایجنت دقیقاً چه وظیفهای دارد و برای انجام آن به چه ابزارهایی نیاز دارد؟ |
| سطح دسترسی | کدام فایلها، سرویسها و مقصدهای شبکه باید برای ایجنت مجاز باشند؟ |
| اعتبارنامهها | اعتبارنامهها چگونه نگهداری میشوند و ایجنت در چه شرایطی اجازه استفاده از آنها را دارد؟ |
| تأیید انسانی | کدام اقدامات حساس باید پیش از اجرا توسط انسان تأیید شوند؟ |
| ثبت و نظارت | اقدامات انجامشده، درخواستهای ردشده و تغییر مجوزها چگونه ثبت و بررسی میشوند؟ |
| چند ایجنتی | اگر چند ایجنت با هم کار کنند، ارتباط و ترکیب دسترسیهای آنها چه مسیر امنیتی ایجاد میکند؟ |
این پرسشها باید به سیاستهای مشخص و قابلآزمون تبدیل شوند. برای مثال، میتوان عمداً از ایجنت خواست به منبع یا مقصدی خارج از محدوده وظیفهاش دسترسی پیدا کند و سپس بررسی کرد آیا محیط اجرا درخواست را رد و رویداد را ثبت میکند یا خیر.
امنیت از جایی شروع میشود که اختیار محدود میشود
امنیت ایجنتهای هوش مصنوعی به کنترل کاری بستگی دارد که ایجنت میتواند در محیط سازمان انجام دهد. OpenShell نمونهای از انتقال بخشی از این کنترل به زمان اجرا است: دسترسی به منابع بر اساس سیاست تعیین میشود و تصمیم ایجنت بهتنهایی مجوز انجام عمل نیست.
برای استفاده سازمانی، این کنترل باید با هویت مشخص ایجنت، حداقلسازی مجوزها، حفاظت از اعتبارنامه، ثبت رویداد و بررسی ارتباط میان ایجنتها همراه شود. نتیجه مطلوب، ایجنتی است که بتواند وظیفه مجاز خود را انجام دهد و هنگام خروج از محدوده همان وظیفه متوقف شود.
منابع اصلی
برای مطالعه بیشتر و بررسی مستندات اصلی این مطلب:
- معماری NVIDIA OpenShell
- راهنمای کنترلهای امنیتی OpenShell
- تحلیل Red Hat درباره سندباکس ایجنتها
- طرح مفهومی NIST درباره هویت ایجنتها
- معرفی Open Agent Safety Platform از سوی NVIDIA
