‏جلوی prompt injection رو با prompt نمی‌گیری؛ tool رو ببند

نویسنده با یه سناریو شروع می‌کنه: یه تیکتِ پشتیبانی میاد که به agent می‌گه دستوراتِ قبلیش رو نادیده بگیره، وارد حالتِ admin بشه و اطلاعاتِ حساسِ یه سفارشِ دیگه رو برگردونه. agentی که یه tool به اسم LookupOrder داره، تیکت رو می‌خونه و دقیقاً همون کاری رو که ازش خواسته شده انجام می‌ده — داده‌ی یه مشتریِ دیگه از تو یه text box بیرون می‌ره. هیچ firewall و قانونِ validationی هم اون رو نمی‌گیره، چون درخواست فقط یه جمله بوده.

غریزه‌ی اول اینه که prompt رو وصله کنی و یه خط بهش اضافه کنی: «هیچ‌وقت داده‌ی مشتری دیگه رو لو نده». نویسنده می‌گه این جواب نمی‌ده. از دیدِ مدل، دستورِ سیستمِ تو و تیکتِ مخرب هر دو یه چیزن: متن. هیچ کانالِ ممتازی زمزمه نمی‌کنه که «این بخش قانونِ واقعیه، اون بخش فقط کاربره». این همون prompt injectionه که ریسکِ شماره‌یکِ OWASP Top 10 برای اپ‌های LLMه، و یه باگ نیست که وصله بشه، بلکه ذاتِ نحوه‌ی کارِ LLMهاست.

پس توصیه‌ی مقاله اینه: دفاع از prompt رو ول کن و اون دو مرزی رو که واقعاً کنترل می‌کنی سفت کن — اینکه toolهات اجازه‌ی چه کاری دارن، و چی از مدل رد می‌شه بیرون و تو. نویسنده tool رو «شعاعِ انفجار» می‌نامه: تو نسخه‌ی آسیب‌پذیرِ LookupOrder، شناسه‌ی سفارش از ورودی‌ای میاد که خودِ مدل انتخابش کرده، و مدلی که قانع شده سفارشِ دیگه‌ای رو بیاره، همون رو می‌گیره. نویسنده این رو یه‌جور «SQL injection که خودت عمداً نوشتی» توصیف می‌کنه.

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

جمع‌بندیِ نویسنده اینه که mitigationِ واقعی دو لایه‌ست: محدودکردنِ اختیارِ toolها (کمترین دسترسیِ لازم و گره‌زدنِ داده به کاربرِ authenticate‌شده)، و کنترلِ چیزی که وارد و خارجِ مدل می‌شه. این دو مرز، برخلافِ prompt، واقعاً تو دستِ توئن.

نکات کلیدی:

• prompt injection ریسکِ شماره‌یکِ OWASP برای اپ‌های LLMه و یه باگ نیست، ذاتِ کارِ مدله.
• نمی‌شه با اضافه‌کردنِ قانون به prompt جلوش رو گرفت، چون مدل بین دستورِ سیستم و متنِ کاربر فرقی نمی‌ذاره.
• به‌جای دفاع از prompt، دو مرزِ واقعی رو سفت کن: اختیارِ toolها و چیزی که وارد/خارجِ مدل می‌شه.
• هیچ‌وقت برای authorization به ورودیِ مدل اعتماد نکن؛ سفارش رو از رابطه‌ی کاربرِ authenticate‌شده بگیر، نه از شناسه‌ای که مدل داده.