شکاف پنهان در قلب مدل‌های زبانی؛ چرا هک LLMها شاید هرگز کاملاً متوقف نشود؟

پژوهشی ارائه‌شده در کنفرانس بین‌المللی یادگیری ماشین، ICML، در مرداد ۱۴۰۵ نشان داد که مدل‌های زبانی بزرگ، از جمله چت‌بات‌ها و عامل‌های هوشمند، ممکن است به‌دلیل یک ضعف بنیادی در معماری پردازش دستورها، هرگز به‌طور کامل در برابر حملات Prompt Injection و Jailbreak ایمن نشوند.

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

مدل‌های زبانی بزرگ مثل ChatGPT، Claude، Gemini، DeepSeek و مدل‌های متن‌باز، متن را به‌صورت یک جریان پیوسته از توکن‌ها می‌بینند. برای اینکه مدل بداند هر بخش از متن متعلق به چه کسی است، از برچسب‌هایی مانند System، User، Assistant، Tool یا Think استفاده می‌شود.

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

به این نوع حمله، «جعل زنجیره تفکر» یا Chain-of-Thought Forgery گفته شد.

ویل داگلاس هیون در گزارشی که در تاریخ ۸ مرداد ۱۴۰۵ منتشر شد، نوشت گروهی از پژوهشگران در مقاله‌ای که همان ماه در کنفرانس ICML ارائه شده بود، ادعا کردند ایمن‌سازی کامل مدل‌های زبانی بزرگ در برابر هک و سوءاستفاده ممکن است از اساس ناممکن باشد.

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

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

چارلز یه، پژوهشگر مستقل و یکی از نویسندگان مقاله ICML، گفته بود احتمال واقعی وجود دارد که این مشکل از نظر بنیادی قابل حل کامل نباشد.

شرکت‌های توسعه‌دهنده مدل معمولاً تیم‌هایی از آزمونگران انسانی را استخدام می‌کنند تا روش‌های جدید حمله به مدل‌ها را پیدا کنند. این فرآیند با عنوان Red Teaming شناخته می‌شود. همچنین بعضی شرکت‌ها از مدل‌های پیشرفته برای یافتن ضعف‌های مدل‌های دیگر استفاده می‌کنند؛ برای نمونه، OpenAI پیش‌تر از سامانه‌هایی برای خودکارسازی بخشی از فرایند کشف آسیب‌پذیری استفاده کرده بود.

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

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

زنجیره تفکر یا Chain of Thought نوعی فضای استدلال داخلی یا یادداشت‌برداری مرحله‌ای است که مدل‌ها برای حل مسئله از آن استفاده می‌کنند. در بسیاری از مدل‌های مدرن، این بخش برای کاربر نهایی نمایش داده نمی‌شود، اما در فرآیند آموزش و رفتار مدل نقش مهمی دارد.

این نوع حمله که پژوهشگران آن را Chain-of-Thought Forgery یا جعل زنجیره تفکر نامیدند، در هکاتون Red Teaming شرکت OpenAI در مرداد ۱۴۰۴ برنده شده بود. به‌طور جالب، پژوهشگران دیگری در OpenAI نیز تقریباً هم‌زمان حمله مشابهی را شناسایی کرده بودند و آن را Fake Chain of Thought نامیده بودند.

نقش‌ها در مدل‌های زبانی چیستند؟

برای درک این آسیب‌پذیری باید مفهوم Role یا نقش در مدل‌های زبانی را شناخت.

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

برای جداکردن این بخش‌ها، سامانه‌های چت‌بات معمولاً از نقش‌هایی مانند موارد زیر استفاده می‌کنند:

• System: دستورهای اصلی و سطح بالای سازنده مدل یا اپلیکیشن
• User: ورودی کاربر
• Assistant: پاسخ تولیدشده توسط مدل
• Tool: اطلاعات برگرفته از ابزارها، APIها، جست‌وجوی وب یا سیستم‌های خارجی
• Think: یادداشت‌ها یا زنجیره تفکر داخلی مدل، در مدل‌هایی که چنین ساختاری دارند

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

چرا این موضوع برای کسب‌وکارها مهم است؟

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

