Co kwartał projektOWASP Security publikuje zestawienie najważniejszych incydentów związanych z bezpieczeństwem sztucznej inteligencji z danego okresu, przyporządkowując każdy z nich do listy OWASP 10 dla LLM oraz do nowej listy Top 10 dla aplikacji agentowych. Wydanie za pierwszy kwartał 2026 roku zasługuje na uwagę każdego specjalisty ds. bezpieczeństwa — nie ze względu na pojedyncze naruszenie, ale na wzorzec, który przewija się we wszystkich tych przypadkach.
Własne podsumowanie OWASP nazywa to wprost: dziedzina ta przeszła od risk teoretycznego risk rzeczywistych ataków, a działania wyszły poza sam model. Atakujący i osoby dopuszczające się naruszeń skupiają się obecnie na tożsamościach agentów, warstwach koordynacji i łańcuchach dostaw — a nie tylko na wynikach modeli. Zasługę za przeprowadzenie badań należy przypisać OWASP autorom raportów, na które się ona powołuje; poniżej przedstawiam moją analizę czterech incydentów, które mają największe znaczenie dla przedsiębiorstw podlegających regulacjom, oraz wymagania, jakie każdy z nich stawia przed stosowanymi przez Państwa mechanizmami kontroli.
„Zapewnienie bezpieczeństwa sztucznej inteligencji wymaga obecnie przejścia od zabezpieczeń na poziomie modeli do kompleksowych mechanizmów kontroli bezpieczeństwa systemowego, tożsamości i operacyjnego”. — Projekt OWASP Security, podsumowanie za I kwartał 2026 r.
To zdanie mogłoby stanowić misję przewodnią wszystkiego, co tworzymy w OneCompliant. Poniżej po każdym zdarzeniu przedstawiono OneCompliant — środek kontroli, który pozwoliłby je wykryć lub ograniczyć.
1. GrafanaGhost — kiedy pulpit nawigacyjny staje się kanałem wycieku danych
Zgodnie z OWASP (opierającym się na badaniach firmy Noma Security) osoby atakujące mogły umieścić ukryte instrukcje w treściach zewnętrznych, które były pobierane przez asystenta AI serwisu Grafana. Zainfekowany kontekst skłonił asystenta do wyrenderowania zewnętrznego obrazu — a to wywołanie renderowania spowodowało przemycenie danych przedsiębiorstwa na serwer kontrolowany przez atakującego w postaci parametru URL. Grafana załatała ścieżkę renderowania obrazów w formacie Markdown i zaznaczyła, że wykorzystanie luki wymagało znaczącej interakcji ze strony użytkownika. Jednak to charakter ataku ma znaczenie: zaufana warstwa obserwowalności, zawierająca dane telemetryczne, informacje o infrastrukturze, dane klientów oraz dane finansowe, stała się źródłem wycieku.
Wszystko, co asystent AI pobiera — logi, linki, pulpity nawigacyjne, zgłoszenia — należy traktować jako dane wejściowe, których wiarygodności nie można mieć pewności, i kontrolować, jakie informacje może on wysyłać. Jest to pośrednie wstrzyknięcie promptu; należy je modelować pod kątem zagrożeń tak samo jak XSS czy SSRF. Asystent posiadający szeroki dostęp do danych telemetrycznych nigdy nie powinien mieć jednocześnie nieograniczonej ścieżki wyjściowej. Należy sprawdzać kontekst trafiający do modelu oraz kontrolować, jakie informacje mogą z niego wychodzić.
2. Vertex AI „Double Agent” — tożsamość to nowa granica bezpieczeństwa
Zgodnie z podsumowaniem (na podstawie informacji podanych przez Palo Alto Unit 42) wdrożony agent w usłudze Vertex AI Agent Engine platformy Google Cloud uzyskał znacznie szersze uprawnienia niż to było konieczne za pośrednictwem konta usługowego zarządzanego przez Google. Badacze wykorzystali ten nadmiernie rozbudowany profil dostępu do wyodrębnienia danych uwierzytelniających, podszywania się pod agenta usługi, uzyskania dostępu do zasobów projektów klientów, a nawet do zastrzeżonych wewnętrznych obrazów i kodu źródłowego. Firma Google następnie zaktualizowała swoje wytyczne. Wniosek nie brzmi: „Vertex jest niebezpieczny” — chodzi o to, że domyślne ustawienia platformy zarządzanej zapewniły agentowi większy zakres dostępu, niż ktokolwiek zamierzał.
Tożsamość agenta zasługuje na taką samą kontrolę, jak uprawnienia administracyjne o podwyższonym poziomie dostępu. Domyślnie należy stosować zasadę minimalnego uprawnienia agenta, określać zakres uprawnień dla poszczególnych wdrożeń, stosować krótkotrwałe poświadczenia oraz prowadzić na bieżąco wykaz wszystkich tożsamości usług powiązanych z działaniem agenta. Nie należy polegać na domyślnych ustawieniach platformy — należy wyraźnie sprawdzić, czy agent może uzyskać dostęp do innych projektów, zasobników, rejestrów lub infrastruktury modelowej.
3. Wyciek informacji o wewnętrznym agencie firmy Meta — zasięg skutków jednej niebezpiecznej odpowiedzi
Jak wynika z podsumowania (na podstawie informacji z „The Guardian”), inżynier firmy Meta poprosił o pomoc na wewnętrznym forum, agent AI zaproponował rozwiązanie, a inżynier je wdrożył — co spowodowało krótkotrwałe ujawnienie ogromnej ilości poufnych danych użytkowników i firmy inżynierom na około dwie godziny. Nie doszło do ataku z zewnątrz, a firma Meta oświadczyła, że żadne dane użytkowników nie zostały niewłaściwie przetworzone, jednak sytuacja ta wywołała poważną wewnętrzną reakcję służb bezpieczeństwa. Jest to wyraźny przykład tego, jak pojedyncza niebezpieczna rekomendacja agenta może przerodzić się w incydent związany z kontrolą dostępu na skalę przedsiębiorstwa.
Pomiędzy zaleceniem generowanym przez sztuczną inteligencję a jego realizacją musi istnieć warstwa kontrolna. Każde zalecenie, które może zmienić uprawnienia, widoczność danych lub policy przed wdrożeniem przejść deterministyczną weryfikację oraz kontrolę przeprowadzoną przez człowieka — zwłaszcza w ramach procesów inżynieryjnych i związanych z bezpieczeństwem. Wyniki działania agenta należy traktować jako niewiarygodne, dopóki nie zostaną zweryfikowane.
4. Mercor / LiteLLM — łańcuch dostaw sztucznej inteligencji jest szerszy niż same modele
Zgodnie z podsumowaniem (na podstawie informacji magazynu WIRED) firma Meta wstrzymała współpracę z dostawcą danych dla sztucznej inteligencji, firmą Mercor, po naruszeniu bezpieczeństwa związanym ze złośliwymi wersjami narzędzia open source LiteLLM. Ponieważ Mercor obsługuje zastrzeżone procesy generowania danych szkoleniowych dla głównych laboratoriów, incydent ten wzbudził obawy, że poufne metody przetwarzania danych szkoleniowych oraz działania podwykonawców mogły zostać ujawnione — co skłoniło do ponownej oceny sytuacji w wielu laboratoriach. Włamanie nastąpiło poprzez zależność oprogramowania w stosie powiązanym ze sztuczną inteligencją, a nie w samym modelu.
Twój łańcuch dostaw w zakresie sztucznej inteligencji obejmuje biblioteki koordynujące, integracje MCP oraz dostawców generujących dane. Zidentyfikuj i zweryfikuj zależności, wymagaj od dostawców rozwiązań AI dokumentacji w stylu SBOM oraz dojrzałości w zakresie reagowania na incydenty, a także traktuj dostawców danych jako kluczowych partnerów w ramach programu zarządzania — a nie jako dodatek do procedur zakupowych.
Wątek, który je łączy
OWASP drugą kwestię, która powinna zmienić sposób postrzegania risk związanych ze sztuczną inteligencją: większość tych incydentów nie posiada numeru CVE. Nie są to pojedyncze błędy w kodzie — chodzi o nieprawidłową konfigurację, nadmierną autonomię, słabe granice zaufania oraz manipulację przepływem danych. Jedynie klasyczna wada oprogramowania wbudowanego, taka jak aktywnie wykorzystywana luka w Flowise umożliwiająca zdalne wykonanie kodu (CVE-2025-59528), idealnie wpisuje się w tradycyjne zarządzanie podatnościami.
Na tym właśnie polega luka. Jeśli risk związanym ze sztuczną inteligencją opiera się na skanowaniu w poszukiwaniu luk CVE, to z natury rzeczy nie uwzględnia większości przypadków, w których sztuczna inteligencja faktycznie zawodzi. Są to zagrożenia systemowe i architektoniczne, które wymagają mechanizmów kontrolnych działających w czasie wykonywania — obejmujących tożsamość, sprawczość i przepływ danych — oraz generujących dowody.
„Działania przeniosły się z wyników modeli na tożsamości, koordynację i łańcuchy dostaw. Zarządzanie musi podążać za tym trendem — od dokumentów ku mechanizmom kontroli operacyjnej”.
Właśnie taką warstwę OneCompliant : OASF obszary kontroli, OASAT , na jakim poziomie się znajdujesz w odniesieniu do nich, a Aegis je w momencie użytkowania — sprawdzając monity i kontekst, regulując, jakie dane mogą opuszczać system, określając zakres uprawnień agentów oraz rejestrując każdą decyzję jako dowód. Raporty takie jak OWASP to sygnał z praktyki, który pokazuje nam, incydent po incydencie, dlaczego ta warstwa nie jest już opcjonalna.
Zapoznaj się z pełnym zestawieniem — to naprawdę cenne kwartalne źródło informacji, a OWASP materiały do niego: Zestawienie luk w zabezpieczeniachOWASP , I kwartał 2026 r. →
Te zdarzenia odpowiadają środkom kontroli. Czy je posiadacie?
OASAT Twoje środowisko AI pod kątem właśnie tych rodzajów awarii — tożsamości, sprawczości, łańcucha dostaw oraz przepływu danych — a Aegis środki kontroli w czasie wykonywania. Zidentyfikuj luki, zanim staną się one Twoim zgłoszeniem do podsumowania.