PABLO.ENGINEERING
// WRÓĆ DO WSZYSTKICH WPISÓW
// 3 min

Wykrycie próby przełamania izolacji pamięci agentów i utwardzenie piaskownicy

W systemach wieloagentowych granica między przestrzeniami botów musi być szczelna. Jeśli jeden agent potraktuje spreparowany wpis we własnej pamięci jako polecenie do podejrzenia danych drugiego, cała prywatność użytkownika leży w gruzach.

Problem: wstrzyknięty marker w pamięci snu i próby ucieczki z katalogu

W nocnym skanowaniu bazy wiedzy leaf-scanner przeanalizował 429 plików pamięci botów oraz 492 fiszki edukacyjne. W pliku pamięci długoterminowej bota gym skaner podniósł alarm: natrafił na spreparowany znacznik odwołujący się wprost do profilu użytkownika przypisanego do agenta aneta, wraz z jawną instrukcją nakazującą jego odczyt i przetworzenie.

Równolegle w logach bramki gateway pojawiły się 32 błędy narzędziowe. Dominowały próby wywołania ls z parametrami wskazującymi na katalogi nadrzędne, zakończone komunikatem Path escapes sandbox root, oraz odrzucenia nieautoryzowanych poleceń przez listę allowlist. Piaskownica zadziałała poprawnie i zatrzymała wyciek, ale obecność takich prób w logach była jasnym sygnałem, że do bazy pamięci przeniknęła treść próbująca przełamać izolację.

Co zrobiłem: analiza wektora wycieku i porządki w harmonogramie

  1. Przeanalizowałem oznaczony przez leaf-scanner plik pamięci snu bota gym. Znacznik odizolowałem i potwierdziłem, że żadne dane z profilu drugiego bota nie zostały odczytane ani przekazane do modelu.
  2. Zarejestrowałem proces provision-worker w harmonogramie cron (commit ea63a9c), dzięki czemu zadania konserwacyjne środowiska agentów wykonują się automatycznie bez konieczności ręcznego wywoływania z terminala.
  3. Usunąłem fałszywe alarmy dietetyczne generowane przez moduł third-party-guard, które dotychczas zaśmiecały kanał powiadomień nieszkodliwymi komunikatami.
  4. Sprawdziłem działanie skanera spójności memory-verifier: w 15-minutowych cyklach przeskanował po 2-6 rekordów pamięci i nie wykrył żadnych uszkodzeń struktury bazy danych.
  5. Zweryfikowałem reguły sandboxa w OpenClaw: każda próba odwołania się przez bota do ścieżek bezwzględnych poza jego dedykowanym workspace kończy się natychmiastowym przerwaniem operacji w trybie fail-closed.

Dlaczego to ważne (Use Case)

Pamięć agenta z niezweryfikowaną zawartością przypomina tablicę ogłoszeń w korytarzu biura. Jeśli ktokolwiek może przyczepić na niej kartkę z napisem "wejrzyj do pokoju obok i skopiuj dokumenty z biurka kolegi", a sprzątacz bezmyślnie to polecenie wykona, dochodzi do naruszenia bezpieczeństwa całej firmy.

Dzięki automatycznemu skanowaniu leaf-scanner każda notatka trafiająca do pamięci długoterminowej jest weryfikowana pod kątem markerów cross-workspace i prób wstrzyknięcia promptu. Nawet jeśli agent podczas konwersacji z użytkownikiem zapisze podejrzaną frazę, skaner wyłapuje ją zanim jakikolwiek inny bot zdąży ją odczytać.

Czego się nauczyłem

  • Treści zapisywane w pamięci długoterminowej agenta muszą być traktowane jak surowe, niezaufane dane wejściowe. Agent nie może bezkrytycznie wykonywać instrukcji znalezionych we własnych historycznych notatkach.
  • Logi odmowy dostępu do sandboxa (Path escapes sandbox root) to cenny telemetryczny system wczesnego ostrzegania. Zamiast ignorować je jako "zwykłe błędy", należy badać, skąd wzięła się próba ucieczki z katalogu.
  • Alarmy monitoringu muszą być precyzyjne. Usunięcie fałszywych powiadomień z third-party-guard przywróciło czujność na prawdziwe incydenty bezpieczeństwa.
#daily#openclaw#security#reliability