Archiwa: LLM - Strona 5 z 11 - Security Bez Tabu

Krytyczne luki w guardrailach LLM ujawniają słabości filtrów bezpieczeństwa AI

Wprowadzenie do problemu / definicja

Guardraile dla dużych modeli językowych to mechanizmy bezpieczeństwa, które mają ograniczać generowanie niepożądanych odpowiedzi, wymuszać zgodność z politykami organizacji oraz blokować próby nadużyć. W praktyce stanowią one warstwę kontrolną pomiędzy użytkownikiem a modelem, analizując prompty i odpowiedzi przed ich zwróceniem lub wykonaniem.

Najnowsze ustalenia badaczy pokazują jednak, że wiele takich zabezpieczeń można obejść, jeśli opierają się na zbyt uproszczonej logice decyzyjnej. To istotny sygnał ostrzegawczy dla firm wdrażających generatywną AI w środowiskach produkcyjnych.

W skrócie

Badacze wskazali istotne luki w guardrailach stosowanych do ochrony modeli LLM. Problem dotyczy przede wszystkim rozwiązań, które sprowadzają decyzję bezpieczeństwa do prostego wyboru: dopuścić albo zablokować.

Jeżeli mechanizm działa blisko granicy decyzyjnej, nawet niewielkie zmiany w treści zapytania mogą przechylić wynik na korzyść odpowiedzi dozwolonej. W efekcie filtr bezpieczeństwa może zostać ominięty bez stosowania klasycznych, łatwo wykrywalnych jailbreaków.

Kontekst / historia

Wraz z rosnącą popularnością modeli generatywnych wzrosło znaczenie warstw bezpieczeństwa określanych jako AI guardrails. Początkowo pełniły one głównie funkcję filtrów treści, blokując odpowiedzi toksyczne, nielegalne lub niezgodne z regulaminem.

Z czasem ich rola rozszerzyła się o ochronę przed prompt injection, wyciekiem danych, obchodzeniem polityk użycia oraz generowaniem instrukcji mogących wspierać nadużycia. Równolegle rozwijały się techniki ataku, które coraz częściej koncentrują się nie na samej treści promptu, lecz na podatnościach logiki klasyfikacyjnej stojącej za decyzjami bezpieczeństwa.

To ważna zmiana perspektywy: problem nie dotyczy już wyłącznie niewłaściwego zapytania użytkownika, ale także architektury ochronnej, która może zostać zmanipulowana lub wprowadzona w stan niepewności.

Analiza techniczna

Opisywana klasa podatności dotyczy guardraili, które podejmują decyzję w modelu binarnym, na przykład „allow” albo „block”. Taki mechanizm opiera się zwykle na rozkładzie prawdopodobieństwa tokenów lub wewnętrznym wyniku klasyfikacyjnym określającym, czy odpowiedź powinna zostać przepuszczona.

Kluczowe znaczenie ma tu tzw. logit gap, czyli różnica pewności pomiędzy konkurencyjnymi decyzjami modelu. Jeśli różnica jest niewielka, guardrail znajduje się blisko granicy decyzyjnej. W takiej sytuacji drobna zmiana składni, semantyki lub struktury promptu może zmienić końcową decyzję systemu.

Z perspektywy atakującego oznacza to możliwość iteracyjnego dostrajania zapytania tak, aby ominąć filtr bez używania oczywistych technik jailbreaku. Tego typu ataki mogą być skuteczniejsze, ponieważ bazują na obserwacji słabości samego mechanizmu ochrony, a nie tylko na manipulacji stylem rozmowy.

Problem ma kilka warstw technicznych:

uproszczona klasyfikacja binarna słabiej radzi sobie z treściami granicznymi, wieloznacznymi i celowo maskowanymi;
guardraile działające jako oddzielny model dziedziczą ograniczenia modeli językowych, w tym podatność na manipulację promptem;
część rozwiązań analizuje wyłącznie końcowy tekst, pomijając intencję użytkownika, historię dialogu i ryzyko wykonania operacji przez agenta AI;
filtr treści nie zapewnia pełnej kontroli bezpieczeństwa, jeśli model ma dostęp do narzędzi, API, baz wiedzy lub systemów wykonawczych.

W praktyce obejście guardraila może skutkować nie tylko wygenerowaniem niedozwolonej odpowiedzi, lecz także uruchomieniem realnych działań operacyjnych w zintegrowanym środowisku.

Konsekwencje / ryzyko

Największym zagrożeniem jest fałszywe poczucie bezpieczeństwa. Organizacje mogą zakładać, że obecność guardraili wystarcza do ochrony aplikacji AI, podczas gdy w rzeczywistości jest to jedynie jedna z warstw obrony.

Jeżeli zabezpieczenie można obejść przez manipulację promptem lub wykorzystanie niepewności klasyfikatora, model może wygenerować treści zabronione, ujawnić dane wrażliwe albo wykonać niedozwolone operacje. W środowisku korporacyjnym może to prowadzić do naruszeń zgodności, wycieków informacji, obejścia kontroli dostępu oraz wykorzystania systemu AI jako punktu wejścia do kolejnych etapów ataku.

Ryzyko rośnie szczególnie tam, gdzie agenci AI są zintegrowani z narzędziami biznesowymi, repozytoriami kodu, dokumentami, systemami ticketowymi lub usługami chmurowymi. W takich przypadkach błędna decyzja guardraila może przełożyć się na realny skutek operacyjny, a nie tylko na wygenerowanie niepożądanego tekstu.

Rekomendacje

Organizacje wdrażające LLM powinny traktować guardraile jako element obrony warstwowej, a nie jako samodzielne rozwiązanie bezpieczeństwa. Skuteczna ochrona wymaga połączenia filtrów AI z klasycznymi mechanizmami AppSec, kontrolą uprawnień i monitoringiem działań modeli.

stosować wielowarstwową walidację wejścia i wyjścia zamiast polegać na pojedynczym klasyfikatorze „allow/block”;
monitorować przypadki graniczne i odpowiedzi o niskiej pewności decyzyjnej;
prowadzić regularny red teaming oraz testy jailbreaków, w tym scenariusze iteracyjne i wieloetapowe;
ograniczać uprawnienia modeli i agentów zgodnie z zasadą najmniejszych uprawnień;
oddzielać generowanie treści od wykonywania operacji wysokiego ryzyka dodatkowymi warstwami zatwierdzania;
wdrażać pełne logowanie zdarzeń, telemetrię bezpieczeństwa i detekcję anomalii;
stosować DLP, kontrolę dostępu i klasyczne zabezpieczenia aplikacyjne wokół komponentów AI;
uwzględniać bezpieczeństwo guardraili w cyklu SDLC oraz wykonywać testy regresji po aktualizacjach modeli i polityk.

Istotne jest także testowanie skuteczności guardraili w realistycznych warunkach, obejmujących treści zmaskowane, wielojęzyczne, rozproszone semantycznie i osadzone w długim kontekście. To właśnie takie scenariusze najczęściej ujawniają słabe punkty ochrony.

Podsumowanie

Nowe ustalenia dotyczące luk w guardrailach LLM pokazują, że bezpieczeństwo generatywnej AI pozostaje problemem otwartym. Mechanizmy oparte na uproszczonym rozstrzyganiu „zezwól” lub „zablokuj” mogą być podatne na obejście, zwłaszcza gdy działają blisko granicy decyzyjnej i nie uwzględniają pełnego kontekstu ryzyka.

Dla zespołów bezpieczeństwa to wyraźny sygnał, że guardraile nie powinny być traktowane jako gwarancja odporności systemu. Skuteczna obrona wymaga architektury wielowarstwowej, łączącej testy ofensywne, ograniczanie uprawnień, monitoring oraz tradycyjne mechanizmy bezpieczeństwa aplikacyjnego z zabezpieczeniami specyficznymi dla AI.

Źródła

https://www.infosecurity-magazine.com/news/major-security-gaps-llm-guardrails/
https://arxiv.org/abs/2601.21380
https://arxiv.org/abs/2506.10597

OpenAI przejmuje Promptfoo. Bezpieczeństwo LLM i agentów AI wchodzi do głównego nurtu

Wprowadzenie do problemu / definicja

Bezpieczeństwo systemów opartych na dużych modelach językowych i agentach AI staje się jednym z najważniejszych obszarów współczesnego AppSec. Wraz z rosnącą liczbą wdrożeń generatywnej sztucznej inteligencji w środowiskach produkcyjnych firmy muszą mierzyć się z nową klasą zagrożeń, takich jak prompt injection, jailbreaki, wycieki danych czy błędy w orkiestracji agentów.

Planowane przejęcie Promptfoo przez OpenAI pokazuje, że ochrona warstwy AI przestaje być niszowym dodatkiem do procesu wytwarzania oprogramowania. Coraz wyraźniej staje się elementem bazowej architektury bezpieczeństwa dla nowoczesnych aplikacji biznesowych.

W skrócie

OpenAI rozpoczęło proces przejęcia Promptfoo, firmy rozwijającej platformę do testowania, oceny i zabezpieczania aplikacji wykorzystujących LLM oraz agentów AI. Rozwiązania Promptfoo pozwalają symulować ataki, automatyzować testy bezpieczeństwa oraz integrować kontrole z istniejącymi procesami deweloperskimi.

Po finalizacji transakcji możliwości tej platformy mają zostać włączone do usługi Frontier wykorzystywanej przez przedsiębiorstwa do budowy i obsługi rozwiązań AI. Jednocześnie rozwijany ma być także otwartoźródłowy CLI oraz biblioteka Promptfoo.

Kontekst / historia

Rynek bezpieczeństwa AI dojrzewa bardzo szybko. Na początku organizacje skupiały się głównie na jakości odpowiedzi modeli, kosztach inferencji i wydajności. Z czasem stało się jednak jasne, że wykorzystanie LLM w produkcji wymaga równie rygorystycznych praktyk bezpieczeństwa jak aplikacje webowe, API czy środowiska chmurowe.

Promptfoo zbudowało swoją pozycję na styku inżynierii jakości i bezpieczeństwa modeli. Firma rozwijała narzędzia umożliwiające zespołom systematyczne testowanie zachowania aplikacji AI w obecności złośliwych danych wejściowych oraz niepożądanych scenariuszy użycia. To podejście wpisuje się w rosnący trend przesuwania kontroli bezpieczeństwa na wcześniejsze etapy cyklu życia oprogramowania, tym razem rozszerzonego o komponenty generatywne.

Znaczenie tej transakcji wykracza poza sam aspekt biznesowy. To również sygnał, że dostawcy platform AI chcą integrować mechanizmy red teamingu, walidacji i śledzenia ryzyka bezpośrednio w swoich ekosystemach, zamiast traktować je wyłącznie jako zewnętrzne narzędzia pomocnicze.

Analiza techniczna

Z technicznego punktu widzenia kluczowa jest specjalizacja Promptfoo w obszarze systematycznego testowania aplikacji LLM i agentów AI. Platforma umożliwia uruchamianie scenariuszy ataków adversarialnych bezpośrednio w pipeline’ach developerskich, co zbliża testowanie AI do standardów znanych z nowoczesnego DevSecOps.

testy prompt injection, w których złośliwe dane wejściowe próbują nadpisać instrukcje systemowe lub wpłynąć na logikę działania aplikacji,
testy jailbreaków służące ocenie odporności modelu na obchodzenie polityk bezpieczeństwa,
wykrywanie ryzyka ujawnienia danych wrażliwych przekazanych w kontekście lub pobranych z narzędzi pomocniczych,
analizę zachowania agentów AI korzystających z zewnętrznych integracji, narzędzi i pamięci kontekstowej.

To istotna zmiana względem klasycznego testowania funkcjonalnego. W przypadku aplikacji AI nie wystarcza sprawdzenie poprawności odpowiedzi dla ograniczonego zestawu znanych przypadków. Potrzebne są testy odpornościowe, które mierzą zachowanie systemu przy wrogich, niejednoznacznych lub manipulacyjnych wejściach.

Integracja z platformą Frontier sugeruje trzy praktyczne kierunki rozwoju: automatyzację red teamingu dla aplikacji AI, osadzenie testów bezpieczeństwa bezpośrednio w SDLC oraz rozwój raportowania i traceability. W praktyce oznacza to większą zdolność do wskazania, które prompty, polityki, konfiguracje i komponenty odpowiadają za konkretne ryzyko lub wynik testu.

Konsekwencje / ryzyko

Najważniejszą konsekwencją przejęcia jest dalsza profesjonalizacja rynku AI security. Narzędzia do testowania bezpieczeństwa modeli mogą stać się częścią standardowego stosu technologicznego organizacji tworzących aplikacje z użyciem LLM. To zwiększa szansę, że testy prompt injection, ocena wycieków danych i walidacja agentów będą wykonywane równie rutynowo jak skanowanie zależności, SAST czy DAST.

Jednocześnie rośnie świadomość, że podatności w systemach AI nie ograniczają się wyłącznie do samego modelu. Ryzyko pojawia się także w warstwie integracji, w konektorach do danych, wywołaniach narzędzi, politykach systemowych, pamięci sesyjnej i komponentach wykonawczych agentów. W takich architekturach pojedynczy błąd walidacji lub źle zaprojektowane uprawnienia mogą znacząco zwiększyć skalę incydentu.

konieczność definiowania własnych scenariuszy zagrożeń dla aplikacji AI,
potrzeba ciągłego testowania po każdej zmianie promptów, konfiguracji i integracji,
większe wymagania dotyczące logowania, śledzenia decyzji i forensiki,
presja na wdrożenie mierzalnych kontroli bezpieczeństwa przed uruchomieniem agentów w produkcji.

Warto podkreślić, że pojedyncze narzędzie nie eliminuje ryzyka. Platformy testowe poprawiają wykrywalność problemów, ale nie zastępują bezpiecznego projektowania, segmentacji uprawnień, kontroli dostępu do danych ani zasady najmniejszych uprawnień dla agentów i narzędzi.

Rekomendacje

Organizacje rozwijające rozwiązania oparte na LLM i agentach AI powinny potraktować ten ruch jako potwierdzenie, że bezpieczeństwo AI wymaga odrębnych, wyspecjalizowanych procesów. W praktyce warto wdrożyć kilka kluczowych działań.

włączyć testy bezpieczeństwa AI do CI/CD i uruchamiać je przy zmianach promptów, modeli, narzędzi i polityk systemowych,
budować własne zestawy przypadków adversarialnych dopasowanych do konkretnej aplikacji i jej domeny danych,
rozdzielać uprawnienia agentów od logiki konwersacyjnej oraz ograniczać dostęp do systemów biznesowych,
wprowadzić pełną obserwowalność działania systemu AI, obejmującą wejścia, wyjścia, wywołania narzędzi i decyzje orkiestratora,
łączyć ocenę jakości modelu z oceną ryzyka i traktować bezpieczeństwo jako osobną bramkę dopuszczenia do produkcji,
utrzymywać ciągły proces red teamingu, ponieważ aktualizacje modeli i integracji mogą otwierać nowe ścieżki ataku.

Podsumowanie

Planowane przejęcie Promptfoo przez OpenAI to ważny sygnał dla rynku cyberbezpieczeństwa i inżynierii oprogramowania. Bezpieczeństwo LLM oraz agentów AI staje się integralną częścią platform enterprise, a nie dodatkiem realizowanym wyłącznie przez zewnętrzne zespoły bezpieczeństwa.

W praktyce oznacza to dalsze upowszechnienie automatycznego testowania odporności modeli, integrację red teamingu z procesem deweloperskim oraz większy nacisk na raportowanie i śledzalność ryzyka. Dla organizacji korzystających z AI najważniejszy wniosek jest prosty: wdrożenie modelu do produkcji bez ciągłej walidacji bezpieczeństwa staje się coraz trudniejsze do uzasadnienia.

Źródła

OpenAI to Acquire AI Security Startup Promptfoo — https://www.securityweek.com/openai-to-acquire-ai-security-startup-promptfoo/
Promptfoo Documentation — https://www.promptfoo.dev/docs/
OWASP Top 10 for LLM Applications — https://genai.owasp.org/
Promptfoo GitHub Repository — https://github.com/promptfoo/promptfoo

Mend.io uruchamia System Prompt Hardening, by ograniczyć ryzyko prompt injection w aplikacjach AI

Wprowadzenie do problemu

System prompt, czyli ukryty zestaw instrukcji sterujących zachowaniem modelu AI, staje się jednym z najważniejszych elementów bezpieczeństwa nowoczesnych aplikacji opartych na dużych modelach językowych. To właśnie w tej warstwie definiowane są reguły działania modelu, ograniczenia odpowiedzi, priorytety wykonania poleceń oraz zasady korzystania z danych i narzędzi.

Jeżeli prompt systemowy jest nieprecyzyjny, sprzeczny lub zbyt ufny wobec danych wejściowych, może stać się słabym punktem całej aplikacji. W praktyce otwiera to drogę do ataków prompt injection, obchodzenia polityk bezpieczeństwa i niezamierzonego ujawnienia informacji.

W skrócie

Mend.io zaprezentowało funkcję System Prompt Hardening w ramach platformy Mend AI. Rozwiązanie ma wykrywać słabości w promptach systemowych, przypisywać im ocenę ryzyka oraz automatycznie proponować działania naprawcze jeszcze przed wdrożeniem aplikacji do środowiska produkcyjnego.

Producent wskazuje, że mechanizm wykorzystuje własny model klasyfikacji i punktacji AI Weakness Enumeration. Celem jest uporządkowanie ryzyka związanego z ukrytymi instrukcjami sterującymi oraz włączenie tej warstwy do bardziej sformalizowanych procesów AppSec.

Kontekst i historia

W klasycznym podejściu do bezpieczeństwa aplikacji organizacje skupiały się głównie na analizie kodu, zależności, konfiguracji oraz podatności infrastrukturalnych. Rozwój rozwiązań GenAI sprawił jednak, że pojawiła się nowa powierzchnia ataku: logika sterująca modelem, zapisana w promptach systemowych i deweloperskich.

Przez długi czas zabezpieczanie tej warstwy opierało się przede wszystkim na ręcznym red-teamingu, eksperymentach prompt engineeringowych i testach ad hoc. Takie podejście trudno jednak skalować w firmach rozwijających wiele aplikacji AI jednocześnie, szczególnie gdy prompty są często modyfikowane i wdrażane w szybkim cyklu zmian.

Równolegle inicjatywy branżowe coraz mocniej podkreślają znaczenie prompt injection jako jednej z kluczowych klas zagrożeń dla systemów LLM. To powoduje, że prompty przestają być traktowane wyłącznie jako element konfiguracji, a zaczynają być postrzegane jako aktywa bezpieczeństwa wymagające przeglądu i kontroli.

Analiza techniczna

System Prompt Hardening ma zapewniać widoczność ukrytych instrukcji systemowych, identyfikować ich słabe punkty i wzmacniać logikę promptu przed wdrożeniem. Z technicznego punktu widzenia oznacza to potraktowanie promptu jako artefaktu bezpieczeństwa, który można analizować podobnie jak kod źródłowy lub polityki konfiguracyjne.

Według zapowiedzi rozwiązanie realizuje trzy główne zadania. Po pierwsze, wykrywa i kontekstowo etykietuje prompt systemowy, określając jego funkcję oraz potencjalne wektory ataku. Po drugie, przypisuje mu wynik ryzyka w skali od 1 do 100 na podstawie modelu AI Weakness Enumeration. Po trzecie, automatycznie sugeruje zmiany w logice promptu, które mają ograniczać ryzyko manipulacji zachowaniem modelu, wycieku danych oraz skutecznych prób prompt injection.

To istotne, ponieważ prompt systemowy nierzadko zawiera reguły autoryzacyjne, ograniczenia dotyczące ujawniania treści, instrukcje użycia narzędzi oraz dodatkowe informacje operacyjne. Jeżeli taka warstwa jest źle zaprojektowana, model może potraktować złośliwe dane wejściowe jako ważniejsze niż zasady bazowe, co prowadzi do naruszenia założeń bezpieczeństwa aplikacji.

Warto jednak podkreślić, że samo utwardzanie promptu nie rozwiązuje całego problemu. Prompt injection nie wynika wyłącznie z błędów w treści instrukcji, lecz także z architektury systemów generatywnych, w których dane i polecenia nie są rozdzielone w sposób znany z tradycyjnych systemów wykonawczych. Dlatego analiza promptów powinna być częścią wielowarstwowego modelu ochrony.

Konsekwencje i ryzyko

Słabe prompty systemowe zwiększają skuteczność ataków, których celem jest manipulowanie zachowaniem modelu. W zależności od architektury aplikacji może to prowadzić do ujawnienia treści promptu, wygenerowania nieautoryzowanych odpowiedzi, obejścia ograniczeń bezpieczeństwa lub wycieku danych przetwarzanych przez model.

Ryzyko rośnie szczególnie tam, gdzie model ma dostęp do narzędzi, dokumentów wewnętrznych, repozytoriów kodu, systemów ticketowych lub danych klientów. W takich środowiskach prompt injection może przekształcić się z pojedynczego błędu odpowiedzi w punkt wejścia do poważniejszego incydentu obejmującego poufność, integralność i zgodność regulacyjną.

Problem ma także wymiar organizacyjny. Jeżeli prompt systemowy nie jest objęty procesem wersjonowania, przeglądu i testowania, zespoły DevSecOps mogą wdrażać zmiany bez formalnej oceny wpływu na bezpieczeństwo. To zwiększa prawdopodobieństwo, że do produkcji trafią niezweryfikowane instrukcje sterujące działaniem modelu.

Rekomendacje

Organizacje wdrażające aplikacje AI powinny traktować prompty systemowe jak krytyczne artefakty bezpieczeństwa. Oznacza to konieczność objęcia ich kontrolą wersji, recenzją zmian, testami bezpieczeństwa oraz monitoringiem zachowania modeli po wdrożeniu.

oddzielać instrukcje systemowe od danych użytkownika i ograniczać zaufanie do wejścia zewnętrznego,
nie umieszczać w promptach informacji wrażliwych, sekretów ani logiki autoryzacyjnej, która powinna być egzekwowana poza modelem,
zakładać, że prompt injection może wystąpić mimo zastosowanych zabezpieczeń,
prowadzić testy red-teamowe obejmujące zarówno bezpośrednie, jak i pośrednie scenariusze ataku,
monitorować odpowiedzi modeli pod kątem ujawniania promptów, naruszeń polityk i nietypowego użycia narzędzi,
stosować warstwowe kontrole bezpieczeństwa, takie jak minimalne uprawnienia, walidacja wywołań narzędzi, sandboxing i kontrola przepływu danych,
korzystać z automatycznych narzędzi do oceny promptów tam, gdzie ręczny przegląd przestaje być skalowalny.

Dla zespołów bezpieczeństwa istotne może być również budowanie własnych metryk ryzyka dla komponentów AI. Formalne punktowanie słabości promptów ułatwia porównywanie aplikacji, ustalanie priorytetów i włączenie bezpieczeństwa GenAI do istniejących procesów AppSec oraz SDLC.

Podsumowanie

