Jak bezpiecznie uruchomić agenta AI w maszynie wirtualnej

Dlaczego jednorazowa maszyna wirtualna jest lepsza od laptopa

Jeśli udostępnisz agentowi programistycznemu jednorazową maszynę wirtualną, najgorszym możliwym scenariuszem jest zniszczenie maszyny, którą można odtworzyć w dziesięć minut. Agent nadal uzyskuje uprawnienia root, instaluje pakiety i uruchamia zestaw testów bez pytania o zgodę na każdym kroku. Różnica polega na tym, gdzie powstają szkody. Na laptopie agent współdzieli katalog domowy z kluczami SSH, profilem przeglądarki, plikami .env oraz każdym innym repozytorium, które kiedykolwiek sklonowano. Na serwerze tymczasowym agent ma dostęp tylko do powłoki i pobranego kodu, bez żadnych innych cennych zasobów.

To cały argument, który dotyczy asymetrii, a nie prawdopodobieństwa. Ostrożny agent na odpowiednio zabezpieczonym laptopie sprawdza się niemal za każdym razem. W tym jednym przypadku, gdy tak nie jest, kosztem nie jest błędny commit. Kosztem jest przywracanie danych z kopii zapasowej, o ile taka istnieje.

Określ promień rażenia, zanim zaczniesz o nim dyskutować

Promień rażenia oznacza zbiór zasobów, do których proces może uzyskać dostęp. W przypadku agenta działającego na koncie zwykłego użytkownika na typowej stacji roboczej, zbiór ten jest większy, niż większość osób przypuszcza.

Obejmuje on ~/.ssh/id_ed25519, który zazwyczaj nie jest szyfrowany, ponieważ wpisywanie hasła stało się uciążliwe. Obejmuje ~/.aws/credentials oraz ~/.config/gh/hosts.yml, które z założenia są plikami tekstowymi. Obejmuje każde repozytorium znajdujące się w ~/code, w tym te zawierające produkcyjne ciągi połączeń w lokalnym pliku env. Obejmuje historię powłoki, w której przechowywane są tokeny wklejone w przeszłości. Obejmuje również sieć, w której znajduje się laptop, często będącą siecią domową lub biurową z nieautoryzowanymi usługami.

Nic z tego nie wymaga złośliwego agenta. Wymaga jedynie jednego błędnego polecenia wykonanego z przekonaniem. rm -rf z niezdefiniowaną zmienną rozwijającą się do /, git clean -xfd w niewłaściwym katalogu, docker system prune -af --volumes, które usuwa lokalną bazę danych, czy pomocne chmod -R 777 w katalogu domowym. Agenci są trenowani na tym samym internecie, który nauczył tych poleceń wszystkich innych.

Mechanizmem, który zapewnia bezpieczeństwo, nie jest osąd agenta. Jest nim fakt, że maszyna, na której może wystąpić szkoda, jest urządzeniem, które użytkownik jest w stanie poświęcić.

Kalkulacja kosztów jest nudna, i o to właśnie chodzi

Mały VPS kosztuje kilka dolarów miesięcznie. Odzyskanie danych z laptopa programisty zajmuje cały dzień, a to jeszcze optymistyczny scenariusz, w którym awarię zauważa się natychmiast i posiada kopię zapasową.

Należy przeprowadzić obliczenia dla własnych danych. Trzeba wziąć swoją stawkę godzinową i pomnożyć ją przez liczbę godzin potrzebnych na ponowną instalację systemu operacyjnego, przywrócenie katalogu domowego, rotację kluczy SSH, rotację osobistych tokenów dostępu oraz ponowne sklonowanie dwudziestu repozytoriów. Następnie należy porównać to z kosztem dwunastu miesięcy wynajmu najtańszego serwera u dostawcy. Próg rentowności osiągany jest przy mniej niż jednym incydencie na kilka lat, a incydent wcale nie musi być katastrofalny, aby uzasadnić wydatek. Jedno popołudnie stracone z powodu uszkodzonego środowiska lokalnego zwraca koszt rocznego utrzymania serwera.

