Klucze API, OAuth, tokeny — czego NIGDY nie wrzucasz do ChatGPT i agenta AI

Jakub Pytlik | 15 maja 2026 | 8 min czytania

Co realnie się dzieje w 2026

Trzy konkretne wydarzenia z ostatnich miesięcy pokazują skalę problemu.

Luty 2026: krytyczna luka ChatGPT (Check Point Research)

Check Point Research zidentyfikował ukryty kanał wyjścia z runtime'u ChatGPT. Jeden specjalnie spreparowany prompt mógł wyciągnąć: wiadomości użytkownika, uploadowane pliki, wrażliwe treści z izolowanego środowiska wykonawczego. OpenAI potwierdził lukę i wydał poprawkę 20 lutego 2026. Z perspektywy użytkownika: przez tygodnie luka była aktywna, a setki firm, które w tym czasie wrzucały pliki z kluczami i konfiguracjami, nie miały żadnego sygnału, że ich dane mogły zostać skompromitowane.

To nie spekulacja — to udokumentowana podatność klasy prompt injection, oceniona przez Check Point jako krytyczna.

8 000+ kluczy API ChatGPT publicznie (GitHub + strony produkcyjne, Vicarius)

Vicarius w 2026 zidentyfikował:

• 5 000+ publicznych repozytoriów GitHub z hardcoded kluczami ChatGPT API
• 3 000+ działających stron produkcyjnych z kluczami w client-side JavaScript
• Automatyczne skanery harvestują klucze w minutach od commit'a — nie godzinach

To nie są klucze ChatGPT pro forma. To są klucze z pełnymi uprawnieniami, używanymi do kradzieży darmowego ruchu LLM cudzymi pieniędzmi. Klucze do Google Ads API, Meta Ads API, Microsoft Ads — są w identycznym ekosystemie i identycznie podatne.

12 000 kluczy API w danych treningowych modeli AI

Polskie publikacje branżowe (TechSetter, ITHardware) opisały audyt bazy Common Crawl, używanej do trenowania nowoczesnych LLM-ów: znaleziono blisko 12 000 aktywnych kluczy API i haseł. Common Crawl zaciąga publiczne strony. Jeśli ktokolwiek kiedykolwiek wrzucił klucz w publicznym repo, na pastebin lub na blogu — Common Crawl mógł go „zassać", a klucz może być częścią danych treningowych modelu.

To znaczy: AI faktycznie czerpie z danych zawierających cudze sekrety. Mimo wysiłków OpenAI, Google'a i Anthropic'a, żaden model nie ma 100% gwarancji, że nie „przypomni sobie" konkretnego klucza w odpowiedzi na sprytny prompt.

7 typów danych, których NIGDY nie wrzucasz do AI

Pełne wyjaśnienie każdej kategorii:

1. Klucze API platform reklamowych

To są klucze, które otwierają drzwi do Twoich (lub klientów) kont reklamowych. Konkretnie: developer_token dla Google Ads API, client_secret dla OAuth, access_token i refresh_token. Plus odpowiedniki dla Meta Business API, Microsoft Advertising API, TikTok Business API.

Konkretne scenariusze nadużycia: atakujący może kierować ruch z Twoich reklam na strony phishingowe, uruchamiać kampanie wstrzykujące fałszywe reklamy w sieci partnerów Twoich klientów, drenować budżet wolno przez tygodnie (np. +5% wydatku dziennie na puste kliki), albo pompować impresje konkurentów na Twoim koncie. Każdy z tych scenariuszy oznacza realną szkodę finansową i reputacyjną.

2. OAuth refresh tokens

Refresh token to długoterminowy „klucz do klucza" — pozwala generować access tokeny godzinowe. Atakujący z Twoim refresh tokenem może utrzymać dostęp tygodniami, dopóki ręcznie nie zrevoke'ujesz aplikacji w panelu Google'a / Meta. Większość użytkowników nawet nie wie, że taka opcja istnieje.