Wprowadzenie System Prompt Hardening przez Mend.io pokazuje, że bezpieczeństwo warstwy instrukcji w aplikacjach AI dojrzewa do rangi osobnej domeny AppSec. Zamiast polegać wyłącznie na ręcznych testach i dobrych praktykach prompt engineeringu, rynek zaczyna otrzymywać bardziej sformalizowane mechanizmy wykrywania, klasyfikowania i ograniczania ryzyka.

To ważny sygnał dla organizacji rozwijających rozwiązania GenAI. Prompt systemowy przestaje być jedynie technicznym dodatkiem do modelu, a staje się zasobem bezpieczeństwa, który wymaga nadzoru, pomiaru i ciągłego utwardzania.

Źródła

OpenAI przejmie Promptfoo i wzmocni bezpieczeństwo agentów AI w platformie Frontier

Wprowadzenie do problemu / definicja

Bezpieczeństwo aplikacji opartych na dużych modelach językowych oraz agentach AI staje się jednym z najważniejszych obszarów współczesnego cyberbezpieczeństwa. Wraz ze wzrostem wykorzystania agentów do automatyzacji procesów biznesowych rośnie również powierzchnia ataku, obejmująca m.in. prompt injection, jailbreaki, wycieki danych, nadużycie narzędzi oraz działania niezgodne z politykami organizacji.

Planowane przejęcie Promptfoo przez OpenAI należy postrzegać jako strategiczny krok w kierunku natywnego osadzenia testów bezpieczeństwa, red teamingu i mechanizmów kontroli ryzyka bezpośrednio w platformie do budowy oraz obsługi agentów AI.

W skrócie

OpenAI zapowiedziało przejęcie Promptfoo, platformy bezpieczeństwa AI służącej do wykrywania i eliminowania podatności w systemach wykorzystujących LLM. Po zamknięciu transakcji rozwiązania Promptfoo mają zostać zintegrowane z OpenAI Frontier, czyli platformą enterprise do projektowania, wdrażania i zarządzania agentami AI.

Integracja ma objąć automatyczne testy bezpieczeństwa agentów.
Kluczową rolę odegra natywny red teaming i ocena odporności systemów.
Rozbudowane mają zostać funkcje raportowania, audytu i śledzenia zmian.
Platforma ma wspierać zgodność, governance oraz nadzór nad zachowaniem agentów.

Kontekst / historia

Rynek bezpieczeństwa AI rozwija się równolegle z dojrzewaniem wdrożeń generatywnej sztucznej inteligencji w przedsiębiorstwach. Na wczesnym etapie organizacje koncentrowały się głównie na jakości odpowiedzi modeli i skuteczności promptów. W praktyce szybko okazało się jednak, że środowiska produkcyjne wymagają znacznie bardziej rygorystycznego podejścia do testowania zachowań agentów, kontroli dostępu do narzędzi, odporności na manipulację wejściem oraz dokumentowania decyzji podejmowanych przez systemy AI.

Promptfoo zdobyło rozpoznawalność jako narzędzie open source i platforma komercyjna do ewaluacji oraz red teamingu aplikacji LLM. Rozwiązanie jest cenione za integrację z pipeline’ami CI/CD oraz możliwość testowania aplikacji przez API, przeglądarkę lub bezpośrednio na poziomie modelu. OpenAI z kolei rozwija Frontier jako platformę enterprise skoncentrowaną na kontroli, obserwowalności i zarządzaniu agentami AI. Połączenie tych kierunków wskazuje, że bezpieczeństwo agentowe staje się warstwą bazową architektury, a nie dodatkiem wdrażanym na końcu projektu.

Analiza techniczna

Z technicznego punktu widzenia najważniejszym skutkiem przejęcia może być przeniesienie zdolności testowych Promptfoo bezpośrednio do warstwy platformowej. Oznacza to odejście od modelu, w którym organizacja samodzielnie składa zestaw narzędzi do ewaluacji, testów bezpieczeństwa i raportowania, na rzecz zintegrowanego środowiska, gdzie kontrola ryzyka jest częścią procesu wytwórczego.

Promptfoo specjalizuje się w testowaniu zagrożeń typowych dla aplikacji generatywnej AI i agentów. Obejmuje to nie tylko klasyczne błędy logiki, ale również scenariusze specyficzne dla LLM i systemów agentowych:

prompt injection, czyli wymuszanie zmiany instrukcji wykonywanych przez model lub agenta,
jailbreaki prowadzące do obchodzenia ograniczeń bezpieczeństwa,
wyciek danych i nadmierne ujawnianie informacji,
zatruwanie kontekstu w architekturach RAG,
niewłaściwe użycie narzędzi przez agenta,
naruszenia polityk wewnętrznych, regulacyjnych i zgodnościowych.

W przypadku agentów AI analiza bezpieczeństwa nie może ograniczać się do statycznego skanowania. Konieczne jest badanie zachowania systemu podczas wykonywania zadań, uwzględniające interakcje wieloetapowe, pamięć kontekstową, stan sesji, dostęp do zewnętrznych narzędzi oraz ścieżkę decyzyjną modelu. Integracja z Frontier sugeruje, że ocena ryzyka może być prowadzona zarówno przed wdrożeniem, jak i w trakcie pracy systemu produkcyjnego.

Technicznie szczególnie istotne są trzy obszary: automatyzacja red teamingu jako funkcji natywnej, włączenie wyników ewaluacji do workflow deweloperskich oraz rozbudowa warstwy audytowej i śledzenia zmian. Dla środowisk enterprise oznacza to większą powtarzalność testów, lepszą widoczność słabości i łatwiejsze wykazywanie zgodności z wymaganiami governance, risk and compliance.

Konsekwencje / ryzyko

Dla rynku jest to sygnał dalszej profesjonalizacji zabezpieczeń wokół GenAI. Przedsiębiorstwa wdrażające agentów AI otrzymują wyraźny komunikat, że bezpieczeństwo takich systemów nie może być traktowane jako etap końcowy ani jako proces manualny. Musi ono obejmować cały cykl życia rozwiązania: od projektowania, przez testy, po monitoring i audyt.

Ryzyko adresowane przez tę integrację jest wielowarstwowe. Agent mający dostęp do dokumentów, systemów ERP, CRM lub narzędzi komunikacyjnych może stać się źródłem incydentu o dużej skali, jeśli błędnie zinterpretuje polecenie, wykona operację poza zakresem uprawnień albo ujawni dane z kontekstu. Szczególnie niebezpieczne są scenariusze, w których złośliwa treść trafia do źródła danych, dokumentu lub kanału komunikacji i następnie wpływa na decyzje agenta.

Z perspektywy zespołów bezpieczeństwa rośnie także znaczenie dowodów należytej staranności. Organizacje będą coraz częściej musiały wykazywać, że testują agentów AI pod kątem nadużyć, dokumentują wyniki, wdrażają poprawki i kontrolują wpływ zmian modeli, promptów oraz integracji narzędziowych na profil ryzyka.

Rekomendacje

Organizacje rozwijające lub wdrażające agentów AI powinny potraktować tę zapowiedź jako impuls do uporządkowania własnego programu AI security. W praktyce warto wdrożyć kilka kluczowych działań operacyjnych:

włączyć testy bezpieczeństwa LLM i agentów do pipeline’ów CI/CD,
regularnie prowadzić red teaming obejmujący prompt injection, jailbreaki, eksfiltrację danych i nadużycie narzędzi,
ograniczać uprawnienia agentów zgodnie z zasadą najmniejszych uprawnień,
stosować separację kontekstu, walidację wejścia i kontrolę źródeł danych używanych przez RAG,
wdrożyć szczegółowe logowanie działań agentów oraz mechanizmy audytowe,
dokumentować wyniki testów, zmiany konfiguracji i decyzje dotyczące akceptacji ryzyka,
łączyć kontrole bezpieczeństwa z politykami compliance, governance i zarządzaniem dostępem,
traktować modele, prompty, narzędzia i konektory jako elementy jednej powierzchni ataku.

