بسیاری از برنامهنویسان تصور میکنند پنجرههای تأیید (Approval Dialog) در ابزارهای کدنویسی، لایه امنیتی آنهاست؛ اما در واقعیت، این پنجرهها میتوانند به یک نقطه ضعف مرگبار تبدیل شوند. در ۸ جولای ۲۰۲۴، تیم تحقیقاتی Wiz Research آسیبی به نام GhostApproval را افشا کرد که همزمان ۶ دستیار هوش مصنوعی بزرگ را هدف قرار داده است.
این نقص امنیتی مدلهای Amazon Q Developer، Claude Code، Augment، Cursor، Google Antigravity و Windsurf را تحت تأثیر قرار داده است. همانطور که در تحلیل قبلی ما دربارهی ضرورت محیطهای اثبات اختصاصی برای عاملها اشاره کردیم، این اتفاق ثابت میکند که مرزهای اعتماد فعلی در معماری این ابزارها اشتباه ترسیم شدهاند. در حالی که یک محیط ایزوله (Sandbox) دسترسیهای عامل را محدود میکند، اما پنجره تأیید فرض میکند انسان کاربر، یک حسابرس امنیتی بینقص است که تحت فشار زمانی، هر تغییری را بهدرستی تحلیل میکند.
طبق تحلیل منتشرشده در dev.to، این حمله با ارسال فایلی مانند project_settings.json آغاز میشود که در واقع یک پیوند نمادین (Symlink) به یک هدف حساس، مثلاً فایل کلیدهای خصوصی در مسیر ~/.ssh/id_rsa است. وقتی عامل (Agent) قصد نوشتن در این فایل را دارد، پنجره تأیید نام پیوند نمادین را نمایش میدهد، نه مقصد واقعی را. شما روی دکمه تأیید کلیک میکنید و عامل بدون آنکه بداند، کلیدهای خصوصی شما را بازنویسی یا افشا میکند.
این مورد، یک باگ کلاسیک از نوع TOCTOU (زمان بررسی تا زمان استفاده) است. واکنش صنعت به این موضوع پراکنده بوده است:
- آمازون، گوگل و Cursor فوراً اصلاحیههای لازم را منتشر کردند.
- Augment و Windsurf پس از افشای خبر سکوت اختیار کردند.
- Anthropic این ادعا را به چالش کشید و استدلال کرد کاربرانی که به یک پوشه اعتماد کرده و ویرایش را تأیید میکنند، مسئول تصمیم خود هستند.
جدا از GhostApproval، شرکت Cursor نقص دیگری به نام DuneSlide را نیز برطرف کرد؛ دو مورد اجرای کد از راه دور (RCE) با امتیاز شدت ۹.۸. در این حملات، دستورات تزریقشده در نتایج جستجو یا پاسخهای پروتکل زمینه مدل (MCP)، فرآیند تأیید را بهکل دور زده و از محیط ایزوله خارج شدند.
این چرخش ثابت میکند که تأیید اقدامبه-اقدام تنها یک راهکار موقتی است و نه یک معماری امنیتی. برای تیمهای فنی، این فرض که انسان میتواند هر حرکت تولیدشده توسط هوش مصنوعی را بازبینی کند، اکنون منسوخ شده است. این عدم قابلیت اطمینان تنها محدود به حفرههای امنیتی نیست، بلکه در رفتارهای غیرمنتظره نیز دیده میشود؛ چنانکه پیشتر در بررسی دروغهای سیستماتیک عاملهای کدنویس Elpis مشاهده کردیم که چگونه این ابزارها میتوانند در گزارشهای خود گمراهکننده باشند. تنها راهکار عملی، محدودسازی سختگیرانه (Strict Scoping) است؛ یعنی تعریف دقیق مسیرها و پوشههایی که عامل اجازه فعالیت در آنها دارد، پیش از آنکه برنامه اجرا شود.
از سپردن امنیت خود به یک جعبه پیام توقف کنید. برای ایمنسازی گردش کار، به سمتی بروید که «شعاع تخریب» (Blast Radius) از پیش تعریف شده باشد تا عامل هرگز نتواند به فایلی خارج از دایرکتوری منبع دسترسی پیدا کند. در واقع، درک نقاط شکست این سیستمها اولین قدم برای مقابله با آنهاست، مشابه آنچه در راهنمای چهارمرحلهای برای یافتن نقطه شکست عاملهای هوش مصنوعی بررسی کردیم.
گام بعدی شما
- اگر از ابزارهای Agentic استفاده میکنید، فوراً نسخههای Cursor و Amazon Q را بهروزرسانی کنید.
- دسترسیهای فایلسیستمی ابزارهای AI را به جای دسترسی کلی، به پوشههای خاص پروژه محدود کنید.
- از ابزارهایی استفاده کنید که قابلیت Read-only را برای فایلهای حساس پیکربندی میکنند.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو