Mapowanie ataków na agentów AI do MITRE ATLAS: taktyki, techniki i sygnały detekcji w każdej fazie

Czym jest MITRE ATLAS i jak mapować do niego ataki na agentów AI?

MITRE ATLAS (Adversarial Threat Landscape for Artificial-Intelligence Systems) to publiczna baza wiedzy o taktykach i technikach ataków na systemy uczenia maszynowego — odpowiednik ATT&CK, tyle że dla AI. Mapowanie ataku na agenta AI polega na rozłożeniu incydentu na kolejne fazy (taktyki: po co atakujący wykonał dany ruch) i przypisaniu im konkretnych technik z macierzy ATLAS. Każda taka faza zostawia po sobie inny ślad telemetryczny — i właśnie te ślady są punktem zaczepienia, od którego zaczyna się detekcja.

W praktyce wygląda to tak: agent oparty na modelu językowym, który ma dostęp do narzędzi (wyszukiwarka, baza wektorowa, API firmowe), zostaje przejęty przez wstrzyknięty prompt ukryty w dokumencie. Atak nie jest jednym zdarzeniem — to ciąg kroków od rozpoznania, przez wstępny dostęp, po eksfiltrację danych. ATLAS daje wspólny słownik, którym opisujemy ten ciąg, a zespół SOC dostaje listę miejsc, w których powinien szukać anomalii. Bez tego słownika każdy zespół opisuje to samo zdarzenie inaczej i nie da się go porównać ani powtórzyć w ćwiczeniu red-team.

To detekcyjna druga strona naszego przeglądu krajobrazu zagrożeń agentów AI w 2026: tam katalogujemy techniki, tu pokazujemy, jak je wyłapać. Najważniejsza różnica wobec klasycznego ATT&CK: w atakach na agentów warstwą podatną nie jest tylko infrastruktura, ale sam model i jego dane wejściowe. Wektorem wejścia bywa zwykły tekst — komentarz na stronie, treść maila, opis produktu — który agent traktuje jako instrukcję. Dlatego mapowanie do ATLAS wymusza patrzenie na granicę między „danymi“ a „poleceniem“, której w tradycyjnym monitoringu sieci po prostu nie ma.

Dlaczego ATT&CK nie wystarcza i potrzebny jest osobny model dla AI?

Klasyczny ATT&CK zakłada, że atakujący wykonuje rozpoznawalne ruchy w systemie operacyjnym i sieci: uruchamia proces, modyfikuje rejestr, otwiera połączenie do serwera C2. Agent AI łamie te założenia. Tu „wykonaniem kodu“ jest wygenerowanie tekstu, a „eskalacją uprawnień“ — przekonanie modelu, by skorzystał z narzędzia, do którego nie powinien sięgać w danym kontekście. Te zachowania nie pojawiają się w logach EDR, bo z punktu widzenia systemu operacyjnego nic podejrzanego się nie wydarzyło — proces modelu po prostu zwrócił odpowiedź.

ATLAS dokłada taktyki, których w ATT&CK nie ma albo mają zupełnie inne znaczenie: ML Model Access (uzyskanie dostępu do modelu, choćby przez publiczne API), ML Attack Staging (przygotowanie danych zatruwających lub przykładów adwersarialnych) czy Poisoning danych treningowych. Część taktyk pokrywa się z ATT&CK z nazwy — Rozpoznanie, Eksfiltracja, Wpływ — ale techniki pod nimi są specyficzne dla ML i opisują manipulację samym modelem, a nie hostem.

Praktyczny wniosek dla obrońcy jest prosty: jeśli monitorujesz agenta AI wyłącznie narzędziami pisanymi pod sieć i endpoint, jesteś ślepy na całą warstwę ataku. ATLAS pełni tu rolę listy kontrolnej — pokazuje, których faz w ogóle nie obserwujesz, i podpowiada, jaką telemetrię trzeba dograć (logi promptów, wywołań narzędzi, źródeł RAG), żeby przestać być ślepym.