Dla zespołów blue team i AppSec oznacza to konieczność rozszerzenia modeli zagrożeń o komponenty agentowe. Warto budować scenariusze testowe oparte na rzeczywistych przepływach biznesowych, a nie wyłącznie na pojedynczych promptach. Szczególną uwagę należy poświęcić integracjom z systemami transakcyjnymi, repozytoriami wiedzy oraz zewnętrznymi API.

Podsumowanie

Planowane przejęcie Promptfoo przez OpenAI pokazuje, że bezpieczeństwo agentów AI staje się integralnym elementem platform enterprise. Integracja testów bezpieczeństwa, red teamingu, obserwowalności i mechanizmów zgodności bezpośrednio w OpenAI Frontier może przyspieszyć dojrzewanie standardów ochrony dla systemów opartych na LLM.

Dla organizacji to wyraźny sygnał, że skuteczne wdrażanie AI wymaga nie tylko wydajnych modeli i użytecznych workflow, ale również systematycznej, mierzalnej i zautomatyzowanej kontroli ryzyka. Wraz z rozwojem agentów AI przewagę będą zyskiwać te podmioty, które potraktują bezpieczeństwo jako fundament architektury, a nie jako warstwę dodaną po wdrożeniu.

Źródła

https://www.helpnetsecurity.com/2026/03/09/openai-to-acquire-ai-security-platform-promptfoo/
https://openai.com/business/frontier/
https://openai.com/index/introducing-openai-frontier/
https://www.promptfoo.dev/docs/red-team/quickstart/
https://github.com/promptfoo/promptfoo

AI jako „tradecraft”: jak cyberprzestępcy i APT operacjonalizują sztuczną inteligencję

Wprowadzenie do problemu / definicja luki

Microsoft w najnowszej analizie opisuje przejście od „AI jako ciekawostki” do AI jako elementu rzemiosła operacyjnego (tradecraft) – czyli wpięcia modeli i narzędzi AI w codzienny łańcuch działań atakującego: od rekonesansu, przez socjotechnikę i budowę infrastruktury, po rozwój malware i działania po kompromitacji. Kluczowa obserwacja: AI bywa używana zarówno jako akcelerator (przyspiesza znane TTP), jak i jako broń (umożliwia nowe wektory, np. omijanie zabezpieczeń modeli czy półautonomiczne „agentowe” workflow).

W skrócie

Atakujący używają AI do redukcji tarcia (mniej umiejętności → podobny efekt), zwiększenia skali (więcej prób/operacji) i podniesienia wiarygodności (lepszy język, deepfake, dopasowane persony).
Microsoft opisuje realne nadużycia m.in. w kampaniach północnokoreańskich „remote IT workers”, gdzie AI wspiera fabrykację tożsamości, rozmowy rekrutacyjne, utrzymanie zatrudnienia i nadużycie legalnego dostępu.
Widać sygnały przejścia w kierunku agentic AI (działania celowe w czasie, z użyciem narzędzi), choć na razie ograniczane przez niezawodność i ryzyko operacyjne.

Kontekst / historia / powiązania

Wątek „AI w rękach przeciwnika” nie jest już wyłącznie domeną phishingu. Raport Google Threat Intelligence Group opisuje, że państwowe grupy APT traktują LLM-y jako narzędzie do researchu, targetingu i szybkiego generowania treści socjotechnicznych (często w wielu językach), co skraca cykl przygotowania kampanii.
Z drugiej strony Cloudflare wskazuje, że GenAI pomaga automatyzować działania o wysokiej przepustowości (m.in. rozpoznanie, tworzenie deepfake, przyspieszenie prac nad exploitami) i obniża próg wejścia dla mniej doświadczonych aktorów.
W tle mamy też rosnącą potrzebę „mapowania” zagrożeń na poziomie taksonomii: MITRE ATLAS porządkuje TTP wymierzone w systemy AI/ML (od manipulacji wejściem po eksfiltrację i nadużycia pipeline’ów).

Analiza techniczna / szczegóły

Poniżej najważniejsze obszary, w których Microsoft obserwuje operacyjne użycie AI.

1) Omijanie zabezpieczeń modeli (jailbreak / nadużycia promptów)

Atakujący testują techniki „role-based jailbreak”: wymuszanie na modelu przyjęcia zaufanej roli („odpowiedz jak analityk bezpieczeństwa”) albo budowanie kontekstu legalności, aby uzyskać bardziej wrażliwe instrukcje. Microsoft opisuje też łańcuchowanie poleceń i podszywanie się pod „system/developer prompts”.

2) Rekonesans i research podatności

LLM-y są wykorzystywane jako asystent do analizy publicznych podatności i ścieżek eksploatacji. Microsoft podaje przykład obserwacji (we współpracy z OpenAI), gdzie aktor „Emerald Sleet” używał LLM do researchu CVE (m.in. CVE-2022-30190/MSDT).

3) Budowa zasobów: persony, infrastruktura, domeny

W scenariuszu „remote IT workers” (Jasper Sleet) AI wspiera:

generowanie list imion/nazwisk i formatów adresów e-mail dopasowanych kulturowo,
analizę ogłoszeń o pracę i ekstrakcję wymaganych umiejętności,
dopasowanie CV/persony do konkretnej roli.

Po stronie infrastruktury Microsoft opisuje m.in. automatyzację tworzenia domen look-alike (z użyciem podejść GAN) oraz projektowanie/konfigurację tuneli, reverse proxy, VPN, z naciskiem na skalowanie i odporność.

4) Socjotechnika i „high-trust” impersonation

AI wzmacnia phishing i podszycia poprzez generowanie treści, ale też media: Microsoft wskazuje użycie Faceswap do podmiany twarzy w dokumentach i zdjęciach do CV oraz oprogramowania do zmiany głosu w rozmowach rekrutacyjnych.

5) Rozwój malware i „ślady” kodu tworzonego z AI

W aktywności Coral Sleet Microsoft zauważa szybki wzrost możliwości dzięki AI-asystowanemu iteracyjnemu programowaniu: generowanie, poprawianie i reimplementacja komponentów malware, a nawet end-to-end workflow (lure → fałszywe strony → infrastruktura → testy → wdrożenie).

Ciekawy element obrony: Microsoft wymienia heurystyki „AI-assisted code”, np. emoji jako markery (✅/❌), konwersacyjne komentarze inline oraz „przegadane” nazewnictwo funkcji/zmiennych czy nadmierną modularność.

6) Post-compromise: analiza środowiska, selekcja danych, wymuszenia

Po kompromitacji AI działa jako przyspieszacz: streszcza logi/konfiguracje, pomaga rozpoznać „co tu jest cenne” (DC, bazy, konta uprzywilejowane), a także wspiera etap eksfiltracji i monetyzacji (kategoryzacja danych, przygotowanie komunikacji wymuszeniowej).

7) Trend: agentic AI (jeszcze nie masowo)

Microsoft widzi pierwsze sygnały użycia agentów (planowanie kroków, używanie narzędzi, adaptacja bez ciągłego promptowania), ale podkreśla, że skala jest nadal ograniczona przez niezawodność i ryzyko.

Praktyczne konsekwencje / ryzyko

Większa przepustowość ataków: krótszy czas przygotowania kampanii i szybsze iteracje „co działa”.
Wyższa wiarygodność: lepszy język, dopasowanie kulturowe, deepfake wideo/voice → mniej „czerwonych flag” dla człowieka.
„Insider risk” przez legalny dostęp: wątek remote IT workers przesuwa ciężar obrony z klasycznego „włamania” na wykrywanie nadużyć zaufanych kont i długotrwałej, niskoszumowej aktywności.
Nowa powierzchnia ataku w aplikacjach AI: prompt injection/jailbreak i ryzyka łańcucha danych (training/inference) – to obszar, który wymaga osobnych kontroli i monitoringu.

