شما نمی‌توانید از تزریق دستور (Prompt Injection) جلوگیری کنید. پس چه کار باید کرد؟

تلاش برای ساختن یک پیام سیستم (system message) بی‌نقص را متوقف کنید. منتظر نسخه بهتری از مدل برای حل مسائل امنیتی نباشید.

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

تمرکز خود را تغییر دهید. نپرسید چگونه از تزریق جلوگیری کنیم؛ بپرسید که اگر تزریق با موفقیت انجام شد، عامل (agent) شما چه کارهایی می‌تواند انجام دهد.

برای محدود کردن خسارت، این قوانین را دنبال کنید:

  • از اعتبارنامه‌های محدود به قابلیت (capability-scoped credentials) استفاده کنید. به عامل خود فقط مجوزهایی را بدهید که برای وظیفه فعلی نیاز دارد. عاملی با دسترسی فقط‌خواندنی (read-only) نسبت به عاملی با کلید ادمین، خسارت کمتری وارد می‌کند.
  • اقدامات مخرب را محدود کنید (Gate). برای اقداماتی مانند حذف، پرداخت یا اعطای دسترسی، به تایید دومرحله‌ای یا بررسی دستی نیاز باشد. اجازه ندهید مدل تصمیم بگیرد که آیا این اقدامات ایمن هستند یا خیر.
  • با تمام ورودی‌های خارجی به عنوان ورودی‌های غیرقابل‌اعتماد برخورد کنید. این شامل پیام‌های کاربر، صفحات وب، خروجی‌های ابزار و اسناد می‌شود. داده‌ها اغلب وقتی وارد پنجره بافت (context window) می‌شوند، به دستورالعمل تبدیل می‌گردند.
  • خروجی‌های ابزار خود را زیر نظر داشته باشید. بسیاری از فریم‌ورک‌ها لاگ‌های ابزار را مستقیماً به بافت مدل (model context) می‌فرستند. مطالعه‌ای روی ۱۷,۰۲۲ مهارتِ عامل نشان داد که در ۷۳.۵٪ موارد، اعتبارنامه‌ها از طریق لاگ‌های عیب‌یابی (debug logs) نشت می‌کنند. پیش از آنکه اطلاعات حساس به مدل برسند، آن‌ها را از خروجی‌های ابزار حذف (Redact) کنید.
  • رفتار را زیر نظر بگیرید، نه فقط کیفیت را. یک عاملِ ربوده‌شده (hijacked)، در حالی که اقدامات غیرمجاز انجام می‌دهد، متنی با کیفیت بالا تولید می‌کند. شما باید توالی اقدامات عادی را به عنوان معیار (baseline) تعیین کنید و در صورت مشاهده انحراف، هشدار دهید.

از این سه سطح نظارت رفتاری استفاده کنید:

  • قوانین ایستا (Static rules): تغییرات آشکار را شناسایی کنید، مانند زمانی که یک عامل ناگهان شروع به ارسال ایمیل می‌کند.
  • الگوهای توالی (Sequence patterns): اقداماتی را که با ساختار معمول کارِ عامل همخوانی ندارند، علامت‌گذاری کنید.
  • بررسی مستقل (Independent review): از یک مدل دوم برای قضاوت درباره عامل اصلی استفاده کنید.

اگر عامل شما از حافظه استفاده می‌کند، آن را پاکیزه نگه دارید. یک تزریق واحد می‌تواند یک واقعیت مسموم (poisoned fact) بنویسد که در هر جلسه تکرار می‌شود. حافظه را برای هر نمونه (instance) محدود کنید و ردیابی کنید که هر قطعه از اطلاعات از کجا آمده است.

اگر همین الان یک عامل ربوده شود، آیا آن را در لاگ‌های خود خواهید دید؟ یا در تاریکی حرکت می‌کنید؟

Source: https://dev.to/brennhill/you-cant-prevent-prompt-injection-so-what-do-you-actually-do-1d37

Optional learning community: https://t.me/GyaanSetuAi