Hasła, tokeny API i dane połączeń wykorzystywane przez agenta Claude Code mogą zostać przez niego zapisanym w pliku konfiguracyjnym. Umieszczenie go w repozytorium lub publikowanej paczce może prowadzić do ujawnienia poświadczeń. Badacze Apiiro znaleźli tysiące potencjalnie rzeczywistych sekretów w publicznych repozytoriach.
Jak dochodzi do ujawnienia?
Claude Code może wykonywać polecenia wymagające uwierzytelnienia, np. podczas sprawdzania połączenia z bazą danych lub wywoływania API. Jeśli proponowane polecenie zawiera bezpośrednio hasło lub token, wybranie opcji „Yes, and don’t ask again” może zapisać je wraz z poświadczeniami w pliku .claude/settings.local.json.
Plik przechowuje reguły uprawnień, dzięki którym narzędzie nie musi ponownie pytać o zgodę na określone operacje. W ten sposób mechanizm zapamiętywania zgód może jednocześnie tworzyć dodatkowe, jawne kopie sekretów. Zjawisko opisano we wcześniejszych zgłoszeniach użytkowników, a dokumentacja Claude Code potwierdza przechowywanie trwałych zgód w lokalnym pliku ustawień. Do ujawnienia dochodzi, gdy zawierający je plik zostanie następnie wysłany do repozytorium, dołączony do paczki oprogramowania lub udostępniony wraz z katalogiem projektu. Użytkownik może nie zauważyć problemu, ponieważ sekret znajduje się w konfiguracji narzędzia, a nie w typowym pliku z hasłami.
Apiiro raportuje wykrycie 2539 potencjalnie rzeczywistych sekretów w 1994 publicznych repozytoriach, uwzględniając pliki ustawień, historię zmian i inne artefakty pracy agentów. Autorzy nie testowali poświadczeń przez próby uwierzytelnienia. Wyniki wskazują więc na ekspozycję danych sklasyfikowanych jako sekrety, lecz nie określają liczby nadal aktywnych dostępów ani skutecznych włamań. Szczegółowe kryteria klasyfikacji i ograniczenia badania przedstawiono w publikacji Apiiro. Warto przy tym podkreślić, że wcześniejsze doniesienia wskazywały również na możliwość podobnego ujawniania informacji w paczkach npm.
Kogo dotyczy zagrożenie?
Przede wszystkim użytkowników Claude Code, którzy udostępniają agentowi konfiguracje zawierające sekrety lub pozwalają mu wykonywać polecenia uwierzytelniające. Szczególnej uwagi wymagają projekty korzystające z poświadczeń produkcyjnych, administracyjnych oraz tokenów umożliwiających publikowanie oprogramowania. W przypadku braku sprawdzonej konfiguracji DLP, uniemożliwiającej przekazanie agentowi poświadczeń, warto założyć potencjalne naruszenie i zweryfikować repozytoria oraz paczki.
Prywatne repozytoria ograniczają skutki wycieku, lecz wciąż naruszać mogą zasady wiedzy koniecznej. Co więcej, kopie poświadczeń będą pozostawać w historii zmian i lokalnych klonach repozytorium.
Samo gitignore może nie wystarczyć
Zgodnie z dokumentacją Claude Code, przy tworzeniu lokalnego pliku ustawień w repozytorium dodaje jego wykluczenie do globalnej konfiguracji Git danego użytkownika. Nie jest to jednak reguła zapisana w projektowym .gitignore, która byłaby przekazywana wraz z projektem.
Dodatkowo reguły ignorowania nie działają na pliki już śledzone przez Git. Jeżeli lokalne ustawienia wcześniej znalazły się w repozytorium, samo dopisanie ich do .gitignore nie zatrzyma wersjonowania kolejnych zmian. Wykluczenie z Git nie zastępuje także kontroli zawartości paczek, obrazów kontenerów i archiwów. Szczegóły działania wykluczeń opisuje dokumentacja Git.
Zalecane działania
Organizacje korzystające z Claude Code powinny przeprowadzić przegląd projektów, w których agent miał dostęp do poświadczeń: również wtedy, gdy nie otrzymały dotąd informacji o wycieku.
- Podejrzewając naruszenie, należy sprawdzić pliki i historię zmian. Przegląd powinien objąć
.claude/settings.local.json,.claude/settings.json, historię repozytoriów oraz zapisane rozmowy i artefakty agenta. Należy uwzględnić również wcześniej opublikowane wersje paczek. - Zaleca się również wykluczenie lokalnych ustawień z dystrybucji. W tym celu należy dodać odpowiednią regułę do projektowego
.gitignore, a plik już śledzony usunąć także z indeksu Git. Osobno zweryfikować zawartość paczek, obrazów i archiwów. - Rekomenduje się ograniczenie utrwalania poświadczeń przez niezapisywanie trwałych zgód dla poleceń zawierających jawne hasła lub tokeny. Zamiast nich należy korzystać z kontrolowanego dostarczania sekretów i ograniczać dostęp agenta do danych produkcyjnych.
- Zaleca się zasadniczo objąć artefakty agentów skanowaniem. Kontrole przed wysłaniem zmian i publikacją powinny wykrywać również zwykłe hasła w poleceniach oraz ciągach połączenia, a nie tylko tokeny o charakterystycznym formacie. Apiiro wskazuje, że standardowe skanery nie wykryły wszystkich takich przypadków.
- W przypadku podejrzenia naruszenia poufności poświadczeń, należy niezwłocznie je unieważnić lub zmienić. Następnie zaleca się sprawdzić logi ich użycia, ocenić zakres ekspozycji i usunąć ujawnione kopie. Samo usunięcie pliku z bieżącej wersji projektu nie unieważnia sekretu ani nie usuwa go z historii i pobranych kopii.
Pliki ustawień i pozostałości pracy agentów warto traktować jako potencjalne nośniki informacji poufnych. Ich kontrola powinna stać się częścią procesu przeglądu kodu i publikowania oprogramowania, szczególnie tam, gdzie agent korzysta z rzeczywistych poświadczeń.
Źródła:
Cohen S., Giladi M. (2026). Coding Agents Copy Your Secrets to a Hidden File. Thousands Are on GitHub. Apiiro [Online].
Feyo (2026). Claude Code Source Code Leaked via npm Source Maps: What You Need to Know. Feyo [Online].