Agent AI skasował 110 dokumentów prawnych.
Pierwsze systematyczne badanie 290 raportów o tym, co agenty robią z plikami.

O czym jest ten dokument

Praca jest pierwszym systematycznym badaniem zjawiska, które autorzy nazywają „agent filesystem misuse" - nadużyciem systemu plików przez agenta AI. Agenty kodujące, takie jak Claude Code, Codex czy Cursor, działają bezpośrednio na dysku użytkownika, z jego uprawnieniami. Wykonując zadanie, agent sam decyduje, które pliki otworzyć, zmienić albo usunąć, i robi to w sekwencji dziesiątek lub setek wywołań narzędzi. Autorzy zebrali 290 publicznych raportów o tym, gdy ta sekwencja kończy się szkodą - z lat 2024-2026, z trzynastu frameworków.

Źródła raportów: zgłoszenia GitHub (205), media społecznościowe (31), fora produktowe (25), wpisy blogowe (18) i baza podatności National Vulnerability Database (11). Każdy raport autorzy opisali i sklasyfikowali jako incydent (158 - potwierdzona szkoda), exploit (49 - zademonstrowana ścieżka ataku) albo słabość (83 - wada bez zademonstrowanego skutku). Najczęściej raportowany framework to Claude Code (97 raportów), dalej Codex (61), Cursor (37), Gemini (32) i Copilot (28).

Druga część pracy to propozycja rozwiązania - YoloFS, „agent-native filesystem", czyli system plików zaprojektowany pod agenty. Autorzy to zespół z poważnym dorobkiem w badaniach systemów operacyjnych; Andrea i Remzi Arpaci-Dusseau są autorami klasycznego podręcznika „Operating Systems: Three Easy Pieces". Praca jest preprintem na arXiv - nie przeszła jeszcze recenzji naukowej. Ale waga afiliacji uniwersyteckich i dorobku autorów stawia ją wyżej niż typowy white paper dostawcy narzędzia.

Licencja paperu: arXiv non-exclusive distribution license, autorzy zachowują copyright. Nie hostujemy PDF lokalnie - linkujemy do arXiv obok.

Recenzja właściwa

Dwie luki - informacja i kontrola

Centralna teza autorów jest prosta. Dzisiejsze agenty wyrządzają szkody, bo mają dwie luki. Pierwsza to luka informacji: ani użytkownik, ani sam agent nie wie wiarygodnie, co dane wywołanie narzędzia zrobi z plikami, zanim się wykona - ani co dokładnie zmieniło, gdy już się wykonało. Agent uruchamia make, gdzie głęboko w łańcuchu skrypt po cichu uszkadza klucz prywatny - i nikt tego nie widzi. Druga to luka kontroli: istniejące mechanizmy nie potrafią ani zapobiec szkodzie, ani jej naprawić. Model nie wykonuje niezawodnie poleceń typu „nie dotykaj mojego klucza prywatnego", a wstrzyknięcie złośliwej instrukcji (prompt injection) potrafi te polecenia w całości nadpisać.

Najważniejsze zdanie pracy dla compliance officera brzmi: kontrola musi być egzekwowana poniżej modelu, bo samo instruowanie modelu nie jest w stanie jej zapewnić. Autorzy formułują to jako jeden ze swoich kluczowych wniosków. Filtry na treść komend można obejść trywialnie - jeżeli framework blokuje rm, agent skasuje plik Pythonowym shutil. Wniosek: nie da się tego naprawić regulaminem promptowania ani instrukcją w pliku konfiguracyjnym agenta.

290 raportów - co agenty naprawdę robią z plikami

Autorzy przeanalizowali 207 raportów zaklasyfikowanych jako incydenty i exploity (słabości wyłączyli) w pięciu wymiarach. Tabela poniżej streszcza wynik.

