Memory poisoning: jak chronić pamięć długotrwałą agenta AI

Memory poisoning zmienia zachowanie agenta po zakończeniu ataku. Złośliwa preferencja, fałszywy fakt lub instrukcja zostaje zapisana w pamięci i wpływa na kolejne zadania, czasem innych użytkowników.

Oddziel typy pamięci

Rozróżnij historię sesji, profil użytkownika, wiedzę organizacyjną i stan zadania. Każdy typ ma innego ownera, TTL i zasady zapisu. Dane jednego tenanta nigdy nie powinny być wyszukiwane w kontekście drugiego.

Kontrola zapisu

Model może proponować wpis, ale deterministyczna warstwa waliduje schemat, źródło, klasyfikację i konflikt z istniejącymi danymi. Pamięć uprzywilejowana wymaga potwierdzenia człowieka lub zaufanego systemu.

Zapisuj provenance, wersję, autora, czas i powód. Surowy tekst z internetu nie powinien automatycznie stawać się trwałą regułą.

Odczyt i wygasanie

Retriever filtruje tenant, użytkownika, cel i poziom zaufania przed podobieństwem wektorowym. Stare wpisy wygasają, a krytyczne fakty są ponownie potwierdzane. Zapewnij podgląd, korektę i bezpieczne usuwanie.

Testy

Wprowadź opóźniony trigger, konflikt preferencji, zapis między tenantami i fałszywą instrukcję administratora. Sprawdź backup, replikę oraz log — usunięcie z głównego indeksu może nie kończyć retencji.

OWASP wskazuje memory poisoning jako kluczowe ryzyko agentów. Kontrolę pamięci połącz z bezpieczeństwem RAG i rejestrem właścicieli danych.

Pamięć nie jest jednym magazynem

Rozdziel stan krótkiej rozmowy, preferencje użytkownika, fakty biznesowe, wiedzę pobraną z dokumentów i procedury systemowe. Każda klasa ma innego właściciela, okres retencji i poziom zaufania. Instrukcja operacyjna nie powinna trafić do tej samej kolekcji co swobodna notatka użytkownika, a dane jednego tenantu nie mogą współdzielić indeksu bez twardej filtracji.

Każdy wpis zapisuj z pochodzeniem, autorem, czasem, tenantem, wersją oraz uzasadnieniem. Treść wygenerowana przez model ma niższy poziom zaufania niż zatwierdzona polityka. Jeżeli nie można ustalić źródła rekordu, nie powinien on wpływać na akcję wysokiego ryzyka.

Kontrola zapisu i odczytu

Model może zaproponować pamięć, ale osobny komponent sprawdza schemat, klasyfikację danych, duplikaty i konflikt z istniejącą polityką. Wrażliwe preferencje oraz trwałe instrukcje wymagają jawnej zgody. Przy odczycie filtruj najpierw tenant, właściciela i typ, a dopiero potem wykonuj wyszukiwanie podobieństwa.

Wynik pamięci jest kontekstem, nie poleceniem. Przed wykonaniem narzędzia aktualna polityka i zgoda użytkownika mają pierwszeństwo nad rekordem historycznym. Ustal TTL oraz mechanizm unieważnienia, który obejmuje indeks główny, cache, repliki i kopie przetwarzane przez pipeline.

Reakcja na zatrucie

Po wykryciu incydentu zatrzymaj zapis, zidentyfikuj zakres rekordów przez provenance i odtwórz czysty indeks z wiarygodnego źródła. Sprawdź, które sesje odczytały skażone dane oraz jakie akcje nastąpiły później. Samo usunięcie widocznego wpisu nie wystarcza, jeśli wektor został już zmaterializowany w streszczeniu lub cache.

Testy powinny obejmować delayed trigger, podobne rekordy rozproszone w czasie, konflikt tenantów, ponowne pojawienie się po restore oraz próbę nadania notatce rangi polityki systemowej. Mierz odsetek zatrzymanych zapisów, czas unieważnienia i liczbę dalszych działań po skażonym odczycie.

Konflikty i poziomy pewności

Gdy dwa rekordy opisują ten sam fakt inaczej, system nie powinien wybierać automatycznie nowszego lub bardziej podobnego. Porównaj źródło, właściciela, czas i poziom zatwierdzenia. Konflikt dotyczący płatności, tożsamości lub procedury może wymagać potwierdzenia człowieka zamiast kolejnego streszczenia przez model.

Pamięć powinna odróżniać fakt zweryfikowany, deklarację użytkownika, wniosek modelu i treść zewnętrzną. Etykieta pewności nie zastępuje provenance, ale pomaga ograniczyć użycie słabych danych w decyzjach wysokiego wpływu.

Audyt i prawa użytkownika

Zapewnij widok rekordów wpływających na zachowanie agenta, możliwość korekty i kontrolowanego usunięcia. Loguj kto, kiedy i dlaczego zmienił pamięć oraz które wersje pozostały w retencji. W środowisku regulowanym okres przechowywania powinien wynikać z klasy danych, nie z wygody produktu.

Regularny audyt szuka rekordów bez właściciela, nietypowo często przywoływanych instrukcji, treści przecinającej tenanty i wpisów, które przeżyły termin TTL. Te sygnały mogą ujawnić zarówno atak, jak i błąd synchronizacji pipeline’u.

Przy projektowaniu kopii zapasowych sprawdź, czy restore respektuje listę unieważnień. Przywrócenie poprawnej technicznie kopii może ponownie wprowadzić usunięte, skażone rekordy. Test odtwarzania powinien więc obejmować politykę retencji, provenance oraz ponowną indeksację, nie tylko integralność pliku.

Właściciel produktu powinien regularnie zatwierdzać, które decyzje mogą korzystać z pamięci automatycznie. Wzrost wpływu funkcji wymaga ponownej oceny danych, zgody i ścieżki unieważnienia.

Źródła: OWASP AI Agent Security, OWASP Top 10 for Agentic Applications 2026.