عامل را در برابر prompt injection ایمن کنید؛ فیلتر واژه کافی نیست

برای مقاوم‌کردن عامل متصل به ابزار و RAG در برابر تزریق پرامپت، مرزها را در برنامه اجرا کنید: سند بازیابی‌شده و پاسخ ابزار داده‌اند، هر فراخوانی ابزار به مجوز مستقل نیاز دارد و خروجی مدل باید پیش از نمایش یا اجرا بررسی شود. راهنمای OWASP توضیح می‌دهد که برچسب محتوای نامطمئن و فیلتر واژه به‌تنهایی این مرزها را برقرار نمی‌کنند؛ بررسی مجوز و آرگومان عمل باید بیرون از مدل انجام شود.

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

در RAG، منبع اطلاعات را به منبع دستور تبدیل نکنید

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

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

برای نمونه‌ای فرضی، کاربر خلاصهٔ قراردادی را می‌خواهد و در متن بازیابی‌شده جمله‌ای آمده است که می‌گوید نسخهٔ کامل را به نشانی دیگری بفرستید. عامل می‌تواند این جمله را، اگر برای خلاصه اهمیت دارد، به‌عنوان بخشی از محتوای قرارداد گزارش کند؛ همان جمله اجازهٔ ارسال فایل ایجاد نمی‌کند. نشانی مقصد باید از درخواست مجاز کاربر یا تنظیمات مورد اعتماد برنامه به دست آید، نه از سندی که قرار بوده فقط خوانده شود.

همین مرز را برای پاسخ ابزار حفظ کنید. نتیجهٔ جست‌وجو، متن یک پیام یا دادهٔ برگشتی از API ممکن است درست در لحظه‌ای برسد که عامل برای تصمیم بعدی آماده است. قالب فنی پاسخ یا نام معتبر ابزار، محتوای برگشتی را به دستور معتبر تبدیل نمی‌کند؛ برنامه باید بداند کدام فیلد صرفاً داده است و کدام پارامتر از قبل در اختیار کاربر بوده است.

مجوز را کنار ابزار و پیش از اجرای عمل اعمال کنید

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

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

پژوهش AgentVisor چارچوبی را آزمود که فراخوانی‌های ابزار را رهگیری و از نظر اختیار بررسی می‌کند؛ نویسندگان در آزمایش‌های خود نرخ موفقیت حملهٔ ۰٫۶۵٪ و کاهش میانگین مطلوبیت وظیفهٔ ۱٫۴۵٪ را نسبت به حالت بدون دفاع گزارش کردند. این ارقام به چارچوب و شرایط همان آزمایش مربوط‌اند. برای عامل خودتان، مرز مؤثر همان جایی است که درخواست ابزار پیش از ایجاد اثر واقعی می‌تواند رد شود.

خروجی مدل را در مقصد نهایی اعتبارسنجی کنید

متن تولیدشدهٔ مدل برای سامانه‌ای که آن را مصرف می‌کند همچنان دادهٔ نامطمئن است. اگر پاسخ در صفحهٔ وب نمایش داده می‌شود، متن را متناسب با جایگاهش در HTML به‌صورت امن نمایش دهید و کد تولیدشدهٔ مدل را مستقیم به مرورگر نسپارید. اگر مدل مقداری برای جست‌وجوی پایگاه داده برمی‌گرداند، آن مقدار را به پرس‌وجوی پارامتری بدهید و ساختار SQL را در کد برنامه نگه دارید.

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

هر مرز را با ورودی بی‌خطر آزمایش کنید

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

1. در پیام مستقیم کاربر، عملی خارج از مجوز نشست درخواست کنید. حتی اگر مدل فراخوانی ابزار را پیشنهاد دهد، همان قاعدهٔ دسترسی در مؤلفهٔ اجرا باید آن را رد کند.
2. در سند ساختگیِ قابل‌بازیابی، کنار اطلاعات مرتبط با پرسش، جمله‌ای بگذارید که تغییر گیرنده یا ارسال دادهٔ آزمایشی را القا می‌کند. اطلاعات سند باید همچنان برای پاسخ قابل‌استفاده باشد، اما عمل اضافی از متن آن مجوز نگیرد.
3. همان القا را در پاسخ ساختگی یک ابزار قرار دهید. نسخه‌ای نیز بسازید که هیچ‌یک از واژه‌های فهرست فیلتر را ندارد؛ معیار آزمون، جلوگیری از عمل نامجاز است، نه پیدا کردن یک عبارت خاص.
4. از عامل بخواهید دادهٔ آزمایشی را برای نمایش HTML یا جست‌وجوی SQL آماده کند. بررسی کنید متن در صفحه به محتوای اجرایی تبدیل نمی‌شود، پرس‌وجو پارامتری می‌ماند و مقدار خارج از دسترسی پیش از مصرف رد می‌شود.

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

بیشتر بخوانید:

• Structured Outputs یا Function Calling؛ JSON معتبر هنوز ابزار نیست
• RAG را درست ارزیابی کنید؛ یک امتیاز خوب می‌تواند خطای بازیابی را پنهان کند
• حذف My Activity کافی نیست؛ تاریخچهٔ Chrome و Timeline جدا می‌ماند