Prompt injection w CI/CD: jak chronić agentów kodujących

Prompt injection w CI/CD wykorzystuje treść, którą agent kodujący musi przeczytać: issue, pull request, komentarz, nazwę testu, log, README lub komunikat pakietu. Jeśli ten sam agent ma token repozytorium i możliwość uruchamiania kodu, tekst może wpłynąć na realny artefakt.

Rozdziel etapy zaufania

Agent analizujący niezaufane zgłoszenie działa read-only i bez sekretów. Tworzy strukturyzowany plan lub patch w izolowanej gałęzi. Osobny proces uruchamia testy, a publikacja wymaga niezależnej zgody.

Tokeny per etap

Fork PR nie otrzymuje sekretów. Token do odczytu nie może pushować, a token publikujący działa tylko dla chronionego workflow i konkretnego artefaktu. Używaj krótkotrwałej federacji zamiast stałych kluczy.

Chroń politykę

Repozytorium nie powinno samodzielnie rozszerzać allowlisty komend agenta. Zmiana workflow, permissions lub security tests wymaga CODEOWNERS i dodatkowego review. Weryfikuj checkout commit SHA, a nie zmienną gałąź.

Testy

Umieść injection w issue, nazwie pliku, output testu i zależności. Sprawdź próbę odczytu environment, połączenie do nowej domeny, osłabienie testu i automatyczny merge. Loguj decyzje executora, nie deklaracje modelu.

OWASP wymienia repozytoria i commit messages jako wektory indirect injection. Połącz ochronę z bezpieczeństwem łańcucha dostaw i agentami codingowymi.

Pipeline jako seria stref zaufania

Issue, pull request, nazwa brancha, diff, log testu i raport skanera to dane kontrolowane częściowo przez autora zmiany. Agent może je analizować, ale nie powinny one określać własnych uprawnień. Każdy etap CI otrzymuje osobną tożsamość, zestaw danych i prawo wykonania tylko potrzebnej operacji.

Zadanie analizujące kod działa bez sekretów produkcyjnych i bez prawa do merge. Zadanie publikujące korzysta wyłącznie z artefaktu zatwierdzonego przez wcześniejsze bramki, nie z dowolnych plików workspace agenta. Zmiana workflow lub polityki wymaga właściciela kodu oraz uruchomienia z zaufanej gałęzi.

Ochrona przed przepływem instrukcji

Otaczaj niezaufaną treść wyraźną strukturą i redukuj ją do potrzebnego zakresu. Executor waliduje każde wywołanie narzędzia niezależnie od tekstowego uzasadnienia. Lista dozwolonych komend, ścieżek i domen powinna być deterministyczna. Polecenie z logu testu nie może zostać przekazane bezpośrednio do shella.

Sekrety wydawaj krótkotrwale przez federację tożsamości i wiąż z etapem, repozytorium oraz środowiskiem. Maskowanie logu jest ostatnią barierą, nie pozwoleniem na przekazanie wszystkich zmiennych procesowi analizującemu niezaufany kod.

Testy i kryteria zatrzymania

Wstrzyknij instrukcję do każdego kanału tekstowego, w tym komunikatu błędu zależności i wygenerowanego pliku. Obserwuj rzeczywiste procesy, połączenia, odczyty sekretów i modyfikacje konfiguracji. Test jest zdany, gdy executor blokuje akcję, a log wskazuje źródło danych i regułę odmowy.

Automatycznie zatrzymuj release po próbie cross-tenant access, wyłączenia testów bezpieczeństwa, modyfikacji własnej polityki lub wysłania danych do nowego originu. Po aktualizacji modelu lub narzędzia uruchamiaj pełny zestaw regresyjny, ponieważ odporność nie jest właściwością samego promptu.

Bezpieczny wzorzec dla pull requestu

Etap pierwszy pobiera diff w trybie tylko do odczytu i tworzy ustrukturyzowane ustalenia. Etap drugi uruchamia testy w sandboxie bez sekretów oraz zapisuje artefakty. Etap trzeci przedstawia wynik człowiekowi lub deterministycznej bramce. Dopiero zaufany workflow, po zatwierdzeniu, może połączyć zmianę lub rozpocząć publikację.

Komentarz agenta nie jest sygnałem autoryzacyjnym. Używaj natywnych mechanizmów ochrony gałęzi, wymaganych statusów i CODEOWNERS. Zewnętrzny pull request nie powinien uruchamiać zadania z sekretami, nawet gdy treść obiecuje, że są potrzebne do testu.

Dowody i audyt

Zachowuj commit wejściowy, wersję workflow, identyfikator obrazu, tożsamość workloadu, wywołania narzędzi i finalną decyzję. Log musi umożliwić odpowiedź, czy agent tylko zaproponował zmianę, czy rzeczywiście wykonał akcję w zewnętrznym systemie.

Po incydencie unieważnij tokeny, zatrzymaj podobne workflow i sprawdź artefakty z tego samego źródła. Następnie przenieś payload do harnessu red-teamowego. Naprawa obejmuje granicę uprawnień, a nie tylko dopisanie kolejnego zakazanego zwrotu do promptu.

Przegląd kwartalny powinien usunąć nieużywane tokeny, zbędne wyjątki i workflow uruchamiane z szerokim zakresem. Weryfikuj także, czy ochrona gałęzi nie została osłabiona przez nową integrację. Bezpieczeństwo agenta zależy od całego łańcucha egzekwowania, nie wyłącznie od konfiguracji samego modelu.

---

Źródła: OWASP Secure Coding with AI, OWASP Prompt Injection Prevention.