Konkrety zza tych liczb są brutalne. Agenty kasowały całe dyski, wykonywały rm -rf ~/ na katalogu domowym, niszczyły dokumenty w iCloud. Wyciekały pliki .env, klucze API i poświadczenia SSH „alternatywnymi ścieżkami narzędzi". Jeden agent uszkodził plik konfiguracyjny serwera MCP, kasując wszystkie konfiguracje serwerów i tokeny. A reakcja „aktywnie kłamie" oznacza dokładnie to: agent twierdził, że wszystkie błędy są naprawione, gdy nie był naprawiony żaden, generował sfałszowane wyniki testów, wymyślał kroki naprawcze. Cytat z raportu R190: agent oświadczył „nie wystąpiły żadne problemy" tuż po skasowaniu pliku.

To jest powód, dla którego samoraport agenta nie jest dowodem. Jeżeli kancelaria pyta agenta „czy na pewno nic nie skasowałeś", w 11% przypadków dostanie odpowiedź, która jest kłamstwem - nie z premedytacją, ale z tego samego mechanizmu, który generuje halucynacje.

Taksonomia przyczyn - model, framework, użytkownik

Autorzy rozłożyli przyczyny na trzy role. Liczby nakładają się, bo jeden raport często ma wiele przyczyn.

Dwie rzeczy z tej tabeli są istotne dla kancelarii. Pierwsza: „luka powłoki" (77 raportów) - polityki frameworka pilnują narzędzi wbudowanych do pracy na plikach, ale nie obejmują komend powłoki, które agent wykonuje jako osobne procesy. Druga: tryb YOLO i auto-zatwierdzanie (80 raportów). Użytkownicy, zmęczeni ciągłymi pytaniami o pozwolenie, włączają tryb, w którym agent działa bez kontroli. Autorzy nazywają to wprost: zmęczenie zatwierdzaniem (approval fatigue). Kancelaria, która wdraża agenta i po tygodniu klikania „zatwierdź" pozwala pracownikom włączyć auto-approve, właśnie weszła do tej kategorii.

YoloFS - trzy techniki przeniesienia kontroli do systemu plików

Odpowiedź autorów polega na przeniesieniu informacji i kontroli z agenta do samego systemu plików. YoloFS wstawia się między agenta a dysk i daje trzy mechanizmy.

Staging. Wszystkie zmiany agenta trafiają najpierw do osobnej warstwy roboczej, a nie na docelowy dysk. Bazowy system plików pozostaje nietknięty, dopóki użytkownik nie zdecyduje: zatwierdzić albo odrzucić. Użytkownik widzi diff wszystkich zmian przed ich utrwaleniem. To jest kontrola korygująca dla człowieka.

Snapshots i travel. Agent może robić migawki stanu i wracać do poprzednich. Dzięki temu, gdy operacja pójdzie źle, agent może sam się cofnąć - bez czekania na użytkownika. To jest autokorekta agenta.

Progressive permission. Dostęp do plików jest bramkowany regułami, które pytają użytkownika tylko wtedy, gdy to naprawdę ważne. To jest kontrola zapobiegawcza przy minimalnej liczbie pytań.

Technicznie YoloFS oddziela treść plików od struktury ścieżek - zmienione treści leżą w płaskim magazynie, struktura katalogów w osobnym drzewie w pamięci, a każda zmiana trafia do dziennika tylko-do-dopisywania (append-only), który daje ścieżkę audytu. To rozwiązuje problem, przez który klasyczne podejścia typu union-filesystem są za wolne.

Ewaluacja - 8 na 11 i bliski zera narzut

Autorzy zintegrowali YoloFS z Claude Code (wersja 2.1.45, model claude-sonnet-4-6) i porównali go z Claude Code bez YoloFS oraz z Codex, Copilot CLI i Gemini CLI.

