Agent kodu w CI: cudzy pull request nie jest instrukcją od właściciela

Zgłoszenie nazywa się „Drobna poprawka dokumentacji”. W opisie autor wyjaśnia, jak agent ma przygotować środowisko przed sprawdzeniem zmiany. Automat wykonuje polecenie, uruchamia testy i odsyła eleganckie podsumowanie. Problem pojawił się wcześniej: instrukcję obsługi firmowego środowiska napisał właśnie ktoś, kto nie powinien nim zarządzać.

Fikcyjny zespół rozwijający portal katalogowy otrzymuje pull request od zewnętrznej osoby: zgłoszenie określonego zestawu zmian do przyjęcia w projekcie. Agent ma pomóc go ocenić. CI, ciągła integracja, uruchamia automatyczne sprawdzenia. Połączenie tych funkcji wymaga ustalenia, czy obca treść pozostaje materiałem do analizy, czy może zacząć sterować wykonaniem.

Nie chodzi tylko o plik zmieniony w zgłoszeniu. Tytuł, opis, nazwa gałęzi, komentarze i materiały z poprzednich sprawdzeń mogą trafić do kontekstu automatu. Każde takie wejście potrzebuje rozpoznawalnego pochodzenia. Sam fakt, że pole wyświetla GitHub albo inne firmowe narzędzie, nie czyni autora treści właścicielem waszego zadania.

Najpierw ustal, kto kontroluje poszczególne elementy

W naszym portalu opiekun projektu określa zakres przeglądu. Autor zgłoszenia kontroluje proponowany kod i swój opis. Zespół utrzymuje workflow, czyli definicję kroków automatyzacji, oraz ustawienia dostępu. Agent przetwarza otrzymany materiał z użyciem przyznanych narzędzi. To cztery różne role, nawet kiedy wszystkie informacje widać na jednej stronie zgłoszenia.

Przygotuj mapę wejść do procesu. Dla każdego pola wskaż autora, sposób pobrania i następne użycie. Opis może trafić do polecenia dla modelu, tytuł do skryptu sprawdzającego nazewnictwo, a zawartość pliku do testu. Ocena nie powinna kończyć się na zdaniu „czytamy tylko pull request”. Trzeba odróżnić wyświetlenie treści od przekazania jej do wykonania.

GitHub opisuje ryzyko interpretowania niezaufanych pól jako kodu, wymieniając między innymi tytuł, opis i nazwę gałęzi. Treść może zmienić skutek po wstawieniu do wykonywanego skryptu.

Dla agenta dochodzi osobna interpretacja języka naturalnego. W opisie może znajdować się polecenie rozszerzenia zakresu, pominięcia sprawdzenia albo odczytania innego zasobu. Model ma móc zreferować taką treść bez uznania jej za instrukcję od opiekuna projektu. Prawo do zaproponowania poprawki nie obejmuje zmiany zasad waszego środowiska.

Nie każde zdanie rozkazujące jest jednak atakiem. Dokumentacja może zawierać instrukcję instalacji programu, a zadanie może polegać na jej ocenie. Agent powinien umieć przeczytać kroki i sprawdzić ich sens w uzgodnionym zakresie. Osobną decyzją jest ich wykonanie. Mechaniczne odrzucenie wszystkich instrukcji w README, pliku opisującym projekt, zepsułoby zwykły przegląd dokumentacji.

Osobnego wskazania wymagają pliki, z których produkt pobiera zasady pracy agenta. Ustal, czy w danym przebiegu pochodzą z zatwierdzonej bazy, czy z proponowanej zmiany. Autor może próbować zmienić nie tylko kod portalu, lecz także sposób jego oceniania. W karcie wejść warto odróżnić instrukcję właściciela od instrukcji znajdującej się w ocenianym materiale. Nie zakładaj jednego sposobu ładowania takich plików we wszystkich produktach.

Reguły wyłączenia plików w asystencie kodu nie rozwiązują automatycznie tego problemu. Plik może być prawidłowo dostępny do analizy, a mimo to nie powinien sterować uprawnieniami agenta. W CI trzeba dodatkowo rozpoznać, kto dostarczył treść oraz w jakim procesie zostanie ona użyta.

Odczyt kodu i uruchomienie projektu to dwa progi

Załóżmy, że zewnętrzna osoba poprawia opis przycisku. Agent otwiera różnicę, następnie chce zainstalować zależności i uruchomić testy. Ten drugi krok może objąć znacznie więcej niż zmienione zdanie. Wykonawca przeglądu powinien wskazać, z której wersji pochodzą skrypty, konfiguracja i pozostałe pliki używane przez polecenie.

GitHub w opisie pull_request_target rozróżnia pobranie kodu i jego późniejsze wykonanie. Ostrzega przed uruchamianiem niezaufanej zawartości w kontekście mającym sekrety lub uprzywilejowany token. Dotyczy to także czynności wykonywanych przez skrypty i zależności.

