Jak ograniczyć dostęp agenta GitHub Copilot

„Agent ma dostęp do repozytorium” to za mało, żeby ocenić ryzyko. Trzeba wiedzieć, które pliki może czytać, co może zmieniać, jakie polecenia uruchomi i do jakich domen wyśle żądania. Inaczej jedna wygodna zgoda może dać mu znacznie więcej niż wymaga zadanie.

We wrześniu 2026 GitHub ogłosił dwie zmiany dla organizacji korzystających z Copilota: wykluczanie treści działa już w aplikacji Copilot i CLI, a zarządzane centralnie uprawnienia pozwalają blokować operacje, wymagać każdorazowej zgody lub dopuszczać je bez pytania. Te mechanizmy rozwiązują różne problemy.

Wykluczanie treści: co trafia do kontekstu?

Administrator repozytorium, organizacji lub przedsiębiorstwa może wskazać pliki, które Copilot ma pomijać. Według dokumentacji GitHuba wykluczone pliki nie powinny zasilać sugestii i odpowiedzi ani być analizowane w Copilot code review. Od 2 września polityki te są respektowane również w aplikacji Copilot i Copilot CLI dla klientów Business i Enterprise.

To nie jest magiczne odcięcie wszystkich śladów informacji. Dokumentacja wymienia istotne ograniczenia: IDE może pośrednio przekazać semantyczną informację o wykluczonym pliku, na przykład typ symbolu; wykluczenia nie obejmują obecnie linków symbolicznych i repozytoriów na zdalnych systemach plików. GitHub zaznacza również brak obsługi wykluczeń w trybach Edit i Agent czatu Copilota w VS Code i innych edytorach. Dlatego sprawdź konkretny klient i tryb pracy, zanim uznasz politykę za szczelną granicę.

Jeśli plik zawiera sekret, rozwiązaniem nadal jest usunięcie sekretu z repozytorium i rotacja poświadczeń. Wykluczenie z kontekstu modelu nie zastępuje zarządzania sekretami.

Zarządzane uprawnienia: co agent może zrobić?

Drugi mechanizm dotyczy operacji. W ustawieniach zarządzanych można zdefiniować reguły deny, ask i allow dla poleceń powłoki, odczytu i edycji plików oraz domen sieciowych. Obowiązuje kolejność deny > ask > allow. Reguła ask wymaga świeżej zgody przy danej operacji; wcześniejsza zgoda i tryb automatycznej akceptacji jej nie zastępują.

Te uprawnienia są ogólnie dostępne w aplikacji Copilot, CLI i sesjach VS Code korzystających z Agent Host. Ostatni warunek ma znaczenie: nie przypisuj zachowania Agent Host każdej sesji agenta w VS Code.

Dla typowego zadania „znajdź przyczynę błędu i przygotuj PR” przyjąłbym taką pierwszą wersję polityki:

Operacja	Decyzja na start	Powód
Odczyt kodu w katalogu usługi	`allow`	potrzebny do analizy
Uruchomienie testów lokalnych	`allow`	wynik ma być sprawdzalny
Edycja plików usługi	`ask`	człowiek widzi moment wejścia w zmianę
`git push`, deploy i zmiany infrastruktury	`ask` lub `deny`	to już działanie poza lokalnym repo
Odczyt katalogów z sekretami	`deny`	zadanie tego nie potrzebuje

To przykładowy podział decyzji, nie gotowy plik konfiguracyjny dla każdej firmy. Konkretne wzorce ścieżek i poleceń trzeba przetestować na używanym kliencie. Dokumentacja GitHuba pokazuje składnię managed-settings.json, a także osobne listy dozwolonych i zablokowanych serwerów MCP. Warto je przejrzeć, jeśli w zespole powstają własne pluginy lub rośnie liczba integracji MCP.

Zacznij od jednego zadania

Wybierz workflow o małym ryzyku, na przykład zmianę walidacji w jednym API. Spisz potrzebne odczyty, edycje, polecenia i połączenia sieciowe. Uruchom agenta i zapisz każdą sytuację, w której polityka zatrzymuje pracę albo przepuszcza zbędną operację. Dopiero po tej próbie rozszerzaj reguły na cały zespół.

W Agent Engineering ten krok należy do warstwy Kontrola. Dobra kontrola nie polega na klikaniu „Zezwól” co minutę. Polega na tym, że zespół umie przed zadaniem powiedzieć, które operacje są zwykłą pracą, a które wymagają decyzji człowieka.

Źródła: wykluczanie treści w aplikacji i CLI, GitHub, 02.09.2026, ograniczenia wykluczania treści, zarządzane uprawnienia, GitHub, 09.09.2026, referencja ustawień zarządzanych. Stan: 23 września 2026.