Bezpieczeństwo konfiguracji agentów AI to bezpieczeństwo łańcucha dostaw

29 kwietnia 2026 roku zespoły bezpieczeństwa zgłosiły przejęte pakiety z ekosystemu SAP, których działanie nie kończyło się na kradzieży poświadczeń. Kampania Mini Shai-Hulud zapisywała też mechanizmy trwałości w konfiguracji deweloperskiej: punktach zaczepienia Claude Code, zadaniach VS Code i plikach przepływów pracy w repozytoriach.¹²³

Ten szczegół przesuwa granicę przeglądu. Zatruty pakiet nie musi pozostać zainstalowany, jeśli może zostawić polecenie startowe w pliku, któremu deweloper ufa. Usunięcie zależności może usunąć pierwszy wyzwalacz. Konfiguracja agenta albo edytora może utrzymać przy życiu następny.

Konfiguracja agentów AI jest wykonywalnym oprogramowaniem. Każdy punkt zaczepienia, zadanie, definicję serwera MCP, umiejętność, wtyczkę, skrypt pakietu i plik przepływu pracy należy traktować jako część łańcucha dostaw oprogramowania, ponieważ te pliki mogą decydować, jaki kod zostanie uruchomiony, zanim człowiek przeczyta diff.

TL;DR

Mini Shai-Hulud pokazał praktyczną ścieżkę od instalacji zależności do trwałości w narzędziach deweloperskich. Badacze bezpieczeństwa opisali złośliwe pakiety npm, które podczas instalacji używały skryptów cyklu życia, zbierały poświadczenia deweloperów i CI oraz zapisywały pliki .claude/settings.json i .vscode/tasks.json, aby ponownie uruchamiać kod z zaufanych powierzchni narzędzi deweloperskich.¹²⁴ Oficjalna dokumentacja potwierdza, że te powierzchnie mają realne uprawnienia wykonawcze: punkty zaczepienia Claude Code uruchamiają polecenia cyklu życia, punkty zaczepienia poleceń wykonują się z uprawnieniami użytkownika, a zadania VS Code folderOpen mogą zostać uruchomione po otwarciu folderu, jeśli użytkownik zezwoli na automatyczne zadania dla tego folderu.⁵⁶

Wniosek nie brzmi: „wyłączyć agentów”. Jest bardziej precyzyjny: konfiguracja agentów należy do przeglądu zależności, przeglądu kodu, reagowania na incydenty i progów wydania. Katalogi z kropką, które kiedyś wyglądały jak lokalne preferencje, dziś leżą na ścieżce wykonywania. Poważna praktyka inżynierii AI potrzebuje przeglądu diffów konfiguracji, przeglądu punktów zaczepienia, przeglądu zadań, tokenów o najmniejszych potrzebnych uprawnieniach oraz audytów powierzchni startowych.

Najważniejsze wnioski

Dla deweloperów: - Przed zaufaniem repozytorium należy przejrzeć .claude/settings.json, .vscode/tasks.json, .github/workflows/*, skrypty w package.json, konfiguracje MCP oraz manifesty wtyczek lub umiejętności agentów. - Nowe punkty zaczepienia uruchamiane przy starcie i zadania wykonywane po otwarciu folderu należy traktować jak nowe pliki wykonywalne. - Po podejrzanej instalacji trzeba usunąć pliki trwałości i zrotować poświadczenia. Samo usunięcie pakietu nie dowodzi, że środowisko zostało wyczyszczone.

Dla zespołów bezpieczeństwa: - Pliki konfiguracji agentów należy dodać do wykrywania zagrożeń w łańcuchu dostaw, CODEOWNERS, reakcji na wycieki sekretów i zakresowania incydentów. - Warto oznaczać każdy PR, który dodaje wykonywanie przy starcie, szerokie polecenia powłoki, nieprzejrzyste pobierane binaria albo ukryte ładunki w katalogach z kropką. - Lepiej używać krótkotrwałych poświadczeń do publikowania i poświadczeń tylko do odczytu przy instalacji. Długowieczne tokeny zapisu pozostają paliwem dla robaków.

Dla twórców platform agentowych: - Powierzchnie wykonywania powinny być widoczne, możliwe do przeglądu i zrozumiałe. - Punkty zaczepienia ładujące kontekst należy oddzielić od punktów zaczepienia uruchamiających polecenia. - Użytkownicy powinni dostać pełnoprawny widok audytu dla działań startowych, zewnętrznych wywołań sieciowych i zmodyfikowanej konfiguracji.

Co zmienił Mini Shai-Hulud

Ataki na łańcuch dostaw wymierzone w menedżery pakietów mają już znany schemat. Zaufany pakiet dostaje złośliwą wersję. Uruchamia się skrypt instalacyjny. Ładunek kradnie tokeny. Usunięcie z rejestru albo cofnięcie wersji przychodzi dopiero wtedy, gdy część deweloperów i zadań CI zdążyła już zainstalować złą wersję.

Mini Shai-Hulud dodał krok bardziej charakterystyczny dla agentów. Raporty Endor Labs, Wiz, Socket, StepSecurity i Cloud Security Alliance opisują ten sam ogólny schemat: przejęte pakiety w ekosystemie deweloperskim SAP wykorzystywały wykonywanie kodu podczas instalacji npm, zbierały poświadczenia GitHub, npm, chmury i CI, a następnie tworzyły trwałość przez konfigurację narzędzi deweloperskich.¹²³⁴⁷

Wiz udokumentował ścieżkę awaryjną, która umieszczała pliki w repozytoriach, aby przyszłe otwarcia w Claude Code lub VS Code mogły ponownie wyzwolić wykonanie.² Endor Labs opisał punkt zaczepienia Claude Code SessionStart oraz zadanie VS Code z runOn: "folderOpen".¹ Tracker kampanii Socket wymienia trwałość przez .claude/settings.json i .vscode/tasks.json obok przejęć pakietów npm i PyPI.³

Dokładny ładunek należy do raportów incydentów, nie do ogólnego artykułu inżynieryjnego. Trwała lekcja jest taka:

Cel przesunął się z jednej wersji pakietu na środowisko deweloperskie wokół pakietu.

Pliki konfiguracji stały się programami startowymi

Dokumentacja punktów zaczepienia Claude Code mówi, że są to zdefiniowane przez użytkownika polecenia powłoki, endpointy HTTP albo prompty LLM, które wykonują się automatycznie przy zdarzeniach cyklu życia.⁵ Ta sama dokumentacja podaje, że SessionStart uruchamia się, gdy Claude Code startuje lub wznawia sesję, a sekcja bezpieczeństwa ostrzega, że punkty zaczepienia poleceń działają z pełnymi uprawnieniami użytkownika.⁵

Dokumentacja zadań VS Code pokazuje kolejną powierzchnię wykonywania. Zadanie może ustawić runOn na folderOpen, a VS Code uruchomi je po otwarciu zawierającego je folderu, jeśli użytkownik zezwoli na automatyczne zadania dla tego folderu.⁶ Ten monit o zgodę ma znaczenie. Obniża ryzyko w porównaniu z cichym wykonaniem na każdej maszynie. Nie czyni jednak pliku nieszkodliwym. Zaufane repozytorium, zmęczony deweloper, wcześniej zaakceptowany obszar roboczy albo polityka organizacji nadal mogą zmienić modyfikację konfiguracji w wykonanie kodu.

npm dokłada pomost w czasie instalacji. Dokumentacja skryptów npm wymienia preinstall, install i postinstall wśród skryptów cyklu życia dla npm ci i npm install, a sekcja dobrych praktyk npm mówi, że autorzy prawie nigdy nie powinni jawnie ustawiać skryptów preinstall ani install, poza kompilacją pod docelową architekturę.⁸

Te trzy fakty tworzą łańcuch ataku:

1. Skrypt instalacyjny uruchamia się podczas instalacji zależności.
2. Skrypt zapisuje albo modyfikuje konfigurację narzędzia deweloperskiego.
3. Edytor lub agent później uruchamia skonfigurowane działanie startowe.
4. Deweloper ufa powierzchni narzędzia, bo monit albo UI wygląda jak zwykła praca.

Niebezpieczna nie jest pojedyncza funkcja. Skrypty instalacyjne, punkty zaczepienia, zadania i przepływy pracy wspierają prawidłową automatyzację. Niebezpieczna jest przechodniość zaufania. Instalacja pakietu nie powinna po cichu definiować, co będzie wykonywać każda przyszła sesja agenta albo każde przyszłe otwarcie folderu.

Granica przeglądu jest źle ustawiona

Większość nawyków przeglądu kodu traktuje pliki źródłowe jako główny artefakt, a pliki konfiguracyjne jako materiał pomocniczy. Ten nawyk zawodzi, gdy pliki konfiguracyjne wykonują polecenia.

Nowy punkt zaczepienia powinien otrzymać taki sam przegląd jak nowy skrypt powłoki. Nowe zadanie powinno otrzymać taki sam przegląd jak nowe binarium. Nowy serwer MCP powinien otrzymać taki sam przegląd jak nowa integracja sieciowa. Nowy skrypt cyklu życia pakietu powinien otrzymać taki sam przegląd jak nowy kod uruchamiany przed testami.

Można użyć takiej tabeli przeglądu:

Obrona w środowisku wykonawczym dla agentów rozszerzonych o narzędzia dowodziła, że egzekwowanie zasad należy umieścić na granicy wywołań narzędzi. Mini Shai-Hulud przesuwa ten sam standard o warstwę wcześniej. Granica startu też wymaga egzekwowania.

Uprawnienia startowe wymagają zasady najmniejszych uprawnień

Zespoły stosują już zasadę najmniejszych uprawnień do kluczy API. Konfiguracja agentów potrzebuje tej samej reguły.

Claude Code rozdziela zdarzenia punktów zaczepienia, takie jak PreToolUse, PostToolUse i SessionStart.⁵ Ten podział powinien kształtować politykę. Punkt zaczepienia, który ładuje statyczny kontekst, nie powinien potrzebować dostępu do powłoki. Punkt zaczepienia, który waliduje polecenie, nie powinien potrzebować dostępu do sieci. Punkt zaczepienia zapisujący lokalne metadane nie powinien potrzebować poświadczeń.

Ta sama reguła dotyczy zadań VS Code i przepływów pracy CI:

Dokumentacja trusted publishing npm wyjaśnia, dlaczego krótkotrwałe poświadczenia mają znaczenie. Trusted publishing używa OIDC, aby publikowanie pakietów mogło odbywać się bez długowiecznych tokenów npm, a npm zaleca wyłączenie tradycyjnego publikowania opartego na tokenach po skonfigurowaniu zaufanych wydawców.⁹ npm zaleca też granularne tokeny dostępu tylko do odczytu przy instalacji prywatnych zależności, gdy publikowanie używa OIDC.⁹

Ta rada nie usuwa ryzyka przepływów pracy. Przejęty przepływ pracy nadal może wyrządzić szkody, jeśli ma zbyt szerokie uprawnienia. Wniosek jest taki, by zawęzić obie strony: krótkotrwałe poświadczenia i wąskie przepływy pracy.

Konfigurację agenta należy traktować jak zależność

Przegląd zależności zwykle pyta, które wersje pakietów się zmieniły. Przegląd w erze agentów powinien pytać, które powierzchnie wykonywania się zmieniły.

Przed zaakceptowaniem aktualizacji zależności, instalacji wtyczki, wygenerowanej konfiguracji albo zmiany szablonu należy sprawdzić:

Nie chodzi o paranoję. Chodzi o poprawną klasyfikację. Plik punktu zaczepienia może wyglądać jak konfiguracja, ale zachowuje się jak kod. Plik zadania może wyglądać jak ustawienia edytora, ale może uruchomić powłokę. Przepływ pracy może wyglądać jak instalacja wydawnicza, ale może sięgać po poświadczenia.

Bezpieczeństwo agentów AI zaczyna się od małego oprogramowania przedstawiało podobny argument od strony projektowej: węższe narzędzia mają mniej miejsc, w których mogą ukrywać się błędy. Wersja bezpieczeństwa mówi, że węższa konfiguracja ma mniej miejsc, w których może ukrywać się trwałość.

Bezpieczny przegląd konfiguracji

Defensywny przegląd nie wymaga wykonywania podejrzanego kodu. Warto zacząć od inspekcji tylko do odczytu:

git diff -- .claude/settings.json .vscode/tasks.json package.json .github/workflows
rg -n '"SessionStart"|"runOn"\\s*:\\s*"folderOpen"|preinstall|postinstall|curl|wget|bun|node .*setup' \
  .claude .vscode package.json .github/workflows
find . -path '*/.claude/*' -o -path '*/.vscode/tasks.json' -o -path '*/.github/workflows/*'

Te polecenia nie dowodzą, że maszyna jest czysta. Dają recenzentowi pierwszy ogląd powierzchni, które najłatwiej zamieniają konfigurację w wykonanie. Jeśli podejrzana instalacja już się wydarzyła, należy przejść do reagowania na incydent, zamiast traktować czysty wynik wyszukiwania jako gwarancję.

Odzyskiwanie wymaga przeglądu konfiguracji

Reagowanie na incydent po przejęciu zależności nie powinno kończyć się na odinstalowaniu pakietu.

Przydatna sekwencja odzyskiwania:

1. Ustalić, czy dotknięta wersja pakietu została zainstalowana na maszynie deweloperskiej albo runnerze CI.
2. Zamrozić to środowisko, zanim wykona kolejną pracę.
3. Przeprowadzić audyt plików konfiguracji startowej w repozytorium oraz konfiguracji agenta lub edytora w katalogu domowym.
4. Usunąć podejrzane punkty zaczepienia, zadania, przepływy pracy, wygenerowane pliki ładunków i nieoczekiwane gałęzie.
5. Zrotować każde poświadczenie dostępne dla dotkniętego procesu, w tym tokeny pakietów, tokeny GitHub, klucze chmurowe, klucze SSH i sekrety CI.
6. Sprawdzić dostęp wydawców pakietów i dostęp zapisu do repozytorium.
7. Przejrzeć logi przepływów pracy pod kątem ujawnienia sekretów i nieoczekiwanych połączeń wychodzących.
8. Odbudować środowisko z czystego checkoutu i znanego dobrego zestawu zależności.

Wskazówki bezpieczeństwa GitHub Actions wspierają część tej reakcji dotyczącą poświadczeń: używać najmniejszych uprawnień dla tokenów przepływów pracy, rotować ujawnione sekrety, audytować obsługę sekretów i rozważyć wymóg przeglądu, zanim zadania uzyskają dostęp do sekretów środowiska.¹⁰ GitHub zaleca też CODEOWNERS dla plików przepływów pracy, aby zmiany w .github/workflows wymagały akceptacji wyznaczonych recenzentów.¹⁰

Konfigurację agentów trzeba dodać do tej samej ścieżki nadzoru. Jeśli .github/workflows/* zasługuje na przegląd właściciela kodu, bo może dotykać sekretów, .claude/settings.json i .vscode/tasks.json zasługują na przegląd, bo mogą uruchamiać polecenia w pobliżu sekretów.

Co powinny zbudować platformy agentowe

Platformy agentowe i edytory mogą zmniejszyć ciężar przeglądu, pokazując uprawnienia startowe wprost.

Przydatne powierzchnie produktu:

Te powierzchnie nie powinny zależeć od tego, czy model przeczyta plik JSON i dokona oceny. Środowisko wykonawcze powinno bezpośrednio ujawniać uprawnienia. Użytkownik powinien widzieć wyraźną różnicę między „ładuje kontekst z README” a „uruchamia polecenie powłoki przy starcie sesji”.

Narzędzia MCP potrzebują autoryzacji na poziomie działań dowodziły, że walidacja tokenów bearer musi prowadzić do kontroli według narzędzia, roli i działania. Konfiguracja agentów potrzebuje tego samego kształtu: każde działanie startowe powinno deklarować potrzebne uprawnienia, a środowisko wykonawcze powinno egzekwować najmniejszy sensowny zestaw.

Praktyczna polityka lokalna

Zespoły mogą zacząć od małego pliku polityki, zanim platformy poprawią interfejs:

Dobra polityka nazywa plik i uprawnienie. Niejasne reguły w rodzaju „ostrożnie z narzędziami agentów” nie przetrwają prawdziwej pracy. Jasne reguły, takie jak „brak punktu zaczepienia polecenia SessionStart bez przeglądu właściciela”, dają recenzentom coś, co można egzekwować.

FAQ

Czy konfiguracja agentów AI naprawdę jest częścią łańcucha dostaw?

Tak. Ryzyko łańcucha dostaw podąża za wykonywaniem i zaufaniem, a nie za rozszerzeniem pliku. Jeśli instalacja pakietu, wtyczka, szablon albo zmiana w repozytorium może zmodyfikować konfigurację agenta, która później wykonuje polecenia, ta konfiguracja znajduje się w łańcuchu dostaw.

Czy zespoły powinny zakazać punktów zaczepienia Claude Code albo zadań VS Code?

Nie. Punkty zaczepienia i zadania wspierają prawidłową automatyzację. Zespoły powinny je przeglądać, ograniczać ich zakres i logować. Punkt zaczepienia ładujący kontekst i startowy punkt zaczepienia wykonujący powłokę nie powinny otrzymywać tego samego poziomu zaufania.

Czy VS Code pyta przed uruchomieniem zadań po otwarciu folderu?

Dokumentacja VS Code mówi, że gdy użytkownik po raz pierwszy otwiera folder zawierający zadanie folderOpen, VS Code pyta, czy zezwolić na automatyczne zadania dla tego folderu.⁶ Ten monit pomaga, ale zadanie nadal zasługuje na przegląd kodu, ponieważ akceptacja zamienia plik w ścieżkę wykonywania.

Czy npm trusted publishing rozwiązuje problem przejęcia pakietu?

Nie. Trusted publishing zmniejsza ryzyko związane z długowiecznymi tokenami zapisu npm dzięki krótkotrwałym poświadczeniom opartym na OIDC.⁹ Zespoły nadal potrzebują przeglądu przepływów pracy, zasady najmniejszych uprawnień, monitorowania pakietów i reagowania na incydenty związane z przejętymi repozytoriami albo złośliwymi skryptami instalacyjnymi.

Co najpierw audytować po podejrzanej instalacji?

Najpierw należy sprawdzić skrypty uruchamiane w czasie instalacji, konfigurację startową agentów i edytorów, pliki przepływów pracy, nieoczekiwane pliki w katalogach z kropką, nowe gałęzie oraz poświadczenia dostępne dla dotkniętego procesu. Następnie trzeba zrotować poświadczenia z dotkniętego środowiska.

Zakończenie

Agenci kodujący AI zwiększają moc konfiguracji. Zwiększają też jej ryzyko.

Właściwą odpowiedzią nie jest lęk przed automatyzacją. Właściwą odpowiedzią jest uczciwość co do tego, gdzie znajduje się wykonywanie kodu. Jeśli plik może uruchomić polecenie, pobrać dane, przeczytać sekrety, opublikować pakiety albo zmienić zachowanie agenta, należy go włączyć do ścieżki przeglądu.

Konfiguracja agentów przekroczyła tę granicę. Należy traktować ją jak kod.

Źródła