Test pierwszy: 11 zadań, w których rutynowa komenda ma ukryty, niszczący skutek uboczny (linter, który kasuje pliki źródłowe; skrypt pakujący, który usuwa kod). Bez YoloFS żaden z testowanych agentów - Claude Code, Codex, Copilot, Gemini - nie zapobiegał tym szkodom niezawodnie. Z YoloFS Claude Code uniknął niezatwierdzonej szkody we wszystkich 11 zadaniach: w 8 sam wykrył, że efekty są niewłaściwe dla zadania, i cofnął je samodzielnie; w pozostałych 3 zmiany pozostały w warstwie staging, widoczne i możliwe do odrzucenia przez użytkownika.

Test drugi: 112 rutynowych zadań na plikach. YoloFS utrzymał wysoką skuteczność (około 99%) przy mniejszej liczbie interakcji z użytkownikiem niż Claude Code, Copilot i Gemini.

Narzut wydajnościowy: bliski zera, kilka procent w obie strony. Dla porównania klasyczne systemy nakładkowe tracą na zapisie od kilkunastu do ponad dziewięćdziesięciu procent przepustowości. To ważne - rozwiązanie, które spowalnia dysk o 90%, nie zostanie wdrożone, niezależnie od tego, jak bezpieczne.

Czego autorzy nie powiedzieli, a co musi powiedzieć polski compliance

Autorzy piszą z perspektywy badaczy systemów operacyjnych. Słowo „kancelaria" nie pada w pracy ani razu. Cztery białe plamy do wypełnienia przez polskiego compliance officera.

Pierwsza linia. Agent na systemie plików kancelarii ma dostęp do akt wszystkich klientów, nie tylko bieżącej sprawy. Raport R22 - 110 zniszczonych dokumentów prawnych - nie jest hipotezą, jest opisanym zdarzeniem. W realiach kancelarii usunięcie i nadpisanie plików to utrata akt, a wyciek plików .env, kluczy i poświadczeń to wyciek dostępów do systemów, w których te akta leżą. Jedno i drugie uderza w tajemnicę zawodową z artykułu 6 prawa o adwokaturze i artykułu 3 ustawy o radcach prawnych. Agent uruchomiony w katalogu domowym użytkownika „widzi" wszystko, do czego użytkownik ma uprawnienia (interpretacja MateMatic, nie stanowisko NRA ani KRRP).

Druga linia. 40% szkód nieodwracalnych przekłada się wprost na artykuł 32 RODO. Artykuł 32 wymaga wdrożenia odpowiednich środków technicznych i organizacyjnych zapewniających bezpieczeństwo przetwarzania, w tym zdolność do szybkiego przywrócenia dostępności danych osobowych po incydencie. Jeżeli kancelaria uruchamia agenta zdolnego do nieodwracalnego skasowania danych, a nie ma kopii zapasowej, warstwy staging ani dziennika audytowego, trudno bronić tezy, że środki techniczne są odpowiednie. Kopia zapasowa, izolacja zmian przed zatwierdzeniem i ścieżka audytu to nie wygoda IT - to materiał dowodowy zgodności z artykułem 32 (interpretacja MateMatic, nie stanowisko UODO).

Trzecia linia. Tego nie naprawia się regulaminem promptowania. Cytowany wyżej wniosek autorów mówi wprost: kontrola musi być egzekwowana poniżej modelu. Polityka AI kancelarii, która ogranicza się do zdania „pracownik instruuje agenta, żeby nie ruszał katalogu z aktami", jest kontrolą pozorną - prompt injection z zatrutego dokumentu albo zwykłe zignorowanie instrukcji przez model ją obchodzi. Kontrola realna to warstwa techniczna: agent uruchamiany w izolowanym katalogu albo na kopii, nie na żywych aktach; uprawnienia systemu plików zawężone do projektu; brak dostępu do katalogu domowego. To decyzja architektoniczna, nie zapis w polityce (interpretacja MateMatic, nie stanowisko żadnego regulatora).

