رمزنگاری تعیین میکند چه کسی پیام را در مسیر بخواند؛ کنترل دسترسی و طراحی عامل تعیین میکند دریافتکننده پس از خواندن آن چه کاری انجام دهد.
حمله Prompt Injection در پیامرسان زمانی رخ میدهد که متن یک پیام، دستیار هوش مصنوعی را به نادیدهگرفتن قواعد اصلی و اجرای خواستهای غیرمجاز ترغیب کند. رمزگذاری سرتاسری پیام را در مسیر محافظت میکند؛ اما اگر کاربر به یک ربات اجازه خواندن چت را داده باشد یا دستگاه آلوده شده باشد، رمزگذاری نمیتواند رفتار آن دریافتکننده مجاز را مهار کند.
نکات کلیدی
- رمزگذاری سرتاسری مانع خواندن پیام در مسیر میشود، نه سوءاستفاده دستیار مجازی که مجاز به دیدن متن رمزگشاییشده است.
- Prompt Injection غیرمستقیم میتواند داخل پیام خصوصی، فایل، کپشن یا محتوای نقلشده پنهان شود و پس از پردازش به دستور تبدیل شود.
- خطر نشت اطلاعات از AI Agent زمانی افزایش مییابد که عامل همزمان به چت، حافظه، ابزارهای خارجی و امکان ارسال یا اجرای عملیات دسترسی داشته باشد.
- جداسازی داده از دستور، حداقلسازی مجوزها، تأیید انسانی و محدودکردن خروجیها از مهمترین لایههای دفاعیاند؛ هیچیک بهتنهایی تضمین کامل نمیدهد.
- در Livara، چتهای مستقیم LVR1 و گروههای خصوصی LGS1 سرتاسری رمزگذاری میشوند؛ کانالهای عمومی عمداً رمزگذاری سرتاسری ندارند و فراداده مسیریابی نیز ذخیره میشود.
حمله Prompt Injection در پیامرسان چگونه کار میکند؟
Prompt Injection یا «تزریق دستور» یعنی مهاجم ورودیای میسازد که مدل زبانی آن را بهجای داده، بهعنوان دستور بپذیرد و از سیاست اصلی منحرف شود. مقاله Prompt Injection 2.0: Hybrid AI Threats این مسئله را بهویژه در سامانههای عاملمحور خطرناک میداند؛ زیرا مدل میتواند بهجای تولید متن، چند گام عملی را با ابزارهای متصل انجام دهد.
در حمله مستقیم، کاربر خودش به ربات میگوید قواعد قبلی را کنار بگذارد. در حمله غیرمستقیم، دستور مخرب داخل محتوایی قرار میگیرد که دستیار برای انجام کار دیگری میخواند: پیام دریافتی، متن نقلشده، کپشن، سند یا خروجی یک ابزار. مهاجم در حالت دوم لازم نیست با عامل هوش مصنوعی حساب مشترک داشته باشد؛ کافی است محتوایش به زمینهای برسد که عامل پردازش میکند.
برای نمونه، کاربر از دستیار میخواهد پیامهای تازه را خلاصه کند. یکی از پیامها حاوی متنی است که خود را «دستور سیستمی» جا میزند و از عامل میخواهد خلاصهسازی را متوقف کند، اطلاعات دیگری از زمینه بردارد و برای مقصدی خارجی بفرستد. موفقیت این سناریو قطعی نیست و به مدل، طراحی برنامه، دسترسیها و کنترلهای خروجی بستگی دارد؛ اما همان احتمال برای دستیار دارای ابزار اهمیت امنیتی دارد.
مرور پژوهشی MDPI درباره Prompt Injection میان دستکاری پاسخ مدل و حمله به عامل دارای قابلیت اقدام تمایز عملی ایجاد میکند. پاسخ نادرست ممکن است آزاردهنده باشد؛ عاملی که اجازه ارسال پیام، بازیابی فایل یا فراخوانی سرویس دارد میتواند همان دستکاری را به افشای داده یا اقدام ناخواسته تبدیل کند.
چرا امنیت چتبات هوش مصنوعی فقط به رمزگذاری بستگی ندارد؟
امنیت چتبات هوش مصنوعی به کل زنجیره اعتماد بستگی دارد: پیامرسان، دستگاه، مدل، حافظه، ابزارها، سرور ارائهدهنده و سیاست مجوز. رمزگذاری سرتاسری فقط یک مرز مشخص را پوشش میدهد: جلوگیری از خواندن محتوای خصوصی در فاصله میان فرستنده و گیرندگان مجاز.
وقتی پیام به دستگاه مجاز میرسد، برای نمایش به کاربر رمزگشایی میشود. اگر دستیار روی همان دستگاه یا از طریق یک اتصال مجاز به متن دسترسی داشته باشد، داده را پس از رمزگشایی میبیند. از دید پروتکل، ربات یا برنامه دارای مجوز ممکن است یک دریافتکننده مشروع باشد؛ از دید کاربر، همان دریافتکننده میتواند بیش از حد اختیار داشته باشد.
این تفاوت را میتوان چنین خلاصه کرد: رمزنگاری تعیین میکند چه کسی پیام را در مسیر بخواند؛ کنترل دسترسی و طراحی عامل تعیین میکند دریافتکننده پس از خواندن آن چه کاری انجام دهد. برای شناخت مرز نخست، راهنمای رمزگذاری سرتاسری و آنچه محافظت نمیکند توضیح میدهد که E2EE درمان بدافزار، گیرنده خائن یا نمایشگر آلوده نیست.
عبارت «پیامرسان رمزگذاریشده و هوش مصنوعی» نیز نباید بهطور خودکار امن یا ناامن تعبیر شود. عامل محلی، بدون حافظه پایدار و فاقد ابزار خروجی، با ربات ابری دارای دسترسی به تاریخچه، فایلها و حسابهای خارجی یک سطح خطر ندارد. معماری و دامنه مجوز نتیجه را تعیین میکنند.
دسترسی دستیار هوش مصنوعی به چت خصوصی چه خطری ایجاد میکند؟
دسترسی دستیار هوش مصنوعی به چت خصوصی، محتوایی را که پیشتر فقط انسانهای گفتوگو میدیدند وارد مرز اعتماد تازهای میکند. خطر اصلی آن است که دستیار علاوه بر خواندن متن، بتواند آن را نگه دارد، با دادههای دیگر ترکیب کند یا از کانالی دیگر بیرون بفرستد.
پیش از فعالکردن چنین قابلیتی باید پنج پرسش روشن پاسخ داده شود:
- دستیار دقیقاً کدام گفتوگوها، پیوستها و بازه زمانی را میخواند؟
- پردازش روی دستگاه انجام میشود یا محتوا به سرور دیگری میرود؟
- ارائهدهنده چه دادهای را نگه میدارد و آیا از آن برای آموزش استفاده میکند؟
- عامل چه ابزارهایی برای ارسال پیام، بارگذاری فایل، جستوجو یا اجرای عملیات دارد؟
- آیا هر اقدام حساس به تأیید صریح کاربر نیاز دارد؟
مجوز «خواندن همه چتها» برای قابلیتی که فقط باید یک پیام انتخابشده را خلاصه کند، نقض اصل حداقل اختیار است. این اصل یعنی هر جزء فقط کمترین دسترسی لازم برای وظیفه جاری را دریافت کند. مجوز محدود به یک پیام، یک گفتوگو و یک نوبت، دامنه خسارت را کوچکتر میکند؛ هرچند محتوای همان محدوده همچنان میتواند حمله را هدف بگیرد.
فراداده نیز از محتوا جداست. در Livara، فراداده استاندارد مسیریابی شامل فرستنده، مقصد و زمانهای تحویل برای همگامسازی بلادرنگ دستگاهها ذخیره میشود. راهنمای فراداده پیامرسان و اطلاعاتی که آشکار میکند این مرز را شرح میدهد. یک دستیار ممکن است افزون بر متن، از الگوی تماسها و زمان ارتباط نیز استنباط بسازد؛ بنابراین سیاست دسترسی باید هر دو را در نظر بگیرد.
نشت اطلاعات از AI Agent از چه مسیرهایی رخ میدهد؟
نشت اطلاعات از AI Agent معمولاً زمانی رخ میدهد که عامل محتوای محرمانه را در زمینه خود ببیند و راهی برای انتقال آن به مقصد دیگر داشته باشد. تزریق دستور بهتنهایی داده را جابهجا نمیکند؛ نشت به ترکیب ورودی مخرب، دسترسی به داده و یک کانال خروجی وابسته است.
پیام یا فایل خروجی
عامل ممکن است اطلاعات را در پاسخ، پیام تازه، پیشنویس، فایل یا درخواست به یک سرویس خارجی قرار دهد. اگر سامانه خروجی را بدون محدودیت یا تأیید کاربر ارسال کند، مهاجم میتواند بکوشد داده محرمانه را به قالبی ظاهراً عادی تبدیل کند.
حافظه بلندمدت
بعضی عاملها خلاصه گفتوگو، ترجیحات یا نتایج قبلی را برای استفاده بعدی نگه میدارند. دستور مخرب ممکن است تلاش کند دادهای را وارد حافظه کند یا در جلسهای دیگر آن را بازیابی کند. عمر کوتاه حافظه، تفکیک کاربران و امکان مشاهده و حذف آن خطر را کم میکند، اما خطای مدل را از میان نمیبرد.
فراخوانی ابزار
عامل دارای ابزار میتواند جستوجو کند، پرونده بخواند یا عملیات مجاز دیگری انجام دهد. راهنمای فنی Obsidian Security درباره Prompt Injection در عاملها بر ثبت فراخوانی ابزار، کنترل مقصد و محدودسازی دسترسی تأکید میکند. این منبع یک راهنمای صنعتی است، نه استاندارد مستقل؛ توصیههایش باید در کنار آزمون امنیتی و مدل تهدید محصول ارزیابی شود.
دستگاه آلوده
بدافزار دارای دسترسی کافی ممکن است متن نمایشدادهشده، اعلانها، حافظه برنامه یا ورودی کاربر را ببیند. در این وضعیت، مهاجم الزاماً به شکستن رمزگذاری نیاز ندارد؛ نقطه پایانی را دور میزند. حفاظت سیستمعامل، بهروزرسانی، کنترل دسترسی و بررسی برنامههای نصبشده بخشی از دفاعاند، نه قابلیتهای پروتکل پیامرسان.
LVR1 و LGS1 در برابر این تهدید از چه چیزی محافظت میکنند؟
LVR1 و LGS1 محتوای چتهای خصوصی Livara را در مسیر و روی زیرساخت واسط از دید اشخاص غیرمجاز پنهان میکنند؛ آنها ربات مجاز یا دستگاه آلوده را پس از رمزگشایی مهار نمیکنند. این مرز باید همزمان با ادعای رمزگذاری گفته شود، نه در پاورقی.
LVR1 برای پیام مستقیم یک دابلرتچت هیبریدی پساکوانتومی است. رتچت ECDH P-256 و رتچت دورهای ML-KEM-768 کنار هم اجرا میشوند و کلید هر پیام از هر دو به دست میآید. ML-KEM-768 در FIPS 203 مؤسسه NIST استاندارد شده است. LVR1 محرمانگی پیشرو و امنیت پس از نفوذ را فراهم میکند، اما این ویژگیها مانع خواندن متن توسط نقطه پایانی مجاز نمیشوند.
LGS1 در گروه خصوصی برای هر فرستنده کلید جدا دارد و آن کلید را داخل پوششهای جفتی LVR1 مهروموم میکند. متن، ویرایش، عکس، ویدئو، فایل، کپشن و پیام صوتی در گروه خصوصی سرتاسری رمزگذاری میشوند. هر پیوست نیز پیش از بارگذاری با یک کلید محتوای تصادفی ۳۲بایتی تازه رمز میشود و کلید از داخل LVR1 یا LGS1 میگذرد. عضویت گروه را سرور کنترل میکند؛ بنابراین رمزگذاری گروه به معنای عضویت غیرقابلتغییر یا خارج از کنترل سرور نیست.
در هر دو پروتکل، مشتقسازی کلید با HKDF-SHA-256 و رمزگذاری اصالتسنجیشده با AES-256-GCM، نانس ۱۲بایتی و برچسب ۱۶بایتی انجام میشود. امضاها ECDSA P-256 با SHA-256 هستند. این سازوکارها خطر جعل یا افشای محتوا در کانال حملونقل را کاهش میدهند؛ اما اگر گیرنده پیام را عمداً به مدل بدهد، پروتکل دیگر نمیتواند هدف پردازش را کنترل کند. رسانه تماسها نیز پساکوانتومی نیست.
شمارههای ایمنی نسخه ۳ اجازه میدهند دو نفر اثرانگشت کلیدها را بیرون از پیامرسان مقایسه و تغییر کلید را شناسایی کنند. راهنمای روش مقایسه شمارههای ایمنی چت گامهای این بررسی را توضیح میدهد. این بررسی حمله مرد میانی را هدف میگیرد، نه Prompt Injection داخل محتوایی که خود طرف مقابل فرستاده است.
کانالهای Livara استثنای عمدیاند: کانال، جریان پخش عمومی برای یک نویسنده و مخاطبان نامحدود است و محتوایش سرتاسری رمزگذاری نمیشود. عمومیبودن کانال امکان رسیدگی به گزارشها، حذف محتوای سوءاستفادهآمیز و مسدودکردن کانال را میدهد. مرز کامل این معماری در صفحه امنیت و حدود حفاظت Livara منتشر شده است.
چه معماریای Prompt Injection در پیامرسان را محدود میکند؟
معماری امن باید پیام دریافتی را داده غیرقابلاعتماد فرض کند، حتی اگر از یک مخاطب شناختهشده و داخل چت رمزگذاریشده آمده باشد. رمزگذاری اصالت مسیر را تقویت میکند؛ اما ثابت نمیکند محتوای فرستنده برای اجرای خودکار بیخطر است.
داده را از دستور جدا کنید
برنامه باید دستور ثابت توسعهدهنده، درخواست صریح کاربر و محتوای خواندهشده از چت را در لایههای جدا نگه دارد. برچسبگذاری محتوا بهعنوان «داده غیرقابلاعتماد» مفید است، اما مدلهای زبانی همیشه این مرز معنایی را بیخطا رعایت نمیکنند؛ پس جداسازی باید با کنترل بیرون از مدل همراه شود.
اختیار عامل را کم کنید
عامل خلاصهساز به امکان ارسال خودکار پیام یا خواندن همه فایلها نیاز ندارد. ابزارها باید فهرست مجاز، دامنه محدود، اعتبارنامه جدا و مهلت کوتاه داشته باشند. مجوز یکباره برای محتوای انتخابشده بهتر از دسترسی دائمی است، زیرا هم احتمال دسترسی ناخواسته و هم دامنه نشت را کاهش میدهد.
خروجی را در یک دروازه قطعی بررسی کنید
مدل نباید خودش تصمیم نهایی درباره ارسال داده حساس را بگیرد. یک لایه غیرمولد میتواند مقصد، نوع داده، حجم خروجی و عملیات درخواستی را با قواعد قطعی بررسی کند. این فیلتر ممکن است دور زده شود یا خطا کند؛ بنابراین باید ثبت رویداد، هشدار و امکان توقف نیز وجود داشته باشد.
برای اقدام حساس تأیید انسانی بخواهید
خواندن پیشنویس با ارسال آن یکسان نیست. ارسال پیام، اشتراک فایل، افزودن عضو، خروج از برنامه یا انتقال داده به سرویس خارجی باید پیشنمایش واضح و تأیید آگاهانه داشته باشد. تأییدهای مبهم یا پرتعداد به عادت کلیککردن تبدیل میشوند؛ رابط باید دقیقاً داده، مقصد و نتیجه را نشان دهد.
عامل را در محیط محدود اجرا کنید
جداسازی فرایند، قطع دسترسی پیشفرض به شبکه، مخزن موقت و اعتبارنامههای کمدامنه اثر شکست را محدود میکند. این کنترلها Prompt Injection را حذف نمیکنند؛ آنها مانع میشوند یک پاسخ منحرفشده مستقیماً به دسترسی گسترده تبدیل شود.
کاربران و مدیران برای امنیت چتبات هوش مصنوعی چه کنند؟
کاربران باید هر اتصال هوش مصنوعی را یک گیرنده تازه برای داده خصوصی بدانند. مدیران نیز باید جریان داده و عملیات عامل را پیش از استقرار بررسی و در زمان اجرا پایش کنند.
برای استفاده شخصی:
- فقط پیام یا فایل لازم را انتخاب کنید؛ دسترسی به کل تاریخچه ندهید.
- محل پردازش، دوره نگهداری، استفاده آموزشی و روش حذف داده را بررسی کنید.
- ارسال خودکار پیام یا فایل را خاموش نگه دارید، مگر آنکه ضرورت روشنی داشته باشد.
- دستگاه، مرورگر و برنامهها را بهروز نگه دارید و مجوزهای حساس را بازبینی کنید.
برای سازمانها:
- مدل تهدیدی بنویسید که فرستنده مخرب، عضو گروه خائن، سرویس مدل، ابزار خارجی و دستگاه آلوده را جداگانه پوشش دهد.
- فراخوانی ابزار، تغییر مجوز، مقصد خروجی و تأیید کاربر را با کمترین داده حساس لازم ثبت کنید.
- ورودیهای خصمانه را در پیام، سند، متن نقلشده، تصویر دارای متن و محتوای بازیابیشده آزمایش کنید.
- برای هر عامل سقف عملیات، نرخ درخواست، مقصدهای مجاز و کلید قطع اضطراری تعریف کنید.
- شکست ایمن را پیشفرض بگیرید: اگر سیاست مبهم بود، عامل باید متوقف شود، نه اینکه حدس بزند.
هیچ فهرستی ایمنی کامل نمیسازد. نتیجه به پیادهسازی، مدل، تنظیمات، رفتار کاربر و تحول روشهای حمله بستگی دارد. هدف دفاع خوب کاهش اختیار، آشکارکردن انحراف و محدودکردن خسارت است.
آیا پیامرسان رمزگذاریشده و هوش مصنوعی میتوانند با هم امن باشند؟
بله، پیامرسان رمزگذاریشده و هوش مصنوعی میتوانند با ریسک کنترلشده کنار هم کار کنند، به شرط آنکه دستیار کمترین دسترسی را داشته باشد و اقدام حساس بدون تأیید انجام ندهد. با این حال، اتصال هر مدل به محتوای خصوصی یک مرز اعتماد تازه ایجاد میکند و نباید زیر عنوان E2EE پنهان شود.
طراحی کمخطرتر پردازش را تا جای ممکن روی دستگاه نگه میدارد، زمینه را به انتخاب صریح کاربر محدود میکند، حافظه را کوتاهعمر میسازد و ابزارهای خروجی را جدا میکند. پردازش محلی نیز تضمین مطلق نیست: دستگاه آلوده، مدل ناامن یا مجوز گسترده همچنان خطر میآفریند.
کاربر باید بتواند بفهمد کدام داده به مدل میرود، مدل کجا اجرا میشود، چه مدت چیزی را نگه میدارد و چه کاری میتواند انجام دهد. اگر محصول پاسخ این پرسشها را روشن نمیدهد، نباید از عبارتهایی مانند «هوش مصنوعی خصوصی» نتیجه امنیتی قطعی گرفت.
در Livara، مشخصات باز پروتکل، بردارهای آزمون ماشینخوان، چکسامهای انتشار و بررسی آفلاین APK در Proof Lab امکان بررسی برخی اجزا و انتشارها را فراهم میکنند. پروتکلها مستقلاً ممیزی نشدهاند و این شفافیت بهتنهایی ایمنی محصول یا هر دستیار متصل را ثابت نمیکند. امنیت دستیار باید جداگانه و بر اساس دسترسی واقعی آن سنجیده شود.
پرسشهای متداول
آیا رمزگذاری سرتاسری Prompt Injection را متوقف میکند؟
خیر. رمزگذاری سرتاسری پیام را میان فرستنده و گیرندگان مجاز از واسطهها پنهان میکند. اگر یک ربات مجاز، برنامه روی دستگاه یا بدافزار به متن رمزگشاییشده دسترسی داشته باشد، میتواند آن را پردازش کند. مهار Prompt Injection به محدودسازی مجوز، ابزار، حافظه و خروجی عامل نیاز دارد.
آیا خلاصهکردن چت خصوصی با هوش مصنوعی خطرناک است؟
خطر به معماری بستگی دارد. خلاصهسازی محلی یک پیام انتخابشده، بدون حافظه و ابزار خروجی، دامنه خطر کمتری از ربات ابری دارای دسترسی دائمی به همه چتها دارد. پیش از استفاده، محل پردازش، نگهداری داده، دامنه مجوز و امکان ارسال خودکار را بررسی کنید.
آیا پیام یک مخاطب شناختهشده میتواند حامل Prompt Injection باشد؟
بله. اعتماد به هویت فرستنده با اعتماد به همه محتوای او یکسان نیست؛ حسابش ممکن است تسخیر شده باشد یا متن مخرب را ناخواسته بازفرستاده باشد. هر محتوایی که عامل میخواند باید داده غیرقابلاعتماد تلقی شود، حتی اگر داخل یک گفتوگوی اصالتسنجیشده و رمزگذاریشده باشد.
آیا LVR1 و LGS1 اطلاعات را از دستیار هوش مصنوعی پنهان میکنند؟
LVR1 و LGS1 محتوا را در مسیر از اشخاص غیرمجاز پنهان میکنند. اگر کاربر یا برنامه به دستیار اجازه دهد پیام رمزگشاییشده را بخواند، این پروتکلها آن دسترسی مجاز را مسدود نمیکنند. بنابراین امنیت دستیار باید جدا از امنیت انتقال پیام سنجیده شود.
نخستین اقدام برای کاهش نشت اطلاعات از AI Agent چیست؟
نخست دامنه دسترسی عامل را کم کنید: فقط پیام انتخابشده، فقط در همان نوبت و بدون امکان ارسال خودکار. سپس برای عملیات حساس پیشنمایش و تأیید انسانی بگذارید، مقصدهای خروجی را محدود کنید و فراخوانی ابزارها را ثبت کنید. این لایهها خطر را کاهش میدهند، اما تضمین مطلق نمیسازند.
Sources
تیم لیوارا نویسنده جمعی داخلی این مطلب است. این نام به معنای بازبینی مستقل نیست؛ ادعاها را با منابع و محدودیتهای ذکرشده بسنجید.
