# 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](/pl/docs/under-the-hood/workers/), 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](/pl/docs/security/isolation/) Speedwave.
**Note:** 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](/pl/docs/features/llm-providers/) i [ścieżek tokenów](/pl/docs/reference/token-paths/), ż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](/pl/docs/guides/logs-and-diagnostics/): 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](/pl/docs/integrations/).