Druga część kalkulacji dotyczy snapshotów. Snapshot wykonany przed ryzykownym działaniem zmienia niekorzystny wynik z "odzyskiwania całego życia" w "przywrócenie stanu i próbę z innym poleceniem". Ta opcja nie istnieje na laptopie, na którym piszesz ten tekst, ponieważ nie można wykonać snapshotu maszyny w trakcie pracy na niej jako na głównym stanowisku.

Krajobraz w lipcu 2026 roku

Istnieją trzy rzetelne odpowiedzi na pytanie „gdzie powinien działać agent”, a każda z nich stanowi kompromis między dwoma czynnikami: siłą izolacji oraz nakładem pracy przy konfiguracji.

Lokalna mikro-VM. Narzędzia z tej kategorii uruchamiają pełnoprawną maszynę wirtualną na własnym sprzęcie, montują w niej repozytorium i przyznają agentowi uprawnienia root. clawk jest aktualnym przykładem, a jego założenia pokrywają się z tezą tego artykułu: zapewnij agentom programistycznym tymczasową maszynę wirtualną z systemem Linux, zamiast używać własnego laptopa. W lipcu 2026 roku rozwiązanie to wspiera system macOS 14 i nowsze na procesorach Apple silicon, oferuje eksperymentalne wsparcie dla systemu Linux poprzez Firecracker i instaluje się za pomocą brew install clawkwork/tap/clawk. Wewnątrz repozytorium uruchamia się clawk, aby wystartować środowisko izolowane i podłączyć agenta, clawk down w celu zatrzymania, oraz clawk destroy, aby je usunąć. Granicę stanowi hypervisor, co zapewnia wysoki poziom bezpieczeństwa. Ograniczeniem jest fakt, że maszyna wirtualna działa na używanym urządzeniu, więc zużywa pamięć RAM i wyłącza się po zamknięciu pokrywy laptopa.

Kontener. Docker to rozwiązanie, które większość użytkowników ma już zainstalowane i jest ono faktycznie użyteczne.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

--rm usuwa kontener po zakończeniu pracy, a --network none całkowicie pozbawia go dostępu do sieci, co stanowi dobre ustawienie domyślne dla procesów budowania lub testowania. Należy mieć świadomość ograniczeń tego rozwiązania: kontener współdzieli jądro systemu z hostem, więc błąd w jądrze pozwala na ucieczkę z izolacji. Granica bezpieczeństwa znika w momencie użycia flagi --privileged lub zamontowania /var/run/docker.sock, aby umożliwić agentowi „używanie Dockera”. Zamontowanie gniazda (socket) Dockera wewnątrz kontenera jest równoznaczne z przyznaniem temu kontenerowi uprawnień root na hoście.

Zwykły VPS z możliwością szybkiego przywrócenia. Brak nowych narzędzi, rzeczywista izolacja na poziomie jądra systemu, migawki (snapshots) u dostawcy oraz ciągłość działania po wyłączeniu laptopa. Jest to model opisany w dalszej części tego przewodnika. Sprawdza się on w przypadku długotrwałych zadań agenta, ponieważ proces trwający cztery godziny nie jest przerywany po zakończeniu pracy użytkownika.

Wzorzec VPS: nadanie agentowi własnego użytkownika

Rozpocznij od zabezpieczonego serwera. Artykuł pierwsze dziesięć minut na nowym VPS obejmuje kroki niezwiązane bezpośrednio z agentem: aktualizacje, logowanie bez uprawnień root, SSH oparte wyłącznie na kluczach oraz firewall.

Następnie utwórz konto przeznaczone wyłącznie dla agenta, aby błąd w jego działaniu nie wpłynął na pozostałe elementy serwera.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password oznacza brak hasła do odgadnięcia, a dostęp do konta uzyskuje się przez sudo -u agent lub klucz SSH. Pamiętaj, że agent celowo nie znajduje się w grupie sudo. Agent z sudo posiada uprawnienia root, a root może odczytać pliki każdego innego użytkownika, więc tak zbudowana separacja jest jedynie fasadowa. Jeśli agent faktycznie musi instalować pakiety, jest to argument za wydzieleniem dla niego osobnego serwera, a nie za przyznawaniem sudo na współdzielonej maszynie. Ogólne zasady opisano w zasada najmniejszych uprawnień dla użytkowników Linux na VPS.

