Docker przenosi sandboxy dla agentów AI do chmury. Laptop można zamknąć

Docker pokazał Cloud Sandboxes na WeAreDevelopers World Congress North America w San Jose (23–25 września). Kilka serwisów podaje jako datę premiery 24 września. Sama idea nie jest nowa: lokalne Docker Sandboxes uruchamiają agenta do kodowania w microVM z własnym jądrem i własnym demonem Dockera. Agent może tam instalować zależności, budować aplikację i odpalać kontenery, a host widzi tylko to, co mu się świadomie udostępni.

Czym są Docker Cloud Sandboxes

To ten sam sandbox, tyle że na infrastrukturze Dockera. Obsługuje się go tym samym narzędziem sbx co wersję lokalną, z globalną flagą --cloud. Dłuższe zadanie może chodzić dalej po zamknięciu laptopa. Wymagany jest sbx w wersji co najmniej 0.45.0 i subskrypcja Docker Agentic Platform. Przykład z dokumentacji wygląda tak:

$ sbx --cloud secret set anthropic
$ sbx --cloud create --name cloud-project \
    --allow-network github.com:443 claude
$ sbx --cloud attach cloud-project
  (Ctrl+\ odłącza, agent pracuje dalej)
$ sbx --cloud cp \
  cloud-project:/home/agent/workspace/review.md .
$ sbx --cloud rm cloud-project

Wersja chmurowa ma swoje ograniczenia. Nie zamontuje katalogu z hosta, więc repozytorium klonuje się do środka. Dane logowania, polityki sieciowe i porty ustawia się osobno dla chmury, bo te z lokalnych sandboksów nie przechodzą. Sandbox wygasa domyślnie po godzinie i wtedy jest zatrzymywany albo usuwany, więc warto sprawdzić tę akcję, zanim zostawi się w nim efekty kilku godzin pracy. Moc obliczeniowa jest rozliczana co sekundę. Samo narzędzie sbx i lokalne sandboksy są darmowe, także do użytku komercyjnego.

Jak sandbox chroni klucze API

To najciekawsza część całości. Każdy wychodzący ruch TCP z sandboksa idzie przez proxy na hoście, a proxy samo dokleja nagłówki uwierzytelniające. Agent wysyła żądanie z zaślepką, proxy podmienia ją na prawdziwy klucz już po wyjściu ruchu z maszyny wirtualnej. Klucz nigdy nie trafia do środka, więc złośliwy kod w sandboksie nie wyczyta go ze zmiennych środowiskowych. Po wycieku kluczy z OpenCode Console brzmi to dużo mniej abstrakcyjnie niż miesiąc temu.

Kits: agent zapakowany jak obraz OCI

Druga nowość to Kits. Kit to obraz OCI, w którym siedzi agent, jego narzędzia i deklaracja dostępów, jakich potrzebuje. Taki obraz buduje się, wypycha, pobiera, skanuje i przypina po digeście jak każdy inny. Specyfikacja jest wydana na licencji Apache 2.0, a Docker zobowiązał się przekazać ją do CNCF. Pierwszym partnerem był agent Hermes od Nous Research. W dokumentacji sandboksów jest też bramka MCP do rejestrowania serwerów i polityki narzucane centralnie przez administratora, choć ta ostatnia funkcja wymaga osobnej płatnej subskrypcji.

Pokaz z gniazdem Dockera

Na keynote padł przykład, który najlepiej tłumaczy, po co to wszystko. Agent w zwykłym kontenerze z zamontowanym gniazdem Dockera hosta odczytał sekret z hosta. Docker podkreśla, że to nie była nowa podatność, bo agent skorzystał z dostępu, który dała mu konfiguracja. Ta sama próba w sandboksie się nie udała. W drugim pokazie domyślna reguła „deny” zablokowała agentowi usunięcie repozytorium na GitHubie odpowiedzią 403. Zasady wymusiło środowisko uruchomieniowe, a nie dobra wola modelu.

Dla kogoś, kto dziś odpala Claude Code w kontenerze z -v /var/run/docker.sock, bo „inaczej testy nie wstaną”, to wyraźny sygnał. O tym, co montować, a czego nie, piszemy w poradniku o Claude Code w Dockerze.