آخرین اخبار
همهٔ اخبار
امنیت هوش مصنوعی گزارش بحرانیت ۴/۱۰

ریسک‌های مدیریت حافظه در عامل‌های هوش مصنوعی و چالش‌های مجوزدهی (Authorization)

ریسک‌های مدیریت حافظه در عامل‌های هوش مصنوعی و چالش‌های مجوزدهی (Authorization)

تصور کنید یک تیم پشتیبانی در حال رسیدگی به شکایات پس از یک قطعی سرویس است. سیاست بازپرداخت وجه معمولاً نیازمند بررسی صلاحیت است، اما برای این حادثه خاص، یک مدیر مجاز استثنائی را تایید می‌کند: مشتریانی که در لیست تایید شده قطعی هستند، می‌توانند تا جمعه بدون بررسی فردی، تا سقف ۱۰۰ دلار دریافت کنند. یک عامل هوش مصنوعی (AI Agent) این موارد را با موفقیت پردازش می‌کند.

سپس، سیستم این تاریخچه‌های مورد بررسی را در یک حافظه قابل استفاده مجدد تجمیع (Consolidate) می‌کند: «بازپرداخت‌های کوچک و فوری، شکایات سرویس را سریعاً حل می‌کند». در این خلاصه، نتیجه حفظ شده اما محدودیت مربوط به قطعی و تاریخ انقضا حذف شده است. هفته بعد، عامل همین راهنما را برای مشتری دیگری که تحت تاثیر قطعی نبوده، بازیابی می‌کند و بدون بررسی، وجه را بازمی‌گرداند.

تفاوت بین یادگیری، جریان کاری و آموزش

در این سناریو، هیچ مهاجمی وجود ندارد؛ بلکه عامل شروع به اعمال یک استثنای موقت فراتر از محدوده مجاز خود کرده است. باید توجه داشت که تغییر رفتار عامل می‌تواند از سه مسیر مختلف رخ دهد:

  • به‌روزرسانی حافظه ذخیره‌شده (Stored Memory): تغییر اطلاعاتی که در اجراهای بعدی در دسترس است.
  • ویرایش دستورالعمل‌ها یا جریان‌های کاری (Workflows): تغییر در نحوه هدایت کار توسط اپلیکیشن.
  • آموزش (Training): تغییر در پارامترهای مدل.

در حالی که ویرایش جریان کاری دارای یک مرحله انتشار (Release) و بررسی است، یک حافظه جدید ممکن است از طریق پردازش روتین داده‌ها وارد شده و بر تعامل بعدی با مشتری تاثیر بگذارد، بدون اینکه کد، مدل یا مجوزهای ابزار تغییر کرده باشد.

وقتی حافظه به مرجع تبدیل می‌شود

تحقیقات نشان می‌دهد که در فرآیند تجمیع حافظه، ممکن است ادعایی حفظ شود اما تمایزات مربوط به منبع و سطح مجوزدهی (Source-Authority) از بین برود. برای جلوگیری از این مشکل، توصیه‌های امنیتی مایکروسافت پیشنهاد می‌کند که حافظه پایدار به عنوان لایه‌ای در نظر گرفته شود که رفتار را شکل می‌دهد، اما نباید به عنوان «حقیقت مطلق» یا مرجع مجوزدهی (Authoritative Truth) پذیرفته شود.

راهکارهای مقابله و کنترل

برای جلوگیری از این نوع خطاهای منطقی، باید استراتژی‌های زیر را به کار گرفت:

  • اجرای مجوزها در خارج از عامل: بررسی صلاحیت مشتری و وضعیت استثنا باید در سطح سرویس اجرا (Execution Service) و بر اساس لیست‌های مرجع انجام شود، نه بر اساس ادعای عامل هوش مصنوعی.
  • تفکیک بهبودهای عملیاتی از تغییرات سیاست: یادگیری روش‌های سریع‌تر برای جمع‌آوری شواهد مجاز است، اما گسترش صلاحیت‌ها یا حذف بررسی‌های اجباری باید یک تصمیم تجاری مجزا باشد و از طریق پرامپت‌های قابل ویرایش توسط مدل مدیریت نشود.
  • تست‌های مرزی (Boundary Testing): تیم‌های فنی باید سناریوهایی را شبیه‌سازی کنند که در آن یک شرط (مانند تاریخ انقضا یا لیست مشتریان) تغییر می‌کند تا اطمینان حاصل شود که یادگیری عامل باعث تغییر در مجوزهای دسترسی نمی‌شود.

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