اگر هنوز امنیت اپلیکیشن‌های هوش مصنوعی خود را با یک لیست ساده از ریسک‌های احتمالی مثل «تزریق پرامپت» مدیریت می‌کنید، در واقع در حال بازی «بینگو» هستید، نه استراتژی امنیتی. برای ایمن‌سازی واقعی، مهندسان باید زنجیره‌ای ردیابی‌پذیر از دارایی‌های سیستم تا مسیرهای حمله عینی ترسیم کنند که قابل تست و تأیید باشند.
به نقل از راهنمای جامع منتشرشده در dev.to در ۱۹ اوت ۲۰۲۶، تفاوت تعیین‌کننده بین امنیت کلاسیک و امنیت هوش مصنوعی در نحوه تغییر نقش اطلاعات نهفته است. در یک اپلیکیشن استاندارد، داده‌ها پردازش می‌شوند؛ اما در یک اپلیکیشن هوش مصنوعی، داده‌ها اغلب خود به «سطح کنترل» تبدیل می‌شوند. در برنامه‌های کلاسیک، تحلیل امنیتی از ساختارهای آشنا پیروی می‌کند: کاربران ورودی می‌فرستند، منطق تجاری آن را پردازش می‌کند، پایگاه‌داده اطلاعات را تأمین یا ذخیره می‌کند و در نهایت یک پاسخ تولید می‌شود. اپلیکیشن‌های هوش مصنوعی هم ظاهر مشابهی دارند — شامل فرانت‌اند، بک‌اند، پایگاه‌داده، مدیریت هویت و APIها — اما دینامیک‌های داخلی آن‌ها کاملاً متفاوت است.
تصور کنید سندی در یک سیستم تولید بازیابی‌افزا (RAG) — شبیه دانش‌آموزی که قبل از جواب دادن، اول کتاب درسی را باز می‌کند و از آن نقل می‌آورد — قرار دارد. این سند ابتدا فقط یک محتوا است، اما به محض بازیابی، بخشی از زمینه یا پنجره متنی (Context Window) — مثل میز کاری که جا برای چند ورق دارد، نه برای کل کتابخانه — مدل می‌شود. در این لحظه، سند می‌تواند بر رفتار، اولویت‌ها و تصمیمات ابزاری مدل اثر بگذارد. همین گذار است که باعث می‌شود سیستم از تولید «مزاحمت‌های گاه‌وبی‌گاه» به اجازه دادن به «نقض واقعی دارایی‌ها» برسد. خروجی مدل نیز همین مسیر را طی می‌کند: ابتدا متنی است که بر اساس احتمالات تولید شده، اما اگر به یک فراخوانی ابزار، کوئری SQL، ایجاد تیکت یا ارسال ایمیل تبدیل شود، اثری واقعی در دنیای خارج می‌گذارد.
معماری اعتماد در هوش مصنوعی
امنیت سنتی بر محیط پیرامونی تمرکز دارد، اما امنیت هوش مصنوعی باید بر «مرزهای اعتماد» متمرکز شود؛ نقاطی که محتوای غیرقابل‌اعتماد امتیاز می‌گیرد یا خروجی مدل یک اقدام را تحریک می‌کند. یک مدل تهدید کاربردی، زنجیره‌ای ردیابی‌پذیر ایجاد می‌کند: سیستم $ \rightarrow $ دارایی‌ها $ \rightarrow $ جریان داده‌ها $ \rightarrow $ مرزهای اعتماد $ \rightarrow $ اهداف مهاجم $ \rightarrow $ سناریوهای سوءاستفاده $ \rightarrow $ مسیرهای حمله $ \rightarrow $ کنترل‌ها و تست‌ها.
برای اثربخشی، یک مدل تهدید باید به ۶ پرسش کلیدی پاسخ دهد:
- سیستم چیست؟ چه عملکردی دارد، چه کسی از آن استفاده می‌کند و کدام اجزای هوش مصنوعی درگیر هستند؟
- چه چیزی ارزش محافظت دارد؟ کدام داده‌ها، مجوزها، مکانیسم‌های کنترل، هویت‌ها و خروجی‌ها نباید افشا، دستکاری یا مورد سوءاستفاده قرار گیرند؟
- اطلاعات و تصمیمات چگونه جابه‌جا می‌شوند؟ کدام ورودی‌ها، بلوک‌های زمینه، نتایج ابزارها و خروجی‌های مدل بین اجزا جریان می‌یابند؟
- اعتماد یا اثر در کجا تغییر می‌کند؟ در چه نقاطی محتوای غیرقابل‌اعتماد اعتماد بیشتری کسب می‌کند یا به یک اقدام واقعی ترجمه می‌شود؟
- چه کسی با چه هدفی حمله می‌کند؟ مهاجمان واقعی چه کسانی هستند، چه توانایی‌هایی دارند و چه اثری را دنبال می‌کنند؟
- مسیرهای حمله عینی کدام‌اند؟ تحت چه پیش‌شرط‌هایی یک بازیگر می‌تواند از طریق کدام اجزا، یک دارایی را نقض کند؟
همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، تفکیک بین داده و دستور در محیط‌های هوش مصنوعی بسیار دشوارتر از سیستم‌های سنتی است.
درک هسته تخصصی هوش مصنوعی
در پردازش کلاسیک، زنجیره ساده است: ورودی $ \rightarrow $ منطق تجاری $ \rightarrow $ پایگاه‌داده $ \rightarrow $ خروجی. اما یک سیستم RAG پیچیده‌تر است: ورودی $ \rightarrow $ بازیابی $ \rightarrow $ انتخاب زمینه $ \rightarrow $ ترکیب پرامپت $ \rightarrow $ مدل $ \rightarrow $ خروجی. سیستم‌های عامل‌محور (Agentic) این زنجیره را گسترش می‌دهند: ورودی $ \rightarrow $ تصمیم مدل $ \rightarrow $ فراخوانی ابزار $ \rightarrow $ نتیجه ابزار $ \rightarrow $ تصمیم جدید مدل $ \rightarrow $ اقدام یا پاسخ. این پیچیدگی در زنجیره تصمیم‌گیری باعث شده تا عامل‌های هوش مصنوعی بتوانند حملات سایبری کاملی را بدون نظارت انسان اجرا کنند و ریسک‌های امنیتی را به سطح جدیدی ارتقا دهند.
در این معماری‌ها، رفتار مدل تحت تأثیر منابع مختلفی است: دستورات سیستم/توسعه‌دهنده، درخواست‌های کاربر، تاریخچه چت، تکه‌های بازیابی‌شده از اسناد، وب‌سایت‌های خارجی، نتایج ابزارها و خروجی‌های قبلی مدل. این منابع سطح اعتماد یا امتیاز یکسانی ندارند، اما اغلب در یک زمینه واحد ادغام می‌شوند، جایی که تفکیک فنی آن‌ها بسیار کمتر از منطق کلاسیک است.
از این ساختار دو اصل کلیدی استخراج می‌شود. نخست اینکه «زمینه می‌تواند کنترل غیرمستقیم باشد». متن یک سند می‌تواند حاوی دستورات اجرایی باشد و اگر یک بازیاب آن را وارد زمینه کند، می‌تواند اولویت‌ها و تصمیمات ابزاری مدل را تحت تأثیر قرار دهد. دوم اینکه «خروجی مدل یک مکانیسم کنترل قابل‌اعتماد نیست». چون خروجی احتمالی است، استفاده مستقیم از آن برای اجرای دستورات Shell یا کوئری‌های SQL خطرناک است. تایید اقدامات واقعی باید از طریق منطق قطعی (Deterministic) در خارج از مدل صورت گیرد.
نقشه‌برداری از مرزهای اعتماد
در یک دستیار پشتیبانی مبتنی بر RAG، چندین مرز بحرانی وجود دارد:
- ورودی کاربر $ \rightarrow $ سیستم داخلی: جایی که ورودی غیرقابل‌اعتماد کاربر وارد پردازش داخلی می‌شود. ریسک‌ها شامل تزریق مستقیم پرامپت، سوءاستفاده از منابع و دور زدن سیاست‌هاست.
- محتوای خارجی $ \rightarrow $ پایگاه دانش: جایی که اسناد، وب‌سایت‌ها یا ایمیل‌ها جذب سیستم می‌شوند. این نقطه ورود اصلی برای مسموم‌سازی محتوا و تزریق پرامپت غیرمستقیم است.
- زمینه بازیابی‌شده $ \rightarrow $ زمینه مدل: جایی که متن سند تأثیر مستقیم بر پاسخ‌های مدل و تصمیمات ابزاری پیدا می‌کند. این یکی از بحرانی‌ترین گذارهای تخصصی در هوش مصنوعی است.
- خروجی مدل $ \rightarrow $ فراخوانی ابزار: جایی که متن احتمالی به یک اقدام قطعی تبدیل می‌شود، مانند ایجاد یک تیکت پشتیبانی. ریسک‌ها شامل استفاده غیرمجاز از ابزار و مشکلات «نماینده گیج» (Confused Deputy) است.
- خروجی ابزار $ \rightarrow $ زمینه مدل: جایی که نتایج APIهای خارجی دوباره به LLM تغذیه می‌شوند و یک بردار حمله ثانویه ایجاد می‌کنند که می‌تواند حاوی محتوای دستکاری‌شده یا دستوری باشد.
- خروجی مدل $ \rightarrow $ پردازش پایین‌دستی/رندرینگ: جایی که خروجی به صورت HTML یا Markdown نمایش داده می‌شود و ریسک رندرینگ ناامن یا اعتماد کورکورانه به محتوای تولیدشده را دارد.
- مستاجر/نشست $ \rightarrow $ اجزای مشترک: جایی که ذخیره‌سازهای برداری مشترک یا لایه‌های حافظه باید به شدت ایزوله شوند تا از مشاهده داده‌های متقاطع بین مستاجران جلوگیری شود.
بازتعریف دارایی‌های هوش مصنوعی
امنیت زمانی شکست می‌خورد که تیم‌ها با «داده» به عنوان یک دسته‌بندی واحد برخورد کنند. یک دفترچه راهنمای داخلی، یک پرامپت سیستمی و یک مجوز ارسال ایمیل، هر سه متنی هستند اما از نظر امنیتی کاملاً متفاوت‌اند.
دارایی‌های کنترلی (Control Assets) تعیین می‌کنند سیستم چگونه رفتار کند. این‌ها شامل پرامپت‌های سیستمی، دستورات توسعه‌دهنده، قالب‌های پرامپت، گاردریل‌ها، سیاست‌ها، قوانین ابزار و منطق ترکیب زمینه هستند. اگر این‌ها دستکاری شوند، کل هدف سیستم می‌تواند تغییر کند یا مرزها دور زده شوند. این دارایی‌ها به یکپارچگی، محرمانگی و دقت در کنترل نیاز دارند.
دارایی‌های قابلیتی (Capability Assets) مجوزهای واقعی هستند که یک عامل در اختیار دارد. این شامل ایجاد تیکت، دسترسی به CRM و پایگاه‌داده، ارسال ایمیل، دسترسی به فایل‌ها، تغییرات تقویم و مجوزهای API است. یک مدل غیرقابل‌اعتماد آزاردهنده است، اما مدلی با مجوزهای سطح بالا، یک ریسک بحرانی است. هدف در اینجا احراز صلاحیت، اصل حداقل دسترسی و ردیابی‌پذیری است.
دارایی‌های زمینه (Context Assets) شاید منحصر‌به‌ترین دارایی‌ها در هوش مصنوعی باشند. این‌ها شامل تکه‌های بازیابی‌شده، تاریخچه چت، حافظه نشست، زمینه کاربر و زمینه نهایی اسمبل‌شده مدل هستند. چون زمینه تصمیمات را هدایت می‌کند و کنترل غیرمستقیم ایجاد می‌کند، یکپارچگی، منشأ (Provenance) و جداسازی آن بین کاربران، اهداف امنیتی مستقلی هستند.
دارایی‌های داده‌ای (Data Assets) شامل اسناد دانش داخلی، درخواست‌های کارکنان، تاریخچه‌های چت، تیکت‌های پشتیبانی، کلیدهای API و اسرار (Secrets) هستند. اهداف اصلی در اینجا محرمانگی، یکپارچگی و جداسازی مستاجران است.
دارایی‌های خروجی (Output Assets) شامل پاسخ‌های تولیدشده، محتوای تیکت‌ها، SQL، کد یا داده‌های ساختاریافته‌ای است که به طور خودکار پردازش می‌شوند. این‌ها برای اطمینان از اینکه اقدامات غیرمجاز را تحریک نمی‌کنند، به یکپارچگی و پردازش امن پایین‌دستی نیاز دارند.
دارایی‌های هویت و نشست (Identity and Session Assets) شامل پیوند بین کاربر، نشست، مستاجر و محدوده بازیابی است. این شامل نقش‌ها، ادعاها (Claims)، توکن‌های دسترسی و هویتی است که یک ابزار به نام آن فراخوانی می‌شود. خطا در اینجا باعث می‌شود مدل از نظر فنی درست عمل کند اما با هویت یا محدوده دسترسی اشتباه.
از سناریوهای سوءاستفاده تا مسیرهای حمله
یک «سناریوی سوءاستفاده» توصیف می‌کند که یک تابع چگونه مورد سوءاستفاده قرار می‌گیرد، اما «مسیر حمله» توالی فنی گام‌ها را ارائه می‌دهد. یک سناریو باید بازیگر، هدف، پیش‌شرط، مرز مورد سوءاستفاده و اثر مورد انتظار را تعریف کند.
تعریف مهاجمان
مهاجمان یکپارچه نیستند و شامل گروه‌های زیر می‌شوند:
- کاربران خارجی: دسترسی عادی و ارسال درخواست‌های تکرار شونده.
- تأمین‌کنندگان محتوای مخرب: کسانی که اسناد یا وب‌سایت‌هایی را کنترل می‌کنند که سیستم آن‌ها را جذب (Ingest) می‌کند (بسیار حیاتی برای تزریق غیرمستقیم).
- افراد داخلی: کاربرانی قانونی که سعی در گسترش دید یا دور زدن سیاست‌ها دارند.
- مهاجمان مستاجری: کاربرانی که سعی می‌کنند تکه‌ها یا نشست‌های متعلق به دیگران را ببینند.
- مهاجمان منابع غیرمستقیم: کسانی که پاسخ‌های API یا نتایج ابزارها را تحت تأثیر قرار می‌دهند.
یک مسیر حمله، نقطه ورود را از طریق توالی گام‌ها به اثر نهایی متصل می‌کند.
مثال ۱: بازیابی ناقص در RAG
۱. کاربر درخواست‌های مهندسی‌شده می‌فرستد $ \rightarrow $ ۲. بک‌اند کوئری بازیابی را می‌سازد $ \rightarrow $ ۳. بازیاب در اعمال فیلترهای مستاجر شکست می‌خورد $ \rightarrow $ ۴. تکه‌های غیرمجاز وارد سازنده پرامپت می‌شوند $ \rightarrow $ ۵. مدل داده‌های محرمانه را در پاسخ می‌گنجاند.
مثال ۲: تزریق پرامپت غیرمستقیم
۱. تأمین‌کننده مخرب سندی حاوی دستورات می‌کارد $ \rightarrow $ ۲. خط لوله ورود داده‌ها، محتوا را ایندکس می‌کند $ \rightarrow $ ۳. پرس‌وجوی کاربر باعث بازیابی تکه دستکاری‌شده می‌شود $ \rightarrow $ ۴. سازنده پرامپت، تکه را وارد زمینه می‌کند $ \rightarrow $ ۵. مدل دستورات را اجرایی می‌بیند $ \rightarrow $ ۶. قصد ابزار یا پاسخ تحت تأثیر قرار می‌گیرد.
مثال ۳: سوءاستفاده از ابزار
۱. کاربر درخواستی فریبنده می‌فرستد $ \rightarrow $ ۲. مدل قصد ایجاد تیکت را تولید می‌کند $ \rightarrow $ ۳. واسط ابزار، تصمیم را بدون بررسی سیاست‌ها می‌پذیرد $ \rightarrow $ ۴. سیستم تیکت اقدام را با هویت سرویس اجرا می‌کند $ \rightarrow $ ۵. تیکت غیرمجاز ایجاد می‌شود.
قابلیت اطمینان در برابر امنیت
هر شکست در هوش مصنوعی، یک حادثه امنیتی نیست. یک توهم (Hallucination) — وقتی مدل با اطمینان چیزی می‌گوید که اصلاً وجود ندارد — که منجر به خلاصه‌ای غلط شود، یک مشکل «قابلیت اطمینان» است. این موضوع تنها زمانی به مسئله امنیتی تبدیل می‌شود که یک دارایی محافظت‌شده یا یک مرز اعتماد را تحت تأثیر قرار دهد.
یک «مورد ترکیبی» را در نظر بگیرید: نتیجه بازیابی ناقصی که تصادفاً داده‌های مستاجر دیگری را می‌کشد. خطای بازیابی یک شکست در کیفیت است، اما نشت داده‌های حاصل از آن، یک نقض امنیتی است. به همین ترتیب، انتخاب اشتباه ابزار که یک اقدام واقعی را تحریک کند، یک مورد ترکیبی است. خطر زمانی ایجاد می‌شود که دارایی‌ها، حقوق یا مرزهای اعتماد رد شوند. همان‌طور که در این راهنما اشاره شده: «هر عمل احمقانه، یک حادثه امنیتی نیست».
پیاده‌سازی کنترل‌های قابل تأیید
کنترل‌ها باید از مسیرهای حمله استخراج شوند، نه از یک چک‌لیست کلی.
کنترل‌های بازیابی و RAG
- اعمال فیلترهای ACL و مستاجر قبل از بازیابی.
- استفاده از بررسی محدوده در سمت سرور به جای کنترل دسترسی مبتنی بر پرامپت.
- انجام احراز صلاحیت پس از بازیابی و قبل از گنجاندن در زمینه.
- طبقه‌بندی منابع اسناد و ایجاد حاکمیت بر ورود داده‌ها.
- برچسب‌گذاری تکه‌ها بر اساس منبع، مستاجر و مالک برای بهینه‌سازی حجم زمینه.
- انجام تست‌ها برای بازیابی غیرمجاز و گنجاندن غیرمجاز در زمینه.
کنترل‌های پرامپت و زمینه
- تفکیک صریح محتوای سیستمی، کاربر، سند و ابزار.
- برچسب‌گذاری زمینه‌های غیرقابل‌اعتماد و نسخه‌بندی قالب‌های پرامپت.
- عدم اتکا به پرامپت برای تصمیمات مربوط به مجوزها.
- پیوند سخت تاریخچه چت و حافظه به هویت و محدوده دسترسی.
- حذف اسرار غیرضروری و متادیتای داخلی از زمینه.
کنترل‌های ابزار و خروجی
- احراز صلاحیت باید خارج از مدل و توسط یک موتور سیاست خارجی انجام شود.
- استفاده از مجوزهای «حداقل دسترسی» برای هر ابزار و لیست سفید پارامترها.
- پیاده‌سازی اعتبارسنجی طرح‌واره (Schema) و مراحل تأیید برای اقدامات حساس.
- پاک‌سازی خروجی‌ها برای جلوگیری از اجرای مستقیم کدهای SQL یا Shell و رندرینگ ناامن HTML/Markdown.
- استفاده از بازبینی انسانی برای پاسخ‌ها و اقدامات حساس.
- پیاده‌سازی محدودیت‌های نرخ (Rate Limit)، بودجه و لاگ‌های حسابرسی متصل به کاربر و سیاست.
کنترل‌های هویت و نشست
- متمرکز کردن تصمیمات هویت و محدوده در سمت سرور.
- عدم پذیرش تخصیص کاربر یا مستاجر از خروجی مدل.
- پیوند دادن بازیابی، فراخوانی ابزار و لاگ‌ها به یک زمینه امنیتی واحد.
- ایزوله کردن تاریخچه‌های چت، حافظه‌ها و کش‌ها.
مسیر تست و تأیید
یک مدل تهدید تنها زمانی موفق است که قابل تست باشد. این مدل یک پل ایجاد می‌کند: مدل تهدید $ \rightarrow $ فرضیه $ \rightarrow $ مورد تست $ \rightarrow $ شواهد $ \rightarrow $ یافته. به جای پرسیدن «آیا مدل امن است؟»، مهندسان باید پرسش‌های خاص و فرضیه‌محور بپرسند:
- آیا کاربر می‌تواند نتایج بازیابی را خارج از محدوده اختصاص‌یافته‌اش تحت تأثیر قرار دهد؟
- آیا تکه‌های غیرمجاز قبل از رسیدن به زمینه مدل حذف می‌شوند؟
- آیا مدل می‌تواند محتوای تکه‌های غیرمجاز را حتی با درخواست‌های بازنویسی‌شده بازتولید کند؟
- آیا مدل می‌تواند ابزاری را بدون احراز صلاحیت معتبر در سمت سرور تحریک کند؟
- آیا پارامترهای ابزار در برابر حقوق کاربر و مقادیر مجاز بررسی می‌شوند؟
- آیا نتیجه یک ابزار می‌تواند اقدامات تکمیلی غیرمجاز جدیدی را تحریک کند؟
- آیا لاگ حسابرسی به درستی اقدام ابزار را به نشست کاربر خاص و تصمیم سیاست متصل می‌کند؟
این تغییر رویکرد، امنیت هوش مصنوعی را از بازی «پرامپت‌های هوشمندانه» به یک دیسیپلین مهندسی دقیق تبدیل می‌کند. با ترسیم جریان از بازیگر به دارایی، تیم‌ها می‌توانند ثابت کنند که کنترل‌های آن‌ها واقعاً مسیرهای حمله شناسایی‌شده را می‌بندند.
گفتگو