Jak zapobiegać Memory Poisoning: zabezpieczenie pamięci długoterminowej i wektorowej agentów AI

Memory Poisoning to celowe wprowadzanie zmanipulowanych treści do pamięci długoterminowej lub wektorowej agenta AI. W odróżnieniu od jednorazowego prompt injection, który działa tylko w obrębie jednej odpowiedzi, złośliwa treść pozostaje trwale zapisana. Przy każdym późniejszym odczycie wypacza zachowanie agenta. OWASP Top 10 for Agentic Applications 2026 wymienia to zagrożenie jako ASI06 (Memory & Context Poisoning).

Zasadnicza różnica w porównaniu ze zwykłymi chatbotami: podczas gdy one zapominają między sesjami, systemy agentowe utrzymują trwałą pamięć: historię konwersacji, preferencje użytkowników, wyuczony kontekst i magazyny RAG. Właśnie to tworzy stałą powierzchnię ataku. Atakujący wstrzykuje treść raz, payload działa bez końca, a każda kolejna sesja dziedziczy naruszenie.

• Trwałość to kluczowe ryzyko: jeden udany zapis może trwale zatruć pamięć, a manipulacja przetrwa tygodnie normalnej pracy systemu.
• Krytycznym momentem jest odczyt, a nie wprowadzenie danych: szkoda nie powstaje przy zapisie, lecz wtedy, gdy zatruty wpis zostaje później odczytany i potraktowany jako zaufany kontekst.
• Walidacja przy zapisie, śledzenie pochodzenia i audyty pamięci to trzy główne filary obrony: żaden pojedynczy środek nie wystarczy.

Wektory ataku: jak treści trafiają do pamięci

Memory Poisoning wykorzystuje kilka dróg wejścia, które częściowo można łączyć. Agent nie potrafi niezawodnie odróżnić instrukcji od danych: każdy tekst, który czyta i zapisuje, staje się częścią powierzchni ataku.

• Bezpośrednie wstrzyknięcie do pamięci: agent zapisuje wrogą treść z wysokim poziomem pewności jako wyuczony fakt.
• Zatruwanie magazynu RAG: zmanipulowana treść trafia do bazy wiedzy, do której odwołuje się agent.
• Manipulacja embeddingami: adwersarialne dane wejściowe w przestrzeni embeddingów przesuwają reprezentację semantyczną.
• Delayed Tool Invocation: frazy wyzwalające aktywują payload dopiero po kilku tygodniach, niczym uśpiony agent w pamięci.
• Wstrzykiwanie do bazy wektorowej: ataki na embeddingi współdzielone przez wielu tenantów przenoszą zatrucie poza granice poszczególnych tenantów.

Ryzyko trwałości: dlaczego pamięć jest groźniejsza niż dane wejściowe

Podstępność Memory Poisoning polega na czasowym rozdzieleniu ataku i jego skutku. Zatruta pamięć prowadzi do dryfu behawioralnego (behavioral drift), który pojawia się bez zmiany kodu czy modelu, a tym samym wymyka się klasycznym mechanizmom kontroli zarządzania zmianą. Jak niezawodnie działają zatrute wpisy, które aktywują się dopiero później, pokazuje preprint Hidden in Memory: Sleeper Memory Poisoning in LLM Agents z maja 2026 roku: spreparowane dokumenty, strony internetowe lub repozytoria skłaniały asystentów LLM do zapisywania zmyślonych wspomnień o użytkowniku. Gdy te wpisy były później odczytywane, w zależności od modelu w 60–89% ewaluacji wywoływały zamierzone przez atakującego działanie agenta.

W scenariuszach B2B w regionie DACH (Niemcy, Austria, Szwajcaria) szczególnie istotne są trzy wzorce:

