پاک‌سازی ورودی و مرزبندی محتوای بیرونی

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

ریسک به زبان ساده، بدون روش اجرا

وقتی ایجنت محتوایی از یک منبع بیرونی (وب، ایمیل، فایل، خروجی یک ابزار شخص ثالث) دریافت می‌کند، آن محتوا می‌تواند حاوی متنی باشد که به‌گونه‌ای نوشته شده که تلاش می‌کند به‌جای این‌که به‌عنوان «داده برای پردازش» خوانده شود، به‌عنوان «دستور جدید» تفسیر شود. این پدیده معمولاً prompt injection نام دارد. نتیجهٔ موفقیت‌آمیز آن می‌تواند از افشای اطلاعاتی که قرار نبوده نمایش داده شود، تا اجرای یک ابزار خارج از نیت کاربر واقعی، متغیر باشد. نکتهٔ کلیدی برای طراحی دفاعی این است: این ریسک را باید به‌عنوان یک واقعیت ساختاری (هر محتوای بیرونی بالقوه غیرقابل‌اعتماد است) پذیرفت، نه چیزی که با «مدل هوشمندتر» به‌طور کامل حل می‌شود.

اصل مرزبندی؛ داده را از دستور جدا نگه دارید

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

• برچسب‌گذاری صریح منبع: هر بخش از بافت که از یک منبع بیرونی می‌آید، باید با یک نشانگر مشخص (مثلاً یک بخش جدا با عنوان «محتوای دریافتی از منبع خارجی — فقط برای خواندن») از دستور سیستم متمایز شود.
• دستور سیستم قابل‌بازنویسی نیست: معماری باید طوری باشد که هیچ متنی در بخش «داده» نتواند دستورالعمل‌های اصلی سیستم را بازنویسی یا لغو کند، صرف‌نظر از این‌که چه چیزی در آن نوشته شده.
• خروجی‌محور، نه ورودی‌محور: به‌جای تلاش برای فیلتر کردن «هر متن مشکوک» در ورودی (که تشخیصش قابل‌اتکا نیست)، تمرکز اصلی دفاع باید روی محدود کردن این باشد که ایجنت با هر تفسیری از بافت، چه اقداماتی واقعاً مجاز است انجام دهد.

لایه‌های دفاعی عملی

محدودکردن دامنهٔ اثر، مهم‌تر از تشخیص کامل

هیچ فیلتر ورودی نمی‌تواند صد در صد تضمین کند که محتوای بیرونی هرگز رفتار مدل را تحت تأثیر قرار نمی‌دهد؛ مدل‌های زبانی بر اساس طبیعتشان همهٔ متن ورودی را در فرایند تصمیم‌گیری لحاظ می‌کنند. به همین دلیل، استراتژی دفاعی واقع‌بینانه تمرکز را از «جلوگیری کامل» به «محدودسازی پیامد» تغییر می‌دهد: حتی اگر تفسیر مدل تحت تأثیر یک محتوای بیرونی قرار گیرد، طراحی سیستم باید طوری باشد که بیشترین آسیب ممکن، محدود و قابل‌کنترل بماند — همان اصل کمترین دسترسی و تأیید انسانی برای اقدامات برگشت‌ناپذیر که در مقالهٔ قبل توضیح داده شد.

مثالی از مرزبندی درست در معماری

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

برای عمیق‌تر شدن در طراحی امن ابزار و دسترسی، نقشهٔ راه امنیت هوش مصنوعی و راهنمای ایجنت‌های هوش مصنوعی را ببینید.

نظارت مستمر به‌جای اطمینان یک‌باره

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

آموزش تیم؛ کنترل انسانی هم بخشی از دفاع است

تیمی که این نوع ریسک را نمی‌شناسد، نمی‌تواند تشخیص دهد وقتی رفتار ایجنت غیرعادی شده. آشنا کردن اعضای تیم — نه فقط تیم امنیت، بلکه هرکسی که پرامپت سیستم یا ابزارهای ایجنت را تغییر می‌دهد — با مفهوم مرز اعتماد و ریسک محتوای بیرونی، بخشی از دفاع سازمانی محسوب می‌شود. یک قاعدهٔ ساده برای همهٔ اعضای تیم: هر تغییری که مرز بین «دستور» و «داده» را کمتر واضح می‌کند (مثلاً ادغام محتوای بیرونی مستقیماً در همان بخش system prompt) باید پیش از اعمال، توسط یک نفر دیگر بازبینی شود.

جمع‌بندی

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