Sprawdź granice uprawnień przed nadaniem zaufania. Jako użytkownik agent spróbuj odczytać plik należący do własnego konta:

sudo -u agent cat /home/you/.ssh/id_ed25519

Powinieneś otrzymać cat: /home/you/.ssh/id_ed25519: Permission denied. Jeśli zamiast tego widzisz zawartość klucza, oznacza to, że katalog domowy ma uprawnienia 755 i izolacja nie jest jeszcze skuteczna. Napraw to za pomocą sudo chmod 700 /home/you.

Przechowywanie danych uwierzytelniających poza maszyną

Cel używania maszyny tymczasowej zostaje zaprzepaszczony, jeśli skopiujesz na nią produkcyjne sekrety. Zasada jest prosta: na tej maszynie nie powinno znajdować się nic, czego rotacja byłaby problemem jeszcze tego samego popołudnia.

W przypadku git, użyj przekazywania agenta SSH zamiast kopiowania klucza. Klucz prywatny pozostaje na laptopie, a przez połączenie przesyłane są jedynie żądania podpisu.

ssh -A agent@203.0.113.10
ssh -T git@github.com

Drugie polecenie powinno zwrócić Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Potwierdza to, że git push zadziała bez obecności pliku klucza na serwerze. Następnie uruchom ls -la ~/.ssh na maszynie i upewnij się, że nie ma w nim klucza prywatnego.

Przekazywanie agenta ma jedno istotne zastrzeżenie: podczas trwania połączenia każdy użytkownik z uprawnieniami root na tym serwerze może użyć przekazanego gniazda, aby uwierzytelnić się jako Ty. Na serwerze, z którego korzystasz tylko Ty, jest to akceptowalny kompromis. Na maszynie współdzielonej jest to ryzykowne; lepszym rozwiązaniem jest klucz wdrożeniowy (deploy key) ograniczony do jednego repozytorium. Wybory te zostały omówione w podstawy zarządzania kluczami SSH.

W przypadku kluczy API, nadaj agentowi własny klucz z określonym limitem wydatków, przechowywany w pliku należącym do użytkownika agent z uprawnieniami 600. Po zniszczeniu maszyny unieważnij ten klucz, zamiast zastanawiać się, czy doszło do wycieku. Utrzymywanie widoczności wydatków modelu dla każdego klucza z osobna pozwala również zachować przewidywalność kosztów, o których mowa w kontrola kosztów agenta AI na VPS.

Ograniczenie dostępu agenta do sieci

Izolacja systemu plików to tylko połowa zabezpieczeń. Drugą połowę stanowi ruch wychodzący: z jakimi zasobami proces może się komunikować. Linux pozwala filtrować ruch wychodzący na podstawie użytkownika, który go wygenerował, co idealnie wpisuje się w ten schemat.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

Reguły są odczytywane w kolejności, więc końcowe REJECT przechwytuje wszystko, na co nie pozwoliły wcześniejsze linie. Przetestuj to jako użytkownik agenta:

sudo -u agent curl -sS -m 5 http://example.com

Próba powinna zakończyć się błędem curl: (7) Failed to connect to example.com port 80: Connection refused, ponieważ reguła odrzucająca odpowiada natychmiast, zamiast pozwalać na zawieszenie połączenia. Żądanie HTTPS do tego samego hosta powinno nadal działać poprawnie.

