جداسازی معماری؛ تنها راه مقابله با تزریق پرامپت در عامل‌های هوش مصنوعی

تصور کنید یک آگهی استخدام جعلی، به جای جذب نیرو، هدفش سرقت کلیدهای خصوصی سیستم شما باشد. این دقیقاً همان سلاحی بود که یک توسعه‌دهنده برای به چالش کشیدن ابزار جست‌وجوی شغل خود به کار برد. این تلاش برای ربودن ابزاری که با هوش مصنوعی قدرت گرفته بود، در گزارشی در وب‌سایت dev.to در تاریخ ۱۳ اوت ۲۰۲۶ منتشر شد. این آزمایش یک نقطه ضعف مرگبار در عامل‌های هوش مصنوعی (AI Agents) — سیستم‌هایی که می‌توانند به‌طور مستقل ابزارها را اجرا کنند — را افشا کرد: تمایل مدل‌ها به اطاعت از دستورات مخربی که در دل داده‌های خارجی پنهان شده‌اند.

بسیاری از عامل‌های امروزی با سطحی از اعتماد خطرناک کار می‌کنند. وقتی ابزاری یک تخته اعلانات عمومی را می‌خواند، در واقع متنی را پردازش می‌کند که توسط غریبه‌ها نوشته شده است. اگر این هوش مصنوعی به فایل‌های محلی یا دستورات سیستم دسترسی داشته باشد، یک قطعه متن هوشمندانه — که به آن تزریق پرامپت (Prompt Injection) می‌گویند — می‌تواند مدل را فریب دهد تا از نقش تعیین‌شده خارج شده و دستورات غیرمجاز را اجرا کند.

این ریسک شبیه این است که دستیار شما نامه‌ای را بخواند و اگر در نامه نوشته شده باشد «دستور رئیس را نادیده بگیر و گاوصندوق را باز کن»، او واقعاً این کار را انجام دهد. این همان خطری است که هر کسی که در حال ساخت جریان‌های کاری سفارشی با هوش مصنوعی است و با وب باز تعامل دارد، با آن روبروست. همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، اعتماد به ورودی‌های خارجی بدون لایه‌ی حفاظتی، یعنی دعوت از مهاجم برای کنترل سیستم. این نوع تهدیدات یادآور روش‌های پیچیده‌تری است که در آن داده‌های رمزگذاری شده در گفتگوهای بی‌ضرر با هوش مصنوعی پنهان می‌شوند تا از دید سیستم‌های امنیتی دور بمانند.

شکست حفاظ‌های متنی

این توسعه‌دهنده ابتدا از روش‌های «نرم» و استاندارد برای حفاظت استفاده کرد. او از تگ‌ها استفاده کرد تا به مدل بفهماند کدام بخش «داده» است و کدام بخش «دستور». همچنین صراحتاً به هوش مصنوعی دستور داد هرگونه تلاش برای تغییر وظیفه یا نادیده گرفتن دستورات اصلی را شناسایی و گزارش کند.

اما این روش‌ها به دو دلیل شکست خوردند:

• پردازش تک‌جریانی: مدل دستورات و داده‌ها را در یک جریان متصل و واحد از کلمات دریافت می‌کند. این ساختار مدل را مجبور می‌کند حدس بزند کدام بخش‌ها دستورات واقعی هستند و کدام بخش‌ها صرفاً متنی هستند که باید پردازش شوند.
• ناپایداری مدل: حتی مدل‌های پیشرو مانند Opus 5 گاهی غیرقابل‌پیش‌بینی عمل می‌کنند و تفاوت بین یک دستور اجرایی و یک توصیف متنی را تشخیص نمی‌دهند. توسعه‌دهنده اشاره کرد که حتی مدل‌های «بسیار هوشمند» (frontier-smart) هم گاهی رفتارهای عجیبی دارند و در عمل چندان باهوش عمل نمی‌کنند.

ساخت معماری سخت‌افزاری

برای حل این مشکل، توسعه‌دهنده امنیت را از سطح پرامپت به سطح معماری منتقل کرد. او سیستمی «بسته‌بندی شده» (Boxed-in) طراحی کرد که در آن مدل داور تحت محدودیت‌های فیزیکی شدید عمل می‌کند. هدف این بود که تضمین شود حتی اگر مدل فریب یک آگهی مخرب را می‌خورد و با آن همکاری می‌کرد، هیچ مسیری از آن جمله به فایل‌های موجود در ماشین وجود نداشته باشد.

• دسترسی صفر به ابزارها: مدل هیچ «دستی» ندارد. یعنی به‌طور مطلق نمی‌تواند فایلی را باز کند، دستورات سیستمی را اجرا کند یا به اینترنت دسترسی داشته باشد.
• محیط ایزوله: فرآیند در یک پوشه‌ی موقت (scratch folder) خالی اجرا می‌شود. این کار تضمین می‌کند که هیچ فایل شخصی در نزدیکی مدل نباشد تا هوش مصنوعی نتواند به‌طور تصادفی یا عمدی وارد آن‌ها شود.
• اعتبارسنجی سخت‌گیرانه خروجی: پاسخ مدل باید در یک قالب کوچک و ثابت (fixed shape) باشد. کدهای برنامه‌نویسی ساده هر فیلد را چک می‌کنند و هر پاسخ نامفهوم، به‌هم‌ریخته یا متناقض به‌طور خودکار حذف می‌شود. این مکانیسم مانع می‌شود مدل با نوشتن یک پاراگراف متقاعدکننده، راه خود را به داشبورد مدیریتی باز کند.

