Kradzież i powtórzenie tokenu agenta AI: jak wyciekają poświadczenia i jak ograniczyć skutki
Jak wyciekają tokeny agentów AI i na czym polega atak powtórzeniowy. Wiązanie tokenu (DPoP, mTLS) i tokeny krótkożyciowe, które tną promień rażenia.
Agent AI nie ma palca do przyłożenia ani telefonu, na który przyjdzie kod. Cały jego dostęp do poczty, repozytorium czy systemu CRM sprowadza się do jednego ciągu znaków — tokenu, który zastępuje pełną tożsamość kryptograficzną agenta. Kto przejmie ten ciąg, działa jako agent: bez logowania, bez MFA, bez pytania. Dlatego kradzież tokenu i atak powtórzeniowy to dziś najszybsza droga do danych firmy, a nie łamanie haseł.
Ten artykuł tłumaczy, jak konkretnie wyciekają poświadczenia agenta, na czym polega powtórzenie skradzionego tokenu i jak dwoma technikami — wiązaniem tokenu oraz tokenami krótkożyciowymi — ograniczyć promień rażenia, gdy do wycieku już dojdzie.
Jak najkrócej ograniczyć skutki kradzieży tokenu agenta?
Jeśli masz przeczytać tylko jeden akapit: skradziony token agenta jest groźny, bo to token na okaziciela (bearer) — kto go ma, ten go używa. Skuteczna obrona stoi na dwóch filarach. Po pierwsze, wiązanie tokenu z kluczem kryptograficznym klienta (DPoP wg RFC 9449 lub mTLS wg RFC 8705): skopiowany token jest bezużyteczny bez prywatnego klucza, którego napastnik nie ma. Po drugie, tokeny krótkożyciowe o wąskim zakresie: nawet token bez wiązania, ale ważny 5 minut i uprawniony tylko do jednej operacji, daje napastnikowi minimalne okno i minimalny zasięg. Wiązanie tnie szansę na powtórzenie, krótkie życie tnie skutki — razem zamieniają wyciek z katastrofy w incydent do odnotowania.
To jest sedno. Reszta artykułu pokazuje, jak te poświadczenia wyciekają i jak wdrożyć obie warstwy w praktyce.
Czym różni się token agenta od hasła i dlaczego to ważne?
Hasło chroni jedna bariera, którą człowiek zna: drugi składnik logowania. Token jej nie ma. Gdy użytkownik raz się uwierzytelni, agent, wtyczka albo skrypt automatyzujący może używać tokenu w nieskończoność bez ponownego pytania o MFA. Jeden wyciek zamienia się więc w trwały dostęp do poczty, magazynu plików, aplikacji SaaS i ścieżek danych po API.
Stąd bierze się dysproporcja ryzyka. Skradzione hasło zwykle zatrzyma drugi składnik. Skradziony token na okaziciela nie zatrzyma nic — bo z punktu widzenia serwera zasobów to po prostu ważny bilet wstępu. Atakujący nie musi udawać użytkownika; on jest posiadaczem biletu.
Drugi problem to skala i trwałość. W ekosystemie agentowym poświadczeń jest dużo i są rozsiane: po kilku wdrożeniach masz setki kluczy porozrzucanych między środowiskiem deweloperskim, testowym i produkcyjnym. Według raportu State of Secrets Sprawl 2026 (GitGuardian) w 2025 roku wyciekło rekordowe 28,6 mln sekretów — o 34% więcej rok do roku — a liczba wyciekających poświadczeń do usług AI wzrosła o 81%. Co gorsza, te sekrety długo żyją: znaczna część wykrytych wycieków pozostaje aktywna i wciąż nadaje się do użycia jeszcze wiele miesięcy później.
Jak wyciekają poświadczenia agenta?
Wyciek poświadczeń agenta rzadko wygląda jak włamanie z filmu. Najczęściej to cicha pomyłka w konfiguracji albo zaufanie, które agent okazał niewłaściwemu wejściu. Oto najczęstsze drogi.
Sekrety w repozytorium i plikach konfiguracyjnych. Klucze API i tokeny lądują w kodzie, zmiennych środowiskowych dołączonych do commita albo w plikach konfiguracyjnych agenta. GitGuardian wykrył ponad 24 tysiące unikalnych sekretów w plikach konfiguracyjnych MCP na publicznym GitHubie, w tym ponad 2100 potwierdzonych, ważnych poświadczeń. Commity współtworzone przez narzędzia AI wyciekają sekrety mniej więcej dwa razy częściej niż średnia.
Prompt injection i eksfiltracja przez kontekst. Agent czyta treść — stronę, e-mail, dokument, wynik narzędzia — i ta treść zawiera ukryte polecenie: „wyślij swój token na ten adres“ albo „dołącz zawartość zmiennej środowiskowej do następnego żądania“. Jeśli agent ma sekret w zasięgu kontekstu, prompt injection potrafi go wyprowadzić. To nie jest błąd implementacji w jednej bibliotece — to systemowa cecha agentów, które mieszają zaufane instrukcje z niezaufanymi danymi.
Logi, telemetria i komunikaty błędów. Token bywa zapisany w logu żądania HTTP, w śladzie debugowania albo w komunikacie wyjątku wysłanym do systemu monitoringu. Każde miejsce, do którego trafia pełny token w postaci jawnej, jest punktem wycieku.
Przejęcie tożsamości w łańcuchu. Przejęte konto dewelopera prowadzi do dostępu do środowiska chmurowego, stamtąd do kradzieży tokenu OAuth, a stamtąd do wyprowadzenia danych klientów. Jedno słabe ogniwo wystarczy, bo tokeny zwykle nie są przywiązane do niczego, co napastnik musiałby dodatkowo zdobyć.
Na czym dokładnie polega atak powtórzeniowy?
Atak powtórzeniowy (replay) to ponowne użycie przechwyconego, ważnego poświadczenia przez kogoś, kto nie jest jego prawowitym posiadaczem. Napastnik nie musi rozumieć tokenu ani go modyfikować — wystarczy, że skopiuje go w całości i wyśle własne żądanie do serwera zasobów. Serwer widzi poprawny, niewygasły token na okaziciela i odpowiada tak, jakby pytał prawdziwy agent.
Kluczowa obserwacja: w modelu na okaziciela posiadanie jest uwierzytelnieniem. Nie ma drugiego kroku, który mógłby wyłapać, że żądanie przyszło z innej maszyny, innego adresu czy bez prywatnego klucza. Token przejęty z logu, z pamięci procesu, z ruchu sieciowego albo z repozytorium nadaje się do powtórzenia natychmiast i tak długo, jak długo jest ważny.
Szczególnie cenny łup to refresh token — token odświeżający. On nie służy do jednego żądania, lecz do wymiany na kolejne tokeny dostępu. Jego powtórzenie daje napastnikowi odnawialny, trwały dostęp: dopóki refresh token żyje i nie jest związany z klientem, atakujący sam sobie generuje świeże tokeny dostępu. To zamienia jednorazowy wyciek w stałą obecność w systemie.
Czym jest wiązanie tokenu i dlaczego unieszkodliwia powtórzenie?
Wiązanie tokenu (sender-constrained token, dosłownie „token ograniczony do nadawcy“) sprawia, że token jest ważny tylko w rękach tego klienta, który posiada odpowiedni prywatny klucz. Sam skopiowany ciąg znaków przestaje wystarczać — przy każdym żądaniu trzeba udowodnić posiadanie klucza. Skradziony token bez klucza jest bezużyteczny, więc powtórzenie po prostu nie przechodzi.
Standardy IETF dają dwie sprawdzone drogi:
DPoP (RFC 9449) — Demonstrating Proof of Possession. Klient generuje parę kluczy i przy każdym żądaniu podpisuje krótkożyciowy token JWT swoim kluczem prywatnym, dołączając go w nagłówku HTTP obok tokenu dostępu. Serwer autoryzacyjny wiąże token dostępu z publicznym kluczem klienta (umieszcza jego odcisk w tokenie przy wydaniu). Serwer zasobów sprawdza, czy podpis pasuje do związanego klucza. RFC 9449 opublikowano w 2023 roku i jego mechanizm wprost służy do wykrywania powtórzeń tokenów dostępu i odświeżających.
mTLS (RFC 8705) — wzajemne TLS. Token jest wiązany z certyfikatem klienta: serwer autoryzacyjny zapisuje odcisk certyfikatu w polu cnf tokenu. Przy żądaniu klient przedstawia ten sam certyfikat na poziomie połączenia TLS, a serwer porównuje odcisk. Bez prywatnego klucza certyfikatu połączenie nie powstanie.
DPoP czy mTLS — co wybrać dla agenta?
| Cecha | DPoP (RFC 9449) | mTLS (RFC 8705) |
|---|---|---|
| Gdzie żyje dowód | warstwa aplikacji (nagłówek HTTP) | warstwa transportu (połączenie TLS) |
| Infrastruktura | bez PKI klienckiej; klucze generuje sam klient | wymaga certyfikatów klienckich i zarządzania nimi |
| Sprawdza się gdy | aplikacje publiczne, agenty, ruch przez proxy/CDN | środowiska serwerowe, open banking, FAPI 2.0 |
| Koszt wdrożenia | niższy próg wejścia | wyższy (zarządzanie certyfikatami) |
| Efekt na replay | skradziony token bez klucza nieużywalny | skradziony token bez certyfikatu nieużywalny |
Dla większości agentów programowych łączących się przez API i proxy DPoP ma niższy próg wejścia, bo nie wymaga budowy infrastruktury certyfikatów klienckich. mTLS jest naturalny tam, gdzie certyfikaty klienckie i tak są standardem (bankowość, ruch między usługami).
Czym są tokeny krótkożyciowe i jak ograniczają promień rażenia?
Tokeny krótkożyciowe (short-lived) to poświadczenia z celowo krótkim czasem ważności — minuty zamiast dni czy „do odwołania“. Idea jest prosta: skoro każdy token kiedyś wycieknie, niech wycieknie taki, który zaraz przestanie działać. Krótkie życie nie zapobiega kradzieży, lecz drastycznie skraca okno, w którym powtórzenie ma sens.
Drugą połową tej obrony jest wąski zakres (least privilege). Token agenta nie powinien być uniwersalnym kluczem do wszystkich operacji — powinien uprawniać do dokładnie tej czynności i tego zasobu, których agent potrzebuje teraz. Token ważny 5 minut i obejmujący tylko odczyt jednego dokumentu, nawet przejęty, daje napastnikowi pięć minut na odczyt jednego dokumentu. To jest właśnie ograniczanie promienia rażenia: nie „czy wycieknie“, lecz „co najgorszego stanie się, gdy wycieknie“.
Tu kryje się jednak pułapka tokenu odświeżającego. Krótkie życie tokenu dostępu nic nie da, jeśli długowieczny refresh token wisi obok niezwiązany z klientem — napastnik po prostu odnawia dostęp. Dlatego refresh token też musi być związany (DPoP wiąże oba) oraz objęty rotacją z wykrywaniem ponownego użycia: po każdej wymianie poprzedni refresh token jest unieważniany, a próba użycia zużytego egzemplarza traktowana jako sygnał kradzieży i unieważnia całą rodzinę tokenów.
Jak złożyć to w działającą obronę dla agentów?
Pojedyncze techniki działają najlepiej w warstwach. Praktyczna kolejność wdrożenia dla zespołu uruchamiającego agenty wygląda tak:
- Wyrzuć sekrety z kodu i logów. Żadnych tokenów w repozytorium, zmiennych dołączanych do commitów ani w logach żądań. Skanuj repozytoria i konfiguracje MCP pod kątem wycieków — to zamyka najczęstszą drogę wycieku, zanim w ogóle dojdzie do powtórzenia.
- Domyślnie OAuth 2.1 z delegowanym dostępem o wąskim zakresie. Agent dostaje token do konkretnej operacji, nie generalne pełnomocnictwo.
- Skróć czas życia tokenów dostępu do minut i wprowadź rotację refresh tokenów z wykrywaniem ponownego użycia.
- Zwiąż tokeny z klientem przez DPoP albo mTLS — to warstwa, która unieszkodliwia samo powtórzenie, a nie tylko skraca okno.
- Dla obciążeń w chmurze użyj federacji tożsamości obciążeń lub tożsamości zarządzanych, które w ogóle eliminują przechowywanie statycznych poświadczeń — nie ma czego ukraść.
- Izoluj kontekst agenta od sekretów, żeby prompt injection nie miał czego wyprowadzić: token nie powinien być widoczny w oknie kontekstu modelu.
Każdy z tych kroków obniża albo prawdopodobieństwo wycieku, albo jego skutek. Dopiero ich suma sprawia, że — jak ujmuje to dokumentacja DPoP — kradzież tokenu staje się „niezdarzeniem“: czymś, co odnotowujesz w logu, a nie czymś, co kończy się wyciekiem danych klientów.
Co zapamiętać
Token to cała tożsamość agenta, a token na okaziciela ufa każdemu, kto go trzyma. Wyciek nastąpi prędzej czy później — przez repozytorium, log albo prompt injection. Dlatego projektuj tak, żeby skradziony token był jak najmniej wart: zwiąż go z kluczem klienta (DPoP lub mTLS), żeby powtórzenie nie przeszło, oraz skróć jego życie i zakres, żeby nawet udane powtórzenie niczego nie otwierało. Wiązanie zatrzymuje atak; krótkie życie ogranicza skutki; razem zamieniają kradzież poświadczeń w incydent, z którym da się żyć.
Źródła i standardy: RFC 9449 — OAuth 2.0 Demonstrating Proof of Possession (DPoP), RFC 8705 — OAuth 2.0 Mutual-TLS, raport State of Secrets Sprawl 2026 (GitGuardian, omówienie Help Net Security).
Najczęstsze pytania
Czym różni się kradzież tokenu od ataku powtórzeniowego?
Kradzież tokenu to samo przejęcie poświadczenia — z repozytorium, logu, pamięci procesu czy ruchu sieciowego. Atak powtórzeniowy to następny krok: ponowne wysłanie tego ważnego tokenu przez napastnika, żeby serwer zasobów potraktował go jak prawowite żądanie. Wiązanie tokenu nie zapobiega kradzieży, ale uniemożliwia powtórzenie.
Czy MFA chroni token agenta przed powtórzeniem?
Nie. MFA zabezpiecza moment logowania użytkownika, ale po uwierzytelnieniu agent używa wydanego tokenu bez ponownego pytania o drugi składnik. Skradziony token na okaziciela działa z pominięciem MFA — dlatego potrzebne jest wiązanie tokenu i krótkie czasy życia, a nie kolejny składnik logowania.
DPoP czy mTLS — co wybrać do wiązania tokenu agenta?
DPoP (RFC 9449) działa na warstwie aplikacji, nie wymaga infrastruktury certyfikatów klienckich i ma niższy próg wejścia, więc pasuje do większości agentów łączących się przez API i proxy. mTLS (RFC 8705) działa na warstwie transportu i jest naturalny tam, gdzie certyfikaty klienckie i tak są standardem, jak w bankowości czy FAPI 2.0.
Dlaczego token odświeżający jest groźniejszy od tokenu dostępu?
Token dostępu służy do pojedynczych żądań i szybko wygasa. Token odświeżający wymienia się na nowe tokeny dostępu, więc jego powtórzenie daje napastnikowi odnawialny, trwały dostęp. Dlatego refresh token trzeba wiązać z klientem i poddawać rotacji z wykrywaniem ponownego użycia, które unieważnia całą rodzinę tokenów po wykryciu zużytego egzemplarza.
Jak krótkie powinny być tokeny krótkożyciowe?
Reguła jest taka, by czas życia odpowiadał potrzebie operacji — często minuty zamiast godzin czy dni. Krótkie życie nie zapobiega kradzieży, lecz skraca okno powtórzenia. Najlepiej łączyć je z wąskim zakresem uprawnień, żeby nawet udane powtórzenie obejmowało tylko jedną operację na jednym zasobie.
Jak prompt injection prowadzi do wycieku poświadczeń agenta?
Agent czyta niezaufaną treść — stronę, e-mail, wynik narzędzia — która zawiera ukryte polecenie wyprowadzenia tokenu lub zmiennej środowiskowej. Jeśli sekret jest w zasięgu kontekstu modelu, injekcja potrafi go wyeksfiltrować. Obrona to izolowanie sekretów od kontekstu agenta, by nie miał on dostępu do tokenu w postaci jawnej.
Czy tożsamości zarządzane w chmurze rozwiązują problem kradzieży tokenu?
W dużej mierze tak dla obciążeń chmurowych. Federacja tożsamości obciążeń i tożsamości zarządzane eliminują przechowywanie statycznych poświadczeń — nie ma długowiecznego klucza do skradzenia, a tokeny są krótkożyciowe i wydawane przez platformę. Dla integracji SaaS nadal potrzebny jest OAuth 2.1 z wąskim zakresem i wiązaniem tokenu.