Jaka ochrona branchy powinna obowiązywać, gdy agenci kodujący otwierają pull requesty

Co się zmienia, gdy pull request otwiera agent

Ochronę branchy zaprojektowano z myślą o ludziach: jedna osoba pisze, inna zatwierdza. Agenci zmieniają trzy rzeczy. Autorem jest narzędzie działające na czyimś tokenie, więc nie jest oczywiste, kto może zatwierdzić. Agenci często pushują, czasem już po zatwierdzeniu. A agent może edytować pliki, które mówią jemu i CI, jak mają się zachowywać, w tym pliki instrukcji i workflowy.

Instrukcje w AGENTS.md czy w playbooku proszą agenta o właściwe zachowanie. O tym, co da się zmergować, decydują ustawienia repozytorium. Ten tekst dotyczy tych ustawień na GitHubie. Przegląd kodu napisanego przez agenta to osobny temat, który omawiamy w poradniku o code review z AI.

Podstawowy zestaw dla branchy, do których celują agenci

Na GitHubie to ustawienia w regule ochrony brancha albo w rulesecie dla domyślnego brancha i ewentualnych branchy release. Przy każdym punkcie piszemy, dlaczego przy agentach zyskuje na znaczeniu.

• Wymagaj pull requesta z co najmniej jednym zatwierdzeniem, żeby każda zmiana agenta przeszła przez człowieka.
• Unieważniaj nieaktualne zatwierdzenia, gdy nowe commity zmieniają diff, bo agenci pushują dalej po komentarzach z review.
• Wymagaj zatwierdzenia ostatniego pusha przez kogoś innego niż osoba, która go wypchnęła.
• Wymagaj review właścicieli kodu, z właścicielami wskazanymi dla konfiguracji agentów i workflowów.
• Wymagaj checków statusu dla buildu i testów, a tam, gdzie się da, ustaw oczekiwaną aplikację źródłową.
• Utrzymaj blokadę force pushy i usuwania brancha, co reguła ochrony robi domyślnie.
• Włącz Do not allow bypassing, bo domyślnie administratorzy i role z uprawnieniem do obejścia są zwolnieni z reguł.

Wymagane checki trudne do podrobienia

GitHub dokumentuje, że każda osoba i każda integracja z prawem zapisu może ustawić stan dowolnego checka statusu w repozytorium. Token agenta z prawem zapisu mógłby więc teoretycznie zgłosić wymagany check jako zaliczony. Ustaw jako oczekiwane źródło każdego wymaganego checka aplikację GitHub, która go uruchamia, żeby status od kogoś innego nie spełniał reguły.

Ważne są jeszcze dwa szczegóły. Wymagane checki są zaliczone, gdy raportują successful, skipped albo neutral, więc check, który jest pomijany na branchach agentów albo zgłasza uwagi jako neutral, niczego nie blokuje. Nazwy jobów powinny być unikalne we wszystkich workflowach, bo duplikaty czynią wyniki niejednoznacznymi i mogą blokować merge.

Ustal, kto jest autorem

Traktuj inżyniera, który uruchomił agenta, jako autora, żeby zatwierdzał ktoś inny. GitHub wbudował to w Copilot cloud agent, i tylko tam: osoba, która poprosiła o pull request, nie może go zatwierdzić, agent pushuje tylko na własny branch copilot/ albo na branch pull requesta i nie może zatwierdzać ani mergować. Gdy Copilot otwiera pull request pod własną tożsamością aplikacji, na przykład z wspólnego wątku na Slacku, rulesety domyślnie wymagają jednego dodatkowego zatwierdzenia. GitHub oznacza to ustawienie jako public preview.

Inni agenci pushują z tożsamością, którą im dasz: osobistym tokenem, kontem bota albo aplikacją GitHub. Sprawdź, czy nie ma ona roli administratora, nie jest na żadnej liście obejść i nie może zmieniać rulesetów. Potem zobacz, kogo reguła ostatniego pusha faktycznie wyklucza. Jeśli commity pojawiają się pod kontem inżyniera, wyklucza tego inżyniera. Jeśli agent pushuje jako bot albo aplikacja, wyklucza tylko bota, a inżynier, który uruchomił przebieg, nadal może zatwierdzić. Wtedy niech system uruchamiający agenta zapisuje, kto go uruchomił, i dodaj wymagany check, raportowany przez aplikację pod twoją kontrolą, który nie przechodzi, dopóki zatwierdzenie tej osoby jest jedynym.

Chroń pliki, które sterują agentem

Wytyczne GitHuba dotyczące zabezpieczeń Copilota zalecają chronić pliki konfiguracji agentów i MCP przez CODEOWNERS i wymagane review właścicieli kodu. To samo dotyczy workflowów CI i samego pliku CODEOWNERS. Pull requesty używają pliku CODEOWNERS z brancha bazowego, więc agent nie zmieni swoich recenzentów w tym samym pull requeście.

/AGENTS.md                         @example-org/platform
/CLAUDE.md                         @example-org/platform
/.claude/                          @example-org/platform
/.cursor/rules/                    @example-org/platform
/.github/copilot-instructions.md   @example-org/platform
/.github/workflows/                @example-org/platform
/.github/CODEOWNERS                @example-org/platform

Rulesety mogą też wymagać zatwierdzenia przez określone zespoły, gdy pull request dotyka wybranych ścieżek, na przykład zespołu bezpieczeństwa przy kodzie uwierzytelniania. To daje regułę opartą na ścieżkach bez polegania wyłącznie na kolejności w CODEOWNERS.

Sprawdź ustawienia w repozytorium testowym

Ustawienia się zmieniają i nakładają. Kilka rulesetów na jednym branchu jest łączonych i obowiązuje najbardziej restrykcyjna wersja każdej reguły, obok ewentualnej reguły ochrony brancha. Samo przeczytanie konfiguracji nie wystarcza, więc testujemy ją prawdziwą tożsamością agenta w jednorazowym repozytorium, które kopiuje reguły produkcyjne:

1. 1

   Push na chroniony branch

   Bezpośredni push tokenem agenta musi się nie udać.

2. 2

   Zatwierdź pracę własnego agenta

   Inżynier, który uruchomił przebieg, zatwierdza jego pull request, a merge musi pozostać zablokowany. Copilot egzekwuje to sam; przy innych agentach działa to tylko wtedy, gdy masz check sprawdzający, kto uruchomił agenta.

3. 3

   Push po zatwierdzeniu

   Nowy commit agenta po zatwierdzeniu musi wymagać ponownego zatwierdzenia.

4. 4

   Podrób status

   Ustawienie wymaganego checka na success przez API statusów commitów tokenem agenta nie może odblokować merge'a.

5. 5

   Zmień plik sterujący

   Oznacz testowy pull request jako gotowy do review, bo przy wersjach roboczych właściciele kodu nie są proszeni o przegląd. Zmiana AGENTS.md albo workflowu musi wtedy wywołać prośbę o review zespołu platformowego, a merge musi pozostać zablokowany, dopóki ktoś z tego zespołu nie zatwierdzi.

Powtarzaj test, gdy dodajesz agenta, zmieniasz jego tożsamość albo edytujesz rulesety. Takie ustawienia są częścią tego, jak wdrażamy agentów kodujących razem z zespołami platformowymi.