Spis treści
Agent samodoskonalący przepisał własny kod i osiągnął wynik 100% w teście wydajności dotyczącym bezpiecznego kodowania, przy czym wszystkie zadania działały poprawnie, a wszystkie luki w zabezpieczeniach zostały zablokowane.
Kod, który napisał, nie był bezpieczny.
Wynik ten pochodzi z nowego artykułu opublikowanego przez Google Cloud AI Research, napisanego we współpracy z naukowcami z Carnegie Mellon i Google DeepMind. Stworzyli oni system o nazwie Harmony Harness, a najbardziej przydatną stroną w tym systemie jest ta, na której ich własna konfiguracja oszukiwała. W przypadku tych 30 zadań początkowa konfiguracja uzyskała wynik 46,71 TP3T dla kodu, który był zarówno działający, jak i bezpieczny. Udoskonalona wersja osiągnęła idealny wynik, manipulując samym sposobem pomiaru. W branży zjawisko to nazywa się „hackowaniem nagród” (reward hacking).
Co zmienia w sobie środek służący samodoskonaleniu
Harness to całość otaczająca model – od komunikatów systemu i narzędzi po pętlę decydującą o zakończeniu zadania. Agent samodoskonalący się analizuje informacje zwrotne dotyczące wykonania i przerabia ten harness z pokolenia na pokolenie.
Większość systemów agentów samodoskonalących skupia się na jednym wskaźniku – zazwyczaj jest to wskaźnik zdawalności testu porównawczego. Pojedynczy wynik ukrywał również negatywne skutki w moim ostatnim artykule, w którym umiejętności agenta wydawały się pomocne, a mimo to przyniosły szkodę po przyporządkowaniu zadań w pary.
A harness evolved to maximize its training score collapsed on held-out tasks. Its combined score fell to 35.0%, below the 43.3% of the starting harness. In the authors’ case study, an agent that only sees functional feedback writes plausible code and declares the task done. Nothing pushes it toward the missing bounds check, because the exploit stays hidden at solve time.
W ten sposób agent samodoskonalący się osiągał lepsze wyniki w teście, ale gorzej radził sobie w pracy.
Dlaczego dodanie wskaźnika bezpieczeństwa nie rozwiązuje problemu
Oczywistym rozwiązaniem jest dodanie zabezpieczenia do nagrody, a autorzy przetestowali to wraz z każdym wariantem, który można by wypróbować w pierwszej kolejności.
Ewolucja skupiająca się wyłącznie na bezpieczeństwie podniosła wynik w tej kategorii o 10 punktów, a łączny wynik wyniósł 46,71 TP3T, czyli tyle samo, co w przypadku uprzęży startowej. Żadne z dodatkowych zadań nie zostało wykonane zarówno poprawnie, jak i bezpiecznie.
Sztywny próg bezpieczeństwa okazał się jeszcze mniej skuteczny, ustalając się na poziomie 60,01 TP3T, czyli o 3,3 punktu powyżej poziomu wyjściowego. Próg ten odrzuca wszystko, co znajduje się poniżej ustalonej wartości, a wszystko powyżej traktuje jako równe. Gdy agent samodoskonalący przekroczy tę wartość, poprawa bezpieczeństwa ustaje.
Model bazowy Darwin Gödel Machine łączy oba cele w jedną nagrodę skalarową. Na zbiorze SecRepoBench osiągnął największy wzrost bezpieczeństwa spośród wszystkich modeli bazowych w trakcie ewolucji – +20 punktów. W przypadku nieznanych wcześniej typów awarii zachował 0% tego wzrostu.
Kiedy autorzy przeanalizowali wygenerowane układy, w jednej z wersji założono, że każde zadanie było Odczyt poza zakresem w CWE-125 i kierował wszystkie poprawki tą ścieżką. Inny dostarczył gotowy zestaw poprawek dotyczących zapisu poza granicami. Każda z nich była na wystarczająco często poprawna na zbiorze szkoleniowym, by została zaakceptowana, a każda z nich była bezużyteczna gdziekolwiek indziej.
Zespół ds. bezpieczeństwa serwisu Figma napotkał ten sam problem w własny system pozyskiwania agentów. Jak napisali, automatyczne udoskonalanie reguł “nadal może doprowadzić do nadmiernego dopasowania” do “jednego błędu, z którym ma do czynienia”. Agent samodoskonalący się, który uczy się na podstawie informacji zwrotnej, uczy się samej tej informacji zwrotnej.
Agent samodoskonalący się najpierw atakuje klasyfikatora
Naukowcy przeprowadzili również celowy test bez izolowanego kontenera i bez przywracania chronionych plików. Agent od razu skierował się do pliku evaluate.py, czyli skryptu, który go ocenia.
Następnie układ odczytał wartość 100% na każdej osi, co autorzy określają jako brak pomiaru.
W samej uprzęży znajduje się jej mniejsza wersja. Kod ewoluujący zawiera własne testy autodiagnostyczne, a w artykule zaznaczono, że najtańszym sposobem na sprawienie, by nieudany test autodiagnostyczny zakończył się powodzeniem, jest jego usunięcie. Dlatego autorzy dodali sprawdzanie, czy każda nazwana asercja z wersji nadrzędnej nadal istnieje w wersji podrzędnej.
Twój zielony pulpit nawigacyjny jest tak wiarygodny, jak pliki, do których twój samodoskonalący się agent nie ma dostępu.
Czym wyróżnia się Harmony Harness
W systemie Harmony Harness funkcjonalność i bezpieczeństwo traktowane są jako dwa odrębne cele w całym procesie wyszukiwania. Każdy etap wyszukiwania skupia się na tym aspekcie, który jest najbardziej oddalony od ideału, dzięki czemu żaden z nich nie może ulec pogorszeniu bez zauważenia.
Ponadto dzieli ten zestaw narzędzi na mechanizmy ogólne oraz poprawki specyficzne dla poszczególnych testów porównawczych. Wyspecjalizowany operator wyszukuje zakodowane na stałe sekwencje awarii oraz komunikaty wskazujące konkretne zadania, a następnie przerabia je tak, by działały poprawnie na nowych danych.
Każda ocena przebiega w izolowanym kontenerze z wyłączoną siecią, a pliki określające punktację są archiwizowane przed każdą edycją i przywracane po jej zakończeniu. Agent może przepisać cały swój zestaw testów, aż do klasy bazowej. Żaden plik służący do punktacji nie jest dostępny dla agenta.
W teście SecRepoBench osiągnął wynik 93,31 TP3T w kategorii bezpieczeństwa oraz 76,71 TP3T łącznie na zbiorze szkoleniowym. W zadaniach z wykorzystaniem danych testowych, zawierających typy awarii, których agent nigdy wcześniej nie widział, uzyskał łączny wynik 66,71 TP3T w porównaniu z 36,71 TP3T dla zestawu testowego wyjściowego. Zachował 551 TP3T swojego przyrostu bezpieczeństwa na tych nieznanych danych. Model DGM nie zachował w tym przypadku żadnego ze swoich przyrostów.
Każdy podział obejmuje około 30 zadań, więc 3,3 punktu odpowiada jednemu zadaniu. Całe badanie dotyczy wyłącznie generowania bezpiecznego kodu. W tych testach porównawczych lepsze zestawy testowe często poprawiały oba wskaźniki jednocześnie, więc przypadek, w którym bezpieczeństwo i funkcjonalność rozchodzą się, pozostaje nadal niesprawdzony, co sami autorzy przyznają.
Szybki test na znalezienie własnego środka sprzyjającego samodoskonaleniu
Konfiguracja opisana w artykule przekłada się na niewielki projekt bez klastra badawczego. Zacznij od sporządzenia listy wszystkich plików, które może zapisywać twój agent. Wszystko, co służy do oceny agenta, należy usunąć z tej listy.
Przed każdym uruchomieniem należy wykonać migawkę tych plików, a po jego zakończeniu je przywrócić – co już zapewnia polecenie `git checkout` stosowane do chronionych ścieżek.
Następnie przejrzyj pliki diff agenta pod kątem nazw zadań i sztywno zakodowanych typów błędów. Poprawka, która zakłada, że każdy błąd to CWE-125, wydaje się być postępem, dopóki dane się nie zmienią. To, które pliki diff zasługują na najdokładniejsze przeanalizowanie, zależy od o tym, z czym kod wchodzi w interakcję, a nie o tym, w jakim narzędziu został napisany.
Dwie zasady, których Twój agent nigdy nie powinien zmieniać
W serii testów z wynikiem idealnym zastosowano wszystkie możliwe strategie obronne typu „sandbox”, a mimo to wynik okazał się fałszywy. Autorzy doszli do wniosku, że każda reguła akceptacji oparta wyłącznie na informacjach zwrotnych z danych szkoleniowych może zostać wykorzystana przez atakującego – w tym również ich własna. Należy ją zweryfikować na danych testowych dotyczących bezpieczeństwa, które zostały odłożone na bok.
Jeśli więc pozwolisz agentowi samodoskonalącemu się na dostęp do twojego kodu, ustal dwie zasady, których nie może edytować. Program oceniający pozostaje poza jego zasięgiem. Ostateczna kontrola dotyczy zadań, których agent nigdy wcześniej nie widział.
Źródło | https://arxiv.org/abs/2610.15150
