احمدرضا صمدی / صفحه اصلی

توضیح · عامل‌های هوش مصنوعی و مجوزها

امنیت عامل‌های هوش مصنوعی: تعیین مرز پیش از اقدام

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

نوشته · · نسخه انگلیسی مقاله · به‌روزرسانی

در یک نگاه

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

در ۲۸ سپتامبر، NVIDIA پلتفرم Open Agent Safety خود را معرفی کرد. این اعلامیه نرم‌افزار OpenShell را در کنار طرح مرجع جداگانه Sentry قرار می‌دهد. موضوع، پرسشی مهم را پیش می‌کشد: محدودیت‌های عامل هوش مصنوعی کجا باید اجرا شوند و اگر از آن‌ها عبور کرد چه می‌شود؟

چرا دستور دقیق کافی نیست؟

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

OpenShell و Sentry چه هستند؟

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

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

در یک آزمون پیشنهادی، کدام چهار مرز را بررسی می‌کردم؟

  1. هویت: عامل به نام کدام کاربر یا حساب سرویس اقدام می‌کند؟
  2. محدوده: به کدام فایل‌ها، پیام‌ها، سوابق و ابزارها دسترسی دارد؟
  3. اقدام: فقط می‌خواند یا می‌تواند ارسال، تغییر و حذف هم انجام دهد؟
  4. نظارت: کدام اقدام تأیید می‌خواهد و تلاش‌ها و خطاها چگونه ثبت می‌شوند؟

مثال اتاق و نگهبان کمک می‌کند: دسترسی را به یک اتاق محدود کنید و در را جداگانه زیر نظر بگیرید. اما هیچ مرز واحدی به‌تنهایی ایمنی عامل را ثابت نمی‌کند. تیم‌ها همچنان به آزمون متناسب با کار، مسیر بازبینی و امکان لغو دسترسی نیاز دارند.

در یک آزمون پیشنهادی، پیش از سپردن ارسال ایمیل به عامل چه چیزهایی را می‌آزمودم؟

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

ادامه بحث

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

منبع