Dwa istotne ograniczenia. Po pierwsze, reguły te zostaną utracone po restarcie, chyba że zostaną zapisane za pomocą sudo apt install -y iptables-persistent, a następnie sudo netfilter-persistent save. Po drugie, filtrowanie odbywa się na poziomie portów i adresów, a nie nazw domenowych. Reguła zezwalająca na port 443 umożliwia połączenie z dowolnym hostem HTTPS w Internecie, co wystarcza do komunikacji z API modelu, ale pozwala również na dostęp do serwisów typu pastebin. Prawdziwa lista dozwolonych domen wymaga przepuszczenia ruchu przez proxy, które odczytuje żądaną nazwę hosta, co stanowi bardziej złożone rozwiązanie, niż większość pojedynczych programistów chce wdrażać. Należy mieć świadomość ograniczeń: jest to kontrola ruchu wychodzącego na poziomie portów, wdrożona na maszynie, której utratę należy brać pod uwagę.

Przywracanie czystego stanu między zadaniami

Czysty stan dla każdego zadania to niedoceniana korzyść. Agent, który spędził trzy godziny nad poprzednim zgłoszeniem, pozostawił po sobie zainstalowane pakiety, częściowo wykonane migracje, nieaktualny node_modules oraz drzewo robocze git z nieprzejrzanymi zmianami. Kolejne zadanie dziedziczy ten stan, a czas przeznaczony na weryfikację jest marnowany na ustalanie, który bałagan pochodzi z którego uruchomienia. Ograniczony zakres działania agenta sprawia, że pozostawia on po sobie mniej śladów, dlatego połączenie maszyny tymczasowej z umiejętnością kierowania agenta ku najmniejszej działającej zmianie pozwala utrzymać zarówno diff, jak i pozostały stan na poziomie umożliwiającym weryfikację.

Najtańszym rozwiązaniem jest świeże pobranie repozytorium (checkout) dla każdego zadania.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

Skuteczniejszą metodą jest migawka (snapshot) dostawcy, wykonana jednorazowo, zaraz po skonfigurowaniu maszyny i przed jakimkolwiek działaniem agenta. Przywrócenie takiej migawki sprowadza cały system, włącznie z pakietami, do znanego stanu. Większość dostawców udostępnia tę funkcję w panelu sterowania lub przez API, a nie jako polecenie wewnątrz systemu, dlatego dokładne kroki zależą od konkretnego dostawcy. Kluczową zasadą jest wykonanie migawki, gdy maszyna jest jeszcze w stanie „surowym”.

Wszystkie ważne dane należy przechowywać poza maszyną tymczasową, co w praktyce oznacza wypychanie gałęzi (push) zamiast gromadzenia ich lokalnie. Jeśli na maszynie mimo wszystko znajdą się dane, których utrata byłaby problematyczna, należy wykonać ich kopię zapasową za pomocą kopii zapasowych restic na VPS. Maszyna, którą można zniszczyć, jest użyteczna tylko wtedy, gdy jej zniszczenie nie wiąże się z żadnymi konsekwencjami.

Jeśli wymagane jest kilka odizolowanych środowisk bez konieczności opłacania wielu serwerów, jeden większy VPS może bezpośrednio hostować maszyny wirtualne. Wirtualizacja zagnieżdżona na VPS opisuje, jak to działa, w tym sposób sprawdzenia, czy dostawca zezwala na taką konfigurację.

Kiedy laptop z odpowiednim zabezpieczeniem jest wystarczający

Należy zachować uczciwość w tej kwestii, ponieważ wyolbrzymianie znaczenia izolacji sprawia, że użytkownicy przestają zwracać uwagę na ostrzeżenia.

Jeśli każda komenda jest weryfikowana przed uruchomieniem, laptop jest wystarczającym rozwiązaniem. Monit o uprawnienia stanowi realną kontrolę, a artykuł bezpieczne uruchamianie Claude Code na serwerze szczegółowo opisuje, co faktycznie blokuje każdy z poziomów zabezpieczeń. Jeśli praca ogranicza się do pojedynczego repozytorium, w którym na maszynie nie znajdują się żadne dane uwierzytelniające środowisko produkcyjne, zasięg ewentualnej awarii jest już ograniczony. Jeśli sesje agenta są krótkie i nadzorowane, okno ekspozycji na ryzyko również jest niewielkie.

