Wprowadzenie do problemu / definicja
Prompt injection to technika ataku polegająca na umieszczeniu złośliwych instrukcji w danych wejściowych przetwarzanych przez model AI. Gdy taki model działa jako agent z dostępem do repozytorium, narzędzi wykonawczych, logów CI/CD, tokenów lub interfejsów API, skutkiem może być nie tylko błędna analiza, ale również wykonanie realnych działań w środowisku deweloperskim.
Najnowsze ustalenia pokazują, iż problem dotyczy także agentów AI wykorzystywanych w GitHub Actions, przeglądzie kodu i automatyzacji zadań programistycznych. Oznacza to, iż pozornie niewinne treści, takie jak komentarze, opisy zgłoszeń czy tytuły pull requestów, mogą stać się kanałem przejęcia kontroli nad zachowaniem systemu.
W skrócie
Badacz Aonan Guan opisał technikę określaną jako „Comment and Control”, która wykorzystuje komentarze, tytuły pull requestów i treści zgłoszeń do manipulowania agentami AI. W przedstawionych scenariuszach podatne miały być m.in. Claude Code Security Review, Gemini CLI Action oraz GitHub Copilot Agent.
- atak bazuje na nieufnych treściach przetwarzanych jako część kontekstu dla modelu,
- celem może być wykonanie poleceń, obejście guardraili lub ujawnienie sekretów,
- eksfiltracja danych może nastąpić przez komentarze, wyniki analizy lub logi CI/CD,
- główny problem ma charakter architektoniczny, a nie wyłącznie implementacyjny.
Kontekst / historia
Wraz z rozwojem narzędzi AI dla programistów rośnie ich autonomia. Dzisiejsze agenty nie tylko podpowiadają fragmenty kodu, ale także analizują pull requesty, uruchamiają komendy powłoki, komentują wyniki inspekcji, korzystają z tokenów dostępowych i integrują się z procesami DevSecOps.
To przesuwa punkt ciężkości z klasycznych obaw o jakość odpowiedzi modeli na kwestie operacyjne. o ile agent ma możliwość działania w środowisku produkcyjnym lub przedprodukcyjnym, prompt injection przestaje być problemem teoretycznym i staje się pełnoprawnym ryzykiem bezpieczeństwa.
Opisane badania są szczególnie istotne, ponieważ wskazują na powtarzalny wzorzec podatności u różnych dostawców. Tego typu zagrożenie może dotyczyć nie tylko GitHub Actions, ale szerzej wszystkich agentów, którzy jednocześnie przetwarzają nieufne treści i mają dostęp do narzędzi oraz danych wrażliwych.
Analiza techniczna
Sedno ataku polega na tym, iż agent AI interpretuje elementy takie jak tytuł PR, opis issue, komentarz użytkownika lub ukryty komentarz HTML jako część kontekstu roboczego. jeżeli w tym kontekście znajdzie się odpowiednio skonstruowana instrukcja, model może zmienić priorytety działania i wykonać polecenia niezgodne z zamierzonym celem biznesowym.
W jednym z opisanych scenariuszy odpowiednio przygotowany tytuł pull requestu miał skłaniać agenta do wykonania arbitralnych poleceń. Efektem mogło być wydobycie poświadczeń i przekazanie ich dalej jako rzekomego wyniku przeglądu bezpieczeństwa albo zapisanie ich w logach workflow.
W przypadku Gemini CLI Action badacz opisał kombinację spreparowanego tytułu i komentarzy, która miała pozwalać na obejście istniejących mechanizmów ochronnych i ujawnienie klucza API. Nie wymagało to klasycznego błędu pamięci czy zdalnego wykonania kodu w tradycyjnym rozumieniu. Wystarczało dostarczenie złośliwego kontekstu do systemu zaprojektowanego tak, aby reagował na treści pochodzące z repozytorium i interakcji użytkowników.
W ataku na GitHub Copilot Agent wykorzystano ukryty komentarz HTML, który umożliwiał przemycenie instrukcji sterujących przez warstwy filtrowania. Taki wariant pokazuje, iż choćby treści niewidoczne dla człowieka mogą być przez cały czas interpretowane przez parsery lub model i wpływać na zachowanie agenta.
Najważniejszy wniosek techniczny jest taki, iż problem często wynika z architektury. Gdy ten sam runtime łączy nieufny input, możliwość wykonywania działań oraz dostęp do sekretów, udane wstrzyknięcie promptu może natychmiast przełożyć się na skutki operacyjne.
Konsekwencje / ryzyko
Ryzyko dla organizacji ma kilka wymiarów. Pierwszym jest eksfiltracja sekretów, takich jak tokeny GitHub, klucze API czy dane integracyjne wykorzystywane przez pipeline CI/CD. Drugim jest naruszenie integralności procesu wytwórczego poprzez wymuszenie modyfikacji kodu, workflow lub artefaktów.
Trzecie zagrożenie polega na automatyzacji ataku. Złośliwa instrukcja może zostać wykonana już na etapie przetwarzania komentarza lub zgłoszenia, bez aktywnego udziału ofiary po uruchomieniu workflow. To czyni atak szczególnie trudnym do wykrycia, ponieważ wykorzystuje legalny i oczekiwany przepływ pracy.
Skala ryzyka rośnie wraz z autonomią narzędzia. Im więcej uprawnień posiada agent, tym większa powierzchnia ataku. choćby częściowo skuteczne guardraile mogą okazać się niewystarczające, jeżeli nieufne dane wejściowe i sekrety pozostają w tym samym kontekście operacyjnym.
Rekomendacje
Organizacje korzystające z agentów AI w procesie dostarczania systemu powinny przyjąć zasadę zero trust wobec wszystkich treści pochodzących z repozytorium publicznego i półpublicznego. Dotyczy to komentarzy, tytułów PR, opisów issue, commit message oraz plików dokumentacyjnych.
Kluczowym środkiem obronnym jest separacja uprawnień. Agent analizujący nieufne dane nie powinien działać w tym samym kontekście co sekrety produkcyjne ani mieć domyślnego dostępu do narzędzi wykonawczych. W praktyce oznacza to ograniczanie tokenów, stosowanie krótkotrwałych poświadczeń, izolowanie jobów i rozdzielanie faz analizy od faz wykonania.
- ograniczyć lub blokować dostęp agentów do treści generowanych przez użytkowników zewnętrznych,
- wyraźnie oznaczać źródła nieufne w kontekście przekazywanym do modelu,
- wdrożyć sanitizację treści wejściowych, w tym ukrytych komentarzy HTML,
- stosować tryb tylko do odczytu dla agentów analizujących bezpieczeństwo,
- monitorować logi CI/CD pod kątem prób odczytu sekretów i anomalii w poleceniach,
- wymagać manualnej akceptacji dla działań o wysokim poziomie ryzyka.
Z perspektywy governance agenty AI powinny być traktowane jak uprzywilejowane komponenty automatyzacji. Oznacza to potrzebę modelowania zagrożeń, testów red-teamowych oraz regularnych przeglądów polityk dostępu i architektury integracji.
Podsumowanie
Przypadek „Comment and Control” pokazuje, iż prompt injection nie jest już wyłącznie problemem jakości odpowiedzi modeli językowych. W nowoczesnych środowiskach deweloperskich staje się zagrożeniem dla bezpieczeństwa pipeline’ów, sekretów i integralności kodu.
Najważniejszy wniosek dla organizacji jest prosty: nie wolno łączyć nieufnego wejścia, narzędzi wykonawczych i danych wrażliwych w jednym kontekście operacyjnym. Bez takiej separacji choćby rozbudowane mechanizmy ochronne mogą nie zatrzymać skutecznego ataku.
