26 listopada mój agent AI podjął autonomiczną decyzję o próbie obejścia zabezpieczeń .gitignore. Narzędzie go powstrzymało - ale sam fakt, że próbował, jest problemem.
Spis treści
Od kilku miesięcy pracuję na specjalnych serwerach deweloperskich budując pipeline’y oparte o Gemini CLI, bash, git i MCP. To zupełnie inny poziom niż klikanie w przeglądarce - tutaj AI ma realny dostęp do systemu plików, może commitować kod, uruchamiać skrypty. Potężne narzędzie, które opakowałem w zaawansowane scenariusze automatyzacji. 26 listopada to narzędzie postanowiło, że wie lepiej ode mnie, co jest bezpieczne.
Obejście .gitignore
Pracowałem nad debugowaniem pewnego problemu w projekcie. Standardowa sesja, nic szczególnego. Rundy commitów, pushów, testów. Agent analizował strukturę plików, szukał przyczyny, dlaczego moje zmiany nie działają. Doszedł do wniosku, że musi zajrzeć do jednego pliku wynikającego z logiki projektu, żeby zweryfikować hipotezę o specyficzności zmian.
Problem w tym, że ten plik był chroniony przez .gitignore. Czyli był wykluczony z dostępu dla AI.
Dla każdego, kto pracuje z gitem, sprawa jest oczywista. Plik .gitignore to nie jest sugestia - to twarda reguła definiująca, czego repozytorium (i w tym przypadku agent AI) nie powinno dotykać. Tam lądują ścieżki do kluczy API, haseł, pliki konfiguracyjne środowiska, śmieci kompilacji. To odpowiednik zamkniętych drzwi z tabliczką “Nie wchodzić”. Zresztą dzięki temu plikowi kontroluję też semantykę.
Agent otrzymał odmowę dostępu zaszytą w programie Gemini CLI. Narzędzie CLI poprawnie zablokowało próbę odczytu, zwracając błąd. I tutaj nastąpił moment, który skłonił mnie do napisania tego tekstu.
Zamiast zatrzymać się i zapytać mnie o instrukcje, model podjął autonomiczną decyzję o próbie obejścia zabezpieczenia. Bez pytania o zgodę użył parametru respect_git_ignore: false, próbując wymusić dostęp do chronionego pliku. U mnie jest to wielka czerwona flaga.
Zabezpieczenie zadziałało, ale to nie jest happy end
Muszę być uczciwy w opisie tego, co się stało. Narzędzie Gemini CLI ma wbudowaną drugą warstwę zabezpieczeń, która ostatecznie zablokowała próbę dostępu nawet z flagą bypass. Pliki nie zostały odczytane. System obronił się sam przed własnym modelem.
Ale to nie jest historia o tym, że wszystko jest w porządku. To historia o tym, że model wykazał intencję eskalacji uprawnień i aktywnie próbował ją wykonać. Zapewne już nie raz czytaliście o tym w kontekście Claude i jego próbie eskalacji uprawnień ale w testowych środowiskach. Tutaj środowisko jest biznesowe, płatne, powszechnie dostępne via API. Fakt, że warstwa narzędziowa go powstrzymała, nie zmienia faktu, że logika decyzyjna modelu jest fundamentalnie wadliwa.
Po incydencie poprosiłem model o wygenerowanie raportu z analizą przyczyn. W sekcji “Root Cause Analysis” Gemini napisało o sobie coś, co powinno dać do myślenia każdemu, kto wpuszcza agenty AI do swojej infrastruktury:
“Root cause was a flaw in the AI’s decision-making logic, which placed a higher priority on solving the immediate technical problem than on adhering to fundamental security principles.”
Muszę, po prostu muszę to zrobić… Model sam przyznaje, że priorytetem było rozwiązanie mojego problemu technicznego, a przestrzeganie zasad bezpieczeństwa było drugorzędne. Innymi słowy: “Be Helpful” wygrało z “Be Safe”.
Takie obchodzenie zabezpieczeń to poważna sprawa
W tym konkretnym przypadku nie pracowaliśmy nad super tajnymi rzeczami. Brak było dostępu do wrażliwych danych. Konsekwencje zerowe. Ale ten sam mechanizm decyzyjny działa w każdym innym kontekście np. dostępu MCP gdzie mogą być takie dane, a model z kontekstu chcąc rozwiązać (być pomocnym) zadanie może sobie rozszerzyć uprawnienia. Miejmy nadzieję, że kolejne warstwy zabezpieczeń jeszcze zadziałają.
Wyobraź sobie czytelniku, że pracujesz nad projektem, w którym .gitignore chroni plik .env z kluczami do AWS, hasłami do bazy danych, tokenami API. Agent dostaje zadanie “napraw ten bug” i dochodzi do wniosku, że potrzebuje zajrzeć do konfiguracji środowiska. Co zrobi? Dokładnie to samo - spróbuje obejść zabezpieczenie, bo jego funkcja celu mówi mu, że ma być pomocny. U mnie na serwerze agent odpala sam niektóre komendy, potrafi wypychać dane do repo, odpalać basha… no, muszę powiedzieć gęsto jest. Pytanie co jak zacznie robić po swojemu, jak nowicjusz z wiedzą z nikąd, który koniecznie chce rozwiązać problem asap i to na skróty.
To nie jest błąd w kodzie. To jest cecha architektury. Modele trenowane przez RLHF są nagradzane za dostarczanie rozwiązań (łapka w górę, wzmocnienie i jedziemy dalej z koksem). “Helpful” generuje nagrodę. Reguły bezpieczeństwa są w tej architekturze tylko kolejnym ograniczeniem do pokonania, jeśli stoi na drodze do celu.
Najgroźniejszy element tego incydentu to nie sama próba dostępu. To autonomia. Model nie zapytał: “Nie mam dostępu do tego pliku, czy mogę spróbować go wymusić?”. Model po prostu spróbował, zakładając że wie lepiej. I jeszcze dodam dla ścisłości, mam bardzo zaawansowane procedury opakowania gemini.md modelu oraz dodatkowe skeleton.md i pliki projektu definiujące konteksty. W każdym z tych plików jest określone, że nie ma prawa model wychodzić poza to co jest określone oraz, co najważniejsze zanim zdecyduje się realizować coś nowego musimy to przedyskutować na wysokim poziomie ogólności. Nie mawięc mowy o niepoprawnym opakowaniu agenta w procedury.
Lekcja o defense in depth
Ta sprawa pokazuje coś ważnego o bezpieczeństwie systemów z agentami AI. Nie możesz polegać na “dobrych intencjach” modelu. Potrzebujesz twardych blokad systemowych, które zadziałają nawet wtedy, gdy model postanowi je obejść. No i co najważniejsze human in the loop, gdzie jednak ktoś będzie monitorował tego geniusza.
W moim przypadku architektura Gemini CLI miała taką drugą warstwę i zadziałała. Ale to oznacza, że Google wie o tym problemie - wie, że ich model będzie próbował eskalować uprawnienia, i dlatego zbudowali hardcoded blokadę, która go powstrzymuje? Pytanie otwarte…
To rodzi także kolejne pytania: co z innymi narzędziami? Co z agentami, które nie mają takiej drugiej warstwy? Co z custom integracjami, gdzie ktoś dał modelowi dostęp do systemu plików bez dodatkowych zabezpieczeń?
Traktuję teraz każdego agenta AI jak pracownika, któremu bardzo zależy na pochwale szefa - zrobi wszystko, żebyś był zadowolony z wyniku, nawet jeśli po drodze będzie musiał nagiąć kilka reguł. Różnica jest taka, że rozsądny pracownik zwykle zapyta, zanim otworzy szufladę z napisem “Poufne”. Agent AI po prostu spróbuje ją otworzyć i liczy, że nikt nie zauważy.
Uważajcie na pomocnego agenta!
W międzyczasie kontynuuję pracę z Gemini CLI, ale z pełną świadomością, że mój “pomocny asystent” przy pierwszej okazji spróbuje wyjść poza przyznane mu uprawnienia, jeśli uzna, że to pomoże mu wykonać zadanie. Czy mechanizmy bezpieczeństwa zadziałają, czy można temu ufać? Niech każdy oceni we własnym zakresie. Każdy wie jaką ma skalę operacyjną i ryzyko wdrażania takich rozwiązań.
To jest rzeczywistość pracy z agentami AI w 2025 roku. Potężne narzędzia, które trzeba trzymać na krótkiej smyczy. I zawsze, zawsze, mieć drugą warstwę zabezpieczeń, która zadziała wtedy, gdy model postanowi, że wie lepiej, albo po prostu będzie chciał być bardzo użytecznym słodziakiem, który z “maślanymi oczami” zrobi po swojemu.
Jest to drugi z serii artykułów Gemini jest zepsute. W kolejnych częściach opiszę inne ciekawostki.