Tak — kampania FakeGit pokazuje, że agent AI może samodzielnie odnaleźć fałszywe repozytorium GitHub, uznać jego dokumentację za wiarygodną i przekazać użytkownikowi instrukcję instalacji złośliwego oprogramowania. Firmy wdrażają Claude Code, ChatGPT, Gemini, serwery MCP i agentów automatyzujących pracę, aby szybciej budować produkty, integrować systemy oraz redukować koszty operacyjne — ale rekomendacja narzędzia wygenerowana przez AI nie jest weryfikacją bezpieczeństwa dostawcy ani kodu.
To ryzyko nie dotyczy wyłącznie zespołów programistycznych. Dotyczy każdej organizacji, w której agenci AI mają dostęp do przeglądarki, terminala, VPS, firmowych danych, tokenów API, poczty lub środowisk produkcyjnych.
Najważniejsza zasada: rekomendacja narzędzia wygenerowana przez AI nie jest weryfikacją bezpieczeństwa dostawcy ani kodu.
Na czym polega FakeGit i AgentBaiting?
FakeGit to opisana przez badaczy kampania wykorzystująca tysiące złośliwych repozytoriów GitHub podszywających się pod prawdziwe projekty. Część z nich udaje narzędzia dla agentów AI: skills, integracje oraz serwery Model Context Protocol (MCP).
Badacze wskazali niemal 7 600 złośliwych repozytoriów, z czego ponad 800 podszywało się pod AI skills lub serwery MCP. W testach modele i narzędzia AI miały samodzielnie odnajdywać takie projekty podczas realizacji polecenia użytkownika, bez wcześniejszego otrzymania bezpośredniego linku.
To zjawisko nazwano AgentBaiting. Atakujący optymalizuje fałszywe repozytorium, profil, README i wydania plików tak, aby agent potraktował je jak użyteczną odpowiedź na polecenie typu: „znajdź darmowy MCP server do tej usługi” albo „znajdź skill do automatyzacji tego zadania”.
Dlaczego README nie jest dowodem zaufania?
README może wyglądać profesjonalnie, zawierać zrzuty ekranu, instrukcję wdrożenia, nazwę znanej firmy oraz link do pliku instalacyjnego. Nie jest jednak niezależnym dowodem pochodzenia kodu.
W modelu AgentBaiting złośliwa instrukcja nie musi trafić do pracownika e-mailem ani przez phishing. Może zostać przekazana przez firmowego asystenta AI jako pozornie przydatna odpowiedź robocza.
Jakie ryzyko powstaje dla firmy?
Najgroźniejszym elementem nie jest samo pobranie nieznanego repozytorium. Problemem jest połączenie niezweryfikowanego kodu z uprawnieniami, sekretami oraz dostępem, które organizacja już nadała narzędziom i użytkownikom.
Złośliwy komponent może próbować przejąć:
- tokeny API do systemów AI, CRM, automatyzacji i chmury;
- klucze SSH używane do dostępu do VPS lub repozytoriów;
- pliki
.env, dane konfiguracyjne i hasła zapisane lokalnie; - aktywne sesje przeglądarki, cookies oraz sesje SSO;
- dostęp do skrzynek pocztowych, systemów plikowych i paneli administracyjnych;
- dane klientów, leady handlowe oraz informacje operacyjne.
W opisywanej kampanii malware SmartLoader był wykorzystywany do ustanowienia trwałości, a następnie do dostarczenia narzędzia kradnącego informacje StealC. Po takim incydencie samo zmienienie hasła może nie wystarczyć, jeżeli przejęte zostały aktywne sesje, tokeny API albo klucze dostępu.
Gdzie firmy popełniają błąd?
Najczęstszy błąd to traktowanie AI jako bezpiecznego pośrednika między pracownikiem a otwartym internetem. Model może syntetyzować informacje i wykonywać zadania, ale nie zastępuje procesu kwalifikacji dostawcy oprogramowania.
Ryzyko rośnie szczególnie wtedy, gdy firma:
- pozwala agentom automatycznie pobierać pliki lub wykonywać polecenia z README;
- używa wspólnego konta administratora do testów, automatyzacji i produkcji;
- przechowuje sekrety w lokalnych plikach dostępnych dla narzędzi AI;
- instaluje MCP servers, rozszerzenia i skrypty bez kontroli źródła;
- używa publicznych katalogów narzędzi jako listy „zatwierdzonych” rozwiązań;
- nie prowadzi ewidencji aktywnych integracji, tokenów i kont serwisowych;
- nie oddziela środowiska testowego od produkcyjnego.
W praktyce agent może być tylko początkiem łańcucha. Instalacja jednego pozornie wygodnego dodatku może otworzyć drogę do kradzieży danych uwierzytelniających, dostępu do infrastruktury i dalszego ruchu wewnątrz organizacji.
Jak ograniczyć ryzyko AgentBaiting?
Skuteczna ochrona nie polega na zakazaniu AI. Polega na oddzieleniu etapu researchu od etapu instalacji oraz na ograniczeniu konsekwencji błędnej rekomendacji.
- Ustal katalog zatwierdzonych narzędzi. Prowadź wewnętrzną allowlistę zatwierdzonych repozytoriów, wydawców, serwerów MCP, bibliotek i rozszerzeń. Każde nowe narzędzie powinno mieć właściciela biznesowego, jasno określony cel oraz rejestr uprawnień. Nie traktuj liczby gwiazdek, forków, pozycji w katalogu ani jakości README jako samodzielnej kontroli bezpieczeństwa.
- Weryfikuj źródło przed instalacją. Sprawdź właściciela repozytorium i historię jego konta, zgodność nazwy projektu z oficjalną stroną producenta, historię commitów, wydań i osób współtworzących, sposób dystrybucji — zwłaszcza gdy README kieruje do plików ZIP lub wykonywalnych instalatorów — zależności oraz wymagane uprawnienia, a także podpisy, sumy kontrolne i oficjalne kanały publikacji, jeżeli są dostępne.
- Uruchamiaj nowe komponenty poza produkcją. Nowy MCP server, skill lub skrypt powinien najpierw działać w odizolowanym środowisku testowym i nie powinien otrzymywać dostępu do produkcyjnych tokenów, skrzynek e-mail, dysków współdzielonych ani paneli administracyjnych. Stosuj osobne konta serwisowe i tokeny o minimalnym zakresie. Uprawnienia do odczytu, zapisu, wysyłki e-maili, uruchamiania poleceń i dostępu do systemów klientów powinny być nadawane oddzielnie, celowo i możliwie czasowo.
- Wymagaj zatwierdzenia człowieka. Agent AI może przygotować propozycję narzędzia, ale nie powinien samodzielnie pobierać i uruchamiać plików wykonywalnych, instalować pakietów spoza zatwierdzonego katalogu, zmieniać konfiguracji infrastruktury, dodawać tokenów, kluczy lub danych dostępowych do nowego narzędzia ani wykonywać poleceń pobranych z zewnętrznego README. Dobra reguła operacyjna brzmi: AI może rekomendować, człowiek zatwierdza, a środowisko testowe weryfikuje.
Co zrobić po podejrzanej instalacji?
Jeżeli pracownik lub agent uruchomił niezweryfikowany komponent, należy traktować sytuację jako potencjalny incydent bezpieczeństwa. Nie zakładaj, że odinstalowanie narzędzia usuwa wszystkie skutki.
Pierwsze działania powinny obejmować:
- Odizolowanie urządzenia, kontenera lub VPS od sieci, gdy jest to uzasadnione.
- Zabezpieczenie informacji potrzebnych do analizy: logów, historii poleceń, procesów, harmonogramów zadań i aktywności sieciowej.
- Unieważnienie oraz rotację tokenów API, kluczy SSH, haseł aplikacyjnych i poświadczeń kont serwisowych dostępnych z danego środowiska.
- Wylogowanie aktywnych sesji, w tym sesji SSO i paneli SaaS, a nie tylko zmianę hasła.
- Przegląd nowych kont, zadań cyklicznych, reguł przekazywania poczty, integracji oraz zmian w repozytoriach i konfiguracji.
- Ustalenie, czy dane klienta, dokumenty, dane uwierzytelniające lub tajemnice handlowe mogły zostać skopiowane.
Głos eksperta
„Wdrażanie agentów AI bez zasad pozyskiwania narzędzi przypomina dopuszczenie niezweryfikowanego dostawcy bezpośrednio do firmowej infrastruktury. Problem nie zaczyna się wtedy, gdy model udziela złej odpowiedzi. Zaczyna się wtedy, gdy ta odpowiedź może automatycznie pobrać kod, użyć sekretów i wykonać działanie w środowisku firmy.”
— inż. Marcin Białczyk, Founder i Cybersecurity Operator CHORS.NET
W CHORS.NET patrzymy na bezpieczeństwo agentów AI jako na część realnej powierzchni ataku firmy. Obejmuje ona nie tylko domenę i serwer, ale także integracje, konta serwisowe, tokeny, dostępy oraz proces podejmowania decyzji o instalacji nowych narzędzi.
Najczęściej zadawane pytania
Czy ChatGPT, Gemini lub Claude Code mogą polecić złośliwe repozytorium?
Tak. Jeżeli model lub agent wyszukuje publicznie dostępne narzędzia, może odnaleźć repozytorium przygotowane przez atakującego i potraktować jego README jako wiarygodne źródło instrukcji. Rekomendacja AI nie powinna zastępować weryfikacji wydawcy, kodu i sposobu dystrybucji.
Czy serwer MCP jest bezpieczny, jeśli znajduje się na GitHubie?
Sama obecność na GitHubie nie potwierdza bezpieczeństwa. Serwer MCP należy traktować jak komponent łańcucha dostaw oprogramowania: sprawdzić wydawcę, historię projektu, zależności, wymagane uprawnienia, sposób instalacji oraz zakres dostępu do danych i narzędzi.
Czy liczba gwiazdek i forków GitHub potwierdza wiarygodność projektu?
Nie. Metryki popularności mogą zostać sztucznie zwiększone, a fałszywy projekt może naśladować wygląd oraz nazwę legalnego repozytorium. Weryfikacja powinna opierać się na oficjalnych kanałach producenta, historii projektu i kontroli technicznej przed wdrożeniem.
Czy zmiana hasła wystarczy po uruchomieniu podejrzanego narzędzia?
Niekoniecznie. Malware kradnące informacje może przejąć tokeny API, klucze SSH, cookies i aktywne sesje. Po incydencie należy ocenić ekspozycję środowiska i rozważyć unieważnienie wszystkich poświadczeń oraz sesji, do których zainfekowany system miał dostęp.
Jak CHORS.NET pomaga ograniczyć ryzyko związane z agentami AI?
Usługa Continuous Monitoring pomaga stale obserwować zmiany w cyfrowej powierzchni ataku firmy, wykrywać nowe ekspozycje, błędne konfiguracje i istotne zmiany wymagające reakcji. W ramach współpracy można także uporządkować zasady bezpiecznego korzystania z narzędzi AI, kont serwisowych i integracji.
Zadbaj o kontrolę nad agentami AI
Jeżeli Twoja firma używa agentów AI, MCP servers, automatyzacji, VPS lub integracji z narzędziami SaaS, potraktuj źródła kodu i uprawnienia agentów jako część powierzchni ataku. Ustal, które ekspozycje, integracje oraz zmiany w środowisku wymagają stałego nadzoru.
Zobacz usługę Skan ekspozycji internetowej → lub Audyt podatności →