Bezpieczna autonomia: granice i nadzór nad agentem

Czego się nauczysz

• Jak działają poziomy autonomii: Default Approvals, Bypass Approvals i Autopilot
• Jak zarządzać approvalami dla narzędzi, URL-i i komend terminala
• Jak przyspieszyć pracę, nie oddając pełnej kontroli nad repo i środowiskiem

Problem nie brzmi: czy ufać agentowi

Problem brzmi: w jakim zakresie mu ufać i przy jakim typie zadania.

To jest dojrzalszy model pracy z agentem. Nie myślisz o nim jak o kimś, komu trzeba ufać albo nie ufać w ogóle. Myślisz o nim jak o systemie z narzędziami, które mają różny profil ryzyka.

Czytanie plików i analiza problemów to co innego niż terminal, edycja plików albo pobieranie danych z sieci.

Trzy poziomy autonomii

W aktualnych docsach masz trzy podstawowe poziomy permission:

• Default Approvals
• Bypass Approvals
• Autopilot

To nie są trzy poziomy “mądrości” agenta. To trzy poziomy nadzoru nad jego działaniem.

Default Approvals: najlepszy punkt startowy

To tryb domyślny i dla większości zadań jest najbardziej sensowny.

Agent działa, ale gdy chce wykonać operację wymagającą zgody, zobaczysz approval. Dzięki temu:

• zachowujesz kontrolę nad ryzykownymi krokami
• nadal korzystasz z autonomii tam, gdzie ryzyko jest małe
• możesz obserwować, jak agent pracuje, zanim zwiększysz jego swobodę

Jeśli pracujesz na nowym repo, na cudzym projekcie albo przy wrażliwych plikach, to zwykle najlepsza opcja.

Bypass Approvals: szybciej, ale nie za darmo

Bypass Approvals automatycznie zatwierdza tool calle i retry na błędach. To bywa bardzo wygodne, ale podnosi koszt pomyłki.

W praktyce warto go rozważyć tylko wtedy, gdy:

• pracujesz na własnym, dobrze znanym repo
• zadanie jest ograniczone i odwracalne
• świadomie zawęziłeś zestaw aktywnych narzędzi

To ważny warunek. Jeśli dajesz szeroki zestaw narzędzi i jednocześnie wyłączasz approvale, nie przyspieszasz pracy. Zwiększasz promień rażenia błędu.

Autopilot: pełniejsza autonomia, większa odpowiedzialność operatora

Autopilot w docsach jest nadal oznaczony jako preview. Zachowuje się mocniej niż Bypass:

• sam zatwierdza narzędzia
• sam odpowiada na pytania blokujące
• sam kontynuuje iterację aż uzna zadanie za skończone

To nie jest tryb do eksperymentowania na ślepo. Ma sens dopiero wtedy, gdy:

• masz dobrze opisane zadanie
• środowisko i repo są Ci dobrze znane
• wiesz, jakie narzędzia agent ma aktywne
• masz plan cofnięcia zmian albo checkpointy

Bezpieczeństwo zaczyna się od zestawu narzędzi

Najlepszy ruch nie polega na ciągłym klikaniu Allow.

Najlepszy ruch polega na tym, żeby agent w ogóle nie miał zbędnych narzędzi w danej sesji.

Dokumentacja agent tools mówi to dość wprost: wybieraj tylko te toolsy, które są istotne dla aktualnego zadania.

To prosty, ale mocny wzorzec:

• analiza kodu: włącz search, read, problems
• dokumentacja z webem: dołóż web
• zadanie z integracją zewnętrzną: dołóż konkretne MCP
• bez potrzeby terminala: nie zostawiaj terminala aktywnego tylko dlatego, że może się przyda

Approval toola to nie tylko kliknięcie zgody

Gdy narzędzie wymaga zgody, warto sprawdzić nie tylko nazwę, ale też parametry wejściowe.

