شهریور
Opsless و آینده کار
امنیت در عصر Opsless؛ Prompt Injection روی دادهٔ مشتری
در مدل Opsless، یک Agent مستقیماً پیامهای خام مشتری را — از تیکت Helpdesk، از فرم تماس، از یک ایمیل — میخواند و بر اساس آنها روی CRM یا سیستم حسابداری اقدام میکند. همین ویژگی که Opsless را قدرتمند میکند، یک سطح حملهٔ جدید هم باز میکند: هر متنی که از بیرون سازمان میآید، میتواند حاوی دستوراتی باشد که برای فریب دادن Agent نوشته شدهاند، نه برای خواندن انسانی. این پدیده Prompt Injection نام دارد و چون Agent در Opsless مستقیم به دادههای حساس مشتری دسترسی دارد، ریسک آن صرفاً فنی نیست — مستقیم مالی و اعتباری است. این مقاله فقط دربارهٔ فهمیدن ریسک و راه دفاع در برابر آن است.
لیست مطالب
چرا این ریسک مخصوص عصر Opsless است
در نرمافزار سنتی، متن ورودی مشتری فقط داده است — در یک فیلد ذخیره میشود و روی صفحه نمایش داده میشود. اما وقتی یک Agent مبتنی بر مدل زبانی همان متن را میخواند تا بفهمد چه کاری باید انجام دهد، مرز بین «داده» و «دستور» محو میشود. اگر متن ورودی طوری نوشته شده باشد که شبیه یک دستور سیستمی به نظر برسد، Agent ممکن است آن را بهعنوان یک راهنمایی معتبر تفسیر کند، نه یک محتوای مشتری که فقط باید پردازش شود. در یک محیط CRMless که Agent اجازهٔ نوشتن در سیستمهای واقعی را دارد، نتیجهٔ چنین اشتباهی میتواند از افشای اطلاعات یک مشتری به مشتری دیگر تا اجرای یک عملیات ناخواسته در Accounting باشد.
سطوح ریسک: از کجا داده وارد میشود
| منبع ورودی | سطح ریسک | چرا خطرناک است |
|---|---|---|
| پیام مستقیم مشتری در چت | متوسط | معمولاً کوتاه است و راحتتر بررسی میشود |
| تیکت یا ایمیل طولانی | بالا | محتوای بلند جای پنهانکردن دستور مخرب زیاد دارد |
| پیوست یا فایل ضمیمهشده | بالا | معمولاً بدون بررسی دقیق مستقیم به Agent داده میشود |
| دادهای که از یک سیستم شخص ثالث خوانده میشود | بالا | سازمان کنترلی روی محتوای آن سیستم ندارد |
اصول دفاعی که واقعاً جواب میدهند
۱. جداسازی داده از دستور در سطح معماری
مهمترین اصل این است که پرامپت سیستمی (قوانین و دستورهایی که سازمان به Agent میدهد) هرگز نباید در همان کانالی قرار بگیرد که محتوای مشتری در آن جریان دارد. باید همیشه مشخص باشد که کدام بخش از ورودی «قابلاعتماد» (از سیستم داخلی) است و کدام بخش «غیرقابلاعتماد» (از بیرون) — و Agent باید طوری طراحی شود که دستور را فقط از بخش قابلاعتماد بپذیرد، نه از هر متنی که در محتوای مشتری ظاهر میشود.
۲. اعمال مدل مجوز کمترین دسترسی
حتی اگر یک پیام موفق شود Agent را فریب دهد، خسارت باید محدود بماند. این یعنی Agent هرگز نباید بیشتر از چیزی که برای همان task لازم است دسترسی داشته باشد — مثلاً یک Agent که به تیکتهای پشتیبانی پاسخ میدهد، نباید بدون یک لایهٔ تأیید جداگانه بتواند مستقیم رکورد مالی یک مشتری دیگر را بخواند یا تغییر دهد. این همان مدل مجوز لایهبندیشدهای است که در طراحی هر سیستم Opsless باید از پیش تعریف شود.
۳. تأیید انسانی برای اقدامات پرریسک
عملیاتی که برگشتناپذیر است یا روی دادهی مشتری دیگری اثر میگذارد — تغییر ایمیل تماس، صدور فاکتور، حذف رکورد — باید همیشه از یک لایهٔ تأیید انسانی عبور کند، حتی اگر Agent با اطمینان بالا پیشنهاد داده باشد. این لایه دقیقاً همان چیزی است که جلوی تبدیل یک Prompt Injection موفق به یک خسارت واقعی را میگیرد.
۴. پایش و هشدار برای رفتار غیرعادی
الگوهای غیرعادی — مثل یک تیکت که ناگهان باعث میشود Agent چند رکورد را همزمان تغییر دهد، یا یک session که خارج از الگوی معمول عمل میکند — باید بهصورت خودکار پرچمگذاری و برای بازبینی انسانی متوقف شود، پیش از آنکه اثر آن در سیستم واقعی ثبت شود.
در Opsless، امنترین فرض این نیست که Agent هرگز فریب نمیخورد؛ فرض درست این است که ممکن است فریب بخورد، و طراحی سیستم باید طوری باشد که این فریب، خسارت واقعی نسازد.
چرا تست کردن دفاع باید بخشی از فرآیند عادی باشد
دفاع در برابر Prompt Injection یک اقدام یکباره نیست؛ چون هم مدلها تغییر میکنند و هم روشهایی که ورودی مخرب سعی میکند Agent را فریب دهد. یک سازمان که در مدل CRMless یا هر شکل دیگری از Opsless کار میکند، باید بهطور منظم — نه فقط بعد از یک حادثه — سناریوهای دفاعی خود را بازبینی کند: آیا مرز بین داده و دستور هنوز رعایت میشود؟ آیا سطح مجوز Agent هنوز با کمترین دسترسی لازم منطبق است؟ آیا لایهٔ تأیید انسانی برای عملیات پرریسک هنوز فعال و مؤثر است؟ این بازبینیها بهتر است در چرخههای منظم (مثلاً فصلی) انجام شوند و نتیجهٔ آنها در همان Audit Trailی ثبت شود که برای سایر تصمیمهای عملیاتی استفاده میشود، تا مسئولیت و تاریخچهٔ این بازبینیها هم قابل ردیابی بماند.
مسئولیت مشترک بین ارائهدهندهٔ مدل و سازمان
یک نکتهٔ مهم در فهم درست این ریسک این است که دفاع در برابر Prompt Injection مسئولیت یک طرف تنها نیست. ارائهدهندهٔ مدل مسئول این است که مدل تا حد ممکن نسبت به تلاشهای فریب مقاوم باشد و ابزارهایی برای جداسازی داده از دستور در اختیار توسعهدهنده بگذارد. اما سازمانی که Agent را روی سیستمهای واقعی خودش وصل میکند، مسئول طراحی مدل مجوز، لایهٔ تأیید انسانی و مانیتورینگ است. اتکای کامل به «مدل بهاندازهٔ کافی هوشمند است که فریب نخورد» یک فرض خطرناک است؛ معماری امن، فرض میکند که یک لایه ممکن است شکست بخورد و لایهٔ بعدی باید جلوی گسترش آن خسارت را بگیرد.
جمعبندی
- هر متن ورودی از بیرون سازمان را غیرقابلاعتماد فرض کنید و آن را از پرامپت سیستمی بهطور معماری جدا نگه دارید.
- مدل مجوز کمترین دسترسی را برای هر Agent و هر task جداگانه تعریف کنید، نه یک دسترسی عمومی.
- اقدامات برگشتناپذیر یا حساس همیشه باید یک لایهٔ تأیید انسانی داشته باشند، مستقل از اطمینان مدل.
- رفتار غیرعادی Agent را بهصورت خودکار پایش و پیش از اجرا متوقف کنید.
- ریسک Prompt Injection را در فاز طراحی سیستم لحاظ کنید، نه بهعنوان یک پچ بعد از حادثه.
این مقاله بخشی از دورهٔ Opsless است.