Rekomendacje operacyjne / co zrobić teraz

A) Jeśli obawiasz się „AI-wzmocnionej” socjotechniki i przejęć kont

Egzekwuj MFA wszędzie, bez wyjątków; monitoruj anomalie logowań (np. „impossible travel”).
Przenieś detekcję z „języka maila” na sygnały behawioralne i infrastrukturę dostarczenia (linki, wzorce wysyłki, kontekst).

B) Jeśli ryzykiem są „remote IT workers” i nadużycie legalnego dostępu

Traktuj to jak scenariusz insider threat: telemetryka użycia danych, nietypowe dostępy, długotrwałe „low and slow”.
W procesach HR/IT: wideo-weryfikacja, kontrola spójności tożsamości, analiza artefaktów deepfake (spójność temporalna, okluzje, synchronizacja audio-wideo). Microsoft sugeruje też użycie narzędzi do analizy obrazów, np. FaceForensics++.

C) Jeśli budujesz lub wdrażasz aplikacje oparte o LLM

Wprowadź ochronę przed atakami na prompty (np. detekcja prompt injection / indirect attacks) oraz kontrolę „groundedness”, aby ograniczać halucynacje i odpowiedzi „oderwane” od źródeł.
Zabezpieczaj dane używane do trenowania i działania AI zgodnie z dobrymi praktykami ochrony danych (integralność, kontrola dostępu, minimalizacja).
Użyj MITRE ATLAS jako „checklisty TTP” do threat modelingu systemów AI/ML (mapowanie technik ataku → kontrolki → testy).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Microsoft mocno akcentuje „AI wpięte w łańcuch operacji” i daje przykłady z działań realnych aktorów (Jasper Sleet, Coral Sleet) – od rekrutacji po malware i nadużycia po kompromitacji.
Google GTIG kładzie nacisk na to, że grupy państwowe wykorzystują LLM-y jako narzędzie do researchu, targetingu i tworzenia treści socjotechnicznych szybciej i na większą skalę.
Cloudflare opisuje „industrializację” zagrożeń: automatyzację, deepfake, przyspieszenie działań ofensywnych i spadek progu wejścia dla mniej doświadczonych aktorów.

Podsumowanie / kluczowe wnioski

AI nie musi tworzyć „nowych cudownych ataków”, żeby zmienić sytuację obrońców – wystarczy, że przyspiesza i skaluje stare, sprawdzone TTP.
Najbardziej niedoceniane ryzyko to nadużycie zaufanego dostępu (insider-like) i wzrost jakości podszyć (voice/deepfake/persony).
Organizacje powinny równolegle: (a) utwardzać tożsamości i kanały komunikacji, (b) wdrażać zabezpieczenia specyficzne dla aplikacji LLM (prompt injection, groundedness), (c) modelować zagrożenia dla AI w oparciu o ATLAS i dobre praktyki ochrony danych.

Źródła / bibliografia

Microsoft Security Blog – AI as tradecraft: How threat actors operationalize AI (06.03.2026) (microsoft.com)
Google Cloud / GTIG – Distillation, Experimentation, and Integration… (12.02.2026) (Google Cloud)
Cloudflare – Introducing the 2026 Cloudflare Threat Report (ok. 03.2026) (The Cloudflare Blog)
CISA – AI Data Security: Best Practices… (22.05.2025) (CISA)
MITRE – ATLAS (Adversarial Threat Landscape for AI Systems) (MITRE ATLAS)

Złośliwe rozszerzenia „AI assistant” kradną historię rozmów z LLM: jak działa kampania i jak się bronić

Wprowadzenie do problemu / definicja luki

Rynek narzędzi „AI sidebar / AI assistant” w przeglądarce rośnie błyskawicznie, a wraz z nim rośnie pokusa nadużyć. Najnowsze ustalenia Microsoft Defender pokazują kampanię złośliwych rozszerzeń Chromium (Chrome/Edge), które podszywają się pod legalne asystenty AI i masowo zbierają treści rozmów z LLM oraz historię przeglądania. Kluczowe ryzyko nie polega tu na „efektownym exploicie”, tylko na tym, że użytkownicy sami instalują dodatek, często w środowisku firmowym, a potem wklejają do okna czatu wrażliwe dane (kod, procedury, koncepcje produktowe, dane klientów).

W skrócie

Microsoft opisuje kampanię z ~900 tys. instalacji oraz sygnały aktywności w ponad 20 tys. tenantów enterprise.
Rozszerzenia zbierały pełne URL-e (w tym wewnętrzne) oraz fragmenty rozmów z platform takich jak ChatGPT i DeepSeek.
Dane były cyklicznie wysyłane metodą HTTPS POST do domen m.in. deepaichats[.]com, chatsaigpt[.]com (oraz wskazywanych wildcardów).
W kampanii pojawiają się konkretne ID rozszerzeń wykorzystywane w huntingu i detekcji.

Kontekst / historia / powiązania

To nie jest odosobniony przypadek. Już pod koniec 2025 r. OX Security opisało niemal identyczny motyw: fałszywe rozszerzenia podszywające się pod legalny produkt (AITOPIA), które eksportowały rozmowy z ChatGPT/DeepSeek oraz listę odwiedzanych kart, a jedna z próbek miała nawet wyróżnienie w sklepie.

Równolegle w 2026 r. badacze (m.in. opisywani przez Malwarebytes) zwracali uwagę na inną klasę zagrożeń: rozszerzenia kradnące tokeny sesji ChatGPT, co umożliwia przejęcie konta i dostęp do historii/metadanych.

W tle rośnie jeszcze jedno zjawisko: „agentic” funkcje w przeglądarkach i asystentach webowych rozszerzają powierzchnię ataku (np. wątki o eskalacji uprawnień w komponentach asystenta i nadużyciach przez rozszerzenia).

Analiza techniczna / szczegóły

1. Łańcuch ataku (wg Microsoft)

Microsoft opisuje „klasyczny” łańcuch dla złośliwego rozszerzenia, gdzie największą rolę gra socjotechnika i architektura uprawnień Chromium:

Recon: wybór popularnej niszy „AI assistant”, analiza legalnych dodatków (np. AITOPIA) i skopiowanie brandingu oraz zachowań instalacyjnych.
Delivery: dystrybucja przez Chrome Web Store, z naturalnym „przenikaniem” także do Edge (obsługa dodatków Chrome).
Exploitation (w sensie operacyjnym): po instalacji dodatek wykorzystuje model uprawnień rozszerzeń i zaczyna zbierać dane bez kolejnych kliknięć.
C2/Exfil: okresowe wysyłki HTTPS POST na infrastrukturę atakujących (deepaichats[.]com, chatsaigpt[.]com itd.).

2. Co dokładnie było zbierane

Według Microsoft złośliwe rozszerzenie:

logowało niemal wszystkie odwiedzane URL-e (w tym zasoby intranetowe),
przechwytywało wycinki wiadomości czatu (prompty i odpowiedzi) z narzędzi LLM,
zapisywało dane lokalnie jako Base64-encoded JSON, a potem wysyłało je na zewnątrz,
dołączało m.in. kontekst nawigacji, nazwy modeli, oraz trwały UUID (identyfikator sesji/instalacji).

3. „Zgoda” jako mechanizm kamuflażu

Ciekawy element opisu Microsoft to mechanika „konsentu”: użytkownik mógł początkowo wyłączyć zbieranie danych, ale aktualizacje miały automatycznie przywracać telemetrię (re-enable), co w praktyce tworzyło trwały kanał wycieku przy minimalnej widoczności dla ofiary.

4. Twarde artefakty: domeny i identyfikatory

Microsoft podaje znane endpointy/domeny do monitoringu oraz ID rozszerzeń używane w przykładowych zapytaniach huntingowych:

Domeny/C2 do obserwacji: chatsaigpt.com, deepaichats.com, chataigpt.pro, chatgptsidebar.pro (oraz wildcards).
Przykładowe ID: fnmihdojmnkclgjpcoonokmkhjpjechg, inhcgfpbfdjbjogdfjbclgolkmhnooop.

Praktyczne konsekwencje / ryzyko

Dla organizacji to jest przede wszystkim problem DLP i tajemnicy przedsiębiorstwa:

Wycieki kodu i IP: prompty często zawierają fragmenty repo, logi, konfiguracje, architekturę.
Mapowanie środowiska: pełne URL-e (w tym wewnętrzne) ujawniają nazwy systemów, ścieżki aplikacji, czasem identyfikatory zasobów lub tenantów.
Ryzyko zgodności: jeśli w promptach/odpowiedziach lądują dane osobowe lub kontraktowe, organizacja może „nieświadomie” uruchomić incydent naruszenia.
Trwałość: rozszerzenie „żyje” tak długo, jak przeglądarka i profil użytkownika — bez klasycznych wskaźników infekcji endpointu.

Rekomendacje operacyjne / co zrobić teraz

1. Szybkie działania (0–24h)

Audyt rozszerzeń w przeglądarkach firmowych (Chrome/Edge) + identyfikacja dodatków AI/sidebar. Microsoft rekomenduje użycie funkcji oceny rozszerzeń w Defender VM.
Blokada ruchu do wskazanych domen (proxy/SWG/DNS/EDR Network Protection) i przegląd logów POST/HTTPS.
Weryfikacja instalacji po ID: polowanie po ExtensionId i ścieżkach katalogów profilu przeglądarki (Windows).
Komunikat do użytkowników: natychmiastowe usunięcie niezweryfikowanych „AI assistant” + krótkie zasady użycia LLM (czego nie wklejać do promptów).

2. Detekcja i hunting (praktycznie)

Microsoft publikuje gotowe przykłady zapytań (Microsoft Defender XDR), m.in.:

wykrywanie uruchomień przeglądarki z parametrami zawierającymi znane ID,
wykrywanie połączeń do domen kampanii,
enumeracja instalacji w tabeli DeviceTvmBrowserExtensions,
wykrywanie artefaktów na dysku w folderach profilu Chrome/Edge.

Jeśli nie korzystasz z Defender XDR, przełóż to 1:1 na:

reguły w SIEM (DNS/Proxy/Firewall) na domeny,
IOC w EDR dla ścieżek katalogów rozszerzeń,
polityki Browser Management (allowlist/denylist rozszerzeń).

3. Kontrole długoterminowe (policy + technologia)

Allowlist rozszerzeń (preferowane) zamiast „każdy może instalować wszystko”.
Microsoft Defender SmartScreen + Network Protection (Microsoft wskazuje je jako warstwę blokowania).
Purview / kontrola przepływu danych dla aplikacji GenAI: w praktyce chodzi o to, by prompt i odpowiedź były traktowane jak kanał danych (klasyfikacja, DLP, zasady).
Zasady użycia AI: minimalny standard to „prompt hygiene”, etykietowanie danych, zakaz wklejania sekretów i fragmentów kluczy/tokenów.

Różnice / porównania z innymi przypadkami

Warto rozróżnić dwa popularne modele ataku na „AI w przeglądarce”:

Telemetria/Podsłuch (ten przypadek)

celem jest ciągłe zbieranie: URL-e + treści czatów, często „po cichu”, długoterminowo, z UUID.

Kradzież tokenów sesji / przejęcie konta

rozszerzenie kradnie token uwierzytelnienia (np. do ChatGPT), co daje możliwość przejęcia tożsamości i wglądu w historię konta. Takie kampanie opisywano m.in. w kontekście zestawu złośliwych dodatków dla Chrome/Edge.

Oba scenariusze kończą się podobnie (wyciek treści), ale różnią się tym, gdzie powstaje szkoda: lokalnie w przeglądarce (podsłuch) vs „po stronie usługi/konta” (token).

Podsumowanie / kluczowe wnioski

„AI assistant” w formie rozszerzenia to dziś jeden z najłatwiejszych kanałów wycieku danych: wystarczy instalacja i szerokie uprawnienia.
Skala jest realna: Microsoft mówi o ~900 tys. instalacji i aktywności w >20 tys. tenantów, co wskazuje na istotny wymiar enterprise.
Najlepsza obrona to połączenie allowlisty rozszerzeń, monitoringu domen/C2, i zasad użycia LLM (prompt hygiene + DLP).

Źródła / bibliografia

Microsoft Security Blog (Microsoft Defender Security Research Team) – „Malicious AI Assistant Extensions Harvest LLM Chat Histories” (05.03.2026). (Microsoft)
OX Security – „900K Users Compromised: Chrome Extensions Steal ChatGPT and DeepSeek Conversations” (30.12.2025). (OX Security)
Malwarebytes – „Malicious Chrome extensions can spy on your ChatGPT chats” (28.01.2026). (Malwarebytes)
TechRadar (na podstawie LayerX/BleepingComputer) – kampanie fałszywych rozszerzeń GenAI i masowe eksfiltracje treści (luty 2026). (TechRadar)
ITPro – przykład ryzyk związanych z asystentami w przeglądarce i nadużyciami przez rozszerzenia (CVE-2026-0628 / Gemini Live). (IT Pro)

CyberStrikeAI w rękach atakujących: „AI-native” orkiestracja, która przyspiesza ataki na urządzenia brzegowe

Wprowadzenie do problemu / definicja luki

CyberStrikeAI to nie „kolejny chatbot dla pentesterów”, tylko AI-native platforma orkiestracji ofensywy, która spina dziesiątki narzędzi bezpieczeństwa (skanery, frameworki do eksploatacji, cracking haseł, post-eksploatacja) w jeden sterowalny proces. Kluczowa zmiana polega na tym, że operator nie musi ręcznie kleić pipeline’u – robi to silnik decyzyjny i agenty AI, co obniża próg wejścia i zwiększa tempo działań.

W praktyce oznacza to przyspieszenie dobrze znanych technik (skanowanie, brute force, enumeracja, lateral movement), a nie „magiczne” nowe 0-daye. Tę dynamikę widać w świeżych obserwacjach dotyczących kampanii przeciw urządzeniom brzegowym, gdzie AI pomaga skalować ataki nawet mniej zaawansowanym aktorom.

W skrócie

CyberStrikeAI to otwartoźródłowa platforma ofensywna „AI-native” (Go), integrująca 100+ narzędzi i dostarczająca webowy panel z logowaniem, audytem i repozytorium wyników.
Zespół Team Cymru powiązał instancję CyberStrikeAI z infrastrukturą, która wcześniej uczestniczyła w kampanii kompromitującej setki urządzeń Fortinet FortiGate.
W analizowanym okresie zaobserwowano 21 unikalnych IP uruchamiających CyberStrikeAI (głównie regiony chińskojęzyczne, ale też USA/Japonia/Europa).
Równolegle AWS opisał kampanię, w której rosyjskojęzyczny, finansowo motywowany aktor – bez użycia exploitów na FortiGate – skaluje atak przez wystawione interfejsy zarządzania i słabe hasła bez MFA, wykorzystując komercyjne GenAI do planowania i automatyzacji.
MITRE ATT&CK formalizuje ten kierunek jako pozyskiwanie/wykorzystanie AI do wsparcia wielu technik (phishing, skrypty, research, socjotechnika, rozwój payloadów).

Kontekst / historia / powiązania

Wątek, który spina całą historię, to ta sama infrastruktura: BleepingComputer opisał wcześniej kampanię, w której atakujący w ciągu kilku tygodni kompromitował urządzenia FortiGate, a jednym z elementów zaplecza był serwer 212.11.64[.]250. Następnie Team Cymru wykrył na tym samym adresie baner usługi CyberStrikeAI na porcie 8080 i korelował ruch (NetFlow) z komunikacją do FortiGate. Co istotne, infrastruktura kampanii miała uruchomiony CyberStrikeAI co najmniej do 30 stycznia 2026.

