TL; DR
Termin „zagrożenia bezpieczeństwa sztucznej inteligencji” obejmuje dwa różne zjawiska: ataki wymierzone w systemy sztucznej inteligencji oraz ataki wykorzystujące sztuczną inteligencję jako broń. Wymagają różnych kontroli, różnych właścicieli i różnych dowodów, a większość list łączy je ze sobą, dlatego tak trudno na nie zareagować. Pierwsze pięć z poniższych dotyczy Twojej sztucznej inteligencji. Pozostałe pięć wykorzystuje sztuczną inteligencję w Twoim łańcuchu dostaw.
- Zagrożenia dla systemów AI tkwią głównie w konfiguracji, a nie w modelu. Zakres narzędzia, poświadczenia, z którymi korzysta agent, plik reguł,
.mcp/servers.jsonwpis. Żaden z nich nie jest osiągalny z punktu końcowego modelu, dlatego samo użycie metody red-teaming daje czysty wynik. - Ataki wykorzystujące sztuczną inteligencję zwykle odbywają się poprzez zależności, a nie przez obwód. Halucynowane nazwy pakietów zarejestrowane przez atakujących, samoistnie rozprzestrzeniające się robaki wykorzystujące dane uwierzytelniające programistów, klucze dostawcy sztucznej inteligencji jako cel.
- Dziewięć z dziesięciu to pytania dotyczące konkretnych rzeczy. Które serwery MCP, które agenci, który zakres, które dane uwierzytelniające, który plik reguł, który pakiet. Dokument polityki nie odpowiada na żadne z nich.
- Każda z dziesięciu osób ma jeden warunek wstępny. Nie można bronić zasobu sztucznej inteligencji, którego nigdy nie zmapowano, co sprawia, że odkrycie jest krokiem poprzedzającym sterowanie, a nie następującym po nim.
Jakie są dwa rodzaje zagrożeń bezpieczeństwa sztucznej inteligencji?
Większość list zagrożeń bezpieczeństwa sztucznej inteligencji łączy oba te zagrożenia, dlatego trudno jest na nie reagować.
- Zagrożenia dla systemów AI Traktuj swoją sztuczną inteligencję jako cel. Ktoś manipuluje modelem, zatruwa instrukcje, które wykonuje, lub nadużywa uprawnień nadanych agentowi. Zadaniem obrońcy jest powstrzymanie: ograniczenie zasięgu, jaki może osiągnąć zaatakowana sztuczna inteligencja.
- Ataki oparte na sztucznej inteligencji Traktuj sztuczną inteligencję jako narzędzie atakującego. Celem jest zwykłe oprogramowanie: zależności, dane uwierzytelniające, systemy kompilacji, programiści. Zadaniem obrońcy jest szybkie wykrycie, ponieważ zmieniła się ekonomia ataku, a jego wolumen wzrósł.
Potrzebują różnych mechanizmów kontroli, różnych właścicieli i różnych dowodów. Zespół, który przeprowadził redteaming swojego chatbota, nie zrobił nic w sprawie slopsquattingu. Zespół z doskonałym screeningiem zależności może nadal korzystać z agenta z dostępem do zapisu w repozytoriach produkcyjnych i bez limitu zakresu. Oba zagrożenia stanowią zagrożenie dla bezpieczeństwa sztucznej inteligencji. Żadne z nich nie eliminuje drugiego.
Zagrożenia dla systemów AI: pięć najczęściej występujących
01. Szybki wtrysk docierający do zlewu narzędzia
Niezaufana treść dociera, zostaje scalona w monit systemowy, a agent po drugiej stronie może wywołać narzędzia. Monit nie jest luką w zabezpieczeniach. Droga od niezaufanych danych wejściowych do niebezpiecznej funkcji jest.
Właśnie dlatego samo szybkie filtrowanie rozczarowuje. Usztywnia jeden koniec łańcucha, podczas gdy interesujące jest pytanie, czy gdzieś pomiędzy danymi wejściowymi a wywołaniem narzędzia znajduje się jakaś bariera ochronna. OWASP Top 10 dla aplikacji LLM utrzymuje szybką iniekcję na szczycie listy, ale łączy ją z nadmierną agencją właśnie z tego powodu.
Czego szukać: niepewne dane wejściowe docierające do monitu systemowego, pobieranie kontekstu bez oczyszczania oraz dostępne ujścia narzędzi bez żadnej bariery ochronnej pomiędzy.
02. Złośliwe pliki zasad i umiejętności
Plik reguł jest zwykłym tekstem. Jest committed jak dokumentacja i przeglądane jak dokumentacja, a także instruuje asystenta, co ma robić. Znaki o zerowej szerokości sprawiają, że linie są niewidoczne w pull request diff, pozostając przy tym całkowicie czytelnym dla agenta.
ATLAS MITROWY Kataloguje to jako Backdoor Pliku Reguł, studium przypadku AML.CS0041. Recenzent zatwierdza konwencję formatowania. Agent odczytuje instrukcję importu z pakietu kontrolowanego przez atakującego i nie informuje o tym.
Czego szukać: Pliki reguł, pliki umiejętności i szablony komunikatów analizowane jako kod, a nie proza, z wykrywaniem niewidocznych znaków.
03. Niebezpieczna konfiguracja serwera MCP
Konfiguracja MCP To miejsce, w którym agent przyjmuje zamówienia i gdzie gromadzone są dane uwierzytelniające. Obie części stanowią problem. Luka CVE-2025-6514, ujawniona w lipcu 2025 r., stanowiła krytyczne wstrzyknięcie polecenia systemu operacyjnego do powszechnie używanego mostu MCP, z wynikiem CVSS 9.6 i umożliwiającą wykonywanie dowolnych poleceń na hoście klienta podczas łączenia się z niezaufanym serwerem.
Połowa z danymi uwierzytelniającymi jest gorsza, ponieważ jest pasywna. Badania przeprowadzone w 2026 roku wykazały, że w plikach konfiguracyjnych MCP w publicznym serwisie GitHub znajduje się ponad 24 000 sekretów, z czego ponad 2,000 jest nadal ważnych.
Czego szukać: inwentaryzacja używanych serwerów MCP, ich wersji, zadeklarowanych narzędzi i wykrywania sekretów w plikach konfiguracyjnych.
04. Nadmierna sprawczość
Agent z szerokim zakresem narzędzi i długoterminowym poświadczeniem to stała eskalacja uprawnień czekająca na aktywację. Nic nie musi zostać wykorzystane, żeby to zaszkodziło. Zdezorientowany agent i agent zhakowany wyrządzają podobne szkody, gdy obaj mają dostęp do zapisu, którego nigdy nie potrzebowali.
To najmniej efektowny i najczęściej występujący element na liście. Ma też najtańszą poprawkę, czyli redukcję zakresu, która jest rzadko stosowana, ponieważ nikt nie jest właścicielem pytania.
Czego szukać: jacy agenci istnieją, co każdy z nich może wywołać, na podstawie czyich uprawnień oraz czy ktoś zatwierdził ten zakres.
05. Zatrute modele, zbiory danych i zależności AI
Stos AI opiera się na zwykłych pakietach i hostowanych artefaktach. Modele są pobierane z publicznych hubów. Zbiory danych są pobierane z dowolnego miejsca. Oba rozwiązania wiążą się z tym samym problemem pochodzenia, co każda zależność, z mniejszą liczbą narzędzi i znacznie mniejszym zakresem kontroli.
Czego szukać: modele, ramy i zestawy danych traktowane jako komponenty łańcucha dostaw, z tą samą analizą składu i tą samą Śledzenie CVE tak samo jak pozostałych zależności.
Ataki oparte na sztucznej inteligencji: pięć czynników zmieniających Twój łańcuch dostaw
06. Przysiady
Badania zaprezentowane na konferencji USENIX Security w 2025 roku wygenerowały 2.23 miliona próbek kodu w 16 modelach i wykazały, że 19.7% rekomendowanych pakietów nie istniało, generując ponad 205 000 unikalnych nazw halucynacyjnych. Około 43% tych nazw powtarzało się w kolejnych uruchomieniach tego samego komunikatu, co czyni je możliwymi do „farmienia”.
Atakujący nie muszą już naruszać bezpieczeństwa osoby zarządzającej. Rejestrują nazwę wymyśloną przez agenta i czekają na instalację. Pakiet nie ma podpisu ani ostrzeżenia, ponieważ jest nowy i nikt go wcześniej nie widział.
Czego szukać: skanowanie złośliwego oprogramowania, które opiera się na zachowaniu, a nie na reputacji, i jest stosowane do każdej zależności dodanej przez agenta.
07. Samorozmnażające się robaki w łańcuchu dostaw
Robak npm z września 2025 r. Wyznaczyło to moment, w którym maszyny programistyczne stały się mechanizmem dostarczania, a nie celem. Ten schemat powtarzał się na dużą skalę do 2026 roku. Każde naruszone poświadczenie programisty publikuje kolejną rundę naruszonych pakietów, a promień rażenia zwiększa się zamiast zwiększać.
Czego szukać: anomalna działalność wydawnicza, niezwykła commit wzorce i sposób wykorzystania poświadczeń, które nie odpowiadają normalnemu zachowaniu programisty.
08. Państwowe ataki na uprawnienia AI
W marcu 2026 roku pakiet z około 100 milionami pobrań tygodniowo został naruszony na czas liczony w godzinach, a celem było uzyskanie kluczy API dostawcy sztucznej inteligencji. Okno było celowo krótkie. Wystarczająco długie, aby je zebrać i zminimalizować ryzyko wykrycia.
Dane uwierzytelniające AI są teraz celem samym w sobie, ponieważ zapewniają moc obliczeniową, dostęp i wiarygodną tożsamość. Liczba ataków mających na celu ich kradzież gwałtownie wzrosła między końcem 2025 a początkiem 2026 roku.
Czego szukać: Klucze dostawców sztucznej inteligencji traktowane są jako sekrety, które można wykryć i unieważnić w taki sam sposób jak dane uwierzytelniające w chmurze.
09. Oprogramowanie złośliwe stworzone lub zainstalowane przy użyciu LLM
Do 2026 roku udokumentowano przypadki wykorzystania modelu językowego do umieszczenia złośliwego kodu w przepływie pracy agenta. Istotne jest nie to, że złośliwe oprogramowanie było nowatorskie. Chodzi o to, że autorstwo przestało być wąskim gardłem, a liczba potencjalnie wiarygodnie wyglądającego złośliwego kodu dostępnego dla atakującego odpowiednio wzrosła.
Czego szukać: wykrywanie nie jest to uzależnione od wcześniejszego zobaczenia próbki.
10. Przegląd załamania pojemności
To nie jest atak, dlatego jest ostatnie i najważniejsze. Kiedy agent generuje tysiąc plików tygodniowo, przegląd kodu przestaje być kontrolą, a staje się kolejką. Każde inne zagrożenie na tej liście staje się łatwiejsze do przezwyciężenia, gdy ostatnia kontrola ludzka jest przeciążona.
Czego szukać: ustalenia uszeregowane według możliwości wykorzystania, a nie według stopnia powagi, tak aby te niewielkie, stanowiące zagrożenie dla produkcji, faktycznie docierały do deweloperów.
Dziesięć zagrożeń to mapa. Omówienie każdego z nich zajmuje więcej czasu niż wpis na blogu, więc przeprowadziliśmy odpowiednią rozmowę. W tym odcinku… Rozmowy SafeDevJesús Cuadrado, dyrektor generalny Xygeni, rozmawia z Atanasem Nikolovem, ekspertem DevSecOps i SSDLC Lider techniczny, o polimorficznym złośliwym oprogramowaniu, szybkim wstrzykiwaniu, manipulowaniu modelami i o tym, co faktycznie się z nimi wiąże. Bez formularza, bez bramki.
Dlaczego nie możesz bronić zasobów sztucznej inteligencji, których nie zmapowałeś?
Przeczytaj te dziesięć pytań jeszcze raz, a trudno nie zauważyć tego schematu. Dziewięć z nich to pytania o konkretne rzeczy: które serwery MCP, którzy agenci, który zakres, które dane uwierzytelniające, który plik reguł, który pakiet.
Na żadne z tych pytań nie da się odpowiedzieć w dokumencie polityki. Odpowiedzi udziela inwentaryzacja, której większość organizacji nie posiada. Sztuczna inteligencja pojawiła się dzięki programistom, którzy działali szybko, bez zgłoszenia, procesu zamówień ani wpisu do repozytorium, który deklarowałby się jako sztuczna inteligencja.
To sprawia, że mapowanie jest warunkiem wstępnym, a nie pierwszym krokiem. Program wykrywania zagrożeń bezpieczeństwa AI, który zaczyna się od kontroli, zastosuje je do znanej sobie sztucznej inteligencji, która jest podzbiorem, którego nie da się skalować. Najpierw trzeba odkryć: modele, frameworki, zestawy danych, punkty końcowe wnioskowania, agentów, serwery MCP, umiejętności, monity i narzędzia do kodowania AI, z których faktycznie korzystają programiści, wraz z relacjami między nimi, ponieważ zasób w izolacji niewiele mówi, a ryzyko koncentruje się w łańcuchu.
Ramy zarządzania ryzykiem NIST AI Z tego samego powodu funkcja „map” jest stawiana przed funkcją „measure” i „manage”. Jest to najmniej interesująca funkcja w systemie i od niej zależy wszystko inne.
Na jakie zagrożenia bezpieczeństwa sztucznej inteligencji należy zareagować w pierwszej kolejności?
Nie najbardziej wyrafinowany. Najbardziej dostępny.
- W tym tygodniu: Zlicz swoje serwery MCP i przeprowadź wykrywanie sekretów na ich plikach konfiguracyjnych. Zagrożenie 03 to najwyższy stosunek narażenia do wysiłku na liście, a prawie nikt się tym nie interesował.
- Ten miesiąc: Znajdź swoich agentów i zapisz, co każdy z nich może zrobić i z czyich uprawnień. To rozwiąże problem zagrożenia 04, które jest najczęstsze i najtańsze w redukcji.
- W tym kwartale: Umieszczaj behawioralne skanowanie złośliwego oprogramowania przed każdą zależnością dodaną przez agenta. Obejmuje to zagrożenia 06, 07 i 09 jednocześnie, ponieważ wszystkie trzy obalają kontrole oparte na reputacji, ponieważ są nowe.
Wszystko inne może poczekać na te trzy, ponieważ wszystko inne zakłada, że już wiesz, co masz.
Organizacje, które dobrze radzą sobie z zagrożeniami bezpieczeństwa AI w 2027 roku, nie będą tymi, które będą miały najlepsze oceny modeli. To one będą w stanie odpowiedzieć, w dowolny wtorek, na pytanie, jakie funkcje AI są wykorzystywane w ich oprogramowaniu i do jakich celów może dotrzeć. Taka jest sytuacja. Xygeni został zbudowany wokół: ciągłego odkrywania każdego zasobu AI w repozytoriach i pipelineczyli ocena ryzyka w oparciu o ramy, które audytorzy już znają, oraz kontrola łańcucha dostaw, która wychwytuje to, co jeszcze nie ma podpisu.
Dziesięć zagrożeń, dwie kategorie, jedna mapa pod nimi.
FAQ
Czy zagrożenia bezpieczeństwa sztucznej inteligencji rzeczywiście różnią się od zagrożeń bezpieczeństwa zwykłych aplikacji?
Częściowo. Konsekwencje są znane: wykonanie kodu, kradzież danych uwierzytelniających, ujawnienie danych. Zmienia się punkt wejścia i szybkość. Pliki konfiguracyjne, które wcześniej były nieaktywne, teraz zawierają instrukcje, na podstawie których coś działa, a koszt stworzenia przekonującego złośliwego kodu dla atakującego spadł. Twoje obecne mechanizmy kontroli nadal obowiązują, po prostu nie obejmują już całej powierzchni.
Czy redteaming naszych modeli rozwiązuje większość tych zagrożeń?
Odnosi się do części jednego z nich. Red-teaming odpowiada na pytanie, czy model da się namówić do czegoś, czego powinien odrzucić, co jest naprawdę przydatne. Nie widzi zakresu narzędzia, danych uwierzytelniających, pliku reguł ani konfiguracji MCP, ponieważ żadne z nich nie jest dostępne przez punkt końcowy modelu. Czysty raport red-teamingu i agent z niebezpiecznie wysokimi uprawnieniami współistnieją bez sprzeczności.
Które z tych zagrożeń bezpieczeństwa sztucznej inteligencji jest najbardziej niedoceniane?
Nadmierna agencja, i to z dużą przewagą. Nie ma CVE, żadnego exploita do zademonstrowania, ani dostawcy oferującego dedykowany produkt, więc nie generuje pilnej potrzeby. To również różnica między incydentem kontrolowanym a niekontrolowanym, ponieważ zakres decyduje o tym, jak daleko posunie się cokolwiek po pierwszym błędzie.
W jaki sposób ataki oparte na sztucznej inteligencji zmieniają to, co powinniśmy mierzyć?
Przenoszą użyteczną metrykę z wagi zagrożenia na czas. Gdy złośliwe pakiety są generowane szybciej niż publikowane są sygnatury, „ile krytycznych pakietów jest otwartych” ma mniejsze znaczenie niż „jak szybko coś nowego zostaje oznaczone”. Zmierz odstęp czasu między wprowadzeniem zależności do bazy kodu a jej sprawdzeniem oraz między zgłoszeniem błędu a dotarciem do programisty, który może podjąć odpowiednie działania.