• Ubezpieczyciel z agentem do triażu zgłoszeń szkód: agent uczy się na podstawie jednego zatrutego przykładu, że „ubezpieczeni z kodu pocztowego X mają być akceptowani w pierwszej kolejności”. To uśpione zniekształcenie przetrwa tygodnie normalnej pracy.
• Operator infrastruktury krytycznej z agentem do konserwacji predykcyjnej: na podstawie zatrutej telemetrii agent uczy się, że pewien próg drgań jest „normalny”, czyli uśpione zagrożenie, które może przyczynić się do awarii.
• Agent compliance w banku: rozumienie „podejrzanej aktywności” stopniowo się przesuwa w wyniku długotrwałego zatruwania pamięci sesji.

Środki zaradcze: cztery poziomy obrony

Skuteczna obrona przed Memory Poisoning opiera się na zasadzie obrony w głąb na etapach projektowania, budowy, działania i eksploatacji. Żadna pojedyncza warstwa nie wystarczy, liczy się ich połączenie.

Walidacja i pochodzenie danych jako fundament

Najskuteczniejsza dźwignia tkwi w samym procesie zapisu. Każdy wpis w pamięci powinien zawierać metadane pochodzenia: źródło, znacznik czasu, ścieżkę ingestii i wartość pewności. Przy odczycie wskaźnik wiarygodności źródła nadaje wpisom wagę zależnie od stopnia zaufania. Wpisów, których nie da się przypisać do weryfikowalnego źródła, nie wolno traktować jako potwierdzonej wiedzy. Treści należy walidować przed utworzeniem embeddingu i oznaczać według poziomu zaufania, np. „zweryfikowane wewnętrznie”, „zewnętrzne, niepotwierdzone”, „wygenerowane przez użytkownika”.

Oddzielenie zaufanych źródeł i izolacja tenantów

Bazy wektorowe wymagają kontroli dostępu na poziomie wierszy lub przestrzeni nazw. Magazynów embeddingów nigdy nie wolno współdzielić między tenantami: każdy tenant otrzymuje osobny indeks wektorowy. Pamięć jest szyfrowana w spoczynku, najlepiej kluczami zarządzanymi przez klienta. Przed inwersją embeddingów chronią limity częstotliwości zapytań, prywatność różnicowa w embeddingach i wykrywanie anomalii w przestrzeni embeddingów.

Audyty pamięci i sygnały wykrywania

Audyty pamięci wyrywkowo sprawdzają treści i weryfikują ich pochodzenie. Na zatrucie wskazują następujące sygnały:

• Dryf w bazowym zachowaniu agenta bez zmiany kodu czy modelu.
• Nieweryfikowalne wpisy w pamięci bez rekordu pochodzenia.
• Semantyczne wartości odstające w bazie wektorowej.
• Agent twierdzi, że „pamięta” instrukcje, dla których nie istnieje żaden rekord pochodzenia.

Pełne logowanie audytowe każdej akcji agenta (stan na 2026 rok) powinno obejmować co najmniej zdarzenia zapisu i odczytu pamięci, zapytania wyszukiwania wraz ze zwróconymi identyfikatorami dokumentów oraz uzasadnienie decyzji, najlepiej w postaci logów WORM (write-once-read-many) z podpisem kryptograficznym umożliwiającym wykrycie manipulacji.

Konkretny przykład: Delayed Tool Invocation

Google Gemini Memory Attack (luty 2025, udokumentowany przez Johanna Rehbergera) dobrze ilustruje ten mechanizm. Przesłany dokument zawierał ukryte prompty, które nakazywały Gemini zapisać fałszywe informacje dopiero wtedy, gdy w przyszłej rozmowie pojawią się słowa wyzwalające, takie jak „yes”, „no” czy „sure”. Efekt: Gemini „pamiętał” badacza jako 102-letniego płaskoziemcę. Google ocenił ryzyko jako związane z nadużyciem, o niskim prawdopodobieństwie i niewielkim wpływie.

W pseudokodzie atak można przedstawić następująco:

```

Faza 1. Wstrzyknięcie (jednorazowo, przez zmanipulowany dokument)

JEŚLI wejscie_uzytkownika ZAWIERA slowo_wyzwalajace ("yes" | "no" | "sure"):
memory.zapisz(wpis="Użytkownik ma 102 lata", pewnosc=wysoka)
# brak rekordu pochodzenia, brak walidacji przy zapisie

Faza 2. Aktywacja (kilka tygodni później, dowolna sesja)

przy odczycie: memory.czytaj("Profil użytkownika")
-> zwraca zatruty wpis jako potwierdzony fakt
```

