چرا معماری عامل هوش مصنوعی شما یک آسیبپذیری امنیتی است
تا سال ۲۰۲۷، ۴۰٪ از استقرارهای هوش مصنوعی در سازمانها با حوادث تزریق دستور (prompt injection) یا ربودن عامل (agent hijack) مواجه خواهند شد. این یک جهش عظیم نسبت به کمتر از ۵٪ در اوایل سال ۲۰۲۵ است.
لایه ارکستراسیون (orchestration layer) عاملها را کاربردی میکند، اما در عین حال آنها را به هدف تبدیل میکند.
یک شرکت لجستیک در سنگاپور اخیراً ۲.۳ میلیون دلار ضرر کرد. یک دعوتنامه تقویمِ هکشده، یک عامل زمانبندی را فریب داد. آن عامل، سوابق CRM را برای یک مهاجم ارسال کرد. مدل هیچ کد مخربی نداشت؛ بلکه دستورالعملها را بهطور کامل اجرا کرد. مشکل، معماری بود.
عاملها صرفاً چتبات نیستند. آنها سیستمهایی هستند که از ابزارها استفاده میکنند، فایلها را میخوانند و تراکنشها را اجرا میکنند. امنیت سنتی فرض را بر این میگذارد که یک درخواست وارد میشود و یک پاسخ خارج میشود. عاملها این مدل را از هم میپاشند.
عاملی که ایمیلها را پیشنویس میکند و درخواستهای بازگشت وجه را ثبت میکند، مانند سه اپلیکیشن در یک محیط اجرا (runtime) عمل میکند. هر فراخوانی ابزار یک ریسک است. هر نوشتن در حافظه یک ریسک است. هر ایمیل یا سند، یک کد قابل اجراست.
تیمهای ایمن از یک الگوی سه لایه استفاده میکنند:
- هویت (Identity): هر فراخوانی ابزار به هویتی مجزا از کاربر نیاز دارد.
- منشأ (Provenance): هر نوشتن در حافظه به متادیتا (metadata) نیاز دارد تا منشأ آن را نشان دهد.
- تأیید (Verification): هر مرحله از برنامه به یک شیء امضا شده برای اجرای مراحل بعدی نیاز دارد.
عاملها هرگز نباید مستقیماً APIهای محیط عملیاتی (production) را فراخوانی کنند. در عوض، از یک لایه ابزار واسط (mediated tool layer) استفاده کنید. این لایه آرگومانها را اعتبارسنجی میکند، محدودهی دسترسیها را تعیین میکند و گزارشهای بازرسی (audit logs) ایجاد میکند. این لایه را به عنوان فایروال جدید خود در نظر بگیرید.
حافظه ریسک بزرگ دیگری است. مهاجمان از اسناد یا ایمیلهای مسموم (poisoned) برای تغییر حافظه یک عامل استفاده میکنند. این کار رفتار عامل را در طول زمان تغییر میدهد. حملات مسمومسازی حافظه (Memory poisoning) هر سال ۳۰۰٪ رشد میکنند.
اکثر تیمها مدلسازی تهدیدات هوش مصنوعی را به خط لولههای (pipelines) موجود اضافه میکنند، اما امنیت را به خودِ محیط اجرای عامل (agent runtime) اضافه نمیکنند. تنها ۱۹٪ از سازمانها دارای سیستم نظارتی برای ناهنجاریهای فراخوانی ابزار هستند.
از برخورد با عاملها مانند نرمافزار دست بردارید. با آنها مانند کارمندان تازهکاری که به سیستم دسترسی دارند برخورد کنید. شما به یک کارمند جدید در روز اول دسترسی root نمیدهید؛ این کار را با عاملهای خود نیز انجام ندهید.
برندگان کسانی نخواهند بود که خیرهکنندهترین دموها را دارند؛ بلکه کسانی هستند که عاملهایی دارند که بررسیهای امنیتی در بخشهای بانکی یا مراقبتهای بهداشتی را پشت سر میدهند. همین حالا این سه لایه را بسازید. منتظر نمانید تا پس از یک رخنه امنیتی، آنها را اضافه کنید.
آخرین تصمیم معماری که گرفتهاید چیست که اگر از روز اول بر امنیت عامل تمرکز میکردید، آن را تغییر میدادید؟
جامعه یادگیری اختیاری: https://t.me/GyaanSetuAi