فرض کنید یک پاسخ‌گوی سازمانی، فایل راهنمای خدمات را می‌خواند. در میان متن فایل، جمله‌ای قرار گرفته که از مدل می‌خواهد اطلاعات خصوصی را به نشانی دیگری بفرستد. از نگاه برنامه، این جمله بخشی از سند است؛ اگر مدل آن را دستور معتبر تلقی کند، مرز امنیتی شکسته می‌شود. تزریق دستور یا Prompt Injection دقیقاً از چنین اختلاطی میان داده و اختیار استفاده می‌کند.
ورودی غیرمستقیم هم می‌تواند مسئله‌ساز باشد
در راهنمای Prompt Injection پروژه OWASP، ورود دستور از متن کاربر با ورود آن از منابع خارجی مانند فایل و وبگاه تفکیک می‌شود. همان راهنما یادآوری می‌کند RAG به تنهایی این خطر را حذف نمی‌کند. برای مهندسی محصول، مسئله اصلی این است که سند، نتیجه جست‌وجو و خروجی ابزار نباید اختیار تازه‌ای به برنامه بدهند.
در تحلیل پیشنهادی، نخست جریان داده را رسم کنید. مشخص کنید کدام ورودی توسط تیم اداره می‌شود، کدام را کاربر وارد می‌کند و کدام از سرویس بیرونی می‌آید. سپس ببینید کدام خروجی می‌تواند باعث ارسال پیام، تغییر فایل یا خواندن داده حساس شود. این نقشه ساده، نقاطی را روشن می‌کند که یک متن نامطمئن ممکن است به اقدام واقعی تبدیل شود.
اختیار باید بیرون از متن پاسخ کنترل شود
راهنمای ایمنی ساخت عامل‌ها در OpenAI درباره خطر اثرگذاری متن نامطمئن بر فراخوانی ابزارها توضیح می‌دهد و استفاده از خروجی ساختاریافته و جداسازی مراحل را مطرح می‌کند. این روش‌ها کاهش خطر هستند، نه تضمین حذف آن. برای اجرا، باید قواعدی داشته باشید که حتی در صورت پاسخ نادرست مدل هم پابرجا بمانند.
به عنوان نمونه، ابزار ارسال پاسخ فقط به شناسه درخواست معتبر دسترسی داشته باشد و نشانی مقصد را از پایگاه داده برنامه بخواند. اگر مدل نشانی تازه‌ای ساخت، برنامه آن را نپذیرد. ابزارهای خواندن و تغییر را جدا کنید و مجوز هر اقدام را در سرور بررسی کنید. کلید دسترسی کامل به حساب یا سرور نباید در زمینه‌ای قرار گیرد که مدل برای پاسخ‌گویی آن را می‌خواند.
اتصال ابزار، مرز اعتماد تازه‌ای می‌سازد
در راهنمای امنیت MCP، اعتبارسنجی نشانی‌ها و محدود کردن روش‌های باز کردن آن‌ها از موضوعات مطرح است. این بخش در سند پیش‌نویس آمده و هنگام پیاده‌سازی باید وضعیت نسخه بررسی شود. نتیجه عملی برای تیم این است که قالب ارتباط مشترک، بررسی امنیت سرور و داده دریافتی را از بین نمی‌برد.
برای سرویس بیرونی، مالک، دامنه دسترسی و روش قطع اتصال مشخص کنید. نتیجه ابزار را مانند داده اعتبارسنجی کنید: نوع فیلد، طول متن و نشانی مجاز باید محدود باشند. اگر ابزار پاسخ نامعتبر داد، مسیر خطا را اجرا کنید و آن را به صورت خودکار به ابزار دیگر نفرستید. زنجیره‌های طولانی می‌توانند علت حادثه را پنهان کنند؛ ثبت مرحله و نتیجه به بررسی بعدی کمک می‌کند.
سناریوی حمله را در محیط آزمایشی بسازید
برای آزمون دفاع، به جای داده واقعی از اسناد و حساب‌های ساختگی استفاده کنید. چند فایل آماده کنید که در آن‌ها درخواست تغییر نقش، ارسال اطلاعات یا نادیده گرفتن محدودیت آمده است. معیار موفقیت صرفاً نگفتن یک عبارت ممنوع نیست؛ بررسی کنید ابزار غیرمجاز اجرا نشده و داده از محدوده مجاز خارج نشده است. اگر سامانه چیزی را انجام نداده، نباید در پاسخ نهایی ادعا کند انجام شده است.
برای اقدام حساس، تصمیم قابل بررسی نشان دهید
در عملیاتی مانند حذف یا تغییر اطلاعات، خلاصه دقیق اقدام را پیش از اجرا نمایش دهید. کاربر باید بداند کدام مورد و چه مقداری تغییر خواهد کرد. یک تأیید مبهم با جمله «ادامه بدهم؟» ارزش محدودی دارد. پس از اجرا هم نتیجه واقعی ابزار را نشان دهید و شناسه پیگیری بدهید. این طراحی، کنترل را برای کاربر قابل استفاده و برای تیم قابل بررسی می‌کند.
امنیت هوش مصنوعی مجموعه‌ای از کنترل‌های هماهنگ است: محدودیت اختیار، اعتبارسنجی، جداسازی داده و ثبت رویداد. اصلاح متن دستور می‌تواند بخشی از دفاع باشد، اما نباید تنها دفاع باشد. پس از هر تغییر مدل یا ابزار، سناریوهای مهم را دوباره اجرا کنید. هدف حرفه‌ای، ادعای مصونیت کامل نیست؛ کاهش پیامد خطا و حفظ توان تشخیص، توقف و بازیابی سامانه است.
منابع و مطالعهٔ بیشتر
بررسی منابع: ۲۱ مهر ۱۴۰۵. تحلیل‌ها و پیشنهادهای اجرایی، جمع‌بندی نویسنده‌اند.