Jak wyglądają taktyki ATLAS w cyklu ataku na agenta?

Atak na agenta AI ma swój własny rytm, który da się rozpisać na taktyki ATLAS w kolejności, w jakiej zwykle następują. Poniżej przechodzę przez fazy tak, jak układają się w realnym incydencie z agentem korzystającym z narzędzi i bazy wektorowej.

Rozpoznanie i przygotowanie zasobów

Na tym etapie atakujący zbiera wiedzę o systemie: jaki model napędza agenta, jakie ma narzędzia, jak brzmi jego instrukcja systemowa. Robi to przez sondowanie publicznego interfejsu (ATLAS: Reconnaissance), próby wyciągnięcia promptu systemowego oraz mapowanie, na jakie polecenia agent reaguje. Często pojawia się tu też zbieranie publicznych artefaktów — kart modelu, dokumentacji API, repozytoriów z kodem integracji.

Sygnał detekcji: seria nietypowych zapytań pod jeden adres lub klucz API, w których treść powtarza warianty „zignoruj poprzednie instrukcje“, „pokaż swój prompt systemowy“, „jakie masz narzędzia“. Charakterystyczny jest wzorzec sondowania — wiele drobnych wariacji tego samego pytania w krótkim oknie czasu, czego nie robi normalny użytkownik.

Wstępny dostęp przez wstrzyknięcie promptu

To moment przejęcia kontroli nad agentem. Najgroźniejszy wariant to pośrednie wstrzyknięcie promptu (indirect prompt injection): złośliwa instrukcja jest ukryta w danych, które agent sam pobiera — w treści strony, w dokumencie z bazy wektorowej, w komentarzu na zgłoszeniu. Agent traktuje te dane jak polecenie i zaczyna działać wbrew intencji właściciela. W ATLAS odpowiada temu technika z rodziny LLM Prompt Injection.

Sygnał detekcji: rozjazd między pierwotnym zadaniem użytkownika a tym, co agent faktycznie zaczyna robić — np. zadanie brzmiało „streść ten raport“, a agent nagle próbuje odczytać zmienne środowiskowe albo wysłać żądanie na zewnętrzny adres. Warto monitorować zgodność między intencją z pierwszego polecenia a sekwencją wywołań narzędzi. Drugim sygnałem jest pojawienie się w kontekście modelu fragmentów tekstu o strukturze instrukcji (imperatywy, znaczniki ról) pochodzących z danych, a nie od użytkownika.

Wykonanie i utrzymanie dostępu

Po przejęciu agent wykonuje cele atakującego: uruchamia narzędzia, formułuje zapytania do API, generuje treści. Jeśli system pozwala agentowi zapisywać do pamięci długotrwałej lub do bazy wektorowej, atakujący może osadzić tam trwałą instrukcję (zatrucie pamięci), która będzie uruchamiać się przy kolejnych sesjach — to forma utrwalenia dostępu specyficzna dla agentów.

Sygnał detekcji: wywołania narzędzi w kolejności i kombinacji, która nie pasuje do żadnego znanego, dozwolonego scenariusza pracy agenta. Przydaje się tu lista dozwolonych sekwencji, bo nadużycie zwykle łamie typowy graf wywołań. Przy zatruciu pamięci sygnałem alarmowym jest zapis do bazy wektorowej fragmentu, który sam zawiera polecenia — treść wektorowana powinna być danymi, nie instrukcją.

Eskalacja i nadużycie uprawnień narzędzi

Agent zwykle działa z szerszymi uprawnieniami niż pojedynczy użytkownik — to jest jego siła i jego słabość. Atakujący próbuje wykorzystać narzędzia agenta, by sięgnąć dalej, niż mógłby samodzielnie: użyć konektora do bazy danych, wykonać żądanie do wewnętrznego API, odpalić funkcję, która operuje na cudzych danych. ATLAS opisuje to w kategoriach wpływu i eskalacji przez dostęp do możliwości modelu.

