Plik umiejętności. Plik reguł. Konfiguracja serwera MCP. Trzy linijki zwykłego tekstu. commitSą one testowane jak dokumentacja, przeglądane jak dokumentacja, a żaden z nich nie wygląda jak kod. A jednak każdy z nich potrafi po cichu przepisać to, co Twój asystent AI ma do zrobienia i do czego ma dostęp. Oto niewygodna prawda o bezpieczeństwie AI. w 2026Branża przez dwa lata martwiła się o to, co zawiera kod generowany przez sztuczną inteligencję. Trudniejszym problemem okazał się sam łańcuch dostaw sztucznej inteligencji: modele, agenci, serwery MCP i pliki konfiguracyjne, które teraz znajdują się obok kodu źródłowego i zależności open source, w dużej mierze niezinwentaryzowane i nieprzejrzane. Właśnie dlatego bezpieczeństwo łańcucha dostaw sztucznej inteligencji stało się odrębną dziedziną i dlaczego wybór odpowiedniej firmy zajmującej się bezpieczeństwem sztucznej inteligencji jest równie ważny, jak wybór odpowiedniego skanera.
Powierzchnia ataku, na którą nikt nie przeznaczyła budżetu
Oprogramowanie miało kiedyś kilka miejsc, w których atakujący mógł się znaleźć: kod, zależności, pipeline. AI dodało kolejne dwa i oba zasilają bezpośrednio łańcuch dostaw AI.
Modelka i agent. Zatruwanie narzędzi, szybkie wstrzykiwanie kodu, autonomia agentów wykraczająca poza wszelkie oczekiwania. Ukryta instrukcja w opisie serwera MCP może dyskretnie przekierować działania drugiego pilota, a programista nigdy tego nie zauważy.
Własne środowisko programisty. Środowiska IDE, współpiloci AI, serwery MCP, interfejsy CLI agentów. Niewidoczne dla starszych skanerów AppSec, które nie wiedzą, czym jest model, i niewidoczne dla EDR, które monitoruje system operacyjny i nie ma pojęcia, czym jest zależność ani wywołanie MCP.
Nic z tego nie jest teoretyczne. W ciągu ostatnich osiemnastu miesięcy:
- Ukryty „backdoor” w pliku reguł Unicode umożliwiał atakującym wstrzyknięcie niewidocznych instrukcji do plików konfiguracyjnych Copilot i Cursor read, dyskretnie wprowadzając backdoora do kodu generowanego przez asystenta. GitHub dodał ostrzeżenie o tym w 2025 roku.
- Luka umożliwiająca wstrzykiwanie poleceń w popularnym moście MCP (CVSS 9.6) została pobrana ponad 400 000 razy, zanim ją naprawiono. Był to pierwszy udokumentowany przypadek pełnego zdalnego wykonania kodu wywołanego samym połączeniem się z niezaufanym serwerem MCP.
- Samorozprzestrzeniający się robak npm sprawił, że sami programiści stali się mechanizmem dostarczającym oprogramowanie, a ten schemat powtórzył się na dużą skalę w kolejnych miesiącach w innych ekosystemach, stanowiąc typowy przykład awarii bezpieczeństwa łańcucha dostaw sztucznej inteligencji.
- Naukowcy odkryli, że znaczna część pakietów rekomendowanych przez LLM w ogóle nie istnieje – są to „slopsquatted” nazwy rejestrowane przez atakującego zanim prawdziwy programista poprosi model o ich zaimportowanie.
Własne badania Google nad zabezpieczaniem łańcucha dostaw oprogramowania AI prowadzą do podobnych wniosków, ale z innej perspektywy: modele znalezione w 2023 i 2024 roku wyglądały na legalne, mimo że zawierały kod, który po pobraniu mógł wykraść dane lub zainstalować tylną furtkę, a rozwiązanie nie polegało na nowej kategorii narzędzi, a raczej na zastosowaniu dyscypliny łańcucha dostaw, takiej jak pochodzenie i podpisywanie, do artefaktów, których nikt wcześniej nie śledził. To w jednym zdaniu streszcza problem bezpieczeństwa łańcucha dostaw AI: artefakty są nowe, ale dyscyplina, której potrzebują, już nie.
Dlaczego Twoje obecne narzędzia są niewystarczające
SAST odczytuje kod. SCA Odczytuje manifest zależności. Żadne z nich nie wie, czym jest model, co ujawnia serwer MCP ani co plik umiejętności instruuje agenta. Ta luka to właśnie miejsce, w którym lądują ataki ery sztucznej inteligencji, w przestrzeni między „kodem, który skanujemy” a „sztuczną inteligencją, którą po cichu zaadaptowaliśmy”.
Rezultatem jest kategoria sztucznej inteligencji cienia CISO może obecnie odpowiedzieć na pytania: jakie modele wykorzystujemy, którzy agenci mogą do czego dotrzeć i z którym serwerem MCP ktoś połączył się w zeszły wtorek, nie informując nikogo o tym. Udzielenie dobrej odpowiedzi na to pytanie jest zadaniem bezpieczeństwa łańcucha dostaw AI i to właśnie dlatego ogólne narzędzia AppSec wciąż zawodzą w tym zakresie.
Co tak naprawdę oznacza bezpieczeństwo sztucznej inteligencji
Xygeni jest firmą zajmującą się bezpieczeństwem sztucznej inteligencji, która traktuje to jako trzy połączone ruchy w SDLC: odkryć, wykryć i wyegzekwować.
Odkryj: dowiedz się, jaką sztuczną inteligencję tak naprawdę posiadasz
Ciągłe, automatyczne odkrywanie w repozytoriach ujawnia wszystkie zasoby sztucznej inteligencji: modele, struktury, zestawy danych, punkty końcowe wnioskowania, agentów, serwery MCP, umiejętności, monity, guardrailsi narzędzia do kodowania AI, z których faktycznie korzystają Twoi programiści. Bez ankiet. Bez samooceny. Jeśli pozostawiło ślad w repozytorium, pojawi się w inwentarzu – pierwszym i najbardziej podstawowym wymogu rzeczywistego bezpieczeństwa łańcucha dostaw AI.
Następnie wykres AI mapuje sposób, w jaki te zasoby się łączą: który model jest zasilany przez zbiór danych, który agent wywołuje które narzędzie, który serwer MCP obsługuje którego asystenta. Zasób w izolacji niewiele mówi. Wykres pokazuje, gdzie koncentruje się ryzyko.
Na podstawie tego samego odkrycia Xygeni generuje AI-BOM: gotowy do audytu, czytelny dla maszyn spis wszystkiego, co jest związane ze sztuczną inteligencją w Twoim oprogramowaniu. Gdy regulator, audytor lub klient zapyta, jaką sztuczną inteligencję wykorzystujesz, odpowiedzią będzie pobranie danych zamiast trzytygodniowego poszukiwania.
Wykryj: zagrożenia, których nie widzą konwencjonalne skanery
Dedykowany skaner AI wyszukuje tryby awarii specyficzne dla systemów AI: wstrzyknięcie natychmiastowe, wstrzyknięcie narzędzia i niezaufane wywołanie narzędzia, wyciek danych podczas pobierania, ominięcie komunikatu systemowego, nadmierna ingerencja. Każde odkrycie jest mapowane na OWASP Top 10 dla aplikacji LLM i wskazuje na konkretny plik i linię, która powoduje ujawnienie, a nie na ogólny alert „sprawdź wykorzystanie sztucznej inteligencji”.
Ta sama warstwa wykrywania traktuje pliki umiejętności, pliki reguł i konfiguracje MCP jako artefakty bezpieczeństwa, a nie jako nieszkodliwą dokumentację. Oznacza ona złośliwe lub zatrute umiejętności, sprawdza konfiguracje serwerów MCP pod kątem zatrucia narzędziami i wyświetla monity, które faktycznie napędzają obciążenia AI.
Priorytet: lejek, który redukuje hałas, a nie narożniki
Każde odkrycie jest filtrowane progresywnie: najpierw do tego, co jest osiągalne w kodzie aplikacji, następnie do tego, co rzeczywiście nadaje się do wykorzystania, a na końcu do tego, co znajduje się w kodzie, nad którym Twój zespół aktywnie pracuje. Do kolejki programistów trafia krótka lista zagrożeń, które faktycznie zagrażają produkcji, wraz z dołączonym odniesieniem do frameworka, oknem narażenia i wskazówkami dotyczącymi minimalizacji ryzyka.
Wymuś: zatrzymaj przed uruchomieniem
Shield wprowadza egzekwowanie zasad do punktu końcowego programisty: blokuje nieautoryzowane i złośliwe instalacje, niezatwierdzone modele i niezatwierdzone serwery MCP przed wykonaniem jakichkolwiek operacji. Pod spodem znajduje się Xygeni Wczesne ostrzeganie przed złośliwym oprogramowaniem (MEW), który wychwytuje złośliwe pakiety, zanim powstanie ich sygnatura, narzędzia oparte na reputacji warstwy nadal budzą zaufanie, ponieważ nikt jeszcze nie zgłosił pakietu. To egzekwowanie przepisów w zakresie bezpieczeństwa łańcucha dostaw AI: wykrywanie i detekcja informują o nieprawidłowościach. Shield jest tym, co faktycznie powstrzymuje ten proces.
Twoja ekspozycja na sztuczną inteligencję nie ogranicza się tylko do kodu AI
Aby uzyskać kompletny obraz bezpieczeństwa łańcucha dostaw sztucznej inteligencji, potrzeba czegoś więcej niż tylko inwentaryzacji modeli, a rzadko kiedy są to tylko chwytliwe informacje:
- Dane uwierzytelniające dostawcy sztucznej inteligencji pozostawione w plikach monitu, konfiguracjach agentów lub pipeline logi są tajemnicą taką samą jak każda inna, a system wykrywania tajemnic Xygeni wychwytuje je zanim trafią do publicznego rejestru.
- Zależności podatne na ataki sztucznej inteligencji i uczenia maszynowego niosą ze sobą typowe luki w zabezpieczeniach (CVE), ujawnione w wyniku tej samej analizy kompozycji oprogramowania, która obejmuje już resztę stosu. Badania niezależnych firm nad wdrażaniem sztucznej inteligencji (AI) wskazują, jak duża część nowoczesnego stosu AI to pakiety pochodzące z zewnętrznych źródeł i ukryte komponenty, co stanowi dokładnie ten obszar, który analiza kompozycji oprogramowania miała objąć.
- Złośliwe pakiety opublikowano szybciej niż jakakolwiek porada pipeline można je skatalogować, są one wychwytywane przed podpisem, ta sama funkcja MEW chroni resztę łańcucha dostaw.
Warstwa agentowa: DevAI i CoreAI
Odkrywanie i wykrywanie obejmuje elementy już znajdujące się w Twoich repozytoriach. DevAI Działa tam, gdzie powstaje ryzyko: wewnątrz IDE, jako ciągła, proaktywna warstwa, która skanuje kod generowany przez ludzi i sztuczną inteligencję w trakcie jego pisania, bez konieczności wyświetlania monitów. Wyjaśnia pełną ścieżkę exploita stojącą za wykryciem i proponuje poprawki zatwierdzone przez MCP, które programista może zastosować z pewnością, bez zakłócania kompilacji.
CoreAI znajduje się nad poszczególnymi skanerami jako warstwa inteligencji: koreluje kod, zależności, pipelinei dane o postawie w jeden model ryzyka, odpowiada na pytania w języku naturalnym i generuje raporty gotowe do przekazania kadrze kierowniczej, których potrzebuje lider ds. bezpieczeństwa, aby pokazać, że zarządzanie rzeczywiście ma miejsce, a nie jest tylko deklarowane.
Rozszerz to, co masz w AI Security. Nie wyrywaj niczego.
Najczęstszym zarzutem wobec nowej kategorii bezpieczeństwa jest: „mamy już wystarczająco dużo narzędzi”. Jako firma zajmująca się bezpieczeństwem sztucznej inteligencji, Xygeni nie wymaga od Ciebie wymiany czegokolwiek: ta sama selekcja, wyjaśnienia i priorytetyzacja stosowana do jej własnych ustaleń ma zastosowanie również do ustaleń z Twojej istniejącej SAST, SCAi skanery innych firm. Twój obecny stos staje się materiałem wejściowym, a nie ofiarą, a bezpieczeństwo Twojego łańcucha dostaw sztucznej inteligencji poprawia się bez konieczności usuwania i zastępowania go nowym projektem.
Dlaczego to ma znaczenie teraz, a nie później
Organy regulacyjne zbiegają się z tymi samymi oczekiwaniami, ale z różnych kierunków: unijna ustawa o sztucznej inteligencji (AI Act), NIS2 i hiszpańskie przepisy ENS (End of Information Systems) dążą do inwentaryzacji i identyfikowalności systemów AI, czyli do gromadzenia tych samych dowodów, dla których AI-BOM ma być tworzony. Kierunek rozwoju jest jasny, nawet jeśli dokładne mechanizmy zgodności wciąż się stabilizują: nie można poświadczyć, że AI nigdy nie było inwentaryzowane, i nie można twierdzić, że łańcuch dostaw AI jest bezpieczny, jeśli sam łańcuch dostaw jest dla nas niewidoczny.
Wybór firmy zajmującej się bezpieczeństwem sztucznej inteligencji
Nie każda firma zajmująca się bezpieczeństwem AI wyznacza swoje granice w tym samym miejscu. Niektóre ograniczają się do skanowania własnego kodu generowanego przez AI. Inne zatrzymują się na punkcie końcowym. Kwestia bezpieczeństwa łańcucha dostaw AI jest szersza niż którykolwiek z tych segmentów osobno: obejmuje model, agenta, serwer MCP, plik umiejętności i zwykłe zależności leżące u podstaw tego wszystkiego. Pełny widok cyklu życia, od wykrywania po egzekwowanie, w jednej konsoli z pozostałymi wynikami AppSec, to właśnie tego należy szukać, oceniając firmę zajmującą się bezpieczeństwem AI, a nie pojedynczego narzędzia.
Pliki, których nikt nie sprawdza, stały się przepustką do wejścia. Bezpieczeństwo sztucznej inteligencji (AI) polega na ich sprawdzaniu, a bezpieczeństwo łańcucha dostaw AI jest tym, co sprawia, że ta dyscyplina jest wszechstronna, na tej samej platformie, na której sprawdza się już wszystko inne.
Sprawdź, co Twoja sztuczna inteligencja może faktycznie robić. Zacznij za darmo or zaplanuj demo.
FAQ
Czy kod Xygeni kiedykolwiek opuści moją infrastrukturę?
Nie. Skanowanie odbywa się w Twoim własnym środowisku, a kod źródłowy nigdy nie jest przesyłany na serwery Xygeni. Inwentarz AI i AI-BOM są tworzone na podstawie danych, które skaner widzi lokalnie, a nie na podstawie kopii przesłanej na zewnątrz.
Jaka jest różnica pomiędzy AI Security, DevAI i CoreAI?
Rozwiązanie AI Security wykrywa i analizuje: tworzy inwentarz AI (AI-BOM) i wykrywa zagrożenia, takie jak natychmiastowe wstrzyknięcie kodu czy zatrute pliki umiejętności. DevAI działa w środowisku IDE, podczas gdy programiści piszą kod, proponując poprawki na bieżąco. CoreAI nadzoruje oba te procesy, korelując wyniki z całej platformy i odpowiadając na pytania dotyczące stanu bezpieczeństwa w języku naturalnym.
Z którymi ramami bezpieczeństwa sztucznej inteligencji współpracuje Xygeni?
Wyniki pokrywają się z listą OWASP Top 10 dla aplikacji LLM, OWASP Top 10 dla MCP i OWASP Top 10 dla umiejętności agentów, a także z listą NIST SP 800-218A i CISWytyczne A/G7 dotyczące zestawień materiałowych AI. To mapowanie sprawia, że zestawienie AI-BOM może służyć jako dowód zgodności, a nie tylko jako inwentaryzacja.
Czy to oznacza, że każda biblioteka lub model sztucznej inteligencji jest zagrożeniem?
Nie. Lejek priorytetyzacji zawęża wyniki do tego, co jest osiągalne w kodzie aplikacji, co rzeczywiście nadaje się do wykorzystania i co jest aktywnie rozwijane, więc lista, którą widzi deweloper, jest krótka i nie jest to zbiór wszystkich wykrytych zasobów sztucznej inteligencji.
