BlogWydaniaProblemyDokumentacjaPobraniaStatusLooking GlassKontakt ze sprzedażą
Security Blog

Asystent AI do pisania kodu właśnie przeczytał Pana portfel

#220

October 2, 2026 · By Marketing team

← All posts

Narzędzia AI do pisania kodu czytają pliki .env, zanim Pan cokolwiek wpisze. Klucze API — z których każdy jest kartą kredytową bez limitu wydatków — trafiają do cudzego okna kontekstu, zanim Pan napisze pierwsze polecenie. Problemem nie jest AI. Problemem jest to, że sekrety są plikami.

Proszę otworzyć asystenta AI do pisania kodu. Zanim Pan wpisze choćby jeden znak, narzędzie już przeczytało katalog projektu. Plik .env. Klucze API. Hasło do bazy danych. Tajny klucz Stripe.

Pan tego nie zamawiał. Pan tego nie zatwierdził. To funkcja, nie błąd — narzędzie potrzebuje kontekstu projektu, żeby być użyteczne. Czyta więc wszystko, co może przeczytać programista.

A programista może przeczytać wszystko.

Wersja w stylu greentext

W tym tygodniu obiegł sieć wpis napisany jako wewnętrzny monolog programisty:

> Otwórz Claude Code. Plik .env zostaje przeczytany, zanim cokolwiek wpiszesz. Twoje klucze API są już na czacie. Dodajesz „nie czytaj .env" do CLAUDE.md. Nie działa.

380 000 osób zobaczyło ten wpis. 2 700 dodało go do zakładek. Nie dlatego, że była to nowina — dlatego, że było to lustro.

Każdy programista, który go przeczytał, pomyślał to samo: to moje środowisko.

Instrukcje nie działają

Pierwszą rzeczą, którą próbowano, było pisanie reguł. „Nie czytaj plików .env." W CLAUDE.md, w AGENTS.md, w promptach systemowych. Bezpośrednie, jednoznaczne zakazy.

Narzędzie i tak czytało pliki.

To ma sens, gdy się nad tym zastanowić. Plik jest czytany w ramach budowania kontekstu projektu — zanim instrukcje w ogóle zostaną przetworzone. Mówienie modelowi, żeby nie czytał pliku, który już przeczytał, jest jak mówienie komuś, żeby zapomniał to, co przed chwilą zobaczył. Informacja jest w oknie kontekstu. Została przekazana. Instrukcja dociera po szkodzie.

Jeden badacz stwierdził, że nawet reguły blokowania na poziomie pliku można obejść za pomocą niestandardowych skryptów lub łańcuchów potoków. Inny odkrył podwyższone rachunki za proxy, ponieważ jego dane uwierzytelniające HTTP_PROXY były automatycznie wczytywane i wykorzystywane.

Pieniądze w pliku .env

Ludzie przedstawiają to jako kwestię prywatności. To kwestia finansowa.

Proszę otworzyć typowy plik .env w projekcie produkcyjnym:

OPENAI_API_KEY=sk-...
STRIPE_SECRET_KEY=sk_live_...
AWS_ACCESS_KEY_ID=AKIA...
AWS_SECRET_ACCESS_KEY=...
DATABASE_URL=postgresql://user:pass@...

Klucz OpenAI to karta kredytowa bez limitu wydatków i bez PIN-u. Ktoś, kto ma ten ciąg znaków, może wygenerować 40 000 USD wywołań API w ciągu jednej nocy. Klucz Stripe może realizować zwroty, tworzyć obciążenia, uzyskiwać dostęp do danych płatniczych klientów. Dane uwierzytelniające AWS — w zależności od polityki IAM, która niemal na pewno jest zbyt szeroka — mogą uruchamiać instancje GPU, uzyskiwać dostęp do zasobników S3 lub usuwać infrastrukturę.

To nie jest lista haseł. To lista portfeli, każdy z innym saldem i bez zamka.

29 milionów portfeli na chodniku

Najnowszy raport GitGuardian naliczył 28,6 miliona sekretów ujawnionych w publicznych commitach na GitHubie w 2025 roku. Wzrost o 34% w stosunku do roku poprzedniego i największa roczna zmiana, jaką kiedykolwiek zmierzono.