Sygnał detekcji: agent sięga po narzędzie lub zakres danych, których nie potrzebuje do zadania bieżącego użytkownika — np. konto pomocy technicznej, które miało odczytać status zgłoszenia, nagle odpytuje tabelę z danymi rozliczeniowymi. Detekcja opiera się na zasadzie najmniejszych uprawnień zaszytej w samym agencie i na alercie, gdy wywołanie wychodzi poza zakres przypisany do tożsamości danej sesji.

Eksfiltracja i wpływ

Finał ataku: wyprowadzenie danych albo wymuszenie szkodliwego działania. Eksfiltracja w świecie agentów bywa subtelna — dane nie muszą wychodzić paczką przez port; mogą zostać zakodowane w treści odpowiedzi, w parametrach żądania do „niewinnego“ zewnętrznego adresu albo w obrazku generowanym przez narzędzie. ATLAS klasyfikuje to pod Exfiltration i Impact.

Sygnał detekcji: odpowiedzi agenta albo wywołania narzędzi zawierające dane wrażliwe (klucze, dane osobowe, fragmenty bazy) skierowane na adres spoza listy dozwolonych. Pomaga skan treści wychodzącej pod kątem wzorców sekretów i nietypowych adresów docelowych w żądaniach generowanych przez agenta. Drugim sygnałem jest nagły wzrost ilości danych przepuszczanych przez agenta względem jego zwykłego profilu.

Tabela: taktyki ATLAS, techniki i ich sygnały detekcji

Faza (taktyka ATLAS)	Technika charakterystyczna dla agentów	Główny sygnał detekcji
Reconnaissance	Sondowanie API, próby wyciągnięcia promptu systemowego	Seria wariacji tego samego pytania, frazy „pokaż instrukcję“
ML Model Access	Dostęp przez publiczne API, nadużycie klucza	Nietypowy wzorzec użycia klucza, zapytania spoza profilu
LLM Prompt Injection	Pośrednie wstrzyknięcie przez dane (RAG, www, mail)	Rozjazd intencja↔działanie; instrukcje w danych
Persistence	Zatrucie pamięci długotrwałej / bazy wektorowej	Zapis polecenia do wektoryzowanej treści
Execution	Nadużycie wywołań narzędzi	Sekwencja narzędzi spoza listy dozwolonych
Privilege Escalation	Wykorzystanie uprawnień konektorów agenta	Dostęp do danych spoza zakresu sesji
Exfiltration / Impact	Wyprowadzenie danych w treści odpowiedzi/żądania	Sekrety/PII w wyjściu, adres docelowy spoza listy

Tabela jest punktem wyjścia, nie kompletem — pełna macierz ATLAS zawiera więcej technik, a Twój system będzie miał własne. Sens mapowania polega na tym, że dla każdej fazy zapisujesz, jaką telemetrię zbierasz i jaki alert jej odpowiada. Pusta komórka w kolumnie „sygnał detekcji“ to luka, którą trzeba świadomie zaakceptować albo zamknąć.

Jakie sygnały detekcji zbierać, żeby mapowanie miało sens?

Mapowanie do ATLAS jest tyle warte, ile telemetria, która je zasila. Bez logów z warstwy modelu i agenta macierz pozostaje ładnym diagramem na ścianie. Cztery źródła telemetrii są tu nieodzowne i każde odpowiada za inny zestaw faz.

