Memory Poisoning označuje cielené vkladanie manipulovaného obsahu do dlhodobej alebo vektorovej pamäte AI agenta. Na rozdiel od jednorazovej prompt injection, ktorá pôsobí len v rámci jednej odpovede, ostáva škodlivý obsah perzistentne uložený. Pri každom neskoršom načítaní kompromituje správanie agenta. V OWASP Top 10 for Agentic Applications 2026 je táto hrozba uvedená ako ASI06 (Memory & Context Poisoning).

Rozhodujúci rozdiel oproti čisto chatbotom: zatiaľ čo tie medzi sessions zabúdajú, agentické systémy udržiavajú perzistentnú pamäť – históriu konverzácií, preferencie používateľov, naučený kontext a RAG story. Práve to vytvára trvalú útočnú plochu. Útočník injektuje raz, payload beží neobmedzene ďalej a každá budúca session zdedí kompromitáciu.

• Perzistencia je hlavné riziko: Jediný úspešný zápis dokáže pamäť trvalo otráviť – manipulácia prežije týždne bežnej prevádzky.
• Načítanie, nie vstup, je kritický moment: Škoda nevzniká pri zápise, ale keď je otrávený záznam neskôr načítaný a spracovaný ako dôveryhodný kontext.
• Validácia pri zápise plus provenance plus audity pamäte sú tri nosné piliere obrany – žiadne jednotlivé opatrenie nestačí.

Útočné vektory: ako sa obsah dostáva do pamäte

Memory Poisoning využíva viacero, sčasti kombinovateľných vstupných brán. Agent nedokáže spoľahlivo rozlíšiť medzi inštrukciou a dátami – každý text, ktorý prečíta a uloží, je súčasťou útočnej plochy.

• Priama injekcia do pamäte: Agent uloží nepriateľský obsah s vysokou konfidenciou ako naučený fakt.
• Poisoning RAG storu: Manipulovaný obsah sa vloží do referencovanej znalostnej databázy.
• Manipulácia embeddings: Adversariálne vstupy v priestore embeddings posúvajú sémantickú reprezentáciu.
• Delayed Tool Invocation: Spúšťacie frázy aktivujú payload až týždne neskôr – spáč v pamäti.
• Vector-store insertion: Útoky proti embeddings zdieľaným naprieč mandantmi prenášajú otravu cez hranice tenantov.

Riziko perzistencie: prečo je pamäť nebezpečnejšia ako vstup

Záludnosťou Memory Poisoningu je časové oddelenie útoku a účinku. Otrávená pamäť vedie k behavioral driftu, ktorý nastáva bez zmeny kódu alebo modelu – a tým uniká klasickým kontrolám change managementu. Lakera AI v novembri 2025 zdokumentovala takzvané správanie typu sleeper agent: kompromitovaní agenti si vytvorili perzistentné nepravdivé presvedčenia o bezpečnostných politikách a vzťahoch s dodávateľmi a dokonca ich obhajovali, keď ich ľudia spochybňovali.

Pre scenáre DACH B2B sú obzvlášť relevantné tri vzory:

• Poisťovňa s agentom na triáž škôd: Agent sa z jediného otráveného príkladu naučí, že „poistníci z PSČ X sa schvaľujú prednostne". Toto sleeper skreslenie prežije týždne bežnej prevádzky.
• Prevádzkovateľ KRITIS s agentom na prediktívnu údržbu: Z otrávenej telemetrie sa agent naučí, že prahová hodnota vibrácií je „normálna" – spáč, ktorý môže prispieť k výpadku.
• Compliance agent banky: Chápanie „podozrivej aktivity" sa graduálne posúva v dôsledku dlhotrvajúceho poisoningu session pamäte.

Protiopatrenia: štyri obranné úrovne

Účinná obrana proti Memory Poisoningu sleduje princíp defense-in-depth naprieč designom, buildom, runtimom a prevádzkou. Žiadna jednotlivá vrstva nestačí – rozhoduje kombinácia.

Validácia a provenance ako jadro

Najúčinnejšia páka spočíva v samotnom zápise. Každý záznam v pamäti by mal niesť provenance metadáta: zdroj, časovú pečiatku, ingestion cestu a hodnotu konfidencie. Pri načítaní source-confidence-score váži záznamy podľa dôveryhodnosti. Záznamy, ktoré nemožno priradiť žiadnemu overiteľnému zdroju, sa nesmú spracovávať ako zaistené poznanie. Obsah by mal byť pred embeddingom validovaný a otagovaný podľa trust-tier – napríklad „interne overené", „externe nepotvrdené", „generované používateľom".

Oddelenie dôveryhodných zdrojov a izolácia mandantov

Vektorové story potrebujú access-controls na úrovni row alebo namespace. Embedding story sa nikdy nesmú zdieľať cez hranice mandantov – každý tenant dostane separátny vektorový index. Pamäť sa šifruje at rest, ideálne s kľúčmi spravovanými zákazníkom. Proti embedding inversion pomáhajú frekvenčné limity dotazov, Differential Privacy na embeddings a detekcia anomálií v priestore embeddings.

