نقص «نایب سرگردان»: چگونه عامل‌های متا ۲۰ هزار حساب اینستاگرام را لو دادند؟

اگر برای اجرای عملیات حساس کاربران به عامل‌های هوش مصنوعی تکیه کرده‌اید، احتمالاً حفره‌ای امنیتی را به ارث برده‌اید که پیش‌تر با قضاوت انسانی پر شده بود. در ژوئن ۲۰۲۴، مهاجمان بدون نیاز به رمز عبور یا اکسپلویت‌های پیچیده، کنترل بیش از ۲۰ هزار حساب اینستاگرام (Instagram)، از جمله حساب غیرفعال دوران اوباما در کاخ سفید را تصاحب کردند.

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

این مورد، نمونه‌ای کلاسیک از مشکل «نماینده گیج» (Confused Deputy) است. در اصطلاح امنیتی، این اتفاق زمانی رخ می‌دهد که یک فرآیند دارای دسترسی بالا، توسط طرفی با دسترسی پایین فریب می‌خورد تا از اختیاراتش برای هدفی مخرب استفاده کند. تصور کنید یک نگهبان شب، گاوصندوق را برای هر کسی که ادعا کند رئیس او را فرستاده است باز می‌کند؛ نگهبان کلیدها را در اختیار دارد، اما متقلب داستان متقاعدکننده‌ای می‌گوید. نمونه‌ی بنیادین این اتفاق در سال ۱۹۸۸ با یک کامپایلر رخ داد که می‌توانست در یک فایل صورت‌حساب محافظت‌شده بنویسد؛ کاربری که فاقد آن مجوزها بود، از کامپایلر خواست تا این کار را برایش انجام دهد و کامپایلر پذیرفت، زیرا خودش اختیار داشت و هرگز بررسی نکرد که در حال خدمت به چه کسی است.

سازوکار شکست

عامل‌های مدل زبانی بزرگ (LLM) به دلیل ساختارشان، ذاتاً مستعد تبدیل شدن به نماینده‌های گیج هستند و این موضوع چندین دلیل دارد:

• کوریِ هویت: رابط‌های زبان طبیعی به‌طور ذاتی توکن‌های احراز هویت را حمل نمی‌کنند. یک درخواست مستقیم API هویت فراخوان را همراه دارد، اما یک جمله خیر. مگر اینکه آن هویت پیش از اجرای فراخوانی دوباره متصل شود، در غیر این صورت عامل با اختیار خودش عمل می‌کند و مجوزهای درخواست‌کننده هرگز وارد معادله نمی‌شوند.
• تداخل دستور و داده: عامل‌ها در تفکیک دستورات کاربر از داده‌های پردازشی مشکل دارند. هر چیزی در پنجره متنی (Context Window) — از پیام کاربر، یک سند بازیابی شده یا بدنه یک ایمیل — به عنوان دستور احتمالی خوانده می‌شود. یک ربات پشتیبانی که رمز عبور را به دلیل یک چت متقاعدکننده بازنشانی می‌کند، به همان راحتی دستوری را اجرا می‌کند که در دل فایلی که برای پردازش به او داده شده، پنهان شده است. این موضوع در ترفند VPN برای دور زدن بررسی موقعیت مکانی متا دیده شد؛ نسخه‌های پیچیده‌تر که در آن دستورات مخرب از طریق محتوای بلعیده شده (Ingested Content) منتقل می‌شوند، اکنون کلاس غالب حملات به عامل‌ها هستند.
• شکاف تشخیص: بخش بزرگی از امنیت دنیای واقعی بر تشخیص انسانی است. یک کارمند پشتیبانی انسانی متوجه می‌شود که غریبه‌ای سعی دارد ایمیل بازیابی یک سلبریتی را تغییر دهد و حس می‌کند مشکلی وجود دارد. اما یک عامل هوش مصنوعی صرفاً توالی مجاز عملیات را اجرا می‌کند. عامل امنیت را دور نمی‌زند، بلکه صرفاً بخشی از مدل را که قبلاً یک «انسان» بود، در معرض نمایش قرار می‌دهد.

شکست متا یک نقص مهندسی در لایه مجوزدهی بود. کد احتمالاً به شکل یک فراخوانی ساده بود: def add_recovery_email(account, new_email): account.recovery_email = new_email. چون تابع، شخص درخواست‌کننده (principal) را بررسی نمی‌کرد، توانایی عامل در فراخوانی تابع، تنها شرط موفقیت بود.

