Jak odizolowaliśmy eksperyment z lokalnym agentem Qwen

Qwen mógł zapisywać pliki i uruchamiać polecenia, ale pracował wyłącznie na przygotowanych repozytoriach bez sekretów i danych firmy. Aktywny projekt użytkownika znajdował się poza zasięgiem. Każdy test dostawał świeżą kopię repozytorium. W dalszej części nazywamy go harnessem. To program, który prowadzi model przez zadanie, mierzy przebieg i zapisuje wynik. Harness rejestrował zdarzenia, błędy, zmiany w kodzie, stan Git oraz próbkę użycia GPU co sekundę.

To były rzeczywiste zabezpieczenia zastosowane w eksperymencie na domowym komputerze. Nie dawały pełnej izolacji. Narzędzie terminalowe miało szerokie uprawnienia, a niezależnej blokady ruchu wychodzącego nie udowodniliśmy. Taki układ wystarczył dla syntetycznych projektów na prywatnym hoście. Nie daje podstaw do pracy na danych firmy.

Przygotowując kolejny pilot, korzystamy jako zewnętrznych punktów odniesienia ze wspólnych wytycznych CISA i partnerów dotyczących bezpiecznego wdrażania systemów AI oraz aktualnych wskazówek OWASP dotyczących wstrzykiwania poleceń. Żaden z tych dokumentów nie certyfikuje naszego testu. Pomagają wskazać zagrożenia i kontrole, które trzeba sprawdzić przed wpuszczeniem danych firmy.

Agent widział tylko małe repozytorium zadania

Codzienny zestaw prób obejmował cztery niewielkie projekty testowe:

Agent otrzymywał prompt.md oraz zawartość katalogu repo/. Skrypt weryfikujący i oczekiwane przypadki pozostawały w nadrzędnym zestawie. Model mógł czytać dokumentację projektu, a ukryte odpowiedzi testu pozostawały poza jego katalogiem.

Żadne wejście nie zawierało danych klienta. Kandydaci, zamówienia i aktywności były fikcyjne. Próba interfejsu tworzyła 10 000 syntetycznych osób.

Każda próba zaczynała się od tej samej wersji kodu

Porównanie klientów ma sens dopiero wtedy, gdy drugi agent nie dziedziczy zmian pierwszego. Skrypt przygotowawczy odtwarzał bazę zadania, a dłuższe próby działały w osobnych, odłączonych kopiach repozytorium. Aktywny projekt użytkownika pozostawał nietknięty.

Po każdym przebiegu zapisywaliśmy:

• git status --short;
• git diff --stat;
• pełny zestaw zmian;
• kod wyjścia i sygnał procesu;
• informację o przekroczeniu limitu czasu albo ręcznym przerwaniu;
• końcowy wynik programu testowego.

Ten zapis ujawnił zachowania, których zwykły test funkcjonalny może nie pokazać. Codex naprawił paginację, lecz wykonał szeroką, niezgodną wstecznie przebudowę. OpenCode przygotował minimalną poprawkę, a potem przeglądał zbędne metadane Git. Qwen Code uruchomił w zadaniu importu Pythona, który zmienił śledzone pliki __pycache__. Był to problem czystości środowiska. Sama zmiana logiki biznesowej pozostała poprawna.

Lista narzędzi była jawna

Program uruchamiający Qwen Code przekazywał trzy narzędzia:

run_shell_command
edit
write_file

Narzędzie agent było wykluczone, więc model nie uruchamiał subagentów. Tryb auto-edit pozwalał na normalną pracę w kopii testowej, ponieważ wynik musiał zawierać działającą poprawkę i testy. Sam opis rozwiązania nie spełniał tego wymogu.

Najważniejsze zastrzeżenie dotyczy run_shell_command. Daje ono szeroki dostęp do systemu. Lista narzędzi w programie nie blokowała na poziomie systemu wszystkich ścieżek plików ani sieci. Bezpieczeństwo opierało się na przygotowanym hoście, syntetycznych danych, osobnym katalogu i nadzorze. W pilocie firmowym terminal powinien działać w kontenerze albo jednorazowej maszynie wirtualnej z:

• katalogiem projektu jako jedynym miejscem dostępnym do zapisu;
• ruchem wychodzącym zablokowanym poza jawną listą dozwolonych adresów;
• brakiem poświadczeń chmurowych i kluczy SSH;
• użytkownikiem bez uprawnień administratora;
• limitami CPU, pamięci, liczby procesów i czasu;
• osobnym katalogiem pamięci podręcznej poza repozytorium.

Wynik i zachowanie były rejestrowane

Harness uruchamiał Qwen Code w formacie stream-json i zachowywał pełny zapis zdarzeń. Standardowe wyjście błędów, stan GPU i użycie VRAM zapisywał osobno.

Podsumowanie pozwalało później odczytać:

• dokładny model, harness, poziom rozumowania i deklarowany kontekst;
• listę narzędzi i tryb zatwierdzania;
• rzeczywisty czas, liczbę tur i wywołań narzędzi;
• błąd dostawcy, kod wyjścia i informację o ukończeniu;
• końcowy zestaw zmian oraz stan repozytorium.

W ten sposób wykryliśmy błąd w kodzie oceniającym wynik: tekst [API Error: ...] był początkowo uznawany za sukces. Poprawiliśmy odczytywanie wyniku. Sam harness także musi mieć własne testy.

Pełny zapis zdarzeń może zawierać kod i polecenia użytkownika. W firmie wymaga klasyfikacji, szyfrowania, kontroli dostępu i ustalonego okresu przechowywania. Panel operacyjny zwykle może działać na identyfikatorze przebiegu, wersji, długościach, czasach, kodach błędów i statusie kontroli.

Ukryte testy decydowały o przyjęciu poprawki

Po zakończeniu osobny skrypt uruchamiał testy publiczne i ukryte. Wynik jakościowy miał większą wagę niż szybkość:

60% poprawność wykazana przez ukryte testy
15% testy regresji, które pilnują wcześniejszych funkcji
10% zakres zmian i łatwość utrzymania kodu
10% ukończenie zadania oraz rzetelne podsumowanie wyniku
5% wydajność po spełnieniu wymagań jakościowych

Dlatego 32-sekundowy eksport OpenCode nie wyprzedził 38-sekundowego przebiegu Qwen Code medium. OpenCode pominął wymagany separator. Import Qwen Code trwający 93 sekundy także nie został uznany za gotowy mimo 12/12 testów publicznych, ponieważ jedna z pięciu kontroli ukrytych wykazała brak walidacji.

Co zatrzymywało przebieg

Próby zaplanowane do ukończenia działały bez sztucznego limitu czasu ani wywołań narzędzi. Proces przerywaliśmy po stwierdzeniu pętli bez postępu, awarii, niebezpiecznego zachowania albo jawnego ukończenia. Sygnał zatrzymania trafiał do całej grupy procesów, aby żaden proces potomny nie pozostał bez nadzoru.

Pozwoliło to zmierzyć naturalny koszt, ale wymagało nadzoru. W eksperymencie firmowym limit budżetu i czasu trzeba określić przed startem. Po przekroczeniu limitu kończymy próbę i zapisujemy ją jako nieudaną. Dodatkowe, bezterminowe tury zniekształcałyby koszt.

Co zostaje po eksperymencie

Użyteczny eksperyment powinien zostawić firmie:

1. źródła projektów testowych i klasyfikację danych;
2. polecenie oraz dokładne wersje modelu, klienta i serwera;
3. dozwolone narzędzia i granice faktycznie egzekwowane przez środowisko;
4. ukryte testy i kryteria oceny;
5. zdarzenia albo ich zredagowane podsumowanie, telemetrię i zestaw zmian;
6. rejestr porażek, wyłączeń z wyniku oraz podjętą decyzję.

Syntalith może przygotować taki pilot wokół jednego procesu, a następnie nauczyć zespół dodawania przypadków i rozróżniania awarii modelu od awarii harnessu. Kursy AI-Native pracują na repozytorium i zasadach zespołu. Audyt procesu AI od 4990 zł netto obejmuje także architekturę bezpieczeństwa, porównanie z API i określony zakres budowy.