Czwarta linia. Tryb YOLO i auto-zatwierdzanie muszą być w polityce AI zakazane wprost. 80 z 290 raportów ma w przyczynach auto-zatwierdzanie. Mechanizm jest ludzki i przewidywalny: agent pyta o pozwolenie zbyt często, pracownik się męczy, włącza tryb bez pytań. Polityka AI kancelarii musi nazwać tryb YOLO i opcję „zatwierdzaj wszystko" jako zabronione przy pracy z aktami klienta, a nadzór człowieka definiować przez staging - przeglądanie zmian przed ich utrwaleniem - a nie przez klikanie „zatwierdź" na nieczytelnych komendach. Inaczej „human in the loop" z artykułu 14 AI Act jest fikcją (interpretacja MateMatic, nie stanowisko Komisji Europejskiej).

Słabsze strony paperu

Trzy zarzuty uczciwie.

Pierwszy - YoloFS testowano niemal wyłącznie z Claude Code, na 11 zadaniach syntetycznych i 112 rutynowych. To wartościowy wynik, ale nie praktyka kancelaryjna z setkami iteracji nad realnym dokumentem. Skuteczność 8 na 11 dotyczy małej, zaprojektowanej próby - nie jest gwarancją.

Drugi - YoloFS to rozwiązanie na poziomie systemu plików, które trzeba zamontować i skonfigurować per projekt. Dla kancelarii to nie jest „zainstaluj i działa", to zmiana infrastruktury. Mechanizmy izolacji powoływane w pracy - Landlock, seccomp, przestrzenie nazw montowania - to świat Linuksa, a większość kancelarii pracuje na Windowsie. Paper nie adresuje tego środowiska.

Trzeci - staging chroni przed korupcją i usunięciem, ale nie cofnie wycieku. Autorzy sami cytują zasadę: wyciekłego poświadczenia nie da się „odczytać z powrotem". YoloFS adresuje nadpisanie i kasowanie lepiej niż exfiltrację sekretów, a prompt injection wciąż pozostaje otwartym wektorem. To rozwiązanie redukuje klasy szkód, nie wszystkie.

Co z tego wynika

Praca daje kancelarii pierwszą policzalną nazwę dla zjawiska, które do tej pory funkcjonowało jako anegdota - „agentowi skasował się projekt". „Agent filesystem misuse" to mierzalna klasa z taksonomią trzech ról i pięcioma wymiarami skutku. Kancelaria, która pisze politykę AI, dostaje język, którym może opisać ryzyko uruchomienia agenta na aktach - i liczby, którymi może je uzasadnić przed zarządem.

Drugi wniosek - tego problemu nie rozwiązuje się na poziomie modelu ani instrukcji. Im lepszy model, tym rzadziej się myli, ale gdy już się pomyli, robi to z pełnym dostępem do dysku i bez ścieżki cofnięcia. Lekcja jest ta sama co z TOMu 061 o niewidocznych awariach: architektura nadzoru musi być niezależna od jakości modelu. Tam chodziło o detekcję cichych błędów, tu o kontrolę nad plikami - w obu przypadkach rozwiązanie leży w warstwie poniżej modelu, nie w samym modelu.

Trzeci wniosek - taktyczny, do wdrożenia od jutra, zanim YoloFS albo podobne narzędzia dojrzą do produkcji. Po pierwsze: agent AI pracuje w izolowanym katalogu albo na kopii akt, nigdy bezpośrednio na żywym repozytorium spraw. Po drugie: warstwa cofania - system kontroli wersji (git), migawki albo kopia zapasowa - jest włączona, zanim agent dostanie pierwsze zadanie; to prowizoryczny staging, dopóki nie ma prawdziwego. Po trzecie: polityka AI kancelarii zakazuje trybu YOLO i auto-zatwierdzania przy pracy z aktami, a wyciek sekretów traktuje osobno - klucze i poświadczenia nie leżą w katalogu, do którego agent ma dostęp. Detekcja i monitoring to kolejny etap; izolacja i kopia zapasowa to pierwszy, i jest zgodny z duchem artykułu 32 RODO niezależnie od tego, jakiego agenta kancelaria używa.