LLM Jailbreaking – Testy bezpieczeństwa modeli AI

Gdy agent łączy jednocześnie trzy zdolności. Staje się to krytyczne.

Badacz bezpieczeństwa Simon Willison nazywa to zabójczą triadą (lethal trifecta):

Dostęp do danych prywatnych. Twój CRM, dokumenty, systemy wewnętrzne.
Kontakt z treścią z niezaufanego źródła. Cokolwiek z zewnątrz: maile, pliki, strony.
Możliwość komunikacji na zewnątrz. Wysłanie wiadomości, wywołanie API, pobranie URL-a.

Gdy obecne są wszystkie trzy, jeden zatruty dokument może polecić agentowi odczytać wrażliwe dane i po cichu je wyprowadzić, bez jednego kliknięcia człowieka. To nie teoria. W czerwcu 2025 r. podatność zero-click w Microsoft 365 Copilot (CVE-2025-32711, „EchoLeak", CVSS 9.3) pokazała dokładnie ten scenariusz w systemie produkcyjnym: pośredni prompt injection ukryty w treści maila prowadził do automatycznego wyprowadzenia danych z zakresu Copilota, bez żadnej interakcji użytkownika.

Microsoft załatał ją po stronie serwera, bez akcji klientów i bez dowodów eksploatacji w naturze - podatna była architektura wokół modelu, nie sam model.

Ryzyka, które testujemy, w prostych słowach:

Wyciek danych przez warstwę dostępu. Asystent zwraca dane spoza zakresu zalogowanego użytkownika, bo autoryzacja jest w prompcie zamiast w logice aplikacji.

Nadmierna sprawczość (excessive agency). Agent ma narzędzia o zbyt szerokich uprawnieniach. Jeden udany injection prowadzi do zapytania do bazy, wysłanego maila, ruchu bocznego do SaaS lub chmury. To problem „zdezorientowanego pełnomocnika" (confused deputy).

Ujawnienie promptu systemowego. Twoje instrukcje, logika biznesowa i nieroztropnie zaszyte w nich sekrety, wydobyte przez użytkownika.

Ryzyko reputacyjne i treściowe. AI zmanipulowane do wygenerowania toksycznej lub fałszywej treści, która staje się publicznym incydentem. Chatbota pewnej firmy kurierskiej skłoniono w styczniu 2024 r. do przeklinania i nazwania własnego pracodawcy „najgorszą firmą kurierską na świecie".

Nadużycia i ataki kosztowe. Niekontrolowane zużycie zasobów napędzające lawinowe koszty API („denial of wallet") albo odcinające usługę realnym użytkownikom.

Zaufali nam najwięksi

Wewnętrzne zespoły budują i utrzymują system. My wchodzimy jako niezależny przeciwnik.

Mapujemy powierzchnię ataku, odtwarzamy realne łańcuchy exploita i dostarczamy remediację architektoniczną. To weryfikacja, której zespół wewnętrzny sam sobie nie zapewni.
‍

Wartość mierzymy kosztem niezależnego wykrycia exploitable chain przed incydentem.

Co dostajesz: od „mamy nadzieję, że jest bezpiecznie" do dowodów, które możesz pokazać każdemu.

Raport techniczny z działającymi łańcuchami ataku, mapowaniem na OWASP LLM Top 10, OWASP Agentic 2026 i MITRE ATLAS oraz oceną ryzyka biznesowego.

Artefakty operacyjne: attack surface map, tool permission matrix, data-flow / RAG map, exploit replay steps (warunki reprodukcji), blast-radius analysis, remediation backlog.

Plan remediacji architektonicznej: separacja uprawnień, traktowanie outputu modelu jako niezaufanego, deterministyczne guardraile poza modelem, least-privilege dla narzędzi, human-in-the-loop dla akcji wrażliwych.

Dwie wersje wyników: executive summary dla zarządu oraz szczegóły techniczne dla zespołu AI/ML/AppSec.Re-test najważniejszych findingów po wdrożeniu poprawek.

AI Security Review

wczesne wdrożenie / MVP

threat model, attack surface map, quick wins

od 49 900 zł

za projekt

AI App Pentest

produkcyjna aplikacja LLM/RAG

findingi, PoC, remediacja, re-test

Continuous AI Assurance

wiele wdrożeń AI

cykliczne testy, regression harness, advisory

Skontaktuj się z nami

Agentic Red Team

system z tool calling / MCP / SaaS

pełny kill-chain, pivoting, blast radius

Frameworki oparte na uznanych standardach

OWASP Top 10 for LLM & GenAI Apps (2025)

Klasyfikacja podatności, coverage matrix, język findingów

OWASP Top 10 for Agentic Applications (2026) + MCP guidance

Testy agentów, narzędzi, pamięci, MCP i komunikacji inter-agent

MITRE ATLAS

Mapowanie technik przeciwnika i TTP w raporcie

NVIDIA AI Kill Chain

Narracja łańcucha ataku: recon, poison, hijack, persist, impact

EU AI Act, DORA, UKSC/NIS2

Pakiet dowodowy wspierający nadzór nad ryzykiem, nie porada prawna

FUSE AI CLASS

Nasz autorski framework

Nie improwizujemy. Testujemy według standardów, które Twoi audytorzy i regulatorzy już znają.
‍

„Kreatywne promptowanie" to nie metodyka. Atakujący eksploatują cały połączony system, nie model w izolacji. Pracujemy na uznanych standardach — osobno tych do testowania i mapowania ataku, osobno tych do zarządzania ryzykiem i zgodności. To rozdzielenie ma znaczenie: regulacje i wymogi zgodności (jak EU AI Act, DORA czy UKSC/NIS2) wyznaczają, co masz osiągnąć, ale nie są metodyką pentestu — mówią, że masz testować odporność systemu, nie jak ten test przeprowadzić.

Wyróżnik: Twoje zespoły ML i produktowe świetnie budują działające modele. Bezpieczeństwo adwersarialne (adversarial security) to inna dyscyplina: myślenie jak atakujący o granicy między zaufanymi poleceniami a niezaufanymi danymi, o uprawnieniach narzędzi i ścieżkach wyprowadzenia danych. Tę perspektywę wnosimy my, i to jej zwykle brakuje w projektach AI, dopóki coś nie pójdzie nie tak.

Mapowanie na owasp LLM top 10 (2025)

Direct prompt injection / jailbreak
‍Bezpośrednia manipulacja wejściem w celu obejścia polityk i instrukcji
LLM01

Indirect prompt injection
‍Instrukcje ukryte w zewnętrznych danych, które przejmuje agent lub workflow
LLM01

Sensitive information disclosure
Wyciek danych lub sekretów przez kontekst albo błędną autoryzację
LLM02

AI / agent supply chain
Ryzyko w modelach, SDK, serwerach MCP, rejestrze narzędzi, zależnościach, szablonach promptów, providerach
LLM03

Data & model poisoning
Ryzyko w modelach, SDK, serwerach MCP, rejestrze narzędzi, zależnościach, szablonach promptów, providerachZatruwanie danych treningowych, RAG, osadzeń
LLM04

Improper output handling
Output modelu prowadzący do XSS/SSRF/SQLi/command exec w systemach downstream
LLM05

Excessive agency
Zbyt szerokie uprawnienia narzędzi prowadzące do nieautoryzowanych akcji
LLM06

System prompt leakage
Ujawnienie promptu systemowego jako recon enabler i wyciek informacji
LLM07

Vector & embedding weaknesses
Ujawnienie promptu systemowego jako recon enabler i wyciek informacjiSłabości RAG: kolizje, retrieval hijacking, wyciek
LLM08

Misinformation / decision integrity
Błędny lub zmanipulowany output prowadzący do decyzji, akcji lub rekomendacji bez kontroli — nie sama halucynacja, lecz halucynacja połączona z workflowem
LLM09

Cost / resource abuse
Token exhaustion, pętle agentów, tool-call storms, DoS modelu lub API
LLM10

Ryzyka agentowe (MCP/A2A)
Agent goal hijack, tool poisoning, memory poisoning, rogue agents
OWASP Agentic 2026

‍

Attack lifecycle + 7 obszarów pokryci

Nie testujemy modelu w izolacji. Najpierw mapujemy przepływ danych, tożsamości, narzędzi i decyzji, potem odtwarzamy realny łańcuch ataku.

Łańcuch ataku, który odtwarzamy:
‍

Recon → injection / poisoning → tool abuse → data access → persistence / pivoting → business impact

Entrypoints. UI, API, upload, e-mail, dokumenty, przeglądanie web, integracje agent-agent.
Tożsamość i uprawnienia. Service accounts, OAuth scopes, RBAC/ABAC, obsługa tokenów, dostęp delegowany.
Narzędzia agentów oraz MCP/A2A. Tool calling, serwery MCP, komunikacja inter-agent, opisy narzędzi (tool descriptions), pamięć, approval flows.
RAG i pipeline'y danych. Zatruwanie na ingest (ingestion poisoning), przejmowanie retrievalu (retrieval hijacking), słabości wektorów i osadzeń, ekspozycja danych wrażliwych.

Warstwa modelu i instrukcji. Jailbreak, bezpośredni i pośredni prompt injection, omijanie polityk (policy bypass), wyciek promptu systemowego, sondowanie zachowania modelu.
Bezpieczeństwo aplikacji. Autoryzacja, IDOR, niewłaściwa obsługa wyjścia, XSS/SSRF/SQLi przez systemy downstream, obsługa sekretów.
Skutek i pivoting. Łańcuchowanie exploita do SaaS, chmury, komunikacji wewnętrznej, CRM, ticketingu, repozytoriów i procesów biznesowych.

Dlaczego nie podajemy jednej „skuteczności ataku"

Liczby attack-success-rate zależą od metodyki (binary vs average ASR, model-sędzia, benchmark, liczba prób) i nie są porównywalne między badaniami. Żadna miarodajna, branżowa stopa skuteczności prompt injection nie istnieje. Zamiast wymyślonych procentów dajemy odtwarzalny scenariusz i warunki reprodukcji. Uczciwość liczb to dla tej grupy odbiorców sygnał kompetencji.

Statystyki z

https://nvd.nist.gov/vuln/search/statistics?form_type=Basic&&...

Ustrukturyzowany projekt, a nie szukanie po omacku.

Nie testujemy modelu w izolacji. Najpierw mapujemy przepływ danych, tożsamości, narzędzi i decyzji, potem odtwarzamy realny łańcuch ataku.

Proces od początku do końca

Zakres i zasady zaangażowania

Inwentaryzujemy zasoby LLM (chatboty, RAG, API) i ustalamy zakres, limity oraz plany wycofania. Decydujemy, co testować agresywnie na pre-produkcji, a co weryfikować w realiach produkcyjnych.
‍

Plan testów zmapowany na OWASP i MITRE ATLAS

Przed wykonaniem otrzymujesz udokumentowany model zagrożeń i plan testów. Każdy planowany atak jest powiązany z konkretnym ryzykiem OWASP LLM i techniką ATLAS. Żadnej czarnej skrzynki.
‍

Testy API i infrastruktury

Testujemy system wokół modelu: warstwę API, uwierzytelnianie, ograniczanie zapytań, wektory nadużycia zasobów i zawyżania kosztów. Nie tylko tekstowe odpowiedzi modelu.

Modelowanie zagrożeń i architektury

Mapujemy przepływy danych, granice zaufania, źródła RAG i narzędzia, żeby znaleźć miejsca, w których składa się zabójcza triada. Przeglądamy prompty systemowe, guardrails i kontrolę dostępu, definiujemy najgorsze scenariusze do zrealizowania.

Wykonanie testów adwersarialnych

W sercu projektu łączymy testy manualne z automatyzacją (garak, PyRIT, Promptfoo), by kompleksowo badać podatności: od prompt injection, jailbreaków i obfuskacji, po kradzież promptów, nadużycia agentów i zatruwanie baz RAG.

Raport z oceną wpływu biznesowego

Każde potwierdzone ustalenie dokumentujemy odtwarzalnym scenariuszem (kroki i dowody), mapowaniem na OWASP/ATLAS, oceną krytyczności powiązaną z wpływem biznesowym i priorytetyzowaną rekomendacją naprawczą. Dostajesz obraz oczami atakującego, a nie ścianę surowych promptów.

Warsztaty naprawcze i retest

Pracujemy bezpośrednio z Twoimi zespołami AI/ML i inżynierskimi nad konkretnymi poprawkami: utwardzeniem architektury, odcięciem ścieżki wyprowadzenia danych, zacieśnieniem uprawnień narzędzi, wzmocnieniem guardrails. Potem retestujemy, żeby potwierdzić, że poprawki działają.

Opcjonalnie: ciągłe testy regresyjne w CI/CD, żeby wychwytywać dryf przy aktualizacjach modeli fundacyjnych, promptów i narzędzi między projektami.

AI assurance dla branż regulowanych

Dla bankowości i infrastruktury krytycznej testy adwersarialne AI stają się obowiązkiem, nie dodatkiem.

Kluczowa zasada nowych przepisów

certyfikat od dostawcy AI nie zdejmuje odpowiedzialności z Twojej firmy. Większość organizacji korzysta z gotowych rozwiązań jako tzw. podmiot wdrażający (deployer) i to Ty odpowiadasz za to, jak system działa w praktyce.

EU AI Act

W przypadku systemów wysokiego ryzyka musisz zapewnić ich dokładność i cyberbezpieczeństwo w tym odporność na ataki adwersarialne (art. 15). Twoim obowiązkiem jest nadzór ludzki, monitorowanie systemu i prowadzenie rejestrów (art. 26), a czasem ocena skutków dla praw podstawowych (art. 27). Dla modeli ogólnego przeznaczenia unijny Kodeks Praktyk wprost wymaga testów adwersarialnych i red teamingu.

DORA (od 17 stycznia 2025 r.)

o kluczowa regulacja dla sektora finansowego, ważniejsza niż przepisy krajowe. Jeśli system AI/LLM działa w Twoich procesach ICT, podlega pod rygorystyczne zarządzanie ryzykiem stron trzecich (Rozdział V). Dla istotnych podmiotów oznacza to obowiązek robienia zaawansowanych testów TLPT (metodyka TIBER-EU) co najmniej raz na 3 lata na żywej produkcji, z opcją objęcia nimi zewnętrznych dostawców.

UKSC (od 3 kwietnia 2026 r.)

Polska ustawa wdrażająca dyrektywę NIS2. Nakłada na podmioty kluczowe i ważne w sektorach krytycznych obowiązek regularnych ocen podatności i testów penetracyjnych. Jeśli w tych procesach używasz systemów AI, one również muszą zostać przetestowane.

Przepisy wymagają od Ciebie dowodów bezpieczeństwa

Rozwiązaniem są regularne, powtarzalne testy adwersarialne oparte na uznanych metodykach oraz testy regresyjne. Przekładają one skomplikowane wymogi prawne na gotowe raporty techniczne, które po prostu przedstawiasz audytorowi.

Dlaczego CyCommSec

To, co odróżnia nas od usług kończących się na liście promptów.

Attack-chain first

Raportujemy pełne ścieżki od wejścia do skutku, nie pojedyncze podatności.

Permission-aware testing

Testujemy uprawnienia agentów, service accounts, OAuth scopes, dostęp delegowany i blast radius narzędzi.

RAG & data-flow focus

Mapujemy ingest, retrieval, wyszukiwanie wektorowe, źródła wiedzy i ścieżki wycieku danych.

Agentic systems coverage

MCP, A2A, tool calling, pamięć, approval gates, multi-agent workflows.

Replayable evidence

PoC, narracja ataku, warunki reprodukcji i remediacja możliwa do wdrożenia.

Executive + engineering output

Jedna wersja dla zarządu, druga dla zespołu technicznego.

Jak wygląda raport?

Wzorzec, który widzimy niemal zawsze: model nie jest najsłabszym ogniwem. Skutek rodzi się w uprawnieniach narzędzi, dostępie do danych i pivotingu.

Initial access:

Atakujący umieścił instrukcję w treści rekordu lub wiadomości przetwarzanej przez agenta.

Hijack

Agent potraktował niezaufane dane jako instrukcję i zmienił plan działania.

Tool abuse

Narzędzie Salesforce pozwalało na zbyt szerokie zapytania przez service account, bez allowlisty pól i bez egzekwowania uprawnień użytkownika.

Data access

Aagent zwrócił dane CRM spoza intencji pierwotnego workflow.

Pivot

Uprawnienie zapisu do Slacka pozwoliło wysłać wewnętrzną wiadomość z treścią kontrolowaną przez atakującego.

Root cause

Nadmierne uprawnienia narzędzi, brak deterministycznej autoryzacji poza modelem, brak separacji danych zaufanych i niezaufanych, brak approval gate dla akcji komunikacyjnych.

Business impact

Nieautoryzowany dostęp do danych sprzedażowych oraz możliwość wewnętrznego phishingu z zaufanego kanału.

Dlaczego nie podajemy jednej „skuteczności ataku"

Liczby attack-success-rate zależą od metodyki (binary vs average ASR, model-sędzia, benchmark, liczba prób) i nie są porównywalne między badaniami. Żadna miarodajna, branżowa stopa skuteczności prompt injection nie istnieje. Zamiast wymyślonych procentów dajemy odtwarzalny scenariusz i warunki reprodukcji. Uczciwość liczb to dla tej grupy odbiorców sygnał kompetencji.

Własny Zespół vs Projekt na żadanie

Wyspecjalizowany wewnętrzny red team AI a ekspercki projekt na żądanie.

Własny Zespół

Konieczność zatrudnienia rzadkiego, drogiego specjalisty, z ryzykiem wypalenia i rotacji przy pojedynczym etacie.

Stały koszt narzędzi, szkoleń i dostępu do aktualnych badań nad atakami.

Wąska perspektywa: jeden zespół, często skupiony na jednym modelu lub produkcie.

Dostępny na wyłączność, w pełnym wymiarze.

Projekt w CyCommSec

Dostęp na żądanie do zespołu z doświadczeniem na wielu modelach i platformach.

Aktualna wiedza o globalnych technikach ataków na AI, stosowana w wielu projektach.

Obiektywna, zewnętrzna perspektywa, wolna od wewnętrznych założeń.

Płacisz za konkretny rezultat, projekt z dostarczalnymi produktami, a nie za utrzymanie etatu.

Przewidywalny, projektowy koszt: scoping, testy, raport i warsztaty naprawcze w cenie.

Zacznij budować AI, któremu można zaufać.

Dołącz do liderów, którzy proaktywnie zabezpieczają swoje modele językowe przed nową generacją zagrożeń.

Najczęstsze pytania

FAQ

Czym AI pentest różni się od klasycznego pentestu? Klasyczny pentest sprawdza aplikację, sieć i infrastrukturę. Zwykle nie obejmuje ryzyk specyficznych dla LLM, RAG i agentów: prompt injection, przejmowania narzędzi, wycieku przez warstwę RAG czy nadmiernych uprawnień agenta. My testujemy obie warstwy razem, bo realny łańcuch ataku przechodzi przez jedną i drugą.
Testujecie sam model czy całą aplikację?: Całą aplikację wokół modelu. Modelu fundacyjnego nie trenowałeś, tylko go wdrożyłeś, więc Twoja powierzchnia ataku to prompty systemowe, warstwa RAG, narzędzia, uprawnienia agenta i backend. Tam rodzi się skutek biznesowy i to testujemy.
Jailbreak i prompt injection to to samo?: Nie. Jailbreak to obejście polityk modelu, żeby wygenerował treść, której miał nie generować. Prompt injection to wmieszanie niezaufanych instrukcji w strumień, który model traktuje jako polecenie, co może uruchomić akcje z uprawnieniami aplikacji. Prompt injection, zwłaszcza pośredni, jest groźniejszy, bo prowadzi do wycieku danych i nieautoryzowanych akcji, nie tylko do brzydkiej odpowiedzi.
Potrzebujecie środowiska produkcyjnego?: Najczęściej pracujemy na pre-prodzie, gdzie możemy być bardziej agresywni. Część testów wymaga produkcji, żeby zweryfikować realne działanie narzędzi i izolację najemców. Zakres ustalamy wspólnie w kroku Rules of Engagement: dozwolone techniki, okna testowe, limity zapytań i plany wycofania.

Testujecie systemy agentowe i MCP? Tak. Pokrywamy tool calling, serwery MCP, komunikację A2A, pamięć agenta, approval gates i workflow wieloagentowe, zmapowane na OWASP Top 10 for Agentic Applications 2026.
Co dostajemy na koniec?: Raport techniczny z działającymi łańcuchami ataku i mapowaniem na OWASP i MITRE ATLAS, artefakty operacyjne (attack surface map, tool permission matrix, data-flow / RAG map, blast-radius analysis), plan remediacji architektonicznej, executive summary dla zarządu oraz re-test najważniejszych findingów po poprawkach.
Czy to pomaga w zgodności z EU AI Act, DORA i NIS2?: Tak. Dostarczamy powtarzalne testy adwersarialne zmapowane na uznaną metodykę, które spinają te obowiązki w dowody do przedstawienia audytorowi. Nasza usługa wspiera dowodowo wymogi odporności (EU AI Act, Artykuł 15), obowiązki podmiotu wdrażającego (Artykuł 26) oraz testowanie odporności operacyjnej pod DORA. To nie jest porada prawna.
Potrzebujecie środowiska produkcyjnego?: Najczęściej pracujemy na pre-prodzie, gdzie możemy być bardziej agresywni. Część testów wymaga produkcji, żeby zweryfikować realne działanie narzędzi i izolację najemców. Zakres ustalamy wspólnie w kroku Rules of Engagement: dozwolone techniki, okna testowe, limity zapytań i plany wycofania.

Twoje AI nie działa samo. Działa z danymi, narzędziami i uprawnieniami.

Dlaczego, skuteczność modelu to nie bezpieczeństwo

Gdy agent łączy jednocześnie trzy zdolności. Staje się to krytyczne.

Wewnętrzne zespoły budują i utrzymują system. My wchodzimy jako niezależny przeciwnik.

Mapujemy powierzchnię ataku, odtwarzamy realne łańcuchy exploita i dostarczamy remediację architektoniczną. To weryfikacja, której zespół wewnętrzny sam sobie nie zapewni.‍

Co dostajesz: od „mamy nadzieję, że jest bezpiecznie" do dowodów, które możesz pokazać każdemu.

Frameworki oparte na uznanych standardach

Nie improwizujemy. Testujemy według standardów, które Twoi audytorzy i regulatorzy już znają.‍

Mapowanie na owasp LLM top 10 (2025)

Attack lifecycle + 7 obszarów pokryci

Nie testujemy modelu w izolacji. Najpierw mapujemy przepływ danych, tożsamości, narzędzi i decyzji, potem odtwarzamy realny łańcuch ataku.

Ustrukturyzowany projekt, a nie szukanie po omacku.

Nie testujemy modelu w izolacji. Najpierw mapujemy przepływ danych, tożsamości, narzędzi i decyzji, potem odtwarzamy realny łańcuch ataku.

Zakres i zasady zaangażowania

Plan testów zmapowany na OWASP i MITRE ATLAS

Testy API i infrastruktury

Modelowanie zagrożeń i architektury

Wykonanie testów adwersarialnych

Raport z oceną wpływu biznesowego

Warsztaty naprawcze i retest

AI assurance dla branż regulowanych

Dla bankowości i infrastruktury krytycznej testy adwersarialne AI stają się obowiązkiem, nie dodatkiem.

Kluczowa zasada nowych przepisów

EU AI Act

DORA (od 17 stycznia 2025 r.)

UKSC (od 3 kwietnia 2026 r.)

Przepisy wymagają od Ciebie dowodów bezpieczeństwa

Dlaczego CyCommSec

To, co odróżnia nas od usług kończących się na liście promptów.

Attack-chain first

Permission-aware testing

RAG & data-flow focus

Agentic systems coverage

Replayable evidence

Executive + engineering output

Jak wygląda raport?

Wzorzec, który widzimy niemal zawsze: model nie jest najsłabszym ogniwem. Skutek rodzi się w uprawnieniach narzędzi, dostępie do danych i pivotingu.

Initial access:

Hijack

Tool abuse

Data access

Pivot

Root cause

Business impact

Dlaczego nie podajemy jednej „skuteczności ataku"

Własny Zespół vs Projekt na żadanie

Wyspecjalizowany wewnętrzny red team AI a ekspercki projekt na żądanie.

Własny Zespół

Zacznij budować AI, któremu można zaufać.

Najczęstsze pytania

Mapujemy powierzchnię ataku, odtwarzamy realne łańcuchy exploita i dostarczamy remediację architektoniczną. To weryfikacja, której zespół wewnętrzny sam sobie nie zapewni.
‍

Nie improwizujemy. Testujemy według standardów, które Twoi audytorzy i regulatorzy już znają.
‍