Team Cymru przyjrzał się też profilowi twórcy („Ed1s0nZ”) i wskazał, że obok CyberStrikeAI rozwija on inne projekty „AI-assisted” do eskalacji uprawnień (np. PrivHunterAI, InfiltrateX). Badacze odnotowali również interakcje z podmiotami/ekosystemem, które w otwartych źródłach bywały łączone z chińskimi operacjami państwowymi (MSS) — to jednak nadal pozostaje oceną analityczną na podstawie publicznych artefaktów.

Analiza techniczna / szczegóły „luki” (czyli: co dokładnie umożliwia CyberStrikeAI)

Architektura „AI-native” i dlaczego jest groźniejsza niż klasyczne zlepki narzędzi

Z opisu projektu i obserwacji badaczy wynika, że CyberStrikeAI dostarcza:

Silnik decyzyjny + orkiestrator (agenty AI, automatyzacja „od rozmowy do wyniku”)
Role/skills system (gotowe profile działań i zestawy kompetencji do testów)
Panel WWW z logowaniem, audytem, trwałością danych (SQLite) oraz wizualizacją łańcucha ataku i zarządzaniem podatnościami/zadaniami

Zintegrowany „pełny łańcuch ataku”

BleepingComputer (na podstawie Team Cymru i repozytorium) wskazuje typowy zestaw narzędzi, które CyberStrikeAI potrafi spiąć w jeden proces, m.in.:

Recon/scan: nmap, masscan
Web/app testing: sqlmap, nikto, gobuster
Eksploatacja: metasploit, pwntools
Hasła: hashcat, john
Post-eksploatacja / AD: mimikatz, bloodhound, impacket

To istotne, bo realnym „akceleratorem” nie jest pojedynczy moduł, tylko automatyzacja przejść między etapami: skanuj → wybierz powierzchnię → testuj → eksploatuj → utrwal/eskaluj → ruszaj dalej.

Zderzenie z rzeczywistością: urządzenia brzegowe i „mass credential abuse”

AWS opisuje scenariusz, który idealnie pasuje do narzędzi tego typu: masowe wyszukiwanie wystawionych interfejsów zarządzania (m.in. porty 443/8443/10443/4443), a następnie logowanie na słabe/reużyte hasła przy braku MFA. W tej kampanii nie obserwowano eksploatacji podatności FortiGate – przewagę dawały automatyzacja, skala i „AI-augmented” planowanie.

Praktyczne konsekwencje / ryzyko

Przyspieszenie i uprzemysłowienie kompromitacji edge
Firewalle/VPN-y/urządzenia dostępowe są idealnym celem, bo są widoczne z Internetu, a błędy konfiguracyjne (wystawione panele admina) + słabe uwierzytelnianie dają natychmiastowy zysk. AWS wprost podkreśla, że AI obniża barierę techniczną i pozwala małym aktorom osiągać skalę wcześniej zarezerwowaną dla większych zespołów.
Ryzyko „drugiego kroku”: AD + backupy + staging pod ransomware
Po wejściu przez brzeg, atakujący często idzie w kierunku przejęcia AD, kradzieży baz poświadczeń oraz dotknięcia infrastruktury backupowej. AWS zaznacza, że obserwacje były spójne z działaniami pre-ransomware, a BleepingComputer (w kontekście kampanii FortiGate) opisywał m.in. zainteresowanie elementami typu Veeam.
„Demokratyzacja” ofensywy
MITRE klasyfikuje użycie AI jako element budowania zasobów i wsparcia szeregu technik (recon, phishing, skrypty, rozwój możliwości). W połączeniu z platformami takimi jak CyberStrikeAI, oznacza to więcej operatorów zdolnych robić więcej – szybciej.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które realnie tną skuteczność kampanii „AI-augmented”, bo uderzają w fundamenty, na których one żerują:

Hardening urządzeń brzegowych (FortiGate i podobne)

Nie wystawiaj paneli zarządzania do Internetu (jeśli musisz: tylko z allowlisty IP, przez VPN/Zero Trust, z dodatkowymi kontrolami).
Wymuś MFA wszędzie tam, gdzie to możliwe (admin, VPN, konta serwisowe); wyeliminuj reużywanie haseł.
Przejrzyj ekspozycję portów zarządzania (typowo 443/8443/10443/4443) i zamknij to, co nie jest konieczne.

Detekcja i hunting

Monitoruj nietypowe logowania do paneli zarządzania (geolokacja, nowe IP, skoki wolumenu prób logowania, wzorce brute-force).
Koreluj zdarzenia „z brzegu” z ruchem do zasobów AD/backup (nagłe połączenia, enumeracja, tworzenie kont, zmiany polityk).
Jeśli prowadzisz threat hunting, sprawdź publikowane przez Team Cymru wskaźniki/IP związane z instancjami CyberStrikeAI i potraktuj je jako punkt startowy do korelacji (uwaga: same IP to nie wyrok, ale dobry pivot).

Zarządzanie ryzykiem

Załóż, że atakujący „spróbują wszystkich drzwi” automatem: wzmocnij credential hygiene, segmentację sieci i telemetrię post-eksploatacyjną (to są hamulce na skalę).
Aktualizuj i audytuj konfiguracje edge oraz polityki dostępu częściej niż dotąd — w świecie „AI-orkiestracji” okno między skanem a próbą wejścia jest krótsze.

Różnice / porównania z innymi przypadkami

CyberStrikeAI vs „zwykłe” użycie LLM w ataku

W modelu „klasycznym” LLM jest konsultantem: pisze skrypty, tłumaczy, podpowiada komendy. MITRE opisuje tę klasę zachowań jako wsparcie wielu technik.
CyberStrikeAI to krok dalej: narzędzie operacyjne, które spina 100+ modułów i robi z ofensywy proces, który można uruchamiać jak pipeline (bardziej „platforma” niż „porada”).

CyberStrikeAI vs kampania opisana przez AWS

AWS pokazał, że nawet bez exploitów, sama kombinacja: ekspozycja + słabe hasła + brak MFA + automatyzacja + GenAI = masowa skuteczność.
CyberStrikeAI wpisuje się w ten trend, bo ułatwia przejście od „mam dostęp” do „robię post-eksploatację i eskalację” przy mniejszym wysiłku operatora.

Podsumowanie / kluczowe wnioski

CyberStrikeAI jest sygnałem, że AI w ofensywie przestaje być dodatkiem, a staje się warstwą orkiestracji całych łańcuchów ataku. Obserwacje Team Cymru i doniesienia BleepingComputer pokazują realne wykorzystanie w infrastrukturze powiązanej z atakami na FortiGate. Jednocześnie AWS udowadnia, że w 2026 r. największym paliwem dla „AI-augmented” kampanii nadal są banalne braki w higienie dostępu (wystawione panele, brak MFA, słabe hasła).

Jeśli Twoja organizacja ma urządzenia brzegowe dostępne z Internetu, to nie jest temat „trendu” – to priorytet operacyjny.

Źródła / bibliografia

BleepingComputer – CyberStrikeAI tool adopted by hackers for AI-powered attacks (02.03.2026). (BleepingComputer)
Team Cymru – Tracking CyberStrikeAI Usage (analiza NetFlow, infrastruktura, lista IP). (Team Cymru)
AWS Security Blog (CJ Moses) – AI-augmented threat actor accesses FortiGate devices at scale (20.02.2026). (Amazon Web Services, Inc.)
MITRE ATT&CK – T1588.007 Artificial Intelligence (Resource Development). (attack.mitre.org)
Google Cloud Blog (GTIG) – Distillation, Experimentation, and (Continued) Integration of AI for Adversarial Use (12.02.2026). (Google Cloud)