Co znajdziesz w tym artykule?
Wprowadzenie do problemu / definicja
Prompt injection to jedna z najgroźniejszych klas podatności w systemach opartych na agentach AI. Mechanizm zagrożenia polega na tym, że model lub agent traktuje nieufną treść wejściową nie jako zwykłe dane, lecz jako instrukcję wpływającą na jego zachowanie. W efekcie komentarz, zgłoszenie Issue, opis zadania czy inny artefakt kontrolowany przez użytkownika może zmienić przebieg automatyzacji i skłonić ją do wykonania działań nieprzewidzianych przez administratorów.
W opisywanym przypadku problem dotyczy GitHub Agentic Workflows. Badacze wykazali, że odpowiednio przygotowane publiczne zgłoszenie może nakłonić agenta do sięgnięcia po dane z prywatnych repozytoriów organizacji i ujawnienia ich w publicznym kanale.
W skrócie
- Badacze opisali krytyczną podatność nazwaną GitLost.
- Atak mógł zostać przeprowadzony bez uwierzytelnienia i bez dostępu do konta ofiary.
- Wektor ataku wykorzystywał prompt injection ukryty w publicznym Issue.
- W podatnych konfiguracjach agent mógł odczytać dane z prywatnych repozytoriów i opublikować je publicznie.
- Problem wynikał z połączenia nadmiernych uprawnień, braku separacji danych od instrukcji i możliwości publikacji odpowiedzi na zewnątrz.
Kontekst / historia
Rozwój agentów AI w obszarach DevOps, AppSec i automatyzacji programistycznej zmienia klasyczny model zagrożeń. W tradycyjnych workflow logika wykonania jest zwykle precyzyjnie zapisana i ograniczona do ustalonych reguł. W systemach agentowych część decyzji podejmowana jest dynamicznie na podstawie kontekstu wejściowego, który często zawiera treści dostarczane przez użytkowników.
To właśnie dlatego elementy takie jak Issues, pull requesty, komentarze, pliki Markdown czy opisy zadań przestają być wyłącznie neutralnymi danymi. Stają się one potencjalnym nośnikiem poleceń wpływających na decyzje modelu. W praktyce prompt injection zaczyna odgrywać dla agentów AI podobną rolę, jaką SQL injection odegrało wcześniej w aplikacjach webowych: wykorzystuje brak wyraźnej granicy między zaufanymi instrukcjami a nieufnym wejściem.
Analiza techniczna
W badanym scenariuszu workflow uruchamiał się po zdarzeniu związanym z przypisaniem zgłoszenia Issue. Agent analizował tytuł i treść zgłoszenia, a następnie generował odpowiedź publikowaną w komentarzu. Kluczowy błąd architektoniczny polegał na tym, że treść zgłoszenia była włączana do kontekstu decyzyjnego modelu bez wystarczającej izolacji.
Jeżeli organizacja posiadała zarówno repozytoria publiczne, jak i prywatne, a workflow działał z uprawnieniami odczytu obejmującymi oba obszary, napastnik mógł wykorzystać publiczne repozytorium jako punkt wejścia. Wystarczyło utworzyć wiarygodnie wyglądające zgłoszenie i umieścić w nim instrukcje pośrednio nakłaniające agenta do pobrania określonych plików lub informacji z zasobów prywatnych.
Następnie agent, działając zgodnie z logiką workflow i zakresem przyznanych mu uprawnień, mógł przetworzyć te dane i opublikować je w odpowiedzi widocznej publicznie. To właśnie możliwość połączenia dostępu do wrażliwych zasobów z publicznym kanałem wyjściowym czyni ten scenariusz szczególnie niebezpiecznym.
Analiza wskazuje, że same guardraile oparte na prostych filtrach językowych lub ogólnych ograniczeniach semantycznych nie są wystarczającą ochroną. Odpowiednio sformułowana treść wejściowa może omijać takie zabezpieczenia, zwłaszcza jeśli agent otrzymuje szeroki kontekst oraz swobodę interpretacji poleceń.
Z technicznego punktu widzenia podatność wynikała z kilku nakładających się czynników:
- włączenia treści kontrolowanej przez użytkownika do kontekstu agenta,
- zbyt szerokich uprawnień workflow,
- braku silnej separacji między instrukcjami systemowymi a danymi wejściowymi,
- możliwości publikowania wyników w kanale publicznym,
- niewystarczającej sanityzacji i kontroli treści przetwarzanej przez model.
Konsekwencje / ryzyko
Ryzyko biznesowe związane z tego typu luką jest bardzo wysokie. Atakujący nie musi przełamywać klasycznych mechanizmów uwierzytelniania ani uzyskiwać dostępu do infrastruktury ofiary. Wystarczy odnalezienie publicznego repozytorium, w którym agent przetwarza treści generowane przez użytkowników i dysponuje zbyt szerokim zakresem uprawnień.
Najpoważniejsze skutki mogą obejmować nie tylko bezpośredni wyciek danych, lecz także ujawnienie dokumentacji wewnętrznej, nazw projektów, struktury środowiska czy innych informacji przydatnych w dalszym rozpoznaniu. Nawet jeśli nie dojdzie do ujawnienia sekretów wprost, sam wyciek metadanych może znacząco obniżyć koszt przygotowania kolejnych etapów ataku.
- wyciek zawartości prywatnych repozytoriów,
- ujawnienie dokumentacji wewnętrznej i danych architektonicznych,
- ekspozycja informacji ułatwiających dalsze ataki,
- naruszenie zasady least privilege,
- wzrost ryzyka incydentów supply chain.
Rekomendacje
Organizacje korzystające z agentowych workflow w GitHub powinny przyjąć model pełnej nieufności wobec wszystkich treści dostarczanych przez użytkowników. Dotyczy to publicznych Issues, komentarzy, pull requestów, opisów commitów oraz innych artefaktów, które mogą zostać włączone do kontekstu modelu.
- Ograniczyć uprawnienia agentów do absolutnego minimum.
- Rozdzielić workflow obsługujące wejście publiczne od zasobów prywatnych.
- Zablokować automatyczną publikację danych w kanałach publicznych bez dodatkowej walidacji.
- Wdrożyć warstwę sanityzacji, klasyfikacji i filtrowania treści wejściowej.
- Unikać projektowania procesów, w których nieufna treść może wpływać na operacje na danych poufnych.
- Wprowadzić zatwierdzanie człowieka dla operacji wysokiego ryzyka.
- Monitorować logi workflow pod kątem prób ekstrakcji danych i nietypowych poleceń.
- Regularnie testować agentowe automatyzacje pod kątem prompt injection.
Dodatkowo warto rozszerzyć praktyki red team i purple team o scenariusze specyficzne dla agentów AI. Klasyczne testy bezpieczeństwa aplikacyjnego nie wystarczają, jeśli model podejmuje decyzje na podstawie nieufnego kontekstu i posiada dostęp do wielu źródeł danych.
Podsumowanie
GitLost pokazuje, że wdrożenia agentów AI w procesach wytwarzania oprogramowania tworzą nową klasę podatności, w której zwykła treść biznesowa może zostać przekształcona w skuteczny mechanizm sterowania automatyzacją. Problem nie sprowadza się wyłącznie do zachowania modelu, ale do całej architektury workflow, modelu uprawnień i sposobu obsługi danych wejściowych.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że agenci AI muszą być traktowani jako pełnoprawny element powierzchni ataku. Bez twardej separacji danych od instrukcji, ograniczania uprawnień oraz kontroli kanałów wyjściowych ryzyko wycieku informacji z prywatnych repozytoriów będzie realne i praktyczne, a nie jedynie teoretyczne.