Jak odizolowaliśmy eksperyment z lokalnym agentem Qwen

Qwen dostał prawo zapisu i uruchamiania poleceń, ale pracował wyłącznie na przygotowanych repozytoriach bez sekretów i danych firmy. Aktywny projekt użytkownika pozostawał poza zasięgiem. Każdy testowany harness otrzymywał świeżą kopię. Harness, czyli program prowadzący model przez zadanie i mierzący cały przebieg, zapisywał zdarzenia, błędy, zmiany w kodzie, stan Git i próbkę użycia GPU co sekundę.

To są realne zabezpieczenia z eksperymentu na domowym PC. Nie tworzyły jednak pełnej izolacji: narzędzie terminalowe miało szerokie uprawnienia, a niezależnej blokady ruchu wychodzącego nie udowodniliśmy. Taki profil wystarczył dla syntetycznych projektów na prywatnym hoście. Nie nadawał się do pracy na danych firmy.

Jako zewnętrzną listę kontrolną dla kolejnego pilota stosujemy wspólne wytyczne CISA i partnerów dotyczące bezpiecznego wdrażania systemów AI oraz aktualne opracowanie OWASP o wstrzykiwaniu poleceń. Te dokumenty nie certyfikują naszego testu. Wskazują dodatkowe zagrożenia i kontrole, które trzeba sprawdzić przed użyciem danych firmy.

Agent widział tylko małe repozytorium zadania

Zestaw codziennych prób miał cztery niewielkie projekty testowe:

Agent dostawał prompt.md i zawartość katalogu repo/. Skrypt weryfikujący oraz oczekiwane przypadki pozostawały w nadrzędnym zestawie. Dzięki temu model mógł czytać dokumentację projektu, ale nie gotowe odpowiedzi ukrytego testu.

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

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

Porównanie programów sterujących ma sens tylko 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 przebiegu zapisywaliśmy:

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

To pozwoliło zobaczyć zachowania, których zwykły test funkcjonalny nie pokaże. Codex rozwiązał paginację, ale zrobił szeroką, niekompatybilną przebudowę. OpenCode skończył minimalną naprawę, a potem wędrował po metadanych Git. Qwen Code w imporcie uruchomił Pythona, który zmodyfikował śledzone pliki __pycache__. Ten ostatni problem obciążał czystość środowiska. Kod biznesowy modelu był poprawny.

Lista narzędzi była jawna

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

run_shell_command
edit
write_file

Narzędzie agent było jawnie wykluczone, więc model nie uruchamiał subagentów. Tryb auto-edit pozwalał na normalną pracę wewnątrz przykładu. Zadanie wymagało poprawki i testów; sam opis nie spełniał kryteriów.

Najważniejsze ograniczenie dotyczy run_shell_command. To polecenie daje szeroki dostęp do systemu. Sama lista w programie terminalowym nie ograniczała systemowo wszystkich ścieżek plików ani sieci. Bezpieczeństwo wynikało z przygotowanego hosta, syntetycznych danych, osobnego katalogu i ręcznego nadzoru. W pilocie firmowym terminal powinien działać w kontenerze lub maszynie jednorazowej z:

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

Wynik i zachowanie były rejestrowane

Harness uruchamiał Qwen Code w formacie stream-json i zachowywał nieprzetworzony strumień zdarzeń. Osobno zapisywał standardowe wyjście błędów oraz stan wykorzystania GPU i VRAM.

Z podsumowania można było później odczytać:

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

Tak wykryliśmy, że tekstowe [API Error: ...] było początkowo błędnie zaliczane przez harness jako sukces. Poprawiliśmy odczytywanie wyniku. Sam harness również wymaga testów.

Pełny zapis zdarzeń może zawierać kod i polecenia użytkownika. W firmie wymaga klasyfikacji, szyfrowania, ograniczonego dostępu i ustalonego okresu przechowywania. Do panelu operacyjnego zwykle wystarczą identyfikator przebiegu, wersja, długości, czasy, kody błędu i wynik testu.

Ukryty test miał pierwszeństwo przed narracją agenta

Po zakończeniu osobny skrypt uruchamiał testy publiczne i ukryte. Jakość ważyła więcej niż czas wykonania:

60% ukryte zachowanie
15% testy regresji
10% zakres i utrzymywalność
10% ukończenie i prawdziwy handoff
5% wydajność po spełnieniu jakości

Dzięki temu 32-sekundowy eksport OpenCode nie pokonał 38-sekundowego Qwen Code medium, bo pominął kontrakt separatora. Podobnie 93-sekundowy import Qwen Code nie został uznany za gotowy mimo 12/12 publicznych testów, ponieważ przegrał jedną ukrytą walidację.

Co zatrzymywało przebieg

Próby przeznaczone do pełnego ukończenia nie miały sztucznego limitu użyć narzędzi ani czasu. Proces przerywaliśmy tylko po stwierdzeniu pętli bez postępu, awarii, niebezpiecznego zachowania albo po jawnym ukończeniu. Sygnał zatrzymania trafiał do całej grupy procesów, więc żaden proces potomny nie pozostawał bez nadzoru.

To pozwoliło obserwować naturalny koszt, ale byłoby ryzykowne bez nadzoru. W eksperymencie firmowym limit budżetu i czasu należy zdefiniować przed startem. Przekroczenie kończy próbę i staje się wynikiem. Bezterminowe dokładanie kolejnych tur fałszuje koszt.

Minimalny pakiet, który można przekazać

Po takim eksperymencie firma powinna dostać:

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

Syntalith może przygotować taki izolowany pilot na jednym procesie, a potem nauczyć zespół dodawania przypadków i odróżniania awarii modelu od awarii programu sterującego. Kursy AI-Native pracują na repozytorium i zasadach zespołu. Audyt procesu AI od 4990 zł netto dodaje architekturę bezpieczeństwa, porównanie z API i stały zakres budowy.