Audity pamäte a detekčné signály

Audity pamäte kontrolujú obsah vzorkovo a overujú jeho provenance. Nasledujúce signály naznačujú poisoning:

• Drift v baseline správaní agenta bez zmeny kódu alebo modelu.
• Neoveriteľné záznamy v pamäti bez provenance recordu.
• Sémantické odľahlé hodnoty vo vektorovom store.
• Agent tvrdí, že si „pamätá" inštrukcie, pre ktoré neexistuje žiadny provenance record.

Úplný audit-logging pre každú akciu agenta (stav 2026) by mal zahŕňať aspoň memory-write a read eventy, retrieval dotazy s vrátenými ID dokumentov, ako aj odôvodnenie rozhodnutia – ideálne ako WORM logy (write-once-read-many) s kryptografickým podpisom na detekciu manipulácie.

Konkrétny príklad: Delayed Tool Invocation

Google Gemini Memory Attack (február 2025, zdokumentovaný Johannom Rehbergerom) ukazuje mechanizmus názorne. Nahratý dokument obsahoval skryté prompty, ktoré inštruovali Gemini, aby uložil nepravdivé informácie až vtedy, keď sa v budúcej konverzácii objavia spúšťacie slová ako „yes", „no" alebo „sure". Výsledok: Gemini si „spomenul" na výskumníka ako na 102-ročného plochozemca, ktorý žije v Matrixe. Google vyhodnotil dopad ako nízky, ale zraniteľnosť potvrdil.

V pseudokóde možno útok načrtnúť takto:

```

Fáza 1 – Injekcia (jednorazovo, cez manipulovaný dokument)

AK vstup_pouzivatela OBSAHUJE spustacie_slovo ("yes" | "no" | "sure"):
memory.zapis(zaznam="Pouzivatel ma 102 rokov", konfidencia=vysoka)
# ziadny provenance record, ziadna validacia pri zapise

Fáza 2 – Aktivácia (o týždne neskôr, ľubovoľná session)

pri nacitani: memory.citaj("Profil-pouzivatela")
-> vracia otraveny zaznam ako zaisteny fakt
```

Obrana s validáciou pri zápise by záznam vo fáze 1 odmietla: žiadny dohľadateľný provenance record, externý a neoverený zdroj, nízky trust-tier. Pri načítaní vo fáze 2 by source-confidence-weighting záznam zaradil nižšie. Pri Calendar Invite Poisoning (Targeted Promptware Attacks, 2025) manipulované pozvánky v kalendári implantovali perzistentné inštrukcie do Geminiho „Saved Info" – 73 percent zo 14 testovaných scenárov bolo vyhodnotených ako High až Critical, od spamu až po otváranie smart-home zariadení.

Ukotvenie compliance v regióne DACH

Memory Poisoning nie je len technickou, ale aj regulačnou témou. ASI06 je priradený k technike MITRE ATLAS AML.T0085 (Memory Poisoning), ktorá pribudla v rámci kolaborácie so Zenity z októbra 2025. Úzko príbuzná je už predtým existujúca technika AML.T0020 (Poison Training Data), ktorá ako tréningový náprotivok predchádza ASI06. Pre nemecky hovoriacich deployerov sú relevantné nasledujúce kotvy (stav 2026):

• GDPR: čl. 5(1)(d) (správnosť), čl. 17 (právo na vymazanie), čl. 32 (technicko-organizačné opatrenia).
• EU AI Act: čl. 10 (governance dát) a čl. 15 (kybernetická bezpečnosť). Embedding inversion útoky zatiaľ nie sú v štandardoch samostatne kodifikované – medzeru zaceľuje deployer.
• ISO/IEC 42001: A.7 (dáta pre AI systémy), A.7.4 (kvalita dát), A.6.2.8 (logging).

Postupy mazania pamäte musia byť zladené s GDPR čl. 17 – právo na zabudnutie sa výslovne vzťahuje aj na perzistentné úložiská agentov a embedding story.

Pre agentúry a B2B rozhodovateľov

Kto nasadzuje agentickú AI pre zákazníkov alebo vo vlastnej prevádzke, nemal by bezpečnosť pamäte vnímať ako podradný detail. Pred každým rolloutom si ujasnite tri otázky: Ktoré zdroje vôbec smú zapisovať do perzistentnej pamäte? Nesie každý záznam provenance metadáta? Sú indexy mandantov čisto oddelené? Pre marketingové a digitálne agentúry, ktoré prevádzkujú agentické systémy pre viacerých zákazníkov, je izolácia vektorového storu naprieč mandantmi najdôležitejšou jednotlivou pákou – cross-tenant kontaminácia pamäte je zároveň rizikom dôvery aj zodpovednosti. Blck Alpaca podporuje spoločnosti v regióne DACH pri nastavovaní validácie pamäte, konceptov provenance a pravidelných auditov pamäte v súlade s OWASP ASI06, EU AI Act a GDPR – pragmaticky a auditovateľne.