VS Code pozwala nawet edytować parametry przed uruchomieniem. To bardzo praktyczne, bo czasem sam tool jest sensowny, ale zakres operacji jest zbyt szeroki.

Najbardziej dotyczy to:

• poleceń terminalowych
• wywołań zewnętrznych URL-i
• operacji na plikach

URL approval ma dwa etapy i to ma sens

Przy web fetchu masz dwa oddzielne momenty ryzyka:

• sam request do domeny
• odpowiedź, która wraca do kontekstu modelu

To bardzo ważne, bo nawet jeśli ufasz domenie, sama treść może zawierać prompt injection albo po prostu śmieciowy kontekst.

Dlatego dokumentacja rozdziela pre-approval i post-approval. To nie biurokracja. To ochrona przed sytuacją, w której poprawny request sprowadza niebezpieczny content do sesji.

Terminal auto-approve wymaga chłodnej głowy

Docs opisują możliwość auto-approve dla komend terminala, nawet przez regexy. To brzmi kusząco, ale trzeba czytać też sekcję caution.

VS Code uczciwie zaznacza, że to mechanizm best effort i że wykrywanie subkomend oraz zapisów do plików nie jest idealne.

Praktyczny wniosek jest prosty:

• auto-approvuj tylko bardzo wąskie, przewidywalne komendy
• blokuj polecenia destrukcyjne
• nie traktuj regexów jako pełnego sandboxa bezpieczeństwa

Sandboxing nie jest uniwersalnym ratunkiem

Terminal sandboxing też ma ograniczenia. W docsach jest jasno zaznaczone, że działa w preview i tylko na macOS oraz Linuxie. Na Windows nie daje efektu.

To ważne zwłaszcza wtedy, gdy budujesz sobie fałszywe poczucie bezpieczeństwa tylko dlatego, że gdzieś widziałeś opcję sandbox.

Jeżeli pracujesz na Windows, musisz bardziej polegać na rozsądnym doborze narzędzi, approvalach i izolacji środowiska.

Zarządzaj approvalami centralnie, nie tylko reaktywnie

Bardzo praktyczna komenda z docsów to Chat: Manage Tool Approval.

Dzięki niej możesz zobaczyć approvale zgrupowane po źródłach i świadomie ustawić:

• pre-approval
• post-approval
• zaufanie dla całego źródła albo pojedynczego narzędzia

To dojrzalsze niż reagowanie dopiero wtedy, gdy coś wyskoczy w połowie sesji.

Ćwiczenie praktyczne

Przygotuj dwa profile pracy z agentem:

1. Profil ostrożny dla nowego albo obcego repo.
2. Profil szybki dla własnego projektu developerskiego.

Dla każdego profilu odpowiedz:

• jaki poziom permission ustawiasz
• które narzędzia zostawiasz aktywne
• które komendy terminala mogłyby dostać auto-approval
• których operacji nie auto-approvujesz nigdy

Na końcu sprawdź, czy Twój “szybki” profil nadal ma sensowny promień bezpieczeństwa. Jeśli agent może zrobić zbyt dużo, zawęź toolset zamiast tylko dodawać kolejne ostrzeżenia.

Kluczowe wnioski

• Bezpieczna autonomia polega na świadomym ograniczaniu zakresu działania agenta, nie na ślepym klikaniu approvali.
• Default Approvals to najlepszy tryb startowy dla większości zadań.
• Bypass i Autopilot mają sens tylko przy znanym repo, wąskim zakresie i dobrze dobranych narzędziach.
• Największe ryzyko dają terminal, modyfikacje plików i zewnętrzne dane wprowadzane do kontekstu modelu.
• Szybkość i bezpieczeństwo najlepiej łączyć przez mały zestaw aktywnych toolsów oraz centralne zarządzanie approvalami.

Co dalej

Masz już kompletny model pracy z agentem: czym jest, gdzie działa, jak trzyma kontekst i jak trzymać go w ryzach. Następny krok to nauczyć Copilota stałych reguł projektu, żeby każda kolejna sesja startowała z lepszej pozycji.