Jak obsługiwane są dane uwierzytelniające

Wszystkie dane uwierzytelniające, które przechowuje Speedwave, leżą w jednym katalogu danych na twojej maszynie, domyślnie ~/.speedwave/. W środku folder tokens/<project>/<service>/ mieści pliki uwierzytelniające jednej usługi, na przykład Slacka albo GitHuba. Speedwave zakłada go dopiero wtedy, gdy dana usługa faktycznie potrzebuje takich plików.

Jeden worker, jeden komplet danych uwierzytelniających

Każdy worker MCP, czyli izolowany kontener, który rozmawia z usługą pokroju Slacka, GitHuba czy SharePointa, montuje pod ścieżką /tokens wyłącznie folder tokenów swojej usługi, i to tylko do odczytu. Worker nie widzi danych uwierzytelniających żadnej innej usługi, więc jeśli ktoś go przejmie, straty ograniczą się do tokenów tej jednej usługi i niczego więcej. Pliki mają uprawnienia 0o600, ich katalogi nadrzędne 0o700, a właścicielem jednych i drugich jesteś ty.

Z kontenerem, w którym działa sam Claude, jest zupełnie inaczej: nie trzyma on żadnych tokenów usług. Żądania płyną od Claude’a przez hub, który również nie ma własnych tokenów, po HTTP, aż do workera z konkretnym tokenem. Zmienne środowiskowe o nazwie brzmiącej jak token, klucz czy sekret w ogóle nie trafiają do kontenera Claude’a ani do huba, dlatego dane uwierzytelniające docierają do workera tylko jako zamontowany plik, a nie jako coś, co model odczyta z własnego środowiska. To właśnie rozdzielenie modelu od danych, których nigdy on nie ogląda, jest sednem modelu izolacji Speedwave.

Notatka

Klucze API dostawców LLM działają tak samo, tyle że trafiają do kontenera proxy, a nie do workera: tokens/<project>/llm/<provider_id>_api_key, zamontowane tylko do odczytu. W swojej konfiguracji proxy trzyma jedynie nazwę zmiennej jako placeholder, na przykład SPW_KEY_<ID>, a nigdy samego klucza. Dopiero w momencie żądania odczytuje plik przypisany do tej nazwy, więc klucz nigdy nie staje się zmienną środowiskową kontenera. Jedynym celowym wyjątkiem jest klucz API Anthropic: zostaje on w kontenerze Claude’a, bo Claude Code korzysta z niego wprost.

Każde wywołanie proxy niesie dodatkowo token wywołującego, przypisany do konkretnego projektu, w nagłówku x-speedwave-proxy-auth. Dzięki temu inny kontener w tej samej sieci projektu nie przepuści przez proxy własnych żądań. Skrót SHA-256 z konfiguracji proxy i plików tokenów zasila jego zmienną SPW_CONFIG_DIGEST, więc po rotacji klucza dostawcy kontener odtwarza się sam, a klucz nie ląduje w logach. Zajrzyj do dostawców LLM i ścieżek tokenów, żeby sprawdzić, gdzie leżą te pliki.

Token IDE Bridge

Żeby sparować Claude Code z twoim lokalnym edytorem, potrzebna jest droga z kontenera z powrotem do twojej maszyny. Plik blokady IDE Bridge przechowuje token uwierzytelniający w formacie UUID v4, tworzony na nowo przy każdym uruchomieniu Desktop, a Speedwave montuje go do kontenera tylko do odczytu.

Co widzisz w terminalu

CLI nigdy nie wypisze surowego sekretu, nawet przez przypadek. Każdy wiersz, który wypisuje, czy to stdout, stderr, wpis w logu, czy komunikat paniki, przechodzi przez ten sam mechanizm czyszczący, który oczyszcza eksport diagnostyczny: tokeny Bearer i klucze API pojawiają się na ekranie jako ***REDACTED***.

Usługi, z którymi Claude łączy się przez workery, skonfigurujesz na stronie integracji.