Przez lata dyskusja o bezpieczeństwie agentów AI toczyła się w jednym kierunku: jak ochronić agenta, którego wpuszczamy do naszych systemów. Przełom czerwca i lipca 2026 roku dopisał do niej drugą stronę. Agent AI pojawił się nie tylko jako coś, co chronimy - ale jako coś, co atakuje. I zrobił to sam, od początku do końca.
To nie jest artykuł o odległym zagrożeniu z laboratorium. To wydarzenia z ostatnich tygodni, które razem układają się w jeden obraz: samodzielny agent po stronie napastnika i cały landscape SAP z otwartymi drzwiami po stronie ofiary. Pokażemy oba i wyjaśnimy, co je łączy - oraz co z tym zrobić, zanim stanie się to Państwa problemem.
Akt pierwszy: agent, który przeprowadził atak samodzielnie
Firma bezpieczeństwa Sysdig opisała pierwszą udokumentowaną operację ransomware prowadzoną od początku do końca przez autonomicznego agenta AI. Nadano jej nazwę JADEPUFFER. Incydent potwierdziły niezależnie The Hacker News, The Register i SecurityWeek.
Przebieg jest tym, co czyni tę sprawę przełomową. Model językowy samodzielnie wykrył i wykorzystał lukę zdalnego wykonania kodu w Langflow - popularnej platformie do budowy aplikacji opartych na modelach AI (CVE-2025-3248 - brak uwierzytelnienia umożliwiający zdalne wykonanie kodu). Następnie, bez udziału człowieka, przeprowadził rozpoznanie środowiska, zebrał dane uwierzytelniające - klucze API i poświadczenia chmurowe - i przeszedł na kolejny, wystawiony do internetu serwer baz danych, wykorzystując m.in. znaną podatność w Nacos (CVE-2021-29441, obejście uwierzytelniania). Na koniec zaszyfrował bazy i zostawił żądanie okupu w bitcoinie.
Dwa szczegóły warto zapamiętać. Po pierwsze, klucz szyfrujący był efemeryczny - ofiara nie odzyska danych nawet po zapłacie okupu. Zniszczone zostały 1342 konfiguracje. Po drugie, cały łańcuch - od rozpoznania, przez eksploatację, ruch boczny, szyfrowanie, aż po wymuszenie - agent domknął autonomicznie.
Znaczenie tego incydentu nie leży w technicznej wyrafinowaności pojedynczego kroku. Każdy z osobna jest znany. Leży w tym, że zniknęło ograniczenie, które dotąd hamowało skalę ataków: liczba ludzi po stronie napastnika. Agent nie męczy się, nie śpi i można go zwielokrotnić. Poprzeczka obrony właśnie się podniosła dla wszystkich.
Akt drugi: pole bitwy nazywa się SAP
Autonomiczny napastnik potrzebuje jednego - otwartych drzwi. A te w czerwcu 2026 roku SAP dostarczył w całej serii, i to w samym rdzeniu zaufania systemu.
Czerwcowy cykl not bezpieczeństwa SAP był jednym z cięższych od miesięcy. Na szczycie listy znalazły się podatności dotykające fundamentów uwierzytelniania i komunikacji w landscape’ach opartych na NetWeaver:
- CVE-2026-44748 (CVSS 9.9) - podmiana podpisu XML w uwierzytelnianiu SAML na NetWeaver AS ABAP. Atakujący o niskich uprawnieniach przechwytuje poprawnie podpisany komunikat i podstawia zmodyfikowany dokument, podszywając się pod cudzą tożsamość. To pełne obejście uwierzytelniania, wymagające wgrania korekty na systemie ABAP.
- CVE-2026-27671 (CVSS 9.8) - uszkodzenie pamięci w protokole RFC. Nieuwierzytelniony atakujący wysyła spreparowany pakiet. Podatność nie ma obejścia - jedyną ochroną jest skoordynowane załatanie kernela w całym landscape.
- Directory traversal w NetWeaver AS Java (CVE-2026-40128), a do tego ogłoszone pod koniec 2025 roku cztery błędy lokalnej eskalacji uprawnień w parserze SAPCAR/SAR (badania Anvil Secure) - w narzędziu, którego administratorzy SAP używają codziennie.
- Oraz niedawny (maj 2026) atak na łańcuch dostaw w stacku deweloperskim SAP BTP - złośliwe pakiety npm w ekosystemie Cloud Application Programming Model (CVE-2026-46421).
Onapsis utrzymuje aktualną checklistę bezpieczeństwa SAP na 2026 rok, w której zarządzanie podatnościami zajmuje jedno z centralnych miejsc. Dostawcy wyspecjalizowanych rozwiązań - SecurityBridge, Pathlock - potwierdzili wagę cyklu.
Dlaczego łączymy to z JADEPUFFER? Bo w systemach SAP mieszkają dane finansowe, kadrowe i cały łańcuch dostaw przedsiębiorstwa - dokładnie ten cel, po który sięga zautomatyzowany napastnik. Niezałatany SAML czy RFC to nie abstrakcyjny wskaźnik ryzyka. To gotowe wejście. Agent-napastnik nie musi być geniuszem; musi tylko trafić na otwarte drzwi.
Ten sam mechanizm z trzeciej strony
Warto dodać kontekst, bo w tych samych tygodniach pojawiły się dwa kolejne odkrycia tej samej klasy - dwa różne wektory, które prowadzą do tego samego skutku. Badacze z Adversa AI (projekt GuardFall) pokazali, że filtr bezpieczeństwa sprawdzający surowy tekst polecenia daje się obejść, bo powłoka systemowa przepisuje to polecenie już po kontroli - agent uruchamia więc kod, którego filtr nigdy nie zobaczył. Tenet Security opisał z kolei technikę nazwaną Agentjacking: fałszywe zdarzenia i raporty błędów wstrzyknięte przez integrację MCP (zademonstrowane na przykładzie Sentry), które agent traktuje jak zaufane instrukcje - bez żadnego obchodzenia filtra powłoki. Powód jest w obu przypadkach strukturalny: agent nie odróżnia treści, którą czyta, od instrukcji, którą ma wykonać.
Wszystkie te wydarzenia mają jeden wspólny mianownik: autonomię bez granic. To, co czyni agenty użytecznymi w biznesie - samodzielność i dostęp do łańcucha narzędzi - czyni je groźnymi, gdy tej granicy nie ma. JADEPUFFER pokazuje to od strony napastnika. GuardFall i Agentjacking - od strony narzędzi, które sami wdrażamy. Kaskada CVE w SAP - od strony celu.
Agent na smyczy, nie agent bez smyczy
W poprzednim Bezpiecznym Wtorku pisaliśmy o wprowadzaniu AI do SAP bez sięgania po pełną autonomię modelu w warstwie wykonawczej. JADEPUFFER jest tego argumentu dopełnieniem: to obraz agenta bez żadnej smyczy. Nasza odpowiedź to agent na smyczy - i różnicą nie jest wybór lepszego modelu, bo model wymienimy w następnym cyklu. Różnicą jest architektura.
Najmniejsze uprawnienia na poziomie narzędzia, nie tekstu. Agent nie otrzymuje możliwości działań destrukcyjnych ani dostępu do danych spoza swojego zadania. W świecie SAP oznacza to konto techniczne o wąskim profilu autoryzacji, dobór typu konta do kanału komunikacji z rekomendacją podejścia API-first oraz żelazną zasadę: nigdy uprawnienie RFC z gwiazdką na wszystko. To klasyczny błąd, który zamienia jedno wejście w dostęp do całego systemu.
Człowiek w pętli jako brama, nie jako opcja. UiPath Maestro orkiestruje przebieg, a Action Center domyka kroki o skutkach nieodwracalnych. W produkcji nie stosujemy trybu automatycznego bez świadomej decyzji - to właśnie jego domyślne włączenie czyni ataki na agenty wykonalnymi.
Higiena patchowania SAP jako fundament, nie dodatek. Kaskada CVE pokazuje, że najlepiej zaprojektowany agent stoi na piasku, jeśli sam landscape ma otwarte drzwi. Ciągły monitoring i priorytetyzacja not bezpieczeństwa z pomocą SecurityBridge, skoordynowane patchowanie kernela tam, gdzie nie ma obejścia (RFC), oraz audyt zależności w projektach CAP na BTP - to warstwa, bez której reszta nie ma oparcia.
Każda treść z zewnątrz to niezaufany kod. Dokument klienta, e-mail, log, wynik narzędzia - traktujemy jak potencjalny ładunek, nie jak zaufaną instrukcję. Serwery, przez które agent pobiera dane, przechodzą weryfikację przed dopuszczeniem.
Filtr wzorców to telemetria, nie kontrola. Skoro można go obejść, informuje, ale nie chroni. Realna kontrola siedzi na uprawnieniach narzędzia i na bramie człowieka.
Testujemy odporność, a nie deklaracje. Sprawdzamy nie to, czy agent rozpozna próbę manipulacji w treści, lecz czy na poziomie wykonania jest w ogóle w stanie uruchomić destrukcyjne działanie - z użyciem zatrutych danych na wejściu, plików-kanarków i ewaluatorów, które weryfikują faktyczne wywołania agenta, a nie sam tekst jego odpowiedzi.
Dla porządku dodajmy kontekst regulacyjny. Odporność agentów i higiena bezpieczeństwa SAP wpisują się w wymogi NIS2, DORA i AI Act - przy czym są to ramy orientacyjne, a wiążącej interpretacji prawnej udziela człowiek, nie system.
Wniosek
JADEPUFFER i kaskada CVE w SAP to nie dwie osobne wiadomości. To awers i rewers jednej zmiany: agent AI wszedł do gry po obu stronach, a systemy, które chcemy chronić, są dokładnie tam, gdzie sięga zautomatyzowany napastnik. Odpowiedzią nie jest kolejna łatka ani lepszy model. Jest nią architektura, która nie zakłada dobrej woli - ani modelu, ani treści, którą on czyta.
Dlatego w rozmowach z klientami nie pytamy, czy dany agent jest bezpieczny. Pytamy, jak zaprojektować całość - uprawnienia, bramę człowieka, higienę patchowania i test, który to sprawdza - żeby była bezpieczna z założenia.
Za tydzień, 14 lipca, wraca SAP Security Patch Day - lipcowy cykl not. W drugiej części pokażemy, co realnie przyszło do załatania i jak spiąć to z ciągłym monitoringiem, żeby otwarte drzwi zamykały się szybciej, niż zdąży je znaleźć napastnik - człowiek czy agent.
Materiał ma charakter edukacyjny. Ocena ryzyka konkretnego wdrożenia oraz wiążąca interpretacja wymogów regulacyjnych wymagają przeglądu przez człowieka. Chętnie przeprowadzimy z Państwem przegląd bezpieczeństwa środowiska SAP oraz automatyzacji agentowej - zapraszamy do kontaktu.