3. Pliki credentials w pełnej formie

Plik google-ads.yaml, service-account.json, .env, credentials.json. Te pliki zawierają komplet danych do uwierzytelnienia — login, klucz, sometimes refresh tokeny. Wrzucenie ich do ChatGPT „żeby pomógł skonfigurować" oznacza udostępnienie kompletu na tacy.

4. Identyfikatory kont reklamowych klientów

Sam customer_id Google Ads (np. 123-456-7890) lub Meta ad_account_id — bez kluczy — wydaje się nieszkodliwy. Problem pojawia się w kombinacji: ID konta + nazwa firmy klienta + wartości wydatków + struktura kampanii = pełny profil klienta gotowy do analizy konkurencyjnej.

5. Eksporty CRM i dane konwersji z PII

Lista leadów z imionami, e-mailami, telefonami. Eksport zamówień z e-commerce z adresami klientów. Lista subskrybentów newslettera z firmowymi danymi. To są dane osobowe — RODO. Wrzucenie ich do publicznego AI to nie tylko ryzyko biznesowe, ale i ryzyko prawne.

6. Wewnętrzne strategie cenowe i marże

Marża per kategoria, struktura kosztów, plan cenowy nowych produktów, budżety reklamowe per klient. Te dane mają wartość tylko dla Twojej firmy i konkurentów. AI nie ma „intencji" — ale dane raz wprowadzone do systemu mogą zostać użyte do trenowania kolejnych wersji modelu lub wyciec przez lukę bezpieczeństwa.

7. Dokumenty prawne i kontraktowe

NDA, draft umów, korespondencja z radcami prawnymi, dokumenty zawierające klauzule poufności. Wrzucenie do publicznego AI to często wprost złamanie zobowiązań kontraktowych, niezależnie od tego, czy dane „wyciekną".

5 sygnałów kompromitacji — gdzie sprawdzić

Cztery realne sygnały, że Twoje creds są skompromitowane — plus jeden punkt profilaktyczny, który warto zweryfikować przy okazji:

1. Nietypowe wydatki na koncie Google Ads / Meta — wzrost CPC bez powodu biznesowego, kampanie których nie pamiętasz, conversion tracking pingujący z nieznanego źródła.
2. Powiązane aplikacje w Google Account (Security → Third-party apps with account access) — sprawdź listę. Wszystko, czego nie rozpoznajesz, odepnij.
3. Logi API w Google Cloud Console (Logs Explorer) — szukaj zapytań z IP, których nie używasz, lub w godzinach, w których nie pracujesz.
4. Powiadomienia o zmianach w Google Ads — Tools → Change history. Każda zmiana, której nie pamiętasz, jest sygnałem.

Plus profilaktyka — sprawdź przy okazji:

• 2FA / weryfikacja dwuetapowa — to nie jest sygnał kompromitacji, ale jeśli nie masz włączonej, zrób to natychmiast. To pierwszy filtr ograniczający zasięg ewentualnego nadużycia.

Procedura: „wrzuciłem klucz, co teraz"

Jeśli kiedykolwiek wrzucałeś klucz, plik YAML, refresh token, identyfikator klienta — uznaj że dane są skompromitowane i działaj. Procedura w 5 krokach:

1. Zrevoke'uj klucz lub token — dwa różne mechanizmy:
   • Klucze API (developer_token, Google Cloud API key): Google Cloud Console → APIs & Services → Credentials → wybierz klucz → Delete.
   • OAuth refresh tokens (powiązane aplikacje): Google Account → Security → Third-party apps with account access → znajdź aplikację → Remove access. Dla Meta: Business Settings → Apps → Revoke.
   To dwa różne miejsca i dwa różne mechanizmy — sprawdź oba, jeśli nie wiesz, co dokładnie wrzuciłeś.
2. Wygeneruj nowy klucz z restrictions: IP whitelist (jeśli możliwe), application restrictions (web/Android/iOS), API restrictions (tylko te API, które realnie używasz).
3. Sprawdź historię ostatnich 30–90 dni w panelu API logs i panelu Google Ads / Meta. Każda nieznana operacja = dowód, że ktoś używał klucza.
4. Powiadom klientów, jeśli klucz dotyczył kont prowadzonych dla nich. Lepiej zgłosić incident niż czekać, aż klient sam zauważy.
5. Audyt swoich procesów: gdzie jeszcze trzymasz klucze (w .env w publicznym repo? w komentarzu w skrypcie? w mailu?). Konfiguracja kluczy + procesów to fundament, nie jednorazowa akcja.

Bezpieczne wzorce pracy z AI

Można korzystać z AI w pracy z reklamami bez wrzucania creds. Cztery wzorce, które stosuję:

Redacted prompts (zmaskowane prompty)

Zamiast: „Mam refresh token X, customer_id 123-456-7890 dla klienta Y, jak..." pisz: „Mam refresh token (replaced), customer_id (replaced) dla klienta z branży e-commerce, jak..." AI nie potrzebuje konkretów, żeby udzielić sensownej odpowiedzi.

Zanonimizowane eksporty

Eksport z Google Ads do CSV → przepuszczasz przez skrypt, który podmienia nazwy kampanii na C1/C2/C3, customer_id na 000-000-0000, e-maile leadów na hash. Dopiero potem wrzucasz do AI do analizy.

Read-only MCP / agenty

Jeśli korzystasz z agentów AI podpiętych do Google Ads API, używaj read-only service account z minimalnymi uprawnieniami. AI może czytać dane, generować rekomendacje, ale nie ma jak zmienić niczego na koncie. Szczegółowy wzorzec opisuję w osobnym artykule serii o bezpiecznej integracji AI z kontem.

Lokalne LLM-y dla najwrażliwszych danych

Dla bardzo wrażliwych operacji (analiza CRM, draft umów) można uruchomić lokalny model (Llama, Mistral) na własnym sprzęcie. Słabszy niż GPT-4 / Claude, ale dane nie opuszczają Twojej maszyny. Praktyczne dla agencji prawnych, finansowych i medycznych — w marketingu zwykle nie potrzeba aż tyle.

Co Google, Meta, Microsoft mogą zrobić — i czego nie zrobią

Trzy realne oczekiwania od dostawców platform reklamowych w ciągu najbliższego roku:

• Realne ograniczenia kluczy — IP whitelist, app restrictions, scope limitation. Częściowo już działa (Google API restrictions), ale słabo komunikowane. Trzeba ręcznie konfigurować.
• Lepsze panele audytu — kto, kiedy, jakim kluczem, jakie API endpointy. Aktualnie to są surowe logi w Cloud Console; potrzebne są przyjazne dashboardy z alertami.
• Rotacja tokenów wymuszona — refresh token automatycznie wygasający po N dniach. To jest standard w bankowości i medycynie; w marketingu — wciąż wyjątek.

Czego prawdopodobnie nie zrobią szybko: pełnej blokady wysyłania kluczy do AI. To jest niewykonalne technicznie po stronie platformy. Odpowiedzialność za bezpieczeństwo kluczy spoczywa na Tobie — i to nie zmieni się w 2027 ani w 2028.

O źródłach: Check Point Research — luka ChatGPT z lutego 2026; Vicarius — 8 000+ kluczy ChatGPT API publicznie; Cyble — rosnące ryzyko eksponowanych kluczy; TechSetter i SecurityBezTabu nt. Common Crawl i kluczy w bazach treningowych AI. Plus obserwacje z kont prowadzonych w JP Ads — gdzie ostatnio audyt aplikacji powiązanych z kontami klientów wykazał systematycznie 3–5 nieznanych tokenów per konto. Liczby z mojej praktyki oznaczam jako „obserwuję" lub „w audytach" — odróżniaj od twardych danych z badań bezpieczeństwa.