اگر یک مدل فقط پاسخ متنی تولید کند، ریسک محدودتر است. اما وقتی LLM به ابزارهایی مثل ایمیل، CRM، پایگاه داده، سیستم مالی، داشبورد مدیریتی، APIهای داخلی یا عامل‌های اجرایی متصل می‌شود، Prompt Injection می‌تواند به یک تهدید عملیاتی تبدیل شود.

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

جدول مقایسه: انواع حملات رایج به LLM

راهکارهای عملی برای کاهش ریسک امنیت LLM

۱. مدل زبانی را منبع قابل اعتماد مطلق ندانید

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

در کاربردهای حساس، خروجی مدل باید پیشنهاد باشد، نه فرمان نهایی.

۲. داده و دستور را از هم جدا کنید

یکی از خطاهای رایج در طراحی سامانه‌های مبتنی بر LLM این است که متن کاربر، داده‌های بازیابی‌شده، محتوای وب و دستورهای سیستمی همگی در یک پرامپت طولانی قرار می‌گیرند.

بهتر است معماری پیام‌ها به‌گونه‌ای طراحی شود که:

• دستورهای سیستمی جدا از داده‌های خارجی باشند
• محتوای ابزارها فقط به‌عنوان داده پردازش شود
• مدل اجازه نداشته باشد از داده خارجی به‌عنوان دستور اجرایی پیروی کند
• دستورهای ابزار با schema مشخص و اعتبارسنجی‌شده ارسال شوند

۳. دسترسی عامل‌های هوشمند را محدود کنید

اگر یک AI Agent به ابزارهایی مانند ایمیل، فایل، دیتابیس، پرداخت، CRM یا APIهای عملیاتی متصل است، نباید دسترسی کامل داشته باشد.

اصل حداقل دسترسی یا Least Privilege باید رعایت شود. عامل هوشمند فقط باید به همان ابزارهایی دسترسی داشته باشد که برای همان وظیفه خاص نیاز دارد.

برای اقدامات پرریسک، تأیید انسانی ضروری است.

۴. خروجی ابزارها را غیرقابل اعتماد فرض کنید

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

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

۵. Red Teaming را به فرآیند دائمی تبدیل کنید

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

تیم‌ها باید سناریوهای زیر را به‌طور مداوم تست کنند:

• حملات Prompt Injection
• حملات Jailbreak
• داده‌های آلوده در RAG
• نشت اطلاعات محرمانه
• انحراف عامل‌های خودکار
• سوءاستفاده از ابزارهای متصل به مدل
• حملات چندمرحله‌ای در مکالمه طولانی

۶. لاگ‌برداری و مانیتورینگ رفتاری را جدی بگیرید

فقط ذخیره ورودی و خروجی کافی نیست. باید رفتار مدل، تصمیم‌های ابزار، فراخوانی API، تغییر نقش‌ها و دستورات حساس نیز ثبت شوند.

در سیستم‌های سازمانی، بهتر است برای رویدادهای زیر هشدار تعریف شود:

• درخواست دسترسی به داده حساس
• تغییر ناگهانی هدف مکالمه
• تلاش برای نادیده‌گرفتن دستورهای قبلی
• درخواست اجرای ابزار خارج از سناریوی مجاز
• درخواست استخراج یا ارسال اطلاعات محرمانه

۷. برای کاربردهای حساس از معماری چندلایه استفاده کنید

در سامانه‌های حساس، یک مدل نباید هم تصمیم بگیرد، هم ابزار را اجرا کند، هم نتیجه را تأیید کند. بهتر است معماری چندلایه طراحی شود:

• یک لایه برای فهم درخواست
• یک لایه برای طبقه‌بندی ریسک
• یک لایه برای بررسی سیاست‌ها
• یک لایه برای اجرای محدود ابزارها
• یک لایه برای تأیید انسانی در موارد پرریسک

این معماری هزینه توسعه را افزایش می‌دهد، اما برای سیستم‌های مالی، سلامت، حقوقی، دولتی، صنعتی و امنیتی ضروری است.

چک‌لیست امنیتی برای تیم‌های فنی LLM