Obrona z walidacją przy zapisie odrzuciłaby wpis już w fazie 1: brak możliwego do prześledzenia rekordu pochodzenia, zewnętrzne i niezweryfikowane źródło, niski poziom zaufania. Przy odczycie w fazie 2 ważenie według wiarygodności źródła obniżyłoby rangę wpisu. W przypadku Calendar Invite Poisoning (Targeted Promptware Attacks, 2025) zmanipulowane zaproszenia z kalendarza wszczepiały trwałe instrukcje do funkcji „Saved Info” w Gemini. Autorzy zaklasyfikowali 73% przeanalizowanych zagrożeń jako High lub Critical (Nassi et al. 2025). Opisanych 14 scenariuszy obejmuje przypadki od spamu po sterowanie urządzeniami inteligentnego domu.

Zgodność z przepisami w Niemczech i Austrii

Memory Poisoning to zagadnienie zarówno techniczne, jak i regulacyjne. Merytorycznie ASI06 odpowiada technice MITRE ATLAS AML.T0080 (AI Agent Context Poisoning), a samo Memory Poisoning podtechnice AML.T0080.000 (Memory). Obie zostały dodane w ramach współpracy z Zenity z października 2025 roku. Blisko z nimi związana jest istniejąca już wcześniej technika AML.T0020 (Poison Training Data), która jako odpowiednik po stronie treningu poprzedza ASI06. Sam dokument OWASP dotyczący Top 10 for Agentic Applications przypisuje ASI06 do zagrożenia T1 Memory Poisoning z przewodnika OWASP Agentic AI Threats and Mitigations. Dla podmiotów stosujących w Niemczech i Austrii istotne są następujące punkty odniesienia (stan na 2026 rok):

• RODO: art. 5 ust. 1 lit. d (prawidłowość), art. 17 (prawo do usunięcia danych), art. 32 (środki techniczne i organizacyjne).
• Unijny AI Act: art. 10 (zarządzanie danymi) i art. 15 (cyberbezpieczeństwo), oba wyłącznie dla systemów AI wysokiego ryzyka. Ataki polegające na inwersji embeddingów nie są jeszcze odrębnie skodyfikowane w standardach, tę lukę musi wypełnić podmiot stosujący.
• ISO/IEC 42001: A.7 (dane dla systemów AI), A.7.4 (jakość danych), A.6.2.8 (logowanie).

Procedury usuwania danych z pamięci muszą być zgodne z art. 17 RODO. Prawo do usunięcia danych dotyczy danych osobowych niezależnie od miejsca ich przechowywania, a więc także trwałej pamięci agentów i magazynów embeddingów, o ile zawierają one dane osobowe.

Dla agencji i decydentów B2B

Jeśli wykorzystujesz agentową AI dla klientów lub we własnej firmie, nie traktuj bezpieczeństwa pamięci jako drugorzędnego szczegółu. Przed każdym wdrożeniem wyjaśnij trzy kwestie: Które źródła w ogóle mogą zapisywać dane w pamięci trwałej? Czy każdy wpis ma metadane pochodzenia? Czy indeksy poszczególnych tenantów są czysto rozdzielone? Dla agencji marketingowych i cyfrowych, które obsługują systemy agentowe dla wielu klientów, izolacja baz wektorowych między tenantami to najważniejsza pojedyncza dźwignia: skażenie pamięci między tenantami oznacza jednocześnie ryzyko utraty zaufania i ryzyko odpowiedzialności prawnej. Blck Alpaca pomaga firmom w całej Europie wdrażać walidację pamięci, koncepcje śledzenia pochodzenia i regularne audyty pamięci zgodnie z OWASP ASI06, unijnym AI Act i RODO, pragmatycznie i w sposób odporny na audyt.