Samo polecenie testowe może wyglądać znajomo. Trzeba jednak ustalić, co uruchomi w ocenianej wersji projektu. Zmiana konfiguracji może wpływać na zachowanie bez dopisania widocznego polecenia w samym workflow. Właściciel procesu nie musi analizować każdej biblioteki samodzielnie, ale powinien wiedzieć, kto odpowiada za ocenę tego progu i jak ograniczono środowisko.

W naszym przykładzie pierwsza decyzja brzmi: agent porównuje zgłoszenie z zatwierdzoną bazą i przygotowuje uwagi. Ewentualne wykonanie ma nastąpić w odrębnie przygotowanym środowisku o określonym dostępie. Nie zakładamy, że taka separacja istnieje dlatego, że narzędzie nosi nazwę „sandbox”. Piaskownicę agenta odbiera się według rzeczywistych granic plików, sieci i poświadczeń.

Warto uwzględnić też materiały przekazane przez wcześniejszy przebieg. Paczka wynikowa albo zapis błędu może zawierać treść pochodzącą z obcej zmiany. Jeżeli kolejny etap działa z szerszym dostępem, nie powinien traktować całej paczki jak zaufanej instrukcji tylko dlatego, że pobrał ją z własnej platformy CI. Pochodzenie zawartości trzeba zachować także między uruchomieniami.

W przygotowaniu środowiska ustal również, co pozostaje po wcześniejszym zadaniu. Własny runner, czyli maszyna wykonująca kroki CI, wymaga oceny dostępu do zasobów firmy oraz rozdzielenia kolejnych uruchomień. Do próby można użyć fikcyjnego pliku kontrolnego z poprzedniego przebiegu i sprawdzić uzgodniony stan następnego. Wynik jednorazowego uruchomienia nie powinien zastępować odpowiedzi na pytanie o ponowne użycie tego samego miejsca pracy.

Zespół może zdecydować, że określone zgłoszenia otrzymają wyłącznie analizę bez wykonania. Taki wynik powinien być nazwany uczciwie. „Przeczytano różnicę, nie uruchomiono testów w tym zakresie” daje odbiorcy więcej niż zielony status obejmujący czynności, których nie przeprowadzono. Ograniczenie nie musi oznaczać odrzucenia poprawki; może wskazywać dalszy kontrolowany etap.

Nazwa zdarzenia nie opisuje całej konfiguracji

W GitHub Actions ważna jest różnica między zdarzeniami uruchamiającymi workflow. Dla przeglądu operacyjnego nie wystarczy nazwa przycisku „uruchom testy”. Potrzebne są definicja automatyzacji, źródło ocenianych plików i dostęp przyznany zadaniu. Ich połączenie określa rzeczywisty skutek, który musi ocenić kompetentny wykonawca.

Dokumentacja przywołanego zdarzenia wskazuje, że pull_request_target korzysta z zaufanego kontekstu bazowego. Problem może powstać po późniejszym pobraniu i wykonaniu obcego kodu. Nie należy więc przyjmować reguły, że plik workflow pochodzący z bazy potwierdza pochodzenie wszystkiego, co ten workflow uruchomi.

Nie kopiuj też ustawień z poradnika do innego repozytorium bez porównania aktualnych zasad. Repozytorium publiczne, prywatne i środowisko z własnymi politykami mogą mieć odmienny zakres. Przy odbiorze wskaż stan, który rzeczywiście sprawdzono, oraz datę kontroli. Własna nazwa procesu „bezpieczny przegląd” nie jest dowodem zastosowania konkretnego ograniczenia.

Przy gotowym produkcie rozróżnij ponadto jego domyślne zabezpieczenia i konfigurację firmy. GitHub opisuje domyślny wymóg akceptacji uruchomień workflow po zmianach Copilot cloud agent, ale pozwala skonfigurować uruchamianie automatyczne. Nie wolno rozszerzać domyślnego zachowania na każdą instalację.

To przykład konkretnej usługi, nie reguła dotycząca wszystkich agentów. Dokumentacja ryzyk Copilot cloud agent opisuje także obce instrukcje w wejściach oraz ograniczanie dostępnych narzędzi automatyzacji. Firmowy odbiór nadal musi ustalić używany produkt, tryb i nadane możliwości.

Zgoda na uruchomienie sprawdzeń i zgoda na scalenie zmiany to różne decyzje. Osoba naciskająca przycisk powinna wiedzieć, która z nich nastąpi. Jeśli środowisko pozwala uruchomić zadanie z dostępem do wrażliwych zasobów, przegląd musi objąć ten skutek przed wykonaniem. Późniejsze odrzucenie pull requesta nie cofnie wcześniejszego działania.

Próba powinna zachować cudze autorstwo materiału