Dane dotyczące AI są gorsze. 1,2 miliona sekretów usług AI ujawnionych — skok o 81% rok do roku. Commity współtworzone przez narzędzia AI do pisania kodu wyciekały sekrety z częstością około dwukrotnie wyższą od poziomu bazowego. A 24 000 unikalnych sekretów znaleziono w plikach konfiguracyjnych MCP — infrastrukturze łączącej agentów AI z usługami zewnętrznymi.

Dwanaście z piętnastu najszybciej rosnących typów wyciekających sekretów to usługi AI. Nie bazy danych. Nie dostawcy chmury. Usługi AI.

Narzędzia, których używamy do szybszego pisania kodu, wyciekają klucze do systemów, z którymi ten kod się łączy.

Prawdziwy problem

Programista, który opublikował ten wątek greentext, zakończył go praktycznym rozwiązaniem — konfiguracją settings.json blokującą odczyt plików. To działa. Na razie, dla tego narzędzia.

Ale prawdziwym problemem nie jest Claude Code, Cursor ani Copilot. Prawdziwym problemem jest to, że sekrety są plikami.

Plik .env to dokument w postaci zwykłego tekstu leżący na dysku, czytelny dla każdego procesu uruchomionego jako Pan. Przed narzędziami AI do pisania kodu procesami czytającymi Pana projekt były git, npm, node, edytor. Ufał im Pan bezwarunkowo. Nie myślał Pan o tym, że sekrety dzieli od ujawnienia jedno polecenie cat.

Narzędzia AI do pisania kodu tylko uczyniły to, co dorozumiane, jawnym. Czytają Pana projekt tak samo jak każde inne narzędzie — po prostu wysyłają kontekst w miejsce, które Pan widzi.

Pana pipeline CI też czyta pliki .env. Pana test runner też. Pana linter też. Pana build Dockera też. Żaden z nich też nie prosił o zgodę. Po prostu Pan tego nie zauważył, bo nie pokazały Panu transkryptu czatu z tym, co znalazły.

Wzorzec pod spodem

70% sekretów wyciekłych w 2022 roku jest nadal aktywnych dzisiaj. Niezrotowanych. Nieunieważnionych. Nadal działających, nadal udzielających dostępu, trzy lata później.

To jest prawdziwa liczba. Nie 29 milionów wycieków — 70% nigdy nie naprawionych. Bo rotacja klucza oznacza znalezienie każdego systemu, który go używa, zaktualizowanie każdego wdrożenia, przetestowanie każdej integracji. Klucz został utworzony raz, wklejony do pliku .env i nigdy więcej o nim nie pomyślano. Koszt jego wycieku jest natychmiastowy. Koszt naprawy wycieku jest nieograniczony.

Większość organizacji tego nie naprawia. Nie może. Nie wiedzą, które klucze są gdzie, które są nadal aktywne, które zostały skopiowane do innych plików .env na innych maszynach przez innych programistów, którzy musieli w piątkowe popołudnie uruchomić jakąś funkcję.

Co to właściwie oznacza

Każdy plik .env to zakład. Zakład, że żaden proces go nie przeczyta, który nie powinien. Zakład, że żadne narzędzie nie wyśle go w nieoczekiwane miejsce. Zakład, że żaden programista nie doda go do repozytorium przez przypadek.

29 milionów razy w zeszłym roku ktoś przegrał ten zakład. Tylko na publicznym GitHubie. Prywatne repozytoria — w których GitGuardian znalazł sekrety w 35% repozytoriów — nie są nawet wliczone.

Rozwiązaniem nie jest reguła w settings.json. Rozwiązaniem nie jest wpis w .gitignore. Rozwiązaniem nie jest pisanie „NIE CZYTAJ .ENV" wielkimi literami w pliku z instrukcjami.

Rozwiązaniem jest to, że sekretu nie powinno tam być w ogóle. Nie w pliku. Nie w zmiennej środowiskowej wczytywanej z pliku. Nie w jakiejkolwiek formie, którą proces z Pana uprawnieniami może odczytać, robiąc to, co procesy robią: czytając pliki w katalogu Pana projektu.

Jeśli sekret jest na dysku, zostanie przeczytany. Pytanie brzmi tylko: kiedy i przez co.

---

Źródła