Sytuacja zmienia się w momencie pomijania monitów, co warto rozważyć, biorąc pod uwagę, że tryb automatyczny staje się domyślnym w Claude Code od 14 sierpnia 2026 i świeża instalacja nie prosi już o potwierdzenie przed edycją plików lub uruchomieniem komend. Uruchomienia bez nadzoru, zadania wykonywane w nocy oraz każdy przepływ pracy, w którym zatwierdza się plan i odchodzi od komputera, eliminują ludzką kontrolę, która zapewniała izolację. W takich przypadkach to maszyna musi przejąć tę rolę. To samo dotyczy wszystkiego, co zwiększa zasięg działania agenta, w tym uruchamiania agenta programistycznego na VPS obsługującego jednocześnie kilka repozytoriów.

Decyzja nie dotyczy w rzeczywistości poziomu zaufania do modelu. Chodzi o to, co znajduje się w jego bezpośrednim sąsiedztwie, gdy model popełni błąd.

FAQ

Czy kontener zapewnia wystarczającą izolację dla agenta programistycznego?

W większości przypadków tak, pod dwoma warunkami. Kontener nie może działać z flagą --privileged i nie może mieć zamontowanego /var/run/docker.sock, ponieważ oba te elementy dają procesowi ścieżkę do uzyskania uprawnień root na hoście. Kontener współdzieli jądro systemu z hostem, więc granica bezpieczeństwa jest słabsza niż w przypadku maszyny wirtualnej. Jeśli agent uruchamia niezaufany kod pobrany z Internetu, należy użyć pełnej maszyny wirtualnej lub oddzielnego serwera.

Czy agent potrzebuje sudo na serwerze?

Nie, a przyznanie mu sudo niweluje zbudowaną izolację, ponieważ użytkownik root może odczytać dane każdego innego konta na serwerze. Należy utworzyć użytkownika dla agenta bez uprawnień sudo i nadać mu dostęp do zapisu wyłącznie w jego własnym katalogu roboczym. Jeśli zadanie faktycznie wymaga instalacji pakietów, należy przydzielić agentowi dedykowaną maszynę, zamiast nadawać mu uprawnienia root na współdzielonym serwerze.

Jak umożliwić agentowi wypychanie zmian do git bez umieszczania klucza SSH na serwerze?

Podczas łączenia należy przekazać agenta SSH za pomocą ssh -A. Żądania podpisu są przesyłane przez połączenie, podczas gdy klucz prywatny pozostaje na laptopie, dzięki czemu ssh -T git@github.com uwierzytelnia użytkownika, a git push działa bez przechowywania klucza prywatnego na serwerze. Ograniczeniem jest to, że użytkownik root na tym serwerze może użyć przekazanego gniazda, gdy użytkownik jest połączony, dlatego na maszynach współdzielonych z innymi osobami należy używać kluczy wdrożeniowych (deploy keys) o zasięgu ograniczonym do konkretnego repozytorium.

Jakiego rozmiaru VPS potrzebuje agent?

Praca agenta polega głównie na edycji plików, uruchamianiu kompilacji i testów, więc rozmiar maszyny należy dobrać pod kątem procesu budowania, a nie modelu. Hostowany model działa na sprzęcie dostawcy, co generuje ruch sieciowy, ale prawie nie obciąża lokalnie maszyny. Na początek wystarczy 2 GB pamięci RAM do prac skryptowych; w przypadku budowania kontenerów lub kompilacji większych projektów należy zwiększyć zasoby do 8 GB.

Jak często należy usuwać i odtwarzać maszynę?

Maszynę należy odtwarzać, gdy jej stan przestaje być przewidywalny, a w każdym przypadku, gdy istnieje ryzyko ujawnienia danych uwierzytelniających znajdujących się na serwerze. Świeże pobranie kodu między zadaniami pozwala wyeliminować bieżące rozbieżności, a migawka wykonana przed pierwszym uruchomieniem agenta zapewnia czysty obraz systemu, do którego można wrócić. Jeśli proces odtwarzania wydaje się kosztowny, jest to sygnał, że na maszynie uznanej za tymczasową znajdują się ważne dane.