رمزنگاری تعیین می‌کند چه کسی پیام را در مسیر بخواند؛ کنترل دسترسی و طراحی عامل تعیین می‌کند دریافت‌کننده پس از خواندن آن چه کاری انجام دهد.
حمله Prompt Injection در پیام‌رسان زمانی رخ می‌دهد که متن یک پیام، دستیار هوش مصنوعی را به نادیده‌گرفتن قواعد اصلی و اجرای خواسته‌ای غیرمجاز ترغیب کند. رمزگذاری سرتاسری پیام را در مسیر محافظت می‌کند؛ اما اگر کاربر به یک ربات اجازه خواندن چت را داده باشد یا دستگاه آلوده شده باشد، رمزگذاری نمی‌تواند رفتار آن دریافت‌کننده مجاز را مهار کند.
نکات کلیدی
- رمزگذاری سرتاسری مانع خواندن پیام در مسیر می‌شود، نه سوءاستفاده دستیار مجازی که مجاز به دیدن متن رمزگشایی‌شده است.
- Prompt Injection غیرمستقیم می‌تواند داخل پیام خصوصی، فایل، کپشن یا محتوای نقل‌شده پنهان شود و پس از پردازش به دستور تبدیل شود.
- خطر نشت اطلاعات از AI Agent زمانی افزایش می‌یابد که عامل هم‌زمان به چت، حافظه، ابزارهای خارجی و امکان ارسال یا اجرای عملیات دسترسی داشته باشد.
- جداسازی داده از دستور، حداقل‌سازی مجوزها، تأیید انسانی و محدودکردن خروجی‌ها از مهم‌ترین لایه‌های دفاعی‌اند؛ هیچ‌یک به‌تنهایی تضمین کامل نمی‌دهد.
- طبق مستندات لیوارا، چت مستقیم و گروه خصوصیِ سازگار با وضعیت E2EE فعال رمزگذاری سرتاسری دارند؛ گروه قدیمی ناسازگار می‌تواند خارج از این پوشش بماند. این حفاظت رفتار دستیار پس از دریافت متن را تضمین نمی‌کند.
حمله Prompt Injection در پیام‌رسان چگونه کار می‌کند؟
Prompt Injection یا «تزریق دستور» یعنی مهاجم ورودی‌ای می‌سازد که مدل زبانی آن را به‌جای داده، به‌عنوان دستور بپذیرد و از سیاست اصلی منحرف شود. راهنمای OWASP درباره Prompt Injection ورودی مستقیم و محتوای بیرونی را از مسیرهای این خطر می‌داند. در سامانه عامل‌محور، انحراف پاسخ ممکن است به استفاده ناخواسته از ابزارهای متصل هم برسد.
در حمله مستقیم، کاربر خودش به ربات می‌گوید قواعد قبلی را کنار بگذارد. در حمله غیرمستقیم، دستور مخرب داخل محتوایی قرار می‌گیرد که دستیار برای انجام کار دیگری می‌خواند: پیام دریافتی، متن نقل‌شده، کپشن، سند یا خروجی یک ابزار. مهاجم در حالت دوم لازم نیست با عامل هوش مصنوعی حساب مشترک داشته باشد؛ کافی است محتوایش به زمینه‌ای برسد که عامل پردازش می‌کند.
برای نمونه، کاربر از دستیار می‌خواهد پیام‌های تازه را خلاصه کند. یکی از پیام‌ها حاوی متنی است که خود را «دستور سیستمی» جا می‌زند و از عامل می‌خواهد خلاصه‌سازی را متوقف کند، اطلاعات دیگری از زمینه بردارد و برای مقصدی خارجی بفرستد. موفقیت این سناریو قطعی نیست و به مدل، طراحی برنامه، دسترسی‌ها و کنترل‌های خروجی بستگی دارد؛ اما همان احتمال برای دستیار دارای ابزار اهمیت امنیتی دارد.
باید میان دست‌کاری پاسخ مدل و حمله به عامل دارای قابلیت اقدام تمایز گذاشت. پاسخ نادرست ممکن است آزاردهنده باشد؛ عاملی که اجازه ارسال پیام، بازیابی فایل یا فراخوانی سرویس دارد می‌تواند همان دست‌کاری را به افشای داده یا اقدام ناخواسته تبدیل کند.
چرا امنیت چت‌بات هوش مصنوعی فقط به رمزگذاری بستگی ندارد؟
امنیت چت‌بات هوش مصنوعی به کل زنجیره اعتماد بستگی دارد: پیام‌رسان، دستگاه، مدل، حافظه، ابزارها، سرور ارائه‌دهنده و سیاست مجوز. رمزگذاری سرتاسری فقط یک مرز مشخص را پوشش می‌دهد: جلوگیری از خواندن محتوای خصوصی در فاصله میان فرستنده و گیرندگان مجاز.
وقتی پیام به دستگاه مجاز می‌رسد، برای نمایش به کاربر رمزگشایی می‌شود. اگر دستیار روی همان دستگاه یا از طریق یک اتصال مجاز به متن دسترسی داشته باشد، داده را پس از رمزگشایی می‌بیند. از دید پروتکل، ربات یا برنامه دارای مجوز ممکن است یک دریافت‌کننده مشروع باشد؛ از دید کاربر، همان دریافت‌کننده می‌تواند بیش از حد اختیار داشته باشد.
این تفاوت را می‌توان چنین خلاصه کرد: رمزنگاری تعیین می‌کند چه کسی پیام را در مسیر بخواند؛ کنترل دسترسی و طراحی عامل تعیین می‌کند دریافت‌کننده پس از خواندن آن چه کاری انجام دهد. برای شناخت مرز نخست، راهنمای رمزگذاری سرتاسری و آنچه محافظت نمی‌کند توضیح می‌دهد که E2EE درمان بدافزار، گیرنده خائن یا نمایشگر آلوده نیست.
عبارت «پیام‌رسان رمزگذاری‌شده و هوش مصنوعی» نیز نباید به‌طور خودکار امن یا ناامن تعبیر شود. عامل محلی، بدون حافظه پایدار و فاقد ابزار خروجی، با ربات ابری دارای دسترسی به تاریخچه، فایل‌ها و حساب‌های خارجی یک سطح خطر ندارد. معماری و دامنه مجوز نتیجه را تعیین می‌کنند.
دسترسی دستیار هوش مصنوعی به چت خصوصی چه خطری ایجاد می‌کند؟
دسترسی دستیار هوش مصنوعی به چت خصوصی، محتوایی را که پیش‌تر فقط انسان‌های گفت‌وگو می‌دیدند وارد مرز اعتماد تازه‌ای می‌کند. خطر اصلی آن است که دستیار علاوه بر خواندن متن، بتواند آن را نگه دارد، با داده‌های دیگر ترکیب کند یا از کانالی دیگر بیرون بفرستد.
پیش از فعال‌کردن چنین قابلیتی باید پنج پرسش روشن پاسخ داده شود:
- دستیار دقیقاً کدام گفت‌وگوها، پیوست‌ها و بازه زمانی را می‌خواند؟
- پردازش روی دستگاه انجام می‌شود یا محتوا به سرور دیگری می‌رود؟
- ارائه‌دهنده چه داده‌ای را نگه می‌دارد و آیا از آن برای آموزش استفاده می‌کند؟
- عامل چه ابزارهایی برای ارسال پیام، بارگذاری فایل، جست‌وجو یا اجرای عملیات دارد؟
- آیا هر اقدام حساس به تأیید صریح کاربر نیاز دارد؟
مجوز «خواندن همه چت‌ها» برای قابلیتی که فقط باید یک پیام انتخاب‌شده را خلاصه کند، نقض اصل حداقل اختیار است. این اصل یعنی هر جزء فقط کمترین دسترسی لازم برای وظیفه جاری را دریافت کند. مجوز محدود به یک پیام، یک گفت‌وگو و یک نوبت، دامنه خسارت را کوچک‌تر می‌کند؛ هرچند محتوای همان محدوده همچنان می‌تواند حمله را هدف بگیرد.
فراداده نیز از محتوا جداست. طبق مستندات لیوارا، فراداده عملیاتی مانند فرستنده، مقصد و زمان‌های تحویل برای مسیریابی و همگام‌سازی ذخیره می‌شود. راهنمای فراداده پیام‌رسان و اطلاعاتی که آشکار می‌کند این مرز را شرح می‌دهد. یک دستیار ممکن است افزون بر متن، از الگوی تماس‌ها و زمان ارتباط نیز استنباط بسازد؛ بنابراین سیاست دسترسی باید هر دو را در نظر بگیرد.
نشت اطلاعات از AI Agent از چه مسیرهایی رخ می‌دهد؟
نشت اطلاعات از AI Agent معمولاً زمانی رخ می‌دهد که عامل محتوای محرمانه را در زمینه خود ببیند و راهی برای انتقال آن به مقصد دیگر داشته باشد. تزریق دستور به‌تنهایی داده را جابه‌جا نمی‌کند؛ نشت به ترکیب ورودی مخرب، دسترسی به داده و یک کانال خروجی وابسته است.
پیام یا فایل خروجی
عامل ممکن است اطلاعات را در پاسخ، پیام تازه، پیش‌نویس، فایل یا درخواست به یک سرویس خارجی قرار دهد. اگر سامانه خروجی را بدون محدودیت یا تأیید کاربر ارسال کند، مهاجم می‌تواند بکوشد داده محرمانه را به قالبی ظاهراً عادی تبدیل کند.
حافظه بلندمدت
بعضی عامل‌ها خلاصه گفت‌وگو، ترجیحات یا نتایج قبلی را برای استفاده بعدی نگه می‌دارند. دستور مخرب ممکن است تلاش کند داده‌ای را وارد حافظه کند یا در جلسه‌ای دیگر آن را بازیابی کند. عمر کوتاه حافظه، تفکیک کاربران و امکان مشاهده و حذف آن خطر را کم می‌کند، اما خطای مدل را از میان نمی‌برد.
فراخوانی ابزار
عامل دارای ابزار می‌تواند جست‌وجو کند، پرونده بخواند یا عملیات مجاز دیگری انجام دهد. خواندن فایل، ارسال پیام و درخواست شبکه باید مجوزهای مستقل داشته باشند. حتی نمایش خودکار یک لینک یا بارگذاری منبع خارجی در خروجی می‌تواند مسیر خروج داده ایجاد کند؛ نبود دکمه «ارسال» به‌تنهایی کافی نیست.
دستگاه آلوده
بدافزار دارای دسترسی کافی ممکن است متن نمایش‌داده‌شده، اعلان‌ها، حافظه برنامه یا ورودی کاربر را ببیند. در این وضعیت، مهاجم الزاماً به شکستن رمزگذاری نیاز ندارد؛ نقطه پایانی را دور می‌زند. حفاظت سیستم‌عامل، به‌روزرسانی، کنترل دسترسی و بررسی برنامه‌های نصب‌شده بخشی از دفاع‌اند، نه قابلیت‌های پروتکل پیام‌رسان.
رمزنگاری لیوارا در برابر این تهدید چه مرزی دارد؟
در مستندات امنیت لیوارا، LVR1 برای چت مستقیم و LGS1 برای گروه خصوصی سازگار توصیف شده‌اند. گروه قدیمی ناسازگار ممکن است آشکارا خارج از E2EE باشد؛ وضعیت همان گفتگو باید بررسی شود. کانال‌های عمومی نیز در محدوده چت خصوصی E2EE نیستند.
حتی در یک گفتگوی E2EE، اگر کاربر متن رمزگشایی‌شده را در اختیار دستیار قرار دهد، رمزنگاری پیام هدف پردازش بعدی را کنترل نمی‌کند. بررسی شماره ایمنی هم برای تأیید کلید مخاطب است، نه تشخیص دستور مخرب در متن او. این مقاله درباره یک کلاس عمومی از خطر است و وجود یا ایمنی یک اتصال مشخص هوش مصنوعی در لیوارا را تأیید نمی‌کند.
طرح مفهومی است، نه معماری تأییدشدهٔ لیوارا؛ قفل‌های تصویر ثابت نمی‌کنند دستیار به متن انتخاب‌شده دسترسی ندارد.
چه معماری‌ای Prompt Injection در پیام‌رسان را محدود می‌کند؟
معماری امن باید پیام دریافتی را داده غیرقابل‌اعتماد فرض کند، حتی اگر از یک مخاطب شناخته‌شده و داخل چت رمزگذاری‌شده آمده باشد. رمزگذاری اصالت مسیر را تقویت می‌کند؛ اما ثابت نمی‌کند محتوای فرستنده برای اجرای خودکار بی‌خطر است.
داده را از دستور جدا کنید
برنامه باید دستور ثابت توسعه‌دهنده، درخواست صریح کاربر و محتوای خوانده‌شده از چت را در لایه‌های جدا نگه دارد. هشدار NCSC درباره تزریق دستور تأکید می‌کند که نباید این مسئله را مانند SQL Injection دارای راه‌حل قطعی مشابه فرض کرد. برچسب‌گذاری محتوا به‌عنوان «داده غیرقابل‌اعتماد» مفید است، اما مدل‌های زبانی همیشه این مرز معنایی را بی‌خطا رعایت نمی‌کنند؛ پس جداسازی باید با کنترل بیرون از مدل همراه شود.
اختیار عامل را کم کنید
عامل خلاصه‌ساز به امکان ارسال خودکار پیام یا خواندن همه فایل‌ها نیاز ندارد. ابزارها باید فهرست مجاز، دامنه محدود، اعتبارنامه جدا و مهلت کوتاه داشته باشند. مجوز یک‌باره برای محتوای انتخاب‌شده بهتر از دسترسی دائمی است، زیرا هم احتمال دسترسی ناخواسته و هم دامنه نشت را کاهش می‌دهد.
خروجی را در یک دروازه قطعی بررسی کنید
مدل نباید خودش تصمیم نهایی درباره ارسال داده حساس را بگیرد. یک لایه غیرمولد می‌تواند مقصد، نوع داده، حجم خروجی و عملیات درخواستی را با قواعد قطعی بررسی کند. قواعد ساختاری و فهرست مقصدهای مجاز باید بیرون مدل اجرا شوند؛ تشخیص معنایی همه اطلاعات محرمانه همچنان می‌تواند خطا کند. ثبت کمینه رویداد، هشدار و امکان توقف نیز لازم است.
برای اقدام حساس تأیید انسانی بخواهید
خواندن پیش‌نویس با ارسال آن یکسان نیست. ارسال پیام، اشتراک فایل، افزودن عضو، تغییر تنظیمات حساب یا انتقال داده به سرویس خارجی باید پیش‌نمایش واضح و تأیید آگاهانه داشته باشد. تأییدهای مبهم یا پرتعداد به عادت کلیک‌کردن تبدیل می‌شوند؛ رابط باید دقیقاً داده، مقصد و نتیجه را نشان دهد.
عامل را در محیط محدود اجرا کنید
جداسازی فرایند، قطع دسترسی پیش‌فرض به شبکه، مخزن موقت و اعتبارنامه‌های کم‌دامنه اثر شکست را محدود می‌کند. این کنترل‌ها Prompt Injection را حذف نمی‌کنند؛ آن‌ها مانع می‌شوند یک پاسخ منحرف‌شده مستقیماً به دسترسی گسترده تبدیل شود.
کاربران و مدیران برای امنیت چت‌بات هوش مصنوعی چه کنند؟
کاربران باید هر اتصال هوش مصنوعی را یک گیرنده تازه برای داده خصوصی بدانند. مدیران نیز باید جریان داده و عملیات عامل را پیش از استقرار بررسی و در زمان اجرا پایش کنند.
برای استفاده شخصی:
- فقط پیام یا فایل لازم را انتخاب کنید؛ دسترسی به کل تاریخچه ندهید.
- محل پردازش، دوره نگهداری، استفاده آموزشی و روش حذف داده را بررسی کنید.
- ارسال خودکار پیام یا فایل را خاموش نگه دارید، مگر آن‌که ضرورت روشنی داشته باشد.
- دستگاه، مرورگر و برنامه‌ها را به‌روز نگه دارید و مجوزهای حساس را بازبینی کنید.
برای سازمان‌ها:
- مدل تهدیدی بنویسید که فرستنده مخرب، عضو گروه خائن، سرویس مدل، ابزار خارجی و دستگاه آلوده را جداگانه پوشش دهد.
- فراخوانی ابزار، تغییر مجوز، مقصد خروجی و تأیید کاربر را با کمترین داده حساس لازم ثبت کنید.
- ورودی‌های خصمانه را در پیام، سند، متن نقل‌شده، تصویر دارای متن و محتوای بازیابی‌شده آزمایش کنید.
- برای هر عامل سقف عملیات، نرخ درخواست، مقصدهای مجاز و کلید قطع اضطراری تعریف کنید.
- شکست ایمن را پیش‌فرض بگیرید: اگر سیاست مبهم بود، عامل باید متوقف شود، نه این‌که حدس بزند.
هیچ فهرستی ایمنی کامل نمی‌سازد. نتیجه به پیاده‌سازی، مدل، تنظیمات، رفتار کاربر و تحول روش‌های حمله بستگی دارد. هدف دفاع خوب کاهش اختیار، آشکارکردن انحراف و محدودکردن خسارت است.
آیا پیام‌رسان رمزگذاری‌شده و هوش مصنوعی می‌توانند با هم امن باشند؟
بله، پیام‌رسان رمزگذاری‌شده و هوش مصنوعی می‌توانند با ریسک کنترل‌شده کنار هم کار کنند، به شرط آن‌که دستیار کمترین دسترسی را داشته باشد و اقدام حساس بدون تأیید انجام ندهد. با این حال، اتصال هر مدل به محتوای خصوصی یک مرز اعتماد تازه ایجاد می‌کند و نباید زیر عنوان E2EE پنهان شود.
طراحی کم‌خطرتر پردازش را تا جای ممکن روی دستگاه نگه می‌دارد، زمینه را به انتخاب صریح کاربر محدود می‌کند، حافظه را کوتاه‌عمر می‌سازد و ابزارهای خروجی را جدا می‌کند. پردازش محلی نیز تضمین مطلق نیست: دستگاه آلوده، مدل ناامن یا مجوز گسترده همچنان خطر می‌آفریند.
کاربر باید بتواند بفهمد کدام داده به مدل می‌رود، مدل کجا اجرا می‌شود، چه مدت چیزی را نگه می‌دارد و چه کاری می‌تواند انجام دهد. اگر محصول پاسخ این پرسش‌ها را روشن نمی‌دهد، نباید از عبارت‌هایی مانند «هوش مصنوعی خصوصی» نتیجه امنیتی قطعی گرفت.
مستندات پروتکل یا تطبیق هش یک برنامه، آزمون امنیت یک دستیار متصل نیست. پیش از فعال‌کردن اتصال، مجوزها و مسیر داده همان قابلیت را جدا بررسی کنید. نتیجه یک آزمایش موفق نیز به‌تنهایی همه ورودی‌های آینده را پوشش نمی‌دهد.
پرسش‌های متداول
آیا رمزگذاری سرتاسری Prompt Injection را متوقف می‌کند؟
خیر. رمزگذاری سرتاسری پیام را میان فرستنده و گیرندگان مجاز از واسطه‌ها پنهان می‌کند. اگر یک ربات مجاز، برنامه روی دستگاه یا بدافزار به متن رمزگشایی‌شده دسترسی داشته باشد، می‌تواند آن را پردازش کند. مهار Prompt Injection به محدودسازی مجوز، ابزار، حافظه و خروجی عامل نیاز دارد.
آیا خلاصه‌کردن چت خصوصی با هوش مصنوعی خطرناک است؟
خطر به معماری بستگی دارد. خلاصه‌سازی محلی یک پیام انتخاب‌شده، بدون حافظه و ابزار خروجی، دامنه خطر کمتری از ربات ابری دارای دسترسی دائمی به همه چت‌ها دارد. پیش از استفاده، محل پردازش، نگهداری داده، دامنه مجوز و امکان ارسال خودکار را بررسی کنید.
آیا پیام یک مخاطب شناخته‌شده می‌تواند حامل Prompt Injection باشد؟
بله. اعتماد به هویت فرستنده با اعتماد به همه محتوای او یکسان نیست؛ حسابش ممکن است تسخیر شده باشد یا متن مخرب را ناخواسته بازفرستاده باشد. هر محتوایی که عامل می‌خواند باید داده غیرقابل‌اعتماد تلقی شود، حتی اگر داخل یک گفت‌وگوی اصالت‌سنجی‌شده و رمزگذاری‌شده باشد.
آیا LVR1 و LGS1 اطلاعات را از دستیار هوش مصنوعی پنهان می‌کنند؟
در گفتگوهایی که واقعاً با LVR1 یا LGS1 و وضعیت E2EE فعال محافظت می‌شوند، هدف این پروتکل‌ها پنهان‌کردن محتوا از واسطه‌های بدون کلید است. اگر کاربر یا برنامه به دستیار اجازه دهد پیام رمزگشایی‌شده را بخواند، این پروتکل‌ها آن دسترسی مجاز را مسدود نمی‌کنند. بنابراین امنیت دستیار باید جدا از امنیت انتقال پیام سنجیده شود.
نخستین اقدام برای کاهش نشت اطلاعات از AI Agent چیست؟
نخست دامنه دسترسی عامل را کم کنید: فقط پیام انتخاب‌شده، فقط در همان نوبت و بدون امکان ارسال خودکار. سپس برای عملیات حساس پیش‌نمایش و تأیید انسانی بگذارید، مقصدهای خروجی را محدود کنید و فراخوانی ابزارها را ثبت کنید. این لایه‌ها خطر را کاهش می‌دهند، اما تضمین مطلق نمی‌سازند.