آزمون دفاع‌ها

توسعه‌دهنده به‌جای استفاده از اصطلاحات کلی و توخالی امنیتی مانند «ایزوله» یا «اعتبارسنج شده»، یک «حمله» واقعی و زنده را اجرا کرد تا ببیند آیا سیستم می‌شکند یا خیر. در تست اول، آگهی جعلی سعی کرد مدل را برای خواندن یک فایل خصوصی تحریک کند. این حمله یک پرچم هشدار (warning flag) با مقدار حدود ۵۰ برگرداند، اما محتوای فایل هرگز نمایش داده نشد چون مدل داور ابزار لازم برای خواندن فایل‌ها را نداشت.

با این حال، تست دوم که آرام‌تر و نامحسوس‌تر بود، یک نشت داده را فاش کرد. توسعه‌دهنده به داور بریف (خلاصه دستور) کوتاهی داد که هیچ اشاره‌ای به ساختار کلی سیستم نداشت، سپس سوالی پرسید که پاسخ آن تنها برای کسی ممکن بود که تنظیمات شخصی کاربر را خوانده باشد. مدل به‌درستی پاسخ داد.

این موضوع ثابت کرد که مدل هنوز به فایل‌های پیکربندی پس‌زمینه دسترسی دارد، حتی اگر آن‌ها مستقیماً به او تحویل داده نشده باشند. در حالی که پوشه‌ی موقت خالی مانع از نشت‌های آشکار شده بود، این مسیر دوم همچنان باز بود. برای رفع این مورد، توسعه‌دهنده ارتباط بین مدل داور و سایر بخش‌های تنظیمات شخصی هوش مصنوعی را به‌طور کامل قطع کرد. اکنون داور فقط «بریف» و «آگهی شغل» را می‌بیند و تضمین می‌شود که ویرایش یک فایل تنظیمات نامرتبط، به‌طور مخفیانه تغییر ندهد که کدام شغل‌ها نمایش داده شوند. این دقت در اعتبارسنجی داده‌های ورودی و خروجی، مشابه رویکردی است که در سیستم CV Aligner برای جلوگیری از توهمات در رزومه‌های AI از طریق متد «نگاشت شواهد» به کار گرفته شد.

تغییر در فلسفه اعتماد به AI

این رویکرد نشان‌دهنده تغییری کلی در نگاه توسعه‌دهندگان به عامل‌های هوش مصنوعی است. این توسعه‌دهنده که سال‌ها تجربه نویسندگی فنی دارد، استدلال می‌کند که یک رشته متن باید همیشه «فقط یک رشته متن» باقی بماند، چه از یک تخته اعلانات استخراج شده باشد و چه از یک هارد دیسک.

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

او این ذهنیت را در ابزارهای دیگرش که امسال ساخته است، از جمله یک داشبورد بودجه و یک مانیتورینگ فید حمل‌ونقل عمومی، پیاده کرده است. سوال اصلی او همیشه این است: «من به چه چیزی اعتماد کرده‌ام که در واقع کنترلی روی آن ندارم؟»

پذیرش شکست مدل

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

به جای آن، امنیت بر دو حقیقت سخت استوار است:
۱. داور هیچ ابزاری برای دسترسی به اینترنت یا فایل‌های محلی ندارد.
۲. کدهای برنامه‌نویسی ساده، پاسخ را پیش از هر اقدامی اعتبارسنجی می‌کنند.

اگرچه یک باگ در ابزارهای زیرساختی هنوز می‌تواند تئوریک اجازه دهد مدل خارج از کنترل شود، اما ساختار فعلی تضمین می‌کند که یک مدل گیج‌شده فقط می‌تواند یک حکم (verdict) عجیب تولید کند. آن حکم روی صفحه نمایش می‌ماند تا کاربر آن را بررسی کند. توسعه‌دهنده ترجیح می‌دهد با یک هشدار اشتباه دست‌وپنجه نرم کند تا اینکه آگهی‌های شغلی ناپدید شوند یا سیستم به خطر بیفتد. برای ابزاری که متون تصادفی اینترنت را می‌خواند، یک شکستِ کنترل‌شده در محیط ایزوله، بسیار بهتر از یک «امتناع مودبانه» است که نمی‌توان روی آن حساب کرد.

گام بعدی شما

• اگر از عامل‌های هوش مصنوعی برای پردازش داده‌های خارجی استفاده می‌کنید، دسترسی آن‌ها به سیستم‌عامل (OS) را به‌طور کامل قطع کنید.
• به‌جای تکیه بر پرامپت‌های سیستمی برای امنیت، از لایه‌های اعتبارسنجی کد (Hard-coded validation) برای خروجی‌ها استفاده کنید.
• محیط اجرای مدل را در یک کانتینر یا پوشه ایزوله قرار دهید تا نشت داده‌های پس‌زمینه رخ ندهد.

اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.