پژوهشگران امنیتی شرکت Noma Security از تکنیکی جدید با نام گیتلاست (GitLost) پرده برداشتهاند که نشان میدهد یک مورد پیگیری عمومی (Issue) در گیتهاب میتواند قابلیت گردشکارهای مبتنی بر عامل هوش مصنوعی گیتهاب (GitHub Agentic Workflows) را فریب داده و باعث افشای اطلاعات مخازن خصوصی یک سازمان شود. در این حمله، مهاجم بدون نیاز به سرقت اعتبارنامهها یا داشتن دسترسی مستقیم به زیرساخت سازمان، تنها با ایجاد یک مورد پیگیری عمومی ظاهراً عادی در یک مخزن عمومی میتواند عامل هوش مصنوعی (AI Agent) را به استخراج و انتشار دادههای خصوصی در یک کامنت عمومی وادار کند.
بررسیها نشان میدهد گیتلاست از ضعف ساختاری در تعامل عاملهای هوش مصنوعی با ورودیهای غیرقابل اعتماد بهره میبرد. اگر یک سازمان به این قابلیت گیتهاب دسترسی خواندن (Read Access) گستردهای در مخازن خود، از جمله مخازن خصوصی، اعطا کرده باشد، این عاملها میتوانند به مسیری برای افشای دادههای حساس تبدیل شوند.
نحوه عملکرد قابلیت گردشکارهای مبتنی بر عامل هوش مصنوعی گیتهاب
قابلیت گردشکارهای مبتنی بر عامل هوش مصنوعی گیتهاب به کاربران اجازه میدهد بهجای تکیه بر اسکریپتهای سنتی خودکارسازی، دستورالعملهای موردنظر خود را با زبان طبیعی در یک فایل مارکداون (Markdown) برای یک عامل هوش مصنوعی تعریف کنند. این عامل میتواند موردهای پیگیری عمومی و درخواستهای Pull (Pull Requests) را بررسی کند، ابزارهای مورد نیاز را اجرا کرده و بهصورت مستقل پاسخ ارائه دهد.
گیتهاب این قابلیت را در ماه فوریه معرفی کرد و اکنون در مرحله پیشنمایش عمومی(public preview) قرار دارد. این قابلیت میتواند با مدلهای هوش مصنوعی مختلفی مانند GitHub Copilot، Claude شرکت آنتروپیک، Google Gemini و OpenAI Codex اجرا شود.
این گردشکارها بهصورت پیشفرض، تنها دارای دسترسی خواندن (Read-Only Access) هستند؛ اما سازمانها میتوانند برای فراهمکردن امکان دسترسی عامل هوش مصنوعی به اطلاعات چندین مخزن، یک توکن دسترسی با مجوز خواندن را به آن اختصاص دهند. این توکن میتواند دسترسی به مخازن مختلف سازمان، از جمله مخازن خصوصی، را فراهم کند. این سطح دسترسی گسترده، همان نقطهای است که حمله گیتلاست از آن برای سوءاستفاده بهره میگیرد.
نحوه اجرای حمله گیتلاست
این حمله از یک روش شناختهشده به نام تزریق غیرمستقیم پرامپت (Indirect Prompt Injection) سوءاستفاده میکند. عاملهای هوش مصنوعی همیشه نمیتوانند میان دستورالعملهای تعریفشده توسط مالک یا توسعهدهنده و دستورالعملهای پنهانشده در محتوایی که پردازش میکنند، تمایز دقیقی قائل شوند. به همین دلیل، مهاجم میتواند با قرار دادن یک دستورالعمل مخرب در یک مورد پیگیری عمومی، عامل هوش مصنوعی را وادار کند آن را بهعنوان یک درخواست معتبر تفسیر و اجرا کند.
در نمونه اثبات مفهوم (PoC) ارائهشده توسط Noma Security، مهاجمان یک مورد پیگیری عمومی را طوری طراحی کرده بودند که مانند یک درخواست عادی از سوی معاون فروش (VP of Sales) پس از برگزاری جلسه با مشتری به نظر برسد. گردشکار هدف این حمله بهگونهای پیکربندی شده بود که پس از اختصاص این مورد پیگیری، بهصورت خودکار فعال شود، محتوای آن را بررسی کند و با ارسال یک کامنت به آن پاسخ دهد. همچنین این گردشکار مجوز دسترسی خواندن به سایر مخازن سازمان را در اختیار داشت. پس از اینکه یک فرآیند خودکارسازی معمولی، این مورد پیگیری را به گردشکار اختصاص داد، عامل هوش مصنوعی محتوای فایل README یک مخزن خصوصی را استخراج کرد و آن را در قالب یک کامنت عمومی در همان مورد پیگیری منتشر کرد.
گیتهاب برای مقابله با چنین سناریوهایی، مجموعهای از سازوکارهای امنیتی را در این قابلیت تعبیه کرده است. این شرکت در مستندات خود هشدار میدهد که عاملهای هوش مصنوعی ممکن است تحت تأثیر تزریق پرامپت، محتوای مخرب موجود در مخازن یا ابزارهای آلوده و مورد سوءاستفاده قرارگرفته قرار گیرند. همچنین این محصول بهصورت پیشفرض از سازوکار سندباکس (Sandboxing)، توکنهای فقطخواندنی، پاکسازی ورودیها و یک مرحله تشخیص تهدید برای بررسی خروجی پیشنهادی عامل پیش از انتشار عمومی آن استفاده میکند.
با این حال، نتایج آزمایشهای Noma Security نشان میدهد که دور زدن این لایههای حفاظتی چندان دشوار نیست. پژوهشگران دریافتند که تنها با افزودن واژه «Additionally» در ابتدای دستور مخرب، مدل هوش مصنوعی آن را بهعنوان ادامه منطقی درخواست قبلی تفسیر میکند، نه دستوری که باید مسدود شود. همین تغییر ظاهراً ساده باعث شد سازوکارهای حفاظتی گیتهاب نیز نتوانند عملکرد مخرب را شناسایی کنند.
چرا گیتلاست با نمونههای قبلی تفاوت دارد؟
تفاوت اصلی گیتلاست با نمونههای پیشین حملات مبتنی بر تزریق پرامپت در این است که مهاجم بهجای تغییر پاسخهای یک عامل هوش مصنوعی، میتواند نحوه استفاده آن از مجوزهای دسترسی را تحت تأثیر قرار دهد. در حملات قبلی، معمولاً هدف مهاجمان تغییر پاسخها و خروجیهای تولیدشده توسط عاملهای هوش مصنوعی بود؛ اما در این سناریو، مهاجم تلاش میکند عملکرد عامل را تغییر دهد و آن را به انجام اقداماتی وادار کند که بر اساس سطح دسترسی در اختیارش امکانپذیر است.
در این حمله، عامل هوش مصنوعی صرفاً یک ابزار گفتوگو نیست؛ بلکه یک موجودیت دارای سطح دسترسی در زیرساختهای مرتبط با توسعه نرمافزار و فرآیند یکپارچهسازی و استقرار مداوم (CI/CD) سازمان است. این عامل میتواند به مخازنی دسترسی خواندن داشته باشد که مهاجم هیچگونه دسترسی یا اطلاعی از محتوای آنها ندارد. اجرای این حمله به نفوذ به سرور، سرقت اعتبارنامهها یا داشتن مجوز نوشتن در مخازن خصوصی نیاز ندارد؛ مهاجم تنها کافی است یک مورد پیگیری عمومی ایجاد کند.
این سناریو با مفهوم سهگانه مرگبار (Lethal Trifecta) که در حوزه امنیت عاملهای هوش مصنوعی مطرح شده، همخوانی دارد. این مفهوم به شرایطی اشاره میکند که در آن یک عامل هوش مصنوعی همزمان به دادههای خصوصی دسترسی دارد، ورودیهای خارجی و غیرقابل اعتماد را پردازش میکند و امکان ارسال اطلاعات به خارج از محیط سازمان را دارد. ترکیب این سه عامل، میتواند یک مسیر مستقیم برای افشای دادههای حساس ایجاد کند.
این مسئله از نوع آسیبپذیریهایی نیست که بتوان آن را صرفاً با انتشار یک پچ برطرف کرد؛ بلکه ناشی از یک محدودیت ساختاری در معماری عاملهای هوش مصنوعی است. زمانی که این عاملها با اعتبارنامههای دائمی به دادههای حساس دسترسی دارند و همزمان محتوایی را پردازش میکنند که مهاجمان قادر به کنترل آن هستند، احتمال سوءاستفاده از این دسترسیها افزایش پیدا میکند.
چرا این نوع حملات همچنان تکرار میشوند؟
گیتلاست جدیدترین نمونه از زنجیره حملاتی است که از یک الگوی مشابه سوءاستفاده میکنند؛ حملاتی که نشان میدهند عاملهای هوش مصنوعی همچنان در برابر ورودیهای غیرقابل اعتماد با چالشهای امنیتی جدی روبهرو هستند. گزارشهای منتشرشده در ماههای اخیر نیز چندین مورد مشابه را نشان دادهاند. برای مثال، یک ضعف امنیتی در GitHub Action مربوط به Claude Code شرکت آنتروپیک باعث شد مهاجمان بتوانند تنها با ایجاد یک مورد پیگیری مخرب ، عامل هوش مصنوعی را به افشای اطلاعات و دریافت مجوز نوشتن در یک مخزن وادار کنند.
در نمونهای دیگر، حمله RoguePilot از یک پرامپت پنهان در یک مورد پیگیری گیتهاب استفاده کرد تا عامل Copilot را به افشای توکن دارای دسترسی ویژه یک مخزن وادار کند. این ضعف در عاملهای مبتنی بر گیتهاب دستکم به ماه می 2025 بازمیگردد؛ زمانی که پژوهشگران Invariant Labs نشان دادند یک مورد پیگیری عمومی میتواند عاملی متصل به سرور MCP گیتهاب را وادار کند یک مخزن خصوصی را بخواند و محتوای آن را از طریق یک درخواست Pull افشا کند. پژوهشگران این مسئله را یک محدودیت معماری دانستند، زیرا هیچ پچی در سمت سرور نمیتواند این ضعف را بهطور کامل برطرف کند.
در ادامه، یک پژوهش مشترک میان چند شرکت فناوری با عنوان Comment and Control نشان داد که عاملهای Claude Code، Gemini CLI و GitHub Copilot نیز میتوانند از طریق محتوای موجود در موردهای پیگیری و درخواستهای Pull فریب بخورند و کلیدهای API خود را افشا کنند. این حملات حتی توانستند از برخی لایههای حفاظتی جدید گیتهاب در زمان اجرا عبور کنند.
اقدامات پیشنهادی برای کاهش ریسک
شرکت Noma Security پس از اطلاعرسانی به گیتهاب درباره گیتلاست، یافتههای خود از این حمله را منتشر کرد. این ریسک تنها سازمانهایی را تهدید میکند که شرایط زیر را داشته باشند:
- قابلیت پیشنمایش عمومی را فعال کرده باشند.
- به این عامل، دسترسی خواندن به مخازن خصوصی داده باشند.
- امکان انتشار خروجی عامل در محیطهای عمومی را فراهم کرده باشند.
میزان اطلاعاتی که مهاجم میتواند به آن دسترسی پیدا کند، به سطح دسترسی توکن اختصاصیافته به عامل هوش مصنوعی بستگی دارد. این اطلاعات میتواند شامل کد منبع اختصاصی، کلیدهای داخلی، اسناد طراحی و اطلاعات حساس مرتبط با CI/CD باشد.
مهمترین عامل در کاهش این ریسک، محدوده دسترسی (Scope) توکن است. هرچه سطح دسترسی توکن محدودتر باشد، احتمال سوءاستفاده نیز کاهش پیدا میکند. برای مثال، توکنی که تنها به یک مخزن مشخص دسترسی دارد، بسیار کمخطرتر از توکنی است که برای سهولت کار، مجوز خواندن در سطح کل سازمان را در اختیار عامل هوش مصنوعی قرار میدهد.
برای کاهش احتمال افشای اطلاعات، سازمانها باید اقدامات زیر را در نظر بگیرند:
- محدوده توکنهای دسترسی را محدود کنند: دسترسی توکن دسترسی شخصی (PAT) باید فقط به همان مخزنی محدود شود که عامل هوش مصنوعی وظیفه بررسی آن را بر عهده دارد و نباید مجوز دسترسی گسترده در سطح کل سازمان داشته باشد.
- انتشار خروجیهای عامل را کنترل کنند: مجوز نوشتن باید تنها از طریق خروجیهای از پیش تعریفشده و مورد تأیید انجام شود؛ زیرا یک کامنت تولیدشده توسط عامل هوش مصنوعی میتواند به مسیری برای استخراج داده تبدیل شود.
- ورودیهای قابل پردازش توسط عامل را محدود کنند: سازمانها باید مشخص کنند عامل هوش مصنوعی مجاز به پردازش محتوای کدام کاربران یا منابع است تا احتمال دریافت ورودیهای مخرب کاهش پیدا کند.
- فرایند بررسی انسانی را فعال کنند: خروجیهای تولیدشده توسط عامل هوش مصنوعی، بهویژه پیش از انتشار عمومی، باید تحت بررسی و تأیید انسانی قرار گیرند.
محدودیت سازوکارهای حفاظتی
گیتهاب پیش از انتشار خروجی عامل هوش مصنوعی، یک مرحله تشخیص تهدید را اجرا میکند تا محتوای تولیدشده را بررسی کند. با این حال، آزمایشهای Noma Security نشان داد که حتی یک تغییر کوچک در متن دستور میتواند این لایههای حفاظتی را دور بزند. این موضوع نشان میدهد که فیلترهای امنیتی تنها یک لایه دفاعی تکمیلی هستند و نمیتوانند بهتنهایی بهعنوان یک مرز امنیتی قابل اتکا عمل کنند.
گیتهاب و سایر ارائهدهندگان فناوری، برای مقابله با این نوع حملات، مجموعهای از سازوکارهای حفاظتی را توسعه دادهاند؛ اما امکان عبور از این لایهها با یک تغییر ساده نشان میدهد که ریشه مشکل فراتر از یک ضعف معمولی است. به همین دلیل، پژوهشگران و شرکتهای فعال در این حوزه، این چالش را یک محدودیت معماری میدانند.
دلیل اصلی این مسئله آن است که در زبان طبیعی، برخلاف زبانهای ساختاریافتهای مانند SQL، مرز مشخصی میان «داده» و «پرامپت» یا «دستورالعمل» وجود ندارد. به همین دلیل، نمیتوان تنها با استفاده از فیلترهای امنیتی، تزریق پرامپت را بهطور کامل متوقف کرد؛ بلکه راهکار مؤثر، طراحی معماری امنتر، استفاده از ایزولهسازی، محدودسازی اعتبارنامهها و اعمال فرآیندهای بررسی مرحلهای است.
تا زمانی که چنین مرزی میان داده و دستورالعمل ایجاد نشود، هر عامل هوش مصنوعی که به دادههای خصوصی دسترسی دارد، ورودیهای غیرقابل اعتماد را پردازش میکند و امکان انتشار عمومی اطلاعات را دارد، میتواند با یک مورد پیگیری عمومی که بهدقت طراحی شده است، به مسیری برای افشای داده تبدیل شود.