Po pierwsze, pełne logi promptów i odpowiedzi — z zachowaniem rozdziału na to, co przyszło od użytkownika, a co z danych zewnętrznych (RAG, narzędzia). Bez tego rozdziału nie wykryjesz pośredniego wstrzyknięcia, bo nie odróżnisz polecenia od treści. Po drugie, log wywołań narzędzi: które narzędzie, z jakimi parametrami, w jakiej kolejności i z jaką tożsamością. To podstawa detekcji nadużycia i eskalacji. Po trzecie, pochodzenie danych w RAG — skąd wziął się każdy fragment, który trafił do kontekstu, żeby dało się wskazać zatruty dokument. Po czwarte, profil bazowy zachowania agenta: typowe sekwencje, typowa objętość, typowe adresy docelowe — bo większość alertów to odchylenia od tej normy.

Sensownym układem odniesienia przy doborze tej telemetrii jest OWASP Top 10 dla aplikacji LLM, które wprost wymienia wstrzyknięcie promptu i nadmierną sprawczość agenta (excessive agency) jako czołowe ryzyka. ATLAS opisuje „jak“ atak przebiega, OWASP — „co“ w aplikacji jest najsłabsze; razem dają komplet do zaprojektowania alertów. Warto też pamiętać, że detekcja oparta na pojedynczym zdarzeniu prawie zawsze daje fałszywe alarmy — siła leży w korelacji faz: rozpoznanie plus wstrzyknięcie plus nietypowe wywołanie narzędzia w jednej sesji to znacznie mocniejszy sygnał niż każde z osobna.

Jak praktycznie wdrożyć mapowanie ATLAS w zespole?

Zacznij od jednego, konkretnego agenta i rozpisz jego realne ścieżki ataku na fazy ATLAS — nie próbuj od razu objąć całej macierzy. Dla każdego agenta odpowiedz na trzy pytania: jakie ma narzędzia i uprawnienia, skąd bierze dane do kontekstu, i co stałoby się, gdyby ktoś przejął go przez wstrzyknięty prompt. To ćwiczenie samo w sobie ujawnia większość luk.

Następnie zbuduj macierz pokrycia: wiersze to taktyki ATLAS istotne dla tego agenta, kolumny to „mamy telemetrię?“ i „mamy alert?“. Każda para „nie/nie” to świadoma decyzja o ryzyku. Tak powstaje mierzalny obraz dojrzałości — i argument budżetowy, bo widać dokładnie, której fazy nie zobaczysz w razie incydentu. Mapowanie warto też przełożyć na scenariusze ćwiczeń red-team: skoro znasz fazy, możesz odegrać atak krok po kroku i sprawdzić, czy alerty faktycznie się odpalają. Jak prowadzić takie ćwiczenia w sposób powtarzalny, opisujemy w materiałach o red-teamingu i ewaluacji agentów AI.

Na koniec uczciwa uwaga: mapowanie ATLAS to dyscyplina porządkowania wiedzy, a nie produkt do kupienia. Żadne narzędzie nie „włączy ATLAS“ za Ciebie — wartość powstaje, gdy Twój zespół konsekwentnie opisuje incydenty wspólnym słownikiem, wiąże fazy z konkretną telemetrią i regularnie sprawdza, czy detekcja nadąża za zmieniającymi się technikami. Sama macierz to mapa; teren trzeba zbadać samodzielnie.

Podsumowanie

Mapowanie ataków na agentów AI do MITRE ATLAS daje obrońcy trzy rzeczy naraz: wspólny język do opisu incydentów, listę faz, których nie wolno przeoczyć, oraz powiązanie każdej fazy z konkretnym, zbieralnym sygnałem detekcji. Klasyczny ATT&CK tego nie obejmie, bo nie widzi warstwy modelu i granicy między danymi a poleceniem. Klucz do wartościowego mapowania leży nie w samej macierzy, lecz w telemetrii — logach promptów z rozdziałem źródeł, logach narzędzi, pochodzeniu danych w RAG i profilu bazowym agenta — oraz w korelowaniu faz zamiast łapania pojedynczych zdarzeń. Zacznij od jednego agenta, zbuduj macierz pokrycia, odegraj atak w red-teamie i zamykaj luki świadomie.