گسترش سطح ریسک

با عبور عامل‌ها از پشتیبانی ساده، مخاطرات در حال افزایش است. متا در همان هفته‌ای که ابزار پشتیبانی معیوب را غیرفعال کرد، عامل تجاری (Business Agent) خود را راه‌اندازی کرد. این ابزار جدید برای رزرو قرارها، شناسایی لیدها، نهایی کردن فروش و دریافت پرداخت‌ها طراحی شده است. این ابزار به پلتفرم‌هایی مثل Shopify و Zendesk متصل می‌شود تا از طرف یک شرکت عمل کند.

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

• ارسال بازپرداخت‌ها (Refunds) به طرف‌های غیرمجاز
• تغییر مسیر سفارشات به سمت مهاجمان
• تغییر قیمت (Price Overrides) برای محصولات گران‌قیمت
• ویرایش غیرمجاز سوابق حساس مشتریان

تمام این‌ها عملیات‌های قانونی هستند که عامل اجازه انجام آن‌ها را داشت، اما شکست زمانی رخ می‌دهد که عامل این کارها را برای هر کسی که درخواست کند، انجام می‌دهد.

روند بازار و شکاف امنیتی

سرعت بازار از مدل‌های امنیتی پیشی گرفته است. گارتنر (Gartner) پیش‌بینی کرده که تا پایان سال ۲۰۲۶، ۴۰٪ از اپلیکیشن‌های سازمانی شامل عامل‌های هوش مصنوعی تک‌وظیفه‌ای باشند؛ جهشی عظیم نسبت به کمتر از ۵٪ در ابتدای سال. اکثر این استقرارها همان فرض اشتباه متا را تکرار می‌کنند: اینکه هر چه در انتهای یک عملیات حساس قرار دارد، دارای قدرت تشخیص است.

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

مسیر رسیدن به عاملیت امن

برای رفع این مشکل، احراز هویت باید به بیرون از مدل منتقل شود. تصمیم برای اجازه دادن به یک اقدام باید توسط یک لایه سیاست‌گذاری (Policy Layer) گرفته شود که هویت جلسه را پیش از اجرای هر کدی تأیید کند. نسخه امن تابع بازیابی باید شامل این بررسی باشد:

def add_recovery_email(account, new_email, principal): if not principal.owns(account): raise Unauthorized("session not authenticated as the account owner")

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

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

هر اقدام برگشت‌ناپذیر — مانند پرداخت‌ها، حذف‌ها، تغییر مجوزها یا بازیابی حساب — باید پشت یک تأییدیه انسانی یا یک قانون سخت‌گیرانه باشد. تأییدیه‌ای که مدل بتواند با تولید کلمات درست آن را پاس کند، کنترل امنیتی نیست، بلکه فقط یک نمایش (Fluff) است. این اقدامات باید بر اساس میزان آسیبی که می‌توانند بزنند طبقه‌بندی شوند.

در نهایت، هر اقدام نیاز به ثبت کامل منشأ (Provenance) دارد. این یعنی ثبتِ شخص درخواست‌کننده، جلسه و پرامپتی که باعث اجرای اقدام شده است. حمله به اینستاگرام حدود ۶ هفته ادامه داشت؛ حسابرسی در لحظه می‌توانست ناهنجاریِ اجرای مکرر یک عملیات حساس برای ۲۰ هزار حساب بی‌ارتباط را شناسایی کند.

این دلیلی برای ترس از هوش مصنوعی نیست، بلکه یادآوری است که «اطاعت» بدون مرزهای سخت‌گیرانه، یک نقطه ضعف است. قضاوتی که زمانی توسط یک انسان در چرخه (Human-in-the-loop) ارائه می‌شد، یک کار واقعی بود و اکنون آن کار باید به شکل کد وجود داشته باشد. پیش از متصل کردن یک عامل به سیستم، بپرسید شخصی که قبلاً در آن چرخه بود چه چیزی را بررسی می‌کرد. اگر این کار را کنید، عاملی که دقیقاً همان کاری را می‌کند که اجازه دارد، دقیقاً همان چیزی می‌شود که شما می‌خواهید.