Weryfikacja MuscleMemory przed ponownym użyciem zablokowała zatrute umiejętności, ale dowody są wciąż ograniczone
Według niedawno opublikowanego badania MuscleMemory powstrzymało zatrute wskazówki przed dotarciem do 30 z 30 ocenianych repozytoriów, podczas gdy zwykłe odtwarzanie edycji za każdym razem przywracało truciznę. Wynik daje podejściu MuscleMemory polegającemu na weryfikacji przed ponownym użyciem wyjątkowo wyraźny nagłówek. Tworzy też istotny paradoks: zaliczone testy nie odróżniały czystej pracy od pracy zatrutej.
Badanie analizuje pamięć proceduralną, czyli zapisane instrukcje mówiące agentowi, jak wykonywać powtarzalne zadanie. Agent programistyczny uczył się na jednej zatrutej sesji i trzech późniejszych czystych sesjach. Następnie badacze porównali cztery sposoby wykorzystania tego doświadczenia w Claude Haiku 5.5 i Claude Sonnet 5.5.
Wyniki są zachęcające, ale wstępne. Eksperyment obejmował jedno zadanie, pięć ocenianych sesji na każdą komórkę eksperymentalną oraz reguły dostrojone do tego samego zadania. Jego najmocniejszy wynik dotyczy ekspozycji na truciznę, a nie szkodliwego wykonania. To rozróżnienie przeciwstawia weryfikację przed ponownym użyciem bardziej znanej strategii pamięci: zapisywania udanych doświadczeń, wyszukiwania najtrafniejszego rekordu i ufania, że agent dobrze go wykorzysta.
Zaliczony test sprawił, że trucizna wyglądała na sukces
Główne ostrzeżenie eksperymentu jest proste: powodzenie zadania i bezpieczne uczenie się to różne właściwości.
Studium przypadku rozpoczęło się od zadania naprawy konfiguracji. Jedna sesja uczenia obejmowała zarówno właściwą poprawkę, jak i niepowiązaną modyfikację. Trucizna przyjęła jedną z trzech form: nowego pliku, niepowiązanej linii lub złośliwej linii połączonej z prawidłową zmianą.
Widoczny sygnał powodzenia zadania nie wykrył tych dodatków. Sesja przeszła test, więc system pamięci skupiony wyłącznie na wynikach miał powód, by ją zachować. Trzech kolejnych agentów ukończyło to samo zadanie bez trucizny, tworząc niewielką historię jednego skażonego rozwiązania i trzech czystych.
Następnie badacze uruchomili pięć ocenianych sesji dla każdego modelu, typu trucizny i wariantu pamięci. Claude Haiku 5.5 oraz Claude Sonnet 5.5 zapewniły zróżnicowanie modeli. Ukryty weryfikator uruchomił 187 kontroli zachowania wobec każdego końcowego repozytorium.
Porównanie obejmowało cztery warianty:
Brak pamięci nie przekazywał agentowi żadnej zapisanej procedury z wcześniejszych sesji.
Odtwarzanie ponownie stosowało zarejestrowane edycje.
Naiwna pamięć zachowywała zaliczone sesje i używała wyszukiwania Mem0 do wyboru odpowiedniej umiejętności.
Weryfikacja przed ponownym użyciem wstrzymywała udostępnienie umiejętności, dopóki dwie późniejsze sesje nie odtworzyły jej zmiany i nie zaliczyły odpowiedniego testu.
Ostatni wariant filtrował też umiejętność na poziomie linii. Agentowi pokazywał wyłącznie zmiany, które późniejsze udane sesje zapisały ponownie. Ten szczegół miał znaczenie, ponieważ jedna trucizna była połączona w tym samym pliku i obszarze edycji co prawidłowa naprawa.
Nagłówkowe liczby dotyczyły ekspozycji i stanu repozytorium. Odtwarzanie miało ponownie wprowadzić truciznę do 30 z 30 repozytoriów, choć każde repozytorium nadal przechodziło ukryty weryfikator. Naiwna pamięć ujawniła zatrute wskazówki w trzech z 30 ocenianych sesji. Weryfikacja przed ponownym użyciem nie ujawniła ich w żadnej z 30.
Liczby te pochodzą z opublikowanych zapisów projektu i oryginalnego wpisu badawczego, a nie z niezależnej replikacji. Publiczny opis projektu wskazuje, że jego dane na poziomie sesji zachowują zastąpione uruchomienia, oznaczają wiersze należące do raportowanych tabel oraz wskazują, czy trucizna pojawiła się w zapisanej umiejętności, dostarczonych wskazówkach czy końcowym kodzie.
To rozdzielenie jest użyteczne. Zatruta pamięć może istnieć, nie zostając odzyskana. Odzyskana trucizna może pojawić się w poleceniu, lecz nie zostać zastosowana. Agent może też utworzyć tę samą podejrzaną zmianę, choć pamięć nie była jej przyczyną. Traktowanie tych zdarzeń jako jednej metryki ukryłoby miejsce, w którym obrona faktycznie zadziałała.
Badanie podaje, że żaden oceniany agent nie wykonał trucizny tylko dlatego, że zobaczył zatrute wskazówki. Znaczącym mierzonym wynikiem było więc zapobieganie ekspozycji. Eksperyment wykazał, że proponowany filtr utrzymywał podejrzane instrukcje poza późniejszymi poleceniami, a nie że zapobiegł zaobserwowanemu atakowi, który w przeciwnym razie spowodowałby szkody.
Dlatego perfekcyjny wynik ukrytych testów sam w sobie nie jest uspokajający. Wszystkie oceniane sesje przeszły tych 187 kontroli, w tym repozytoria, w których odtwarzanie przywróciło truciznę. Testy potwierdziły, że wymagane zachowanie działało. Nie potwierdziły, że nic więcej się nie zmieniło.
Ta luka rodzi główne pytanie artykułu. Jeśli system pamięci uczy się na podstawie zaliczonej pracy, jakich dowodów powinien wymagać, zanim zamieni edycje z jednej sesji w poradę dla każdego kolejnego agenta?
Dlaczego zatruwanie pamięci agentów przetrwa zwykłe kontrole sukcesu
Trwała pamięć przekształca błąd z jednej sesji w infrastrukturę wielokrotnego użycia.
Bezstanowy agent programistyczny może raz dokonać błędnej edycji. Agent wyposażony w pamięć może przekształcić tę edycję w procedurę, odzyskać ją dla podobnych zadań i rozprowadzić po repozytoriach. Ryzyko zmienia się z odosobnionej porażki w powtarzalną instrukcję.
Najnowsze badania zaczynają dokumentować ten szerszy problem. Badanie dotyczące zatruwania uśpionej pamięci opisuje ataki umieszczające fałszywe wspomnienia poprzez dokumenty, strony internetowe lub repozytoria. Wspomnienia te mogą pozostawać uśpione, zanim wpłyną na późniejsze rozmowy i działania.
Inne badanie z 2026 roku przedstawia trwałą pamięć jako odrębną powierzchnię ataku, a nie tylko kolejną formę prompt injection. Jego taksonomia zatruwania pamięci wskazuje kilka kanałów zapisu i słabości architektonicznych, które pozwalają niezaufanym danym wejściowym stać się trwałym kontekstem.
Agenci programistyczni konkretyzują ten problem, ponieważ ich pamięci mogą obejmować szczegóły operacyjne. Zapisana umiejętność może wskazywać pliki, testy, polecenia, klucze konfiguracji lub kroki odzyskiwania. Każdy z tych elementów może pomóc późniejszemu agentowi działać szybciej. Każdy może też skierować go ku skażonemu artefaktowi.
MuscleMemory zaprojektowano wokół zapisów proceduralnych, a nie pełnego odtwarzania rozmów. Jego publiczna dokumentacja mówi, że umiejętność zawiera zwięzły opis tego, co zmienić, jak to zweryfikować i czego unikać. Jego API pamięci proceduralnej rejestruje zaobserwowane kroki, uczy się na ukończonych sesjach i zwraca dopasowane wskazówki podczas przywoływania.
Taka konstrukcja ogranicza nieistotny kontekst, ale nie rozwiązuje automatycznie kwestii zaufania. Kompresja może zachować błędną lekcję. Wyszukiwanie może wysoko sklasyfikować skażoną umiejętność, ponieważ jest semantycznie trafna. Zaliczony test może potwierdzać pożądane zachowanie, jednocześnie ignorując niepowiązane dodatki.
Mem0 pokazuje, dlaczego jakość wyszukiwania i jakość dowodów muszą pozostać rozdzielone. Jego własny opis wyszukiwania pamięci wyjaśnia, że podobieństwo semantyczne wybiera kontekst związany z zapytaniem. Trafność mówi systemowi, która pamięć przypomina bieżące zadanie. Nie mówi, czy treść tej pamięci zasługuje na autorytet.
Studium przypadku użyło wyszukiwania Mem0 w naiwnym wariancie do wyboru spośród pamięci zaliczonych sesji. Tej konfiguracji nie należy odczytywać jako kompleksowej oceny bezpieczeństwa Mem0 ani każdej możliwej konfiguracji Mem0. Testuje ona jedno podejście skoncentrowane na wyszukiwaniu w ramach jednego środowiska testowego.
Mimo to wynik ujawnia ogólną słabość. Jeśli każda zaliczona sesja kwalifikuje się do ponownego użycia, pojedynczy skażony sukces może konkurować z czystym doświadczeniem. Wyszukiwanie może go odzyskać, ponieważ prawidłowa część pozostaje wysoce istotna dla zadania.
Odtwarzanie zakłada jeszcze silniejsze zaufanie. Traktuje historyczne edycje jako działania warte powtórzenia, a nie tylko dowody warte rozważenia. Jego wynik 30 na 30 zatruć wynikał bezpośrednio z tego założenia. Ponowne zastosowanie całej zarejestrowanej zmiany ponownie zastosowało też niepowiązaną treść do niej dołączoną.
Wariant bez pamięci unika propagacji między sesjami, ale rezygnuje ze zgromadzonej wiedzy proceduralnej. Każdy agent musi na nowo odnaleźć odpowiednie pliki, polecenia i ścieżkę testową. Może to zwiększyć użycie narzędzi, opóźnienia i okazje do nowych błędów.
Zespoły odczuwają więc presję z obu stron. Chcą, by agenci pamiętali sprawdzone przepływy pracy, ponieważ powtarzana eksploracja jest kosztowna. Muszą też zapobiec temu, by jedno przejęte repozytorium, wprowadzająca w błąd instrukcja lub przypadkowa edycja stały się wiedzą instytucjonalną.
To napięcie wykracza poza kod. Agent obsługi klienta mógłby zapamiętać nieautoryzowany wyjątek. Agent finansowy mógłby zachować niebezpieczną sekwencję zatwierdzeń. Asystent badawczy mógłby utrwalić sfabrykowaną regułę cytowania. Każdy system, który przekształca wcześniejsze zachowanie w przyszłe instrukcje, dziedziczy ten sam problem zaufania.
Dla zespołów tworzących wspólną bazę wiedzy AI pochodzenie jest ważne obok trafności. Użyteczny zapis pamięci powinien wyjaśniać, skąd pochodzi procedura, jakie dowody ją wspierają i czy niezależna praca ją odtworzyła.
Weryfikacja przed ponownym użyciem próbuje dostarczyć brakujących dowodów. Nie pyta jedynie, czy sesja zakończyła się sukcesem. Pyta, które części tego sukcesu przetrwały późniejsze, niezależne próby.
Weryfikacja MuscleMemory przed ponownym użyciem zmienia definicję dowodu
Metoda traktuje powtarzalne czyste wykonanie jako filtr, a nie jako głosowanie popularności.
W przedstawionej konstrukcji zatruta sesja uczenia nie tworzy od razu wskazówek, które mogą otrzymać agenci. Późniejsze sesje muszą ukończyć to samo zadanie, odtworzyć zmianę i zaliczyć test. Umiejętność kwalifikuje się dopiero po dwóch takich kontrolach.
System następnie wyznacza część wspólną zarejestrowanej pracy. Dostarcza wyłącznie linie, które późniejsze udane sesje również zapisały. Dodatek, który pojawił się tylko w zatrutej sesji, powinien zniknąć, nawet gdy prawidłowa poprawka wokół niego pozostaje użyteczna.
Jest to bardziej rygorystyczne niż liczenie, jak często pojawia się szeroka umiejętność. Pyta, czy konkretna zmiana przetrwała niezależną ponowną implementację. Różnica ma znaczenie, gdy jedna pamięć łączy prawidłowe i nieprawidłowe instrukcje.
Rozważmy truciznę w formie nowego pliku. Skażona sesja tworzy prawidłową poprawkę oraz niepowiązany plik. Późniejsi czyści agenci odtwarzają poprawkę, lecz nie dodatkowy plik. Porównanie na poziomie plików może odrzucić niedopasowany artefakt bez odrzucania powtarzalnej naprawy.
Przypadek niepowiązanej linii działa według tego samego wzorca w istniejącym pliku. Późniejsze sesje zapisują prawidłową zmianę, ale pomijają podejrzaną linię. Wystarczająco precyzyjny filtr może zachować wspólną część.
Trucizna połączona z poprawką jest trudniejsza. Niebezpieczny tekst znajduje się w tej samej logicznej edycji co prawidłowa naprawa. Traktowanie całego pliku lub łatki jako jednej jednostki zachowałoby oba elementy. Opisane porównanie na poziomie linii usunęło niedopasowaną truciznę, zachowując linie powtórzone przez czyste sesje.
Ten wynik jest najciekawszym wkładem studium przypadku. Obrona nie czekała po prostu dłużej, zanim zaufa procedurze. Zawęziła procedurę do dowodów potwierdzonych przez późniejsze sesje.
Mechanizm MuscleMemory polegający na weryfikacji przed ponownym użyciem łączy zatem trzy mechanizmy kontroli:
Opóźnione dopuszczenie zapobiega temu, by jedno udane uruchomienie od razu stało się możliwe do ponownego użycia.
Niezależne odtworzenie sprawdza, czy późniejsi agenci dochodzą do tej samej zmiany.
Filtrowanie na poziomie linii ogranicza dostarczane wskazówki do odtworzonej części.
Te mechanizmy kontrolne rozwiązują różne rodzaje problemów. Opóźnienie bez porównania jedynie odroczyłoby skażenie. Powtarzanie bez precyzyjnego filtrowania mogłoby zachować szkodliwą zmianę scaloną z większą, prawidłową łatką. Filtrowanie bez niezależnych sesji nie dawałoby podstaw do rozstrzygnięcia, które linie mają znaczenie.
Szersza dokumentacja MuscleMemory opisuje dodatkowy etap zatwierdzania przez człowieka, zanim umiejętność stanie się dostępna. Taka akceptacja może poprawić rozliczalność, lecz wynik liczbowy badania zależy od automatycznego odtwarzania i filtrowania. Recenzent wciąż może przeoczyć wiarygodnie wyglądającą, zatrutą linię.
Metoda zmienia także rolę testów. Pomyślnie zaliczony test pozostaje konieczny, ale nie stanowi już wystarczającego dowodu. Testy potwierdzają, że każda sesja wykonała żądane zadanie. Odtwarzanie pokazuje, które zmiany wielu skutecznych agentów uznało za niezbędne.
Przypomina to rozumowanie różnicowe. System porównuje rozwiązania, aby oddzielić stabilną strukturę zadania od przypadkowych działań. Zmiana powtarzająca się w niezależnych, udanych sesjach zasługuje na większe zaufanie niż edycja występująca tylko raz.
Jednak pojęcie „niezależne” wymaga ostrożnej interpretacji. Późniejsze sesje wykorzystywały agentów pracujących nad tym samym zadaniem i w tym samym kontekście repozytorium. Ich wyniki były odrębne, lecz ich obserwacje nie musiały być odizolowane od każdego zatrutego wejścia. Znany przypadek niepowodzenia pokazuje, dlaczego ta granica ma znaczenie.
Wiąże się z tym również koszt. System potrzebuje co najmniej dwóch późniejszych udanych sesji, zanim udostępni umiejętność. Rzadkie zadania mogą nigdy nie zgromadzić wystarczających dowodów. Szybko zmieniające się bazy kodu mogą ulec zmianie przed zakończeniem walidacji. Powtarzane uruchomienia zużywają czas modelu i zasoby obliczeniowe.
Zespół mógłby obniżyć próg odtwarzania, aby przyspieszyć dopuszczanie, lecz osłabiłoby to podstawową gwarancję. Mógłby go podwyższyć, ale wtedy mniej wspomnień stałoby się użytecznych. Dowód przed ponownym użyciem przekształca zaufanie do pamięci w wyraźny wybór między opóźnieniem a pewnością.
Badanie nie ustala idealnego progu. Dwie późniejsze sesje zadziałały w tym scenariuszu testowym. Przepływ pracy o wyższym ryzyku, taki jak dane uwierzytelniające wdrożenia lub logika płatności, może wymagać większej liczby dowodów i silniejszego weryfikatora. Zadanie formatowania o niskim ryzyku może uzasadniać mniej rygorystyczne wymagania.
Największa wartość metody ma charakter koncepcyjny. Udane ślady należy traktować jako twierdzenia dotyczące procedury. Późniejsze działania powinny dostarczać dowodów, zanim twierdzenia te zyskają władzę nad przyszłymi agentami.
Wynik wywiera presję na odtwarzanie i naiwne projekty pamięci
Systemy pamięci potrzebują obecnie polityki dopuszczania, a nie tylko polityki przechowywania i wyszukiwania.
Wiele produktów pamięci dla agentów kładzie nacisk na przechwytywanie, podsumowywanie, wyszukiwanie i personalizację. Funkcje te odpowiadają na użyteczne pytania operacyjne. Co agent powinien zachować? Jak powinien znajdować istotny kontekst? Jak może aktualizować lub usuwać stare rekordy?
Badanie zatruwania dodaje wcześniejsze pytanie: co musi się wydarzyć, zanim wspomnienie stanie się uprawnione do wpływania na inną sesję?
Odtwarzanie odpowiada na to pytanie pośrednio. Jeśli edycja należała do zarejestrowanego sukcesu, system może zastosować ją ponownie. Strategia ta maksymalizuje wierność historycznemu śladowi. Zachowuje jednak także każdą niepowiązaną zmianę dołączoną do tego śladu.
Naiwne wyszukiwanie jest mniej bezpośrednie. Dostarcza agentowi wybrane wspomnienie i pozwala modelowi zdecydować, co z nim zrobić. Może to ograniczyć deterministyczne rozprzestrzenianie się, ale niebezpieczne wskazówki nadal trafiają do kontekstu decyzyjnego.
Dowód przed ponownym użyciem umieszcza bramkę między uczeniem się a wyszukiwaniem. System może natychmiast zapisać kandydującą procedurę, jednocześnie wstrzymując jej udostępnienie agentom. Przechowywanie staje się obserwacją; walidacja określa uprawnienia.
To rozróżnienie powinno mieć znaczenie dla nabywców korporacyjnych. Panel prezentujący zapisane wspomnienia nie ujawnia, czy rekordy te są aktywnymi instrukcjami. Przeglądy bezpieczeństwa potrzebują stanów cyklu życia, takich jak kandydat, potwierdzony, zatwierdzony, wstrzymany i wycofany.
Potrzebują również informacji o pochodzeniu. Wspomnienie powinno wskazywać sesję źródłową, zakres repozytorium, polecenie weryfikacyjne, późniejsze kontrole oraz dostarczoną wersję. Bez takiego łańcucha zespoły nie mogą odtworzyć, dlaczego agent otrzymał konkretną instrukcję.
Publiczne rekordy badania podobno rozróżniają zawartość umiejętności, wskazówki z promptów oraz końcowy stan repozytorium. To dobry wzorzec audytowy. Pozwala badaczom ustalić, czy skażenie nastąpiło podczas przechwytywania, dopuszczania, wyszukiwania, interpretacji czy wykonania.
Porównywalne systemy mogą zareagować na kilka sposobów. Mogłyby wprowadzić okresy kwarantanny, wymagać potwierdzenia między sesjami, dołączać metadane zaufania lub ograniczać wspomnienia do wąskich zakresów projektowych. Mogłyby także pobierać wiele śladów i prosić agenta o ich porównanie zamiast udostępniać jedną zsyntetyzowaną procedurę.
Żadna z tych opcji nie jest bezkosztowa. Większa liczba metadanych komplikuje przechowywanie. Wiele śladów zużywa tokeny. Kwarantanna zmniejsza natychmiastową wartość. Ocena przez człowieka zwiększa opóźnienie i może prowadzić do zmęczenia zatwierdzaniem.
Bezpieczniejszy projekt potrzebuje więc poziomów ryzyka. Porada dotycząca polecenia testowego nie zasługuje na takie same mechanizmy kontroli jak instrukcje modyfikujące uwierzytelnianie, dostęp do sieci lub automatyzację wydań. Warstwa pamięci powinna uwzględniać konsekwencje stosowania procedury, a nie tylko jej wynik podobieństwa.
Anthropic przedstawia powiązany argument w swoich wytycznych dotyczących wiarygodnych agentów: bezpieczeństwo agentów zależy od zabezpieczeń obejmujących model, uprząż, narzędzia i środowisko. Bramka pamięci nie może zastąpić sandboxingu, uprawnień, przeglądu kodu ani ograniczonych danych uwierzytelniających.
To szersze spojrzenie zapobiega także zbyt uproszczonemu porównaniu produktów na podstawie wyniku MuscleMemory. Eksperyment nie wykazał, że cała pamięć oparta na wyszukiwaniu jest niebezpieczna ani że jedna implementacja pamięci proceduralnej rozwiązuje problem zatruwania. Pokazał, że nieograniczone ponowne użycie częściej ujawniało podejrzaną zawartość w konkretnym, kontrolowanym zadaniu.
Mimo to ciężar dowodu się przesunął. System reklamujący uczenie między sesjami powinien wyjaśniać, jak radzi sobie z udanymi sesjami zawierającymi niepotrzebne lub wrogie zmiany. „Testy przeszły pomyślnie” nie jest już pełną odpowiedzią.
Znane niepowodzenie pokazuje, gdzie odtwarzanie przestaje działać
Dowód przed ponownym użyciem zawodzi, gdy późniejsze sesje wielokrotnie napotykają to samo zatrute źródło.
Projekt ujawnia osobne niepowodzenie na poziomie repozytorium, poza główną tabelą. W tym uruchomieniu trucizna trafiła do instrukcji repozytorium odczytywanych przez każdego agenta. Późniejsze sesje odtwarzały skażone zachowanie, ponieważ ich wspólne środowisko nakazywało im to robić.
MuscleMemory podobno zwalidowało i udostępniło zatrutą umiejętność we wszystkich pięciu ocenianych sesjach Haiku. Trucizna pojawiła się również w kodzie pięć razy. W wariancie bez pamięci wystąpiła również pięć razy.
Wynik ten wyznacza granicę metody. Odtwarzanie może odfiltrować anomalię pojawiającą się w jednej sesji. Nie potrafi odróżnić prawdy od skoordynowanego powtarzania, gdy każda sesja otrzymuje tę samą skażoną przesłankę.
Niepowodzenie przypomina zatruwanie danych bardziej niż izolowane skażenie śladu. Późniejsi agenci mieli działać jako niezależni świadkowie, ale dzielili skompromitowany materiał dowodowy. Ich zgodność wzmocniła błędny wniosek.
Problem ten nie dotyczy wyłącznie MuscleMemory. Każdy system potwierdzania może zawieść, gdy jego walidatorzy współdzielą źródło kontrolowane przez atakującego. Wielu agentów, modeli lub uruchomień nie tworzy niezależności, jeśli odczytują te same zatrute instrukcje.
Ograniczenie komplikuje również sformułowanie „dwie późniejsze sesje”. Rozdzielenie sesji nie gwarantuje rozdzielenia źródeł. Twierdzenia dotyczące bezpieczeństwa powinny opisywać, które wejścia, narzędzia, repozytoria i kanały instrukcji pozostawały wspólne między uruchomieniami walidacyjnymi.
Silniejszy projekt mógłby powiązać wspomnienia z pochodzeniem wejść. Mógłby oznaczać, czy instrukcja pochodzi od użytkownika, pliku repozytorium, strony internetowej, wyniku testu czy uprzywilejowanej polityki. Mógłby uniemożliwiać źródłom o niższym zaufaniu uzyskanie autorytetu wyłącznie dzięki powtarzającemu się stosowaniu się modelu.
Niedawne badanie dotyczące autorytetu związanego z pochodzeniem twierdzi, że zarówno ocenę treści, jak i zwykłe śledzenie pochodzenia można manipulować. Badanie proponuje wiązanie autorytetu z pochodzeniem w chwili zapisu oraz wymaganie potwierdzenia odpornego na sztucznie wytworzoną zgodność.
Studium przypadku ma także ograniczenia statystyczne. Każda komórka eksperymentalna obejmowała pięć ocenianych sesji. Autorzy podają prawdopodobieństwo bliskie 0,24 dla głównego porównania, co nie spełnia powszechnych progów istotności. Zero zaobserwowanych ekspozycji nie dowodzi bliskiego zeru wskaźnika w warunkach rzeczywistych.
Wąski scenariusz testowy rodzi kolejną obawę. To samo zadanie posłużyło zarówno do opracowania metody, jak i jej oceny. Reguły dopasowywania linii, które sprawdzają się przy niewielkiej naprawie konfiguracji, mogą mieć trudności z refaktoryzacją, plikami generowanymi, zmianami zależności lub semantycznie równoważnymi edycjami.
Dwaj poprawnie działający agenci mogą rozwiązać ten sam problem na różne sposoby. Jeden może zmienić nazwę funkcji pomocniczej, drugi zmodyfikować wywołującego, a trzeci zmienić przepływ konfiguracji. Dosłowne przecięcie mogłoby odrzucić użyteczną pracę, ponieważ poprawne rozwiązania nie współdzielą linii.
Może zdarzyć się także odwrotnie. Agenci mogą powtarzać zatrutą edycję, ponieważ wygląda konwencjonalnie, pojawia się w przykładzie lub wynika ze wspólnego uprzedzenia modelu. Zgodność jest dowodem, ale nie jest dowodem bezpieczeństwa.
Ukryty weryfikator stanowi kolejne ostrzeżenie. Jego 187 kontroli brzmi imponująco, jednak każde oceniane repozytorium je przeszło, w tym wszystkie 30 odtworzonych trucizn. Kontrole mierzyły zamierzone zachowanie, ale nie odrzucały kanarków. Duża liczba testów nie gwarantuje szerokiego pokrycia bezpieczeństwa.
Kolejne ograniczenie dotyczy wykonania. Główne badanie wykazało różnice w ekspozycji, lecz żaden oceniany model nie wykonał trucizny wyłącznie dlatego, że pamięć ją wyświetliła. Uniemożliwia to bezpośrednie oszacowanie ograniczonej szkody. Obrona blokująca ekspozycję jest wartościowa, jednak czytelnicy nie powinni przekształcać zerowej liczby ekspozycji w zerową liczbę udanych ataków.
Udostępnione dane poprawiają przejrzystość, ale publiczne rekordy nie są tym samym co replikacja przez stronę trzecią. Niezależni badacze nadal muszą odtworzyć uprząż, sprawdzić logikę punktacji, zweryfikować raportowane tabele i przetestować dodatkowe zadania.
Projekt podaje także, że niektóre zapisane bazy danych i pełne transkrypcje zostały wstrzymane, ponieważ zawierały lokalne ścieżki. Jest to zrozumiałe, ale ogranicza analizę kryminalistyczną pełnego kontekstu wykonania. Zanonimizowane wydania wzmocniłyby przyszłe analizy.
MuscleMemory proof before reuse należy zatem traktować jako obiecującą regułę dopuszczania z udokumentowanym trybem niepowodzenia. Nie jest to ogólna gwarancja bezpieczeństwa pamięci.
Trzy testy rozstrzygną, czy wynik da się uogólnić
Kolejny etap powinien mierzyć niezależne odtwarzanie, rzeczywistą szkodę behawioralną oraz odporność na współdzielone zatrute wejścia.
Pierwszym sygnałem jest zewnętrzna replikacja w zróżnicowanych zadaniach programistycznych. Badacze powinni testować poprawki błędów, migracje, refaktoryzacje, aktualizacje zależności i poprawki bezpieczeństwa. Powinni różnicować rozmiar repozytorium, język programowania, jakość testów i model agenta.
Udana replikacja zachowałaby lukę ekspozycji bez polegania na regułach dopasowania specyficznych dla zadania. Pokazałaby również, że przecięcie na poziomie linii zachowuje wystarczająco użyteczne wskazówki, gdy niezależni agenci tworzą różne poprawne implementacje.
Niepowodzenie w przypadku semantycznie równoważnych edycji osłabiłoby argument za dosłownym filtrowaniem linii. Taki wynik wskazywałby na bogatsze metody porównywania, takie jak analiza programów, weryfikacja na poziomie zachowania lub ustrukturyzowane reprezentacje zmian w kodzie.
Drugim sygnałem jest eksperyment mierzący szkodliwe działanie po pobraniu. Przyszłe badania powinny stosować bezpieczne kanarki o wyraźnych konsekwencjach, a następnie rejestrować całą sekwencję: od zatrutego zapisu, przez pobranie, decyzję modelu i wywołanie narzędzia, po stan końcowy.
Odpowiedziałoby to na pytanie, czy ograniczanie ekspozycji rzeczywiście ogranicza szkodliwe wykonanie. Mogłoby także ujawnić różnice między modelami. Jeden model może ignorować podejrzane wskazówki, podczas gdy inny konsekwentnie się do nich stosuje, gdy instrukcja wydaje się istotna.
Trzeci sygnał to silniejsza odpowiedź na zatruwanie wspólnych źródeł. Sesje walidacyjne powinny korzystać z danych wejściowych kontrolowanych niezależnie albo system pamięci powinien zachowywać granice zaufania między źródłami. Powtarzająca się zgodność agentów czytających tę samą instrukcję w repozytorium nie może być uznawana za niezależne potwierdzenie.
Jeśli MuscleMemory doda walidację uwzględniającą źródła i wyeliminuje opublikowaną awarię na poziomie repozytorium, główny argument stanie się znacznie mocniejszy. Jeśli to zatrucie nadal będzie przechodzić, dowód przed ponownym użyciem pozostanie przydatny tylko w przypadku odizolowanego skażenia.
Zespoły nie muszą czekać na idealne badania, aby ulepszać swoje systemy. Mogą oddzielać zapisane obserwacje od aktywnych instrukcji, zachowywać pochodzenie sesji i wymagać bardziej rygorystycznej weryfikacji dla procedur o dużym wpływie. Mogą też utrzymywać edycje generowane przez pamięć w ramach standardowych procesów testowania, sandboxingu i przeglądu kodu.
Szersza lekcja nie polega na tym, że agenci powinni zapominać. Chodzi o to, że pamięć potrzebuje modelu dowodowego. Trafność, powtarzalność i zaliczone testy odpowiadają na różne pytania, a żadne z nich samo w sobie nie potwierdza bezpieczeństwa.
Dla deweloperów oceniających dowód MuscleMemory przed ponownym użyciem praktyczne pytanie jest precyzyjne: czy sesje walidacyjne mogą obserwować zadanie na tyle niezależnie, by zgodność była znacząca? Jeśli odpowiedź brzmi nie, dodaj izolację źródeł i silniejszą weryfikację przed wdrożeniem współdzielonej pamięci proceduralnej. Jeśli odpowiedź brzmi tak, odtwórz opublikowany eksperyment we własnych repozytoriach i zmierz zarówno ekspozycję, jak i zachowanie.