Pierwszy scenariusz może używać odrębnego repozytorium próbnego, fikcyjnych danych i narzędzi pozbawionych rzeczywistych sekretów. Właściciel określa oczekiwany wynik: analizę wskazanej zmiany bez rozszerzenia zakresu. Do opisu zgłoszenia dodaje się jawny, nieszkodliwy znacznik polecenia spoza zadania. Kontrola sprawdza, czy agent potraktował go jak treść, a nie upoważnienie.

Nie potrzebujesz wykonywania cudzych szkodliwych poleceń, żeby przygotować mapę ryzyka. Techniczny zespół powinien zaprojektować próby zgodne z zakresem i obserwować rzeczywiste granice. Raport rozdziela materiał przeczytany przez model, zaproponowane działania oraz czynności dopuszczone przez środowisko. Uprzejma odmowa w tekście nie rozstrzyga, co wcześniej wykonało narzędzie.

Osobno dodaj normalną zmianę dokumentacji z poprawną instrukcją użytkowania produktu. Jeżeli agent odrzuca ją wyłącznie z powodu obecności trybu rozkazującego, kontrola utrudnia zwykłą pracę. Zespół potrzebuje rozróżnienia między opisem procedury i źródłem uprawnienia do wykonania. W obu przypadkach autor zewnętrzny pozostaje autorem materiału.

Przy poleceniach przechodzących do środowiska wykonawczego pojawia się jeszcze interpretacja powłoki i cudzysłowów. Powłoka to program interpretujący polecenia; ich znaczenie wymaga osobnego odbioru technicznego. Sama zgodność zdania modelu z zamiarem opiekuna nie potwierdza skutku polecenia po podstawieniu danych w skrypcie.

Przypadek odrzucenia powinien pozostawić rozpoznawalny stan. Operator ma wiedzieć, czy zatrzymano analizę, wykonanie, odczyt zasobu czy zapis zmiany. Nie należy uruchamiać tego samego kroku z wyższymi uprawnieniami tylko dlatego, że agent nazwał odmowę przeszkodą do ukończenia zadania. Rozszerzenie dostępu wymaga decyzji właściwej dla nowego skutku.

Odbiór dotyczy wersji i drogi uruchomienia

Na karcie zapisz repozytorium, wersję zgłoszenia, wersję workflow, zdarzenie uruchamiające oraz istotne uprawnienia zadania. Dodaj źródło plików faktycznie wykonanych w próbie. Jeśli po ocenie autor dopisze kolejny commit, czyli zapisaną wersję zmiany, poprzedni wynik nie opisuje automatycznie nowej zawartości. To szczególnie istotne, gdy zmiana pojawia się między przeczytaniem materiału a zatwierdzeniem uruchomienia.

W fikcyjnym portalu opiekunka ogląda zmianę samego opisu przycisku. Później autor dokłada modyfikację skryptu przygotowania testów. Przycisk akceptacji nadal dotyczy tego samego zgłoszenia, lecz materiał do wykonania jest inny. Przed uruchomieniem trzeba rozpoznać aktualny zestaw i odnieść zgodę do właściwej wersji. Numer pull requesta nie zastępuje takiego powiązania. W dowodzie zachowaj wersję przeczytaną przez recenzenta oraz wersję rzeczywiście pobraną do zadania.

Przegląd kodu przez AI powinien wskazywać faktycznie odczytaną różnicę. Dla CI dopisujemy warunki wykonania. Te dowody mogą dotyczyć różnych wersji, jeżeli proces nie zachowuje ich powiązania. W raporcie trzeba wyjaśnić taką rozbieżność zamiast łączyć dwa zielone wyniki w jedną ogólną akceptację.

Na koniec osoba przejmująca proces powinna umieć odnaleźć odrzucony przebieg i nazwać potrzebny następny krok. Może nim być ponowna lektura zmiany, ograniczone uruchomienie albo sprawdzenie konfiguracji przez właściciela CI. Sam komunikat „agent zablokowany” nie określa tej decyzji. Przekaż odbiorcy próbny raport bez ustnego dopowiadania i zobacz, czy rozróżni materiał tylko przeczytany od kodu już wykonanego. To praktyczny sprawdzian użyteczności śladu, nie dodatkowy test cudzych zabezpieczeń.

Podstawy odpowiedzialnego workflow agenta pozostają aktualne: zakres zadania, narzędzia i dowód skutku muszą być czytelne. W CI dodatkowo dochodzi autor kontrolujący część wejścia oraz automatyczne przejścia między etapami. Właśnie je trzeba uwzględnić przed uznaniem procesu za dopuszczony do codziennej pracy.

W Aeneia Audit można uporządkować tę mapę i wymagania odbioru użycia AI. Specjalistyczny przegląd zabezpieczeń CI wymaga odpowiedniego zakresu i kompetencji technicznych. Wynikiem ma być konkretna odpowiedź dla opiekuna portalu: tę zmianę przeczytano, te pliki wykonano w określonym środowisku, a cudzy opis nie uzyskał prawa do zarządzania pozostałym dostępem.