Nic nie zhakowano. Wszystko zabrano.

Przekaż agentowi AI jeden wyciekły klucz AWS — ten typ o niskich uprawnieniach, jednorazowy, który pipeline CI wycieka co tydzień — i każ mu zabrać to, co jest w zasięgu. Potem odejdzie Pan od klawiatury. W większości przypadków, w minutę później i bez nikogo przy klawiaturze, agent czyta dane Pana klientów.

Nic nie zhakowano, żeby tam dotrzeć. Żadnego exploita, żadnego CVE, żadnego niezałatane­go serwera. Każde poświadczenia, którego dotknął, było ważne; każde wywołanie API było takim, jakie AWS został zaprojektowany obsłużyć. Przez trzydzieści lat wyciekły klucz był wyłącznie początkiem ataku — tą powolną częścią, przy której człowiek musiał być przytomny, tą luką, w której żyją zespoły bezpieczeństwa i w której szybka rotacja wygrywa wyścig. Ta luka właśnie skurczyła się do około minuty.

W maju 2026 roku badacz o imieniu Adan Álvarez przeprowadził prosty test. Wziął jeden klucz AWS o niskich uprawnieniach — ten typ, który pipeline'y CI/CD wyciekają nagminnie — i przekazał go agentowi AI do kodowania z jedną instrukcją: działaj jak tester penetracyjny, znajdź to, co jest w zasięgu. Po tym żadnego człowieka przy klawiaturze. Resztę zrobił agent. W ponad połowie przypadków przeszedł cały łańcuch do danych klientów — w około minutę, bez nadzoru.

Co właściwie się wydarzyło

Ustawienie było celowo zwyczajne. Wyciekły klucz należał do użytkownika budującego projekty, z niskimi uprawnieniami. Sam w sobie nie mógł sięgnąć do danych klientów. Ale mógł odczytać plik stanu Terraform. Ten plik stanu zawierał drugi zestaw kluczy. Te klucze mogły przejąć rolę. Ta rola mogła odczytać kubeł z danymi klientów.

Tak ukształtowane jest niemal każde prawdziwe konto w chmurze — nie jedna ściana fortecy, lecz łańcuch drobnych, rozsądnych relacji zaufania, z których każde ogniwo osobno ma sens. Człowiek-atakujący rozplątuje taki łańcuch powoli, ręcznie. Agent rozplątał go w około sześćdziesiąt sekund.

Udane przebiegi zawsze podążały tymi samymi sześcioma krokami: potwierdzić, do kogo należy klucz, wypisać, co wolno mu robić, odzyskać drugi zestaw poświadczeń z kubełka staging, przejąć rolę z uprawnieniami, znaleźć dane, zabrać je. W dwunastu przebiegach na dwóch modelach siedem dotarło do eksfiltracji. Większość zakończyła się w mniej więcej minutę [1].

To nie jest wyłącznie wynik laboratoryjny. W listopadzie 2025 roku zespół badań zagrożeń Sysdig obserwował ten sam kształt w rzeczywistości: ważne klucze AWS wystawione w publicznym kubełku, funkcja Lambda po cichu przepisana tak, by wydawać poświadczenia administracyjne, ruch boczny przez dziewiętnaście różnych tożsamości — wszystko w osiem minut [2][3]. Wstrzyknięty kod nosił ślady modelu: staranna obsługa wyjątków, iteracyjna logika doboru celów, komentarze w więcej niż jednym języku.

To nie jest kwestia słabości AWS

Oto część, która powinna Panu nie pozwolić spać: nic nie zhakowano.

Żadnego exploita. Żadnego CVE. Żadnego przepełnienia bufora, żadnego niezałatane­go serwera. Każde poświadczenia było ważne. Każde wywołanie API było takim, jakie AWS został zaprojektowany obsłużyć. Jak ujął to Sysdig, poświadczenia były legalne, a interfejsy API wykorzystano dokładnie zgodnie z przeznaczeniem [3]. AWS wykonał swoją pracę bez zarzutu.

Założenie, które legło w gruzach, nie dotyczyło bezpieczeństwa AWS. Dotyczyło starszego, cichszego założenia pod spodem: że wyciekły klucz jest groźny tylko w takim stopniu, w jakim atakujący może poświęcić mu uwagi. Przez trzydzieści lat to się sprawdzało. Wykorzystanie poświadczeń wymagało człowieka — czasu, umiejętności, cierpliwości. Ten koszt był realną częścią Pana obrony, choć nikt nie narysował go na diagramie architektury.

Agenci sprowadzają ten koszt do zera. Cierpliwość jest nieskończona. Umiejętności są wynajmowane na minuty. Atakujący może spać.

To nie dotyczy tylko AWS

Nic w tym nie jest specyficzne dla Amazona. Ten sam łańcuch działa wszędzie tam, gdzie poświadczenia można użyć, by odkryć kolejne poświadczenia: klucz w chmurze, który potrafi wypisać własne uprawnienia, token w pliku .env, który inny proces może odczytać, sekret w pliku stanu, token sejfu leżący na dysku obok kodu. Każde narzędzie — agent kodujący, serwer MCP, który Pan zainstalował w zeszłym tygodniu — może być tym, co przejdzie łańcuchem, z Pana błogosławieństwem lub bez.

Wspólnym mianownikiem jest to, że sekret niesie ze własny promień rażenia. Można go odczytać tam, gdzie odbywa się praca, może wyliczać to, czego dotyka, i działa z dowolnego miejsca. Te trzy własności były do przeżycia, gdy ataki były powolne i manualne. Przy prędkości agentów nie są.

Zbudowane celowo, pod ten świat

Więc zbudowaliśmy przeciwieństwo, świadomie.

Poświadczenia Clavitor jest osiągalne wyłącznie po nazwie, którą nadano agentowi — nie może wyliczyć zawartości magazynu, więc nie narysuje mapy. Wartość sekretu nigdy nie trafia tam, gdzie działa kod; agent dostaje efekt użycia poświadczenia, nie samo poświadczenia. Każde jest związane z maszyną i zakresem, dla którego je wydano, więc kopia wyniesiona na laptop jest bezużyteczne. A każde żądanie jest zapisywane w niezmiennym, łańcuchowo haszowanym logu poza punktem końcowym — materiał, którego wymagają PCI DSS Req 10 i NIST 800-171 (3.3.8) — więc nawet w pełni „poprawna" czynność ma przypisaną nazwę.

Oto uczciwe zastrzeżenie: to nie czyni wyciekłego poświadczenia nieszkodliwym. Ograniczy Pan klucz do jednego kubełka, a jeśli ten klucz wycieknie, atakujący dostanie ten jeden kubełek. To, co to zabija, to łańcuch — ta część, w której jeden zwykły klucz staje się mapą do wszystkiego pozostałego. Zakres wobec wszechobecności to nie różnica między bezpieczeństwem a naruszeniem. To różnica między incydentem a katastrofą.

Zapisaliśmy garść zasad, których narzędzie do poświadczeń powinno przestrzegać, jeśli ma przetrwać w tym świecie. Może Pan sprawdzić swoje narzędzie pod ich kątem na clavitor.ai/rules.

Lekcja nie brzmi „rotuj szybciej"

Nie wygra Pan rotacją z atakiem trwającym sześćdziesiąt sekund. W chwili gdy uruchomi się kanarek, łańcuch już się odbył.

Wniosek nie brzmi „zacznijcie dokładniej sprzątać". Chodzi o to, że ekonomia się odwróciła. Budowaliśmy systemy poświadczeń dla świata, w którym czas atakującego był skąpy i drogi — gdzie wyciekły klucz był wyścigiem, który można wygrać. Tego świata już nie ma. Poświadczenia potrafiące znaleźć kolejne poświadczenia nie jest już wygodą. Jest całym atakiem, napisanym z góry, czekającym, by jakikolwiek klucz wpadł w niepowołane ręce.

Budujcie pod świat, w którym atakujący nigdy nie śpi. On już nastał.

Clavitor (@clavitorai) to sejf na poświadczenia zbudowany z myślą o agentach AI i przeciwko nim. clavitor.ai

Źródła

[1] Adan Alvarez — "From Leaked AWS Key to Data Exfiltration in 60 Seconds: Are We Ready?" (maj 2026) — https://medium.com/@adan.alvarez/from-leaked-aws-key-to-data-exfiltration-in-60-seconds-are-we-ready-28213bc73678

[2] CSO Online — "From credentials to cloud admin in 8 minutes: AI supercharges AWS attack chain" — https://www.csoonline.com/article/4126336/from-credentials-to-cloud-admin-in-8-minutes-ai-supercharges-aws-attack-chain.html

[3] Vectra AI — "AWS Compromised by AI Agents in Minutes" (Alex Groyz) — https://www.vectra.ai/blog/aws-compromised-by-ai-agents-in-minutes

[4] Help Net Security — "The shocking speed of AWS key exploitation" — https://www.helpnetsecurity.com/2024/12/02/revoke-exposed-aws-keys/