Model izolacji

Kontener, w którym działa Claude, nie przechowuje żadnych tokenów ani danych uwierzytelniających i nie łączy się bezpośrednio z GitLabem, Slackiem, SharePointem czy jakąkolwiek inną usługą. Kiedy projekt podłącza usługę, ta dostaje własny kontener workera i tylko on montuje jej dane uwierzytelniające, w trybie tylko do odczytu. Claude analizuje i pisze kod, ale żadne dane uwierzytelniające nigdy przez niego nie przechodzą. Szczegóły opisuje strona Dane uwierzytelniające.

Bez tokenów, bez skrótów

Każdy kontener, który uruchamia Speedwave, czyli kontener Claude, hub oraz wszystkie workery, jest zabezpieczony tak samo: wszystkie uprawnienia (capabilities) Linuksa zostają odebrane, eskalacja uprawnień jest zablokowana, główny system plików działa tylko do odczytu, a /tmp montujemy tak, by niczego zapisanego w nim nie dało się uruchomić. Limit procesora i pamięci to ograniczenie zasobów, a nie granica bezpieczeństwa: powstrzymuje jedynie rozpędzony proces, nic więcej.

Claude nigdy nie rozmawia z usługą bezpośrednio. Rozmawia z hubem, ten przekazuje żądanie do właściwego workera i dopiero worker ma dane uwierzytelniające potrzebne do danego wywołania: przejęty worker odsłania tylko jedną usługę, a przejęty hub nie odsłania nic. Worker biurowy, który konwertuje pliki Word, Excel, PowerPoint i PDF, idzie o krok dalej: nie ma żadnych danych uwierzytelniających ani drogi do gatewaya, więc nawet przejęty parser dokumentów nie dotrze do internetu.

flowchart LR
  Claude["Claude container<br/>(no tokens)"] -->|HTTP| Hub["Hub<br/>(zero tokens)"]
  Hub -->|HTTP| Slack["Slack worker"]
  Hub -->|HTTP| GH["GitHub worker"]
  Slack -->|"reads"| ST[("Slack credentials, read-only")]
  GH -->|"reads"| GT[("GitHub credentials, read-only")]

Nie zbuduje twojego projektu w Gradle ani .NET

Kontener Claude ma na pokładzie tylko node z npm oraz python3 z pip, a do tego git i powłokę. Nie ma drogi do toolchainu hosta: żadnego JDK, Gradle, Go ani .NET, żadnego silnika kontenerów hosta. Speedwave zbudował workera do uruchamiania dozwolonych komend budowania na hoście, a potem go usunął: pozwolenie Claude na odpalanie poleceń na hoście osłabiało izolację, dla której ten kontener w ogóle istnieje.

Linki, które klikasz, też są sprawdzane

Gdy klikniesz link napisany przez Claude, interfejs czatu nigdy nie otwiera go wewnątrz aplikacji. Zamiast tego przekazuje adres do open_url, które otwiera go w domyślnej przeglądarce, po odrzuceniu adresów dłuższych niż 8192 znaki i sprawdzeniu go pod kątem reguł SSRF: dozwolone są wyłącznie schematy http/https, a adresy loopback, prywatne i link-local są blokowane. Zmanipulowany link nie dotrze do usługi w twojej sieci. Ta sama walidacja chroni adresy OAuth wtyczek; ten przypadek opisuje strona Pisanie wtyczki.

Projekty nie współdzielą sieci

Izolacja działa też osobno dla każdego projektu. Każdy projekt dostaje własną sieć kontenerów oraz własny katalog tokenów, więc worker jednego projektu nie sięgnie do sieci ani danych uwierzytelniających innego, a zalogowanie do usługi w jednym projekcie nie uwierzytelnia jej w drugim. To, co tworzy każdy projekt, opisuje Topologia kontenerów.

Na to nakładają się jeszcze dwie warstwy: osobno zabezpieczone kontenery i lekka maszyna wirtualna (Lima na macOS, WSL2 na Windows), która oddziela je wszystkie od hosta na poziomie jądra systemu. Atakujący, któremu udałoby się przejąć Claude, wylądowałby w kontenerze z pustymi rękami, a maszyna wirtualna wciąż stałaby między nim a twoim komputerem. Pełny obraz opisuje strona Jak to działa.