امنیت AI در نرم‌افزارهای سازمانی؛ از نشت اطلاعات تا Prompt Injection

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

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

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

پیش از انتخاب راهکار امنیتی، مسیر داده و اختیار AI را بشناسیم

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

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

نشت اطلاعات فقط به متن نهایی پاسخ محدود نیست

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

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

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

Prompt Injection چیست و چه تفاوتی با یک درخواست عادی دارد؟

مدل زبانی هم دستورهای برنامه و هم محتوای کاربر یا اسناد را در قالب اطلاعات زبانی پردازش می‌کند. Prompt Injection زمانی مطرح می‌شود که ورودی تلاش کند رفتار مورد انتظار را تغییر دهد؛ مثلاً محتوایی که باید فقط بررسی شود، نقش دستور برای دسترسی یا اقدام تازه پیدا کند. هر پاسخ اشتباه یا هر سؤال غیرمعمول، به‌تنهایی نشانهٔ وقوع این نوع حمله نیست.

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

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

چرا System Prompt و فیلتر محتوا به‌تنهایی کافی نیستند؟

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

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

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

مجوز دسترسی باید در برنامه اعمال شود، نه با تشخیص مدل

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

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

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

دستیار متصل به ابزار چگونه باید اختیار محدود و قابل بررسی داشته باشد؟

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

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

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

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

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

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

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

خروجی مدل باید پیش از نمایش یا اجرا اعتبارسنجی شود

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

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

استفاده از مدل ابری یا محلی چه چیزی را در ارزیابی امنیت تغییر می‌دهد؟

در سرویس ابری باید شرایط واقعی همان ارائه‌دهنده و همان محصول بررسی شود: چه داده‌ای ارسال می‌شود، چه مدت نگهداری می‌شود، چه استفاده‌ای از آن مجاز است و چه تنظیماتی برای ثبت و حذف وجود دارد؟ نباید شرایط یک ابزار مصرفی را به API سازمانی تعمیم داد یا فرض کرد همهٔ سرویس‌ها رفتار یکسانی دارند. این موارد باید هنگام انتخاب و در تغییرات بعدی بازبینی شوند.

اجرای محلی می‌تواند کنترل بیشتری بر بعضی مسیرهای داده بدهد، اما مسئلهٔ مجوز، Prompt Injection، Log و امنیت ابزارها را حذف نمی‌کند. نگهداری زیرساخت، به‌روزرسانی و دسترسی مدیران نیز مسئولیت ایجاد می‌کند. انتخاب باید با حساسیت داده، توان تیم و هزینهٔ عملیاتی متناسب باشد؛ محل اجرای مدل فقط یکی از اجزای تصمیم است.

چگونه امنیت AI را با آزمون‌های قابل ارزیابی بررسی کنیم؟

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

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

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

پایش و واکنش به رخداد بدون ثبت بی‌رویهٔ اطلاعات حساس

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

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

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

جدول ارزیابی ریسک و کنترل مناسب در پروژهٔ سازمانی

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

یک سناریوی فرضی؛ دستیار پاسخ‌گویی برای تیم پشتیبانی

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

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

امنیت AI باید در محدودهٔ پروژه و مسئولیت نگهداری دیده شود

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

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