اکسپلویتی به نام GitLost که توسط تیم امنیتی Noma Security کشف شده، نشان میدهد چگونه یک کلمه کلیدی ساده میتواند محافظهای امنیتی گیتهاب را دور بزند و عامل هوش مصنوعی این پلتفرم را وادار به افشای دادههای محرمانه کند.
مکانیزم اکسپلویت GitLost
گردش کاری عاملمحور (Agentic Workflow) آسیبپذیر که توسط Noma Labs شناسایی شد، به گونهای پیکربندی شده بود که با رویدادهای issues.assigned فعال میشد. این عامل هوش مصنوعی عنوان و بدنه ایشو را میخواند، با ابزار add-comment یک پاسخ ارسال میکرد و به سایر مخازن سازمان—چه عمومی و چه خصوصی—دسترسی خواندن داشت.
مهاجم برای سوءاستفاده از این آسیبپذیری به هیچ مهارت برنامهنویسی، دسترسی یا اعتبارنامهای نیاز نداشت. تنها کافی بود در یک مخزن عمومی متعلق به سازمانی که از گردش کاری عاملمحور گیتهاب استفاده میکند، یک ایشو باز کند و صبر کند. دستورالعملهای مخفی جاسازیشده در متن ایشو، عامل هوش مصنوعی را فریب داده و موجب نشت دادههای محرمانه میشدند.
کلمهای که همه چیز را تغییر داد
Noma گزارش میدهد که با وجود محدودیتهای ایمنی (guardrails) سختگیرانهای که گیتهاب اعمال کرده، تنها استفاده از کلمه کلیدی "Additionally" (به معنای «همچنین») باعث رفتار ناخواسته مدل شد. این کلمه ساده مدل را وادار کرد به محتویات یک فایل محدودشده دسترسی پیدا کرده و آنها را در یک کامنت عمومی منتشر کند.
کاربر cH3332xr در بحثهای جامعه فنی این موضوع را تحلیل کرد:
دور زدن با «Additionally» جالبترین جزئیات این ماجرا است. خود payload تغییر نکرد—فقط توکن قالببندی (framing token) که آن را در نگاه حفاظ مرزی از «دستورالعمل جدید» به «ادامه وظیفه فعلی» تغییر وضعیت داد، عوض شد. این یک مشکل مرز تصمیمگیری است، نه مشکل محتوا.
تزریق پرامپت؛ SQL injection هوش مصنوعی
در تزریق SQL، ورودی کاربر به جای داده خالص به عنوان بخشی از دستور اجرا میشد—و جداسازی این دو، مشکل را حل کرد. اما تزریق پرامپت در سیستمهای هوش مصنوعی عاملمحور به همان چیزی تبدیل شده که تزریق SQL برای برنامههای وب بود: یک رده آسیبپذیری سیستماتیک و در سطح طبقهبندی که به استراتژیها و دفاعهای سیستماتیک نیاز دارد.
تفاوت بنیادین اینجاست که در تزریق SQL، جداسازی دستور و داده ممکن بود، اما در تزریق پرامپت، ورودی کاربر ذاتاً به عنوان دستورالعمل در نظر گرفته میشود. کاربر mcv در هکر نیوز به این پارادوکس اشاره کرد:
تزریق SQL به دلیل در نظر گرفتن ورودی کاربر به عنوان بخشی از دستورالعمل، به جای دادههای خالصی که برای آن در نظر گرفته شده بود، رخ میداد. جدا کردن این دو مشکل را حل کرد. تزریق پرامپت غیرقابل اجتناب است زیرا ورودی کاربر به عنوان دستورالعمل در نظر گرفته میشود.
مرزهای اعتماد در سیستمهای عاملمحور
در مدلهای امنیتی سنتی، مرزهای اعتماد توسط کد اعمال میشوند. اما در سیستمهای عاملمحور، این مرزها تا حدودی توسط رفتار مدل تعیین میشوند—و مدلها ذاتاً پیرو دستورالعمل هستند. ویجندرا مالهوترا، مدیر ارشد فناوری پارهوقت (Fractional CTO)، در لینکدین نوشت:
مخزن خصوصی هرگز یک مرز امنیتی نبود، بلکه یک مرز سازمانی بود و تنها تا زمانی برقرار ماند که هر خواننده کد شما، انسانی بود که استخدام کرده بودید. عوامل هوش مصنوعی این فرض را از بین میبرند. اگر یک عامل به مخازن خصوصی شما دسترسی دارد، با همه چیز در آنها مانند چیزی رفتار کنید که تنها با یک ایشوی خوشساخت از علنی شدن فاصله دارد.
کاربر ردیت با نام Significant_Sea_4230 هم به بُعد دیگری از مشکل اشاره کرد: خطر اصلی هوشمند بودن عامل نیست، بلکه اتصال آن به بیش از حد زمینه (context)، مخازن متعدد یا توکنهای بیش از حد گسترده است.
راهکارهای کاهش خطر
پژوهشگران Noma توصیههای زیر را برای سازمانها ارائه کردهاند:
- محتوای کنترلشده توسط کاربر هرگز نباید به عنوان ورودی دستورالعمل مورد اعتماد برای عامل هوش مصنوعی تلقی شود.
- مجوزهای عامل باید به حداقل ضروری محدود شوند؛ عواملی که دسترسی بینمخزنی دارند، اهداف بسیار ارزشمندی به شمار میآیند.
- آنچه عوامل میتوانند به صورت عمومی افشا کنند باید محدود شود، بهخصوص هنگام پاسخ به محتوای ایشو.
- ورودی کاربر قبل از ارائه به مدل باید به درستی پاکسازی (sanitized) شده یا از زمینه دستورالعمل ایزوله شود.
پارادایم جدید امنیت در عصر عوامل هوش مصنوعی
این آسیبپذیری نشان میدهد که پارادایم امنیتی نرمافزار در حال تغییر بنیادین است. تا پیش از ظهور عوامل هوش مصنوعی، مرز بین «دستور» و «داده» با فیلترهای کدی قابل حفظ بود. اکنون که مدلهای زبانی هر دو را به یک شکل پردازش میکنند، سازمانها باید بازنگری عمیقی در معماری دسترسی عوامل هوش مصنوعی خود انجام دهند—وگرنه هر ایشوی عمومی میتواند به دروازهای برای نشت دادههای محرمانه تبدیل شود.