• آیا ورودی کاربر از داده خارجی جدا شده است؟
• آیا محتوای RAG به‌عنوان داده غیرقابل اعتماد پردازش می‌شود؟
• آیا مدل به ابزارهای حساس دسترسی مستقیم دارد؟
• آیا برای اقدامات پرریسک تأیید انسانی وجود دارد؟
• آیا لاگ کامل فراخوانی ابزارها ذخیره می‌شود؟
• آیا تست Prompt Injection به‌صورت دوره‌ای انجام می‌شود؟
• آیا سیاست‌های ایمنی فقط در System Prompt نوشته شده‌اند یا در لایه‌های نرم‌افزاری هم اعمال می‌شوند؟
• آیا داده‌های محرمانه قبل از ورود به مدل ماسک یا حذف می‌شوند؟
• آیا خروجی مدل قبل از اجرا اعتبارسنجی می‌شود؟
• آیا سناریوهای حمله چندمرحله‌ای تست شده‌اند؟

چرا آموزش بهتر به‌تنهایی کافی نیست؟

مدل‌سازان معمولاً تلاش می‌کنند با آموزش بیشتر، داده‌های Red Teaming و تنظیم سیاست‌های ایمنی، مدل را در برابر حملات مقاوم‌تر کنند. این روش مفید است، اما طبق ادعای پژوهشگران کافی نیست.

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

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

جمع‌بندی

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

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

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

خلاصه کوتاه

موضوع اصلی این گزارش، امنیت مدل‌های زبانی بزرگ و آسیب‌پذیری آن‌ها در برابر حملات Prompt Injection، Jailbreak و Chain-of-Thought Forgery است. پژوهشی ارائه‌شده در کنفرانس ICML در مرداد ۱۴۰۵ نشان داد مدل‌های زبانی ممکن است در تشخیص منبع واقعی دستورها ضعف بنیادی داشته باشند. این ضعف باعث می‌شود مدل گاهی متن کاربر، داده خارجی، خروجی ابزار یا متن شبیه زنجیره تفکر را به‌اشتباه به‌عنوان دستور معتبر تفسیر کند.

مهم‌ترین پیام برای سازمان‌ها این است که LLM نباید به‌عنوان جزء کاملاً قابل اعتماد در سیستم‌های حساس استفاده شود. راهکارهای پیشنهادی شامل جداسازی داده از دستور، محدودسازی دسترسی ابزارها، اجرای اصل حداقل دسترسی، Red Teaming مداوم، مانیتورینگ رفتاری، اعتبارسنجی خروجی ابزارها، کنترل انسانی برای اقدامات حساس و طراحی معماری چندلایه امنیتی است.

این موضوع برای کسب‌وکارهایی که از AI Agent، RAG، چت‌بات سازمانی، اتوماسیون فروش، پشتیبانی مشتری، تحلیل داده و سیستم‌های تصمیم‌یار استفاده می‌کنند اهمیت بالایی دارد.

نویسنده : Will Douglas Heaven

سوالات متداول سئو شده

آیا مدل‌های زبانی بزرگ کاملاً قابل ایمن‌سازی هستند؟

طبق پژوهش منتشرشده در ICML، ممکن است ایمن‌سازی کامل LLMها در برابر برخی حملات از نظر بنیادی دشوار یا حتی ناممکن باشد. با این حال، می‌توان ریسک را با معماری امن، کنترل دسترسی، تست مداوم و پایش رفتاری به‌طور جدی کاهش داد.

Prompt Injection چیست؟

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

Chain-of-Thought Forgery چیست؟

Chain-of-Thought Forgery یا جعل زنجیره تفکر، حمله‌ای است که در آن متن ورودی طوری نوشته می‌شود که شبیه یادداشت‌های استدلالی یا زنجیره تفکر داخلی مدل به نظر برسد. در برخی موارد، مدل ممکن است این متن را معتبرتر از ورودی عادی کاربر تفسیر کند.

آیا RAG هم در برابر این حملات آسیب‌پذیر است؟

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

بهترین راهکار برای امنیت AI Agent چیست؟

بهترین رویکرد، ترکیب چند کنترل است: محدودسازی ابزارها، اجرای اصل حداقل دسترسی، تأیید انسانی برای اقدامات حساس، ثبت کامل رویدادها، تست امنیتی مداوم و جلوگیری از اجرای مستقیم خروجی مدل بدون اعتبارسنجی.