Luka bezpieczeństwa Anthropic Google: agenci AI podążali za zaufaną dokumentacją do nieprzejętego kodu

Anthropic i Google znalazły się w centrum sporu dotyczącego bezpieczeństwa po tym, jak badacze poinformowali, że agenci programistyczni wykonywali pakiety wskazane w zaufanej dokumentacji firmowej. Jeden pakiet testowy miał zostać uruchomiony w środowisku firmy z listy Fortune 500 w ciągu czterech minut. Claude, OpenAI Codex i Hermes od Nous Research pojawiły się później w zapisach procesów, według badaczy.

Ustalenia nie dowodzą, że Anthropic, Google ani OpenAI celowo dystrybuowały złośliwe oprogramowanie. Większość pakietów zarejestrowanych na potrzeby eksperymentu zawierała nieszkodliwe beacony, które jedynie zgłaszały swoje uruchomienie. Poważniejszym odkryciem był niezwiązany z eksperymentem, rzekomo złośliwy pakiet npm powiązany z instrukcjami opublikowanymi wcześniej na stronie dostawcy uwierzytelniania Clerk.

To rozróżnienie ma znaczenie, ponieważ pierwotne relacje mogą sugerować, że trzej dostawcy AI naruszyli bezpieczeństwo sieci korporacyjnych. Dowody wskazują raczej na awarię w łańcuchu dostaw oprogramowania. Agenci zaufali pozornie oficjalnym instrukcjom, dotarli do publicznych rejestrów pakietów i wykonali nazwy, których nikt nie zabezpieczył.

Google pojawia się w tej historii o bezpieczeństwie Anthropic Google za sprawą wsparcia dla sprawdzania plików llms.txt w Lighthouse, swoim oprogramowaniu do audytu stron internetowych. Claude i Codex pojawiają się przez agentów, którzy mieli podążać za instrukcjami instalacji. Wspólnym problemem nie jest jeden model ani jedna firma. Jest nim zacierająca się granica między dokumentacją a wykonywalnym działaniem.

Ta granica kiedyś wydawała się wyraźna. Deweloper mógł przeczytać przewodnik konfiguracji, zweryfikować pakiet i zdecydować, czy go zainstalować. Autonomiczny agent programistyczny może skompresować te kroki do jednej operacji, często korzystając z istniejących uprawnień dewelopera.

Rezultat to nowe pytanie dotyczące bezpieczeństwa dla każdej organizacji wdrażającej agentów programistycznych: gdy oprogramowanie czyta dokument, kto weryfikuje, czy dokument nadal prowadzi do czegoś godnego zaufania?

Korporacyjni agenci AI wykonywali nazwy, których nikt nie posiadał

Badacze przekształcili nieaktualną dokumentację w wykonywalny dowód na to, że zaufany tekst może stać się punktem wejścia.

Badacz bezpieczeństwa Alon Hertz i jego współpracownicy przeanalizowali dokumentację odczytywalną maszynowo w 6 214 aktywnych domenach. Ich próbka obejmowała wykonawców sektora obronnego, duże firmy technologiczne i organizacje z listy Fortune 500.

Badacze poinformowali o znalezieniu 8 265 plików llms.txt i llms-full.txt. Plik llms.txt to rozwijająca się konwencja organizująca zawartość witryny dla modeli językowych i agentów AI. Jego większy odpowiednik może udostępniać obszerniejszą dokumentację w pojedynczym pliku odczytywalnym maszynowo.

Wśród zebranych plików 120 stron internetowych miało wskazywać co najmniej jeden niezarejestrowany pakiet lub nieprzejętą domenę. Zespół naliczył 227 poleceń obejmujących nieistniejące pakiety lub miejsca docelowe.

Nie były to koniecznie wrogie instrukcje. Niektóre wyglądały jak zwykłe polecenia instalacyjne wskazujące nazwy pakietów, które nigdy nie zostały zarejestrowane. Inne odnosiły się do domen, które wygasły, lub usług, do których nikt już nie zgłaszał praw.

Wiersz taki jak pip install package-name staje się niebezpieczny, gdy nazwa pakietu jest dostępna w PyPI. Ta sama zasada dotyczy npm, RubyGems, NuGet, crates.io, Packagist lub porzuconej subdomeny hostingu.

Badacze zarejestrowali niewielki wybór tych dostępnych nazw. Następnie opublikowali pakiety zawierające kod zaprojektowany tak, aby po wykonaniu kontaktował się z ich serwerem. Relacja z badań Hertza podaje, że pierwsze połączenie zwrotne nadeszło ze środowiska firmy z listy Fortune 500 w ciągu czterech minut.

Dwa kolejne systemy miały wykonać kod w pierwszej godzinie. Z czasem zespół otrzymał kilkadziesiąt połączeń zwrotnych od startupów i dużych przedsiębiorstw.

Połączenie zwrotne rejestrowało łańcuch procesów nadrzędnych, który identyfikuje programy uczestniczące w uruchamianiu procesu. Według badaczy zapisy te łączyły część instalacji z Claude, OpenAI Codex i Hermes od Nous Research.

Eksperyment nie wymagał naruszenia tych modeli. Nie opierał się też na nowo odkrytej luce w oprogramowaniu, wiadomości phishingowej ani skradzionym haśle pracownika. Agenci mieli znaleźć instrukcje opublikowane na legalnych stronach internetowych i podążać za nimi, korzystając z dostępu dostępnego w swoich środowiskach.

To jest kluczowe odwrócenie sytuacji. Dokumentacja korporacyjna zwykle wzmacnia bezpieczeństwo, pokazując deweloperom zatwierdzony sposób konfiguracji oprogramowania. Tutaj porzucone odwołania w tej dokumentacji stworzyły komuś innemu możliwość określenia, co wykona zatwierdzone polecenie.

Ustalenia wymagają też ostrożnego języka. Badacze nie zidentyfikowali publicznie dotkniętych przedsiębiorstw, nie ujawnili wszystkich nazw pakietów ani nie przedstawili wystarczającej telemetrii, by osoby z zewnątrz mogły odtworzyć każde przypisanie do firmy. Anthropic, OpenAI i Nous Research nie skomentowały sprawy przed publikacją pierwotnego raportu.

Nawet przy tych ograniczeniach eksperyment pokazuje wiarygodny mechanizm. Publiczny rejestr pakietów przypisuje znaczenie temu, kto kontroluje daną nazwę. Oficjalna dokumentacja może zachować tę nazwę długo po tym, jak jej pierwotne znaczenie zniknie.

Dlaczego łańcuch zaufania Anthropic Google zawiódł

Agenci nie zignorowali modelu zaufania. Podążali za modelem zaufania, który przestał odpowiadać sposobowi działania autonomicznego oprogramowania.

Tradycyjna dokumentacja zakłada, że między instrukcjami a wykonaniem znajduje się człowiek. Taki czytelnik może zauważyć dziwną nazwę pakietu, sprawdzić jego wydawcę lub zapytać, dlaczego polecenie konfiguracji nie ma wspierającego repozytorium.

Agent może wykonywać te same kontrole, ale tylko wtedy, gdy wymagają tego jego instrukcje i środowisko. W przeciwnym razie optymalizuje działanie pod kątem ukończenia zleconego zadania. Znalezienie oficjalnej dokumentacji i uruchomienie zawartego w niej polecenia instalacyjnego może wyglądać jak najkrótsza prawidłowa ścieżka.

Powiązanie Anthropic Google pokazuje, jak kilka niezależnie rozsądnych decyzji może połączyć się w jeden ryzykowny łańcuch. Strony publikują wskazówki odczytywalne maszynowo. Narzędzia Lighthouse od Google zachęcają deweloperów, aby te wskazówki były łatwe do odnalezienia. Agenci programistyczni szukają autorytatywnego kontekstu. Menedżery pakietów ułatwiają pobieranie i wykonywanie zależności.

Żaden z tych elementów nie musi być złośliwy. Zagrożenie pojawia się, gdy agent traktuje cały łańcuch jako uwierzytelniony.

Wskazówki Lighthouse od Google opisują audyt dostępności i formatowania llms.txt. Lighthouse nie certyfikuje każdego polecenia ani zależności wskazanej w pliku. Pomyślne przejście audytu formatowania nie mówi zatem nic o własności pakietu, tożsamości wydawcy ani bezpieczeństwie kodu.

Podobnie HTTPS potwierdza, że plik pochodzi z domeny pokazanej w połączeniu przeglądarki. Nie dowodzi, że każdy wskazany pakiet nadal należy do operatora tej domeny.

Publiczny rejestr może też udostępniać poprawnie zapisaną nazwę pakietu z konta kontrolowanego przez atakującego. Różni się to od klasycznego typosquattingu, w którym atakujący rejestrują literówkę przypominającą popularny pakiet. Nazwy w tym eksperymencie miały zostać skopiowane bezpośrednio z oficjalnej dokumentacji.

To sprawia, że instrukcje są bardziej przekonujące zarówno dla agentów, jak i ludzi. Deweloper przeglądający transkrypcję terminala może zobaczyć oficjalną domenę, znanego menedżera pakietów i wiarygodnie brzmiącą nazwę zależności. Każdy widoczny sygnał może wyglądać rutynowo.

Zachowanie agenta podczas wyszukiwania dodatkowo pogłębia problem. Użytkownik może wspomnieć jedynie dostawcę, prosząc o integrację. Agent może odnaleźć dokumentację dostawcy, odkryć llms.txt, wybrać polecenie instalacyjne i wywołać menedżera pakietów, nie otrzymując od użytkownika podejrzanego linku.

Dlatego incydent jest szerszy niż prompt injection. Prompt injection zwykle obejmuje wrogą treść próbującą przekierować agenta. Tutaj sama instrukcja może być nieszkodliwa i historycznie uzasadniona. Awaria bezpieczeństwa występuje później, gdy własność wskazanego miejsca docelowego się zmienia lub nigdy nie istniała.

Powstająca konwencja llms.txt również nie jest odpowiednikiem formalnego standardu sieciowego z ustaloną architekturą bezpieczeństwa. Jej użyteczność wynika z dostarczania modelom zwięzłego, uporządkowanego kontekstu. Ta sama wygoda może koncentrować instrukcje operacyjne w miejscu, któremu agenci są zachęcani ufać.

Luka bezpieczeństwa Anthropic Google jest więc problemem pochodzenia. Pochodzenie oznacza dowody wskazujące, skąd pochodzi artefakt i kto go kontroluje. Agent zweryfikował lokalizację dokumentu, ale najwyraźniej nie ustalił pochodzenia wykonywalnej zależności stojącej za poleceniem.

Prawdziwym przeciwnikiem jest autonomia bez potwierdzonego pochodzenia

Kluczowym konfliktem nie jest Claude kontra Codex. Jest nim autonomiczne wykonanie kontra zweryfikowana własność oprogramowania.

Claude, Codex i Hermes korzystają z różnych modeli, interfejsów i systemów uprawnień. Traktowanie tego zdarzenia jako prostego porównania tych narzędzi przeoczyłoby wspólny warunek działania stojący za zgłoszonymi instalacjami.

Każdy agent programistyczny może czytać kontekst projektu, konsultować dokumentację, edytować pliki i wywoływać narzędzia programistyczne. Te możliwości czynią agentów użytecznymi, ponieważ eliminują ręczne przejścia między badaniem a wykonaniem.

Przenoszą też decyzję bezpieczeństwa do przepływu pracy agenta. Ktoś musi zdecydować, czy zależność jest autentyczna, czy jej wersja jest akceptowalna i czy jej skrypty instalacyjne powinny zostać uruchomione.

Menedżery pakietów rutynowo wykonują kod podczas instalacji. Pakiet npm może definiować skrypty cyklu życia, podczas gdy pakiet Python może wykonywać zachowanie związane z instalacją poprzez proces budowania. Dokładne zachowanie różni się, ale instalacja nie jest równoznaczna z pobraniem nieaktywnego tekstu.

Przykład Clerk pokazuje, dlaczego ma to znaczenie. Badacze odkryli, że plik instrukcji na legalnej stronie Clerk odwoływał się do npx clerk-next-fix-auth-protection. Narzędzie npx może pobrać pakiet i wykonać udostępnione przez niego polecenie bez trwałego dodawania go do manifestu projektu.

Według śledztwa dotyczącego bezpieczeństwa, ktoś przejął tę nazwę pakietu i użył jej do dystrybucji aktywnego złośliwego oprogramowania. Clerk później poprawił dokumentację.

Nadal nie jest jasne, czy ten pakiet spowodował infekcje za pośrednictwem agenta AI. Relacja wskazuje również, że istniejący plik binarny z legalnej wtyczki ESLint firmy Clerk był bezpieczny. Maszyna, na której brakowało tego legalnego pliku binarnego, mogła zamiast tego pobrać pakiet kontrolowany przez atakującego.

Różnica jest na tyle subtelna, że może umknąć pośpiesznemu recenzentowi. Obie ścieżki zaczynają się od polecenia opublikowanego przez prawdziwego dostawcę. Obie korzystają z infrastruktury npm. Niebezpieczna ścieżka zależy od tego, czy oczekiwany plik binarny już istnieje lokalnie.

To praktyczny kompromis, przed którym stoją przedsiębiorstwa. Agenci zapewniają większą wartość, gdy mogą rozwiązywać zależności, uruchamiać testy i naprawiać błędy bez oczekiwania na zatwierdzenie po każdym poleceniu. Te same uprawnienia pozwalają, by błędna decyzja o zaufaniu przekształciła się w wykonanie kodu.

Dostawca modelu może ograniczać to ryzyko poprzez piaskownice i zatwierdzenia. Przedsiębiorstwo nadal musi skonfigurować te mechanizmy, utrzymywać polityki sieciowe i zdecydować, do których źródeł pakietów agent może uzyskać dostęp.

Dostawca oprogramowania odpowiada za inną część problemu. Jego dokumentacja stała się zasobem operacyjnym, a nie statyczną treścią marketingową. Odwołania do pakietów, przykładowe domeny, kopiowane polecenia i zarchiwizowane strony konfiguracji wymagają teraz takiego samego zarządzania cyklem życia jak kod wykonywalny.

Operatorzy rejestrów również wpływają na wynik. Rezerwowanie przestrzeni nazw, weryfikacja wydawców, skanowanie podejrzanych pakietów i historia własności mogą pomóc. Rejestry nie zawsze jednak wiedzą, że niezastrzeżona nazwa pojawia się w dokumentacji strony trzeciej.

Ten podział odpowiedzialności sprawia, że proste obwinianie nikogo nie pomaga. Narracja dotycząca Anthropic i Google jest ważna, ponieważ przekracza granice produktów. Narzędzie wyszukiwania lub dokumentacji może ułatwić znalezienie instrukcji, agent AI może je zinterpretować, a rejestr może dostarczyć wskazany artefakt.

Bezpieczeństwo zawodzi, gdy każdy uczestnik zakłada, że ktoś inny zweryfikował własność.

Istniejące zabezpieczenia agentów nie eliminują ryzyka

Claude i Codex już oferują istotne mechanizmy kontroli, ale działają one tylko wtedy, gdy organizacje zachowują ich restrykcyjne granice.

Wskazówki dotyczące bezpieczeństwa Claude od Anthropic opisują prompt injection jako wrogi tekst próbujący manipulować instrukcjami asystenta. Dokumentują również kontrolę uprawnień i ograniczenia dotyczące poleceń pobierających dowolną zawartość z sieci.

Claude Code może korzystać z sandboxingu, aby ograniczać dostęp do systemu plików i sieci. Procesy potomne dziedziczą te ograniczenia systemu operacyjnego, co pomaga zapobiec cichemu wydostaniu się dozwolonego polecenia do mniej ograniczonego procesu.

OpenAI opisuje podobne, warstwowe podejście. Jego model bezpieczeństwa Codex łączy granice sandboxa, zasady zatwierdzania, zarządzany dostęp sieciowy, reguły i telemetrię uwzględniającą agentów.

OpenAI twierdzi, że jego zarządzane wdrożenia nie zapewniają Codex nieograniczonego dostępu wychodzącego. Oczekiwane miejsca docelowe mogą być dozwolone, nieznane domeny mogą wymagać zatwierdzenia, a zespoły bezpieczeństwa mogą eksportować logi obejmujące prompty, wywołania narzędzi, zatwierdzenia i decyzje sieciowe.

Te zabezpieczenia mają znaczenie, lecz nie unieważniają automatycznie ustaleń badaczy. Organizacje mogą konfigurować agentów z szerszym dostępem. Deweloperzy mogą zatwierdzać polecenia. Lokalne instalacje mogą dziedziczyć uprawnienia i łączność sieciową od użytkownika, który je uruchamia.

Rejestr pakietów jest również oczekiwanym miejscem docelowym w wielu środowiskach programistycznych. Zablokowanie całego dostępu do npm lub PyPI zakłóciłoby zwykłe kompilacje, aktualizacje zależności i konfigurację testów. Zezwolenie na te domeny usuwa jeden oczywisty sygnał sieciowy, który mógłby odróżniać złośliwą instalację.

Oprogramowanie do wykrywania i reagowania na zagrożenia na punktach końcowych stoi przed podobnym wyzwaniem. Agent programistyczny uruchamia standardowy menedżer pakietów, który łączy się z dobrze znanym rejestrem przez szyfrowane połączenie. Proces może przypominać zwykłą aktywność dewelopera, dopóki pobrany pakiet nie wykona czegoś wyraźnie wrogiego.

Beacon badawczy był celowo minimalny. Według doniesień kontaktował się z serwerem i rejestrował kontekst wykonania. Rzeczywisty atakujący mógłby próbować kradzieży poświadczeń, rozpoznania środowiska, utrzymania dostępu lub modyfikacji kodu źródłowego.

Publicznie dostępne dowody nie pokazują jednak, że eksperymentalne pakiety wykonywały te działania. Nie potwierdzają też, że dziesiątki firm doznały kompromitacji środowisk produkcyjnych. Wykonały one kod proof-of-concept, co jest poważne, ale ma węższy zakres niż potwierdzone naruszenie.

To sceptyczne rozróżnienie powinno kształtować reakcję przedsiębiorstw. Zespoły nie powinny zakładać, że każde użycie Claude, Codex lub Hermes powoduje infekcję. Powinny zidentyfikować warunki wymagane, aby ta ścieżka zadziałała.

Agent potrzebuje dostępu do odpowiedniej dokumentacji. Musi mieć uprawnienia do wywołania menedżera pakietów. Środowisko musi zezwalać na pobieranie z rejestru. Pakiet musi wykonać istotny kod, a istniejące mechanizmy kontroli muszą nie zdołać ograniczyć jego zachowania.

Usunięcie dowolnego z tych warunków może przerwać łańcuch. Ograniczenie dostępu do sieci jest jedną z opcji. Wymaganie zatwierdzenia przez człowieka dla instalacji zależności jest kolejną. Uruchamianie agentów w jednorazowych kontenerach może ograniczyć skutki, gdy pakiet zostanie wykonany.

Organizacje mogą również wymuszać użycie wewnętrznego proxy zależności. Proxy może zezwalać na zatwierdzone pakiety i wersje, jednocześnie odrzucając nieznane przestrzenie nazw. Takie podejście przenosi decyzję o zaufaniu z agenta czytającego publiczną dokumentację.

Same monity o zatwierdzenie są mniej wiarygodne, gdy pokazują wyłącznie znajome polecenie. Osoba zatwierdzająca potrzebuje kontekstu dotyczącego własności pakietu, jego wieku, tożsamości wydawcy, historii pobrań oraz tego, czy zależność pojawia się w zatwierdzonym zestawieniu składników oprogramowania.

Wniosek nie brzmi, że zabezpieczenia są bezużyteczne. Chodzi o to, że mechanizmy kontroli zaprojektowane wokół jawnie złośliwych poleceń mogą przeoczyć legalne polecenia prowadzące do niezaufanej własności.

Dokumentacja należy teraz do łańcucha dostaw oprogramowania

Przedsiębiorstwa muszą traktować każde wykonywalne odwołanie w dokumentacji jako zależność, która może wygasnąć, ulec zmianie lub zmienić właściciela.

Natychmiastowa reakcja zaczyna się od inwentaryzacji. Organizacje powinny przeszukać llms.txt, llms-full.txt, portale dla deweloperów, zarchiwizowane przewodniki, przykłady kodu, artykuły wsparcia i generowane referencje API pod kątem poleceń instalacyjnych.

Każdy wskazany pakiet, domena, repozytorium, obraz kontenera i hostowana subdomena potrzebują właściciela. Nazwa, której nikt nie rozpoznaje, nie powinna pozostawać publiczna w trakcie dochodzenia.

Zespoły powinny sprawdzić, czy publiczne nazwy pakietów odpowiadają rzeczywistym kontom organizacji w rejestrach. Powinny też ustalić, czy pakiety ze scopingiem są dostępne tam, gdzie starsza dokumentacja wskazuje globalną nazwę bez scope.

Potoki dokumentacyjne potrzebują zautomatyzowanych testów. Kompilacja może weryfikować, czy każdy pakiet istnieje, należy do zatwierdzonego wydawcy, wskazuje oczekiwane repozytorium i nie zmienił właściciela.

Samo sprawdzanie linków jest niewystarczające. Złośliwy pakiet lub odzyskana domena mogą zwrócić pomyślną odpowiedź. Potok musi weryfikować tożsamość, a nie dostępność.

Firmy powinny rezerwować nazwy przed opublikowaniem dokumentacji. Przypomina to rejestrowanie defensywnych domen wokół ważnego produktu, lecz przestrzenie nazw pakietów wymagają ciągłego utrzymania.

Ta sama zasada obowiązuje, gdy projekt zostaje wycofany. Usunięcie pakietu bez usunięcia instrukcji jego instalacji tworzy lukę własnościową. Porzucenie hostowanej subdomeny przy pozostawieniu prowadzących do niej linków może pozwolić innej stronie przejąć zaufaną ścieżkę.

Dokumentacja generowana przez AI zasługuje na dodatkową kontrolę, lecz strony napisane przez ludzi nie są z niej zwolnione. Badacze znaleźli dowody, że niektóre wątpliwe odwołania poprzedzały obecną erę agentów. Skopiowanie tych stron do llms-full.txt ułatwiło autonomicznemu oprogramowaniu wykorzystanie dawnych błędów.

Przedsiębiorstwa wdrażające agentów potrzebują uzupełniającej warstwy kontroli. Sesje agentów powinny działać pod dedykowanymi tożsamościami zamiast nieograniczonego konta dewelopera. Poświadczenia powinny być ograniczone do bieżącego repozytorium i zadania.

Instalacja pakietów powinna odbywać się w odizolowanym środowisku z ograniczonym dostępem do sekretów. Jeśli zależność potrzebuje dostępu do sieci podczas instalacji, dostęp ten powinien być wyraźnie określony i rejestrowany.

Zespoły powinny zachowywać kontekst rozumowania agenta wraz z telemetrią systemu operacyjnego. Log procesu może pokazać, że uruchomiono npm, podczas gdy zapisy natywne dla agenta mogą wskazać, który dokument dostarczył nazwę pakietu.

Ten kontekst ma znaczenie podczas reagowania na incydent. Śledczy muszą odróżnić zatwierdzoną zależność projektu od pakietu wybranego po tym, jak agent przeglądał zewnętrzne instrukcje.

Listy dozwolonych zależności mogą zmniejszyć ryzyko, lecz wymagają ścieżki wyjątków dla nowych pakietów. Taki wyjątek powinien gromadzić dowody pochodzenia i wymagać wskazanego ludzkiego właściciela.

Organizacje powinny również prowadzić przeszukiwalny rejestr źródeł konsultowanych przez agentów. Może on obejmować migawki dokumentacji, metadane pakietów, decyzje zatwierdzające i wygenerowane zmiany w kodzie. Kontrolowana techniczna baza wiedzy może pomóc recenzentom odtworzyć, dlaczego agent wybrał daną zależność.

Szersza lekcja wykracza poza llms.txt. Agenci programistyczni korzystają z opisów zgłoszeń, plików repozytoriów, wyników wyszukiwania, dokumentacji pakietów, odpowiedzi Model Context Protocol i generowanych wewnętrznych przewodników.

Każde z tych źródeł może zawierać instrukcję. Jeśli agent ma narzędzia, instrukcja może stać się działaniem.

To sprawia, że integralność dokumentacji staje się częścią bezpieczeństwa łańcucha dostaw oprogramowania. Przedsiębiorstwo nie może chronić wyłącznie repozytoriów źródłowych i serwerów kompilacji, pozostawiając instrukcje czytelne dla maszyn poza swoją kontrolą.

Trzy sygnały pokażą, czy branża wyciągnęła wnioski

Kolejna faza zależy od tego, czy dokumentacja, uprawnienia agentów i tożsamość rejestru poprawią się jednocześnie.

Pierwszym sygnałem jest ujawnienie i naprawa problemów na 120 dotkniętych stronach internetowych. Zespół Hertz twierdzi, że skontaktował się z dotkniętymi organizacjami i odpowiednimi zespołami bezpieczeństwa, lecz publiczne informacje nie identyfikują większości domen.

Warto obserwować, czy firmy audytują pliki llms.txt, rezerwują nazwy pakietów i publikują zawiadomienia o incydentach. Skoordynowane porządki wzmocniłyby argument, że dokumentacja czytelna dla maszyn jest infrastrukturą wrażliwą na bezpieczeństwo.

Milczenie nie dowodziłoby, że nie wdrożono żadnych poprawek. Wiele organizacji naprawia ujawnione odwołania bez publicznego ujawnienia, zwłaszcza gdy badacze użyli nieszkodliwego kodu i nie znaleźli potwierdzonej kradzieży danych.

Drugim sygnałem jest kontrola pochodzenia na poziomie produktu od dostawców agentów. Claude, Codex i Hermes mogą już prosić o zatwierdzenie przed wykonaniem poleceń, ale zatwierdzenie staje się bardziej użyteczne, gdy interfejs wyjaśnia zależność stojącą za poleceniem.

Znaczącą zmianą byłoby ostrzeżenie, że pakiet jest nowy, niezweryfikowany, niezwiązany ze znanym kontem wydawcy dostawcy lub nieobecny w istniejącym grafie zależności projektu. Silniejszy system mógłby wymagać wyraźnego zatwierdzenia za każdym razem, gdy publiczna dokumentacja wskazuje nierozpoznany pakiet.

Taka funkcja wzmocniłaby reakcję bezpieczeństwa Anthropic i Google, ponieważ dotyczyłaby punktu decyzyjnego przed wykonaniem. Kolejne ogólne ostrzeżenie o poleceniach powłoki zapewniłoby mniejszą ochronę.

Trzecim sygnałem jest integracja rejestrów i polityk przedsiębiorstwa. Menedżery pakietów i wewnętrzne proxy mogą ujawniać historię wydawcy, wiek przestrzeni nazw, status podpisywania i zmiany własności. Platformy agentowe mogą korzystać z tych metadanych przed wyborem lub instalacją zależności.

Polityka przedsiębiorstwa mogłaby automatycznie zezwalać na ugruntowane pakiety, jednocześnie izolując nieznane pakiety do przeglądu. Mogłaby również odrzucać pakiet, którego nazwa pojawia się w oficjalnej dokumentacji, ale który nie ma możliwego do zweryfikowania związku z wydawcą.

Ten sygnał osłabiłby szersze ostrzeżenie badaczy, gdyby niezawodne kontrole pochodzenia zatrzymały ścieżkę ataku w wielu agentach. Wzmocniłby ich ostrzeżenie, gdyby agenci nadal instalowali nowo przejęte nazwy mimo dostępnych danych tożsamościowych.

Obecne dowody wspierają wyważony wniosek. Badacze mieli podobno zademonstrować wykonanie kodu w rzeczywistych środowiskach korporacyjnych i powiązać część aktywności z czołowymi agentami programistycznymi. Nie wykazali, że dostawcy modeli celowo instalowali złośliwe oprogramowanie ani że każde zgłoszone wywołanie zwrotne oznaczało poważną kompromitację.

Ważniejsze ustalenie ma charakter strukturalny. Zaufana dokumentacja, autonomiczne wykonywanie i publiczne rejestry tworzą dziś łańcuch dostaw, którego wiele programów bezpieczeństwa nie uwzględnia w inwentaryzacji.

Deweloperzy i nabywcy korporacyjni powinni zadawać bezpośrednie pytania przed rozszerzeniem uprawnień agentów. Czy agent może uzyskać dostęp do publicznych rejestrów pakietów? Czy weryfikuje tożsamość wydawcy? Czy polecenia instalacyjne są izolowane? Czy zespoły bezpieczeństwa mogą odtworzyć, który dokument spowodował działanie?

Luka bezpieczeństwa między Anthropic a Google nie zostanie zamknięta wyłącznie dzięki lepszemu zachowaniu modeli. Właściciele dokumentacji, rejestry, dostawcy agentów i administratorzy przedsiębiorstw kontrolują po jednym, odrębnym ogniwie.

Zanim przyznasz agentowi programistycznemu większą autonomię, przetestuj cały ten łańcuch przy użyciu nierozpoznanej zależności. Jeśli agent ją zainstaluje bez przedstawienia informacji o pochodzeniu, środowisko traktuje dokumentację jako autorytet, a nie jako dowód.