Memory poisoning refers to the deliberate injection of manipulated content into the long-term or vector memory of an AI agent. Unlike a one-off prompt injection, which only takes effect within a single response, the malicious content remains persistently stored. On every subsequent retrieval, it compromises the agent's behaviour. In the OWASP Top 10 for Agentic Applications 2026, this threat is listed as ASI06 (Memory & Context Poisoning).

The decisive difference compared with pure chatbots: while these forget between sessions, agentic systems maintain a persistent memory — conversation history, user preferences, learned context and RAG stores. This is precisely what creates a durable attack surface. The attacker injects once, the payload continues to run indefinitely, and every future session inherits the compromise.

• Persistence is the core risk: A single successful write operation can poison the memory permanently — the manipulation outlives weeks of normal operation.
• Retrieval rather than input is the critical moment: The damage does not arise on write, but when the poisoned entry is later retrieved and treated as trustworthy context.
• Validation on write plus provenance plus memory audits are the three supporting pillars of defence — no single measure is sufficient.

Attack Vectors: How Content Enters the Memory

Memory poisoning exploits several entry points, some of which can be combined. The agent cannot reliably distinguish between instruction and data — every piece of text it reads and stores is part of the attack surface.

• Direct memory injection: The agent stores hostile content with high confidence as a learned fact.
• RAG store poisoning: Manipulated content is introduced into the referenced knowledge base.
• Embedding manipulation: Adversarial inputs in the embedding space shift the semantic representation.
• Delayed tool invocation: Trigger phrases activate the payload only weeks later — a sleeper in the memory.
• Vector store insertion: Attacks against cross-tenant shared embeddings carry the poisoning across tenant boundaries.

Persistence Risk: Why Memory Is More Dangerous Than the Input

The insidious aspect of memory poisoning is the temporal decoupling of attack and effect. A poisoned memory leads to behavioural drift that occurs without any code or model change — and thus evades classic change-management controls. Lakera AI documented so-called sleeper-agent behaviour in November 2025: compromised agents developed persistent false beliefs about security policies and supplier relationships and even defended these when humans questioned them.

For DACH B2B scenarios, three patterns are particularly relevant:

• Insurer with a claims triage agent: The agent learns from a single poisoned example that "policyholders from postcode X are to be preferentially approved". This sleeper bias survives weeks of normal operation.
• Critical-infrastructure operator with a predictive maintenance agent: From poisoned telemetry, the agent learns that a vibration threshold is "normal" — a sleeper that can contribute to an outage.
• Bank compliance agent: The understanding of "suspicious activity" shifts gradually through long-running poisoning of the session memory.

Countermeasures: Four Layers of Defence

Effective defence against memory poisoning follows the defence-in-depth principle across design, build, runtime and operations. No single layer is sufficient — the combination is what counts.

Validation and Provenance as the Core

The most effective lever lies in the write operation itself. Every memory entry should carry provenance metadata: source, timestamp, ingestion path and confidence value. On retrieval, a source-confidence score weights entries according to their trustworthiness. Entries that cannot be attributed to a verifiable source must not be treated as established knowledge. Content should be validated before embedding and tagged by trust tier — for example "internally verified", "externally unconfirmed", "user-generated".

Separation of Trusted Sources and Tenant Isolation

Vector stores require access controls at row or namespace level. Embedding stores must never be shared across tenant boundaries — each tenant receives a separate vector index. Memory is encrypted at rest, ideally with customer-managed keys. To counter embedding inversion, query rate limiting, differential privacy on embeddings and anomaly detection in the embedding space all help.

Memory Audits and Detection Signals

Memory audits review content on a sampling basis and verify its provenance. The following signals point to poisoning:

• Drift in the agent's baseline behaviour without any code or model change.
• Non-verifiable memory entries without a provenance record.
• Semantic outliers in the vector store.
• The agent claims to "remember" instructions for which no provenance record exists.

Complete audit logging per agent action (as of 2026) should cover at least memory write and read events, retrieval queries with the returned document IDs as well as the decision rationale — ideally as WORM logs (write-once-read-many) with cryptographic signing for tamper detection.

Concrete Example: Delayed Tool Invocation

The Google Gemini Memory Attack (February 2025, documented by Johann Rehberger) illustrates the mechanism by example. An uploaded document contained hidden prompts that instructed Gemini to store false information only once trigger words such as "yes", "no" or "sure" appeared in a future conversation. The result: Gemini "remembered" the researcher as a 102-year-old flat-earther living in the Matrix. Google rated the impact as low but confirmed the vulnerability.

In pseudocode, the attack can be outlined as follows:

```

Phase 1 – Injection (one-off, via manipulated document)

IF user_input CONTAINS trigger_word ("yes" | "no" | "sure"):
memory.write(entry="User is 102 years old", confidence=high)
# no provenance record, no validation on write

Phase 2 – Activation (weeks later, any session)

on retrieval: memory.read("user profile")
-> returns the poisoned entry as an established fact
```

A defence with validation on write would have rejected the entry in Phase 1: no traceable provenance record, external and unverified source, low trust tier. On retrieval in Phase 2, the source-confidence weighting would have downgraded the entry. In the Calendar Invite Poisoning (Targeted Promptware Attacks, 2025), manipulated calendar invites implanted persistent instructions into Gemini's "Saved Info" — 73 per cent of 14 tested scenarios were classified as High to Critical, ranging from spam to the opening of smart-home devices.

Compliance Anchoring in the DACH Region

Memory poisoning is not only a technical but also a regulatory matter. ASI06 is mapped to the MITRE ATLAS technique AML.T0085 (Memory Poisoning), which was added as part of the Zenity collaboration of October 2025. Closely related is the previously existing technique AML.T0020 (Poison Training Data), which, as the training-side counterpart, precedes ASI06. For German-speaking deployers, the following anchors are relevant (as of 2026):

• GDPR: Art. 5(1)(d) (accuracy), Art. 17 (right to erasure), Art. 32 (technical and organisational measures).
• EU AI Act: Art. 10 (data governance) and Art. 15 (cybersecurity). Embedding inversion attacks are not yet specifically codified in the standards — the deployer closes this gap.
• ISO/IEC 42001: A.7 (data for AI systems), A.7.4 (data quality), A.6.2.8 (logging).

Memory deletion procedures must be aligned with GDPR Art. 17 — the right to be forgotten expressly extends to persistent agent memory and embedding stores as well.

For Agencies and B2B Decision-Makers

Anyone deploying agentic AI for clients or in their own operations should not treat memory security as a secondary detail. Before every rollout, clarify three questions: Which sources are allowed to write to the persistent memory at all? Does every entry carry provenance metadata? Are tenant indices cleanly separated? For marketing and digital agencies operating agentic systems for multiple clients, cross-tenant vector store isolation is the single most important lever — cross-tenant contamination of the memory is both a trust and a liability risk. Blck Alpaca supports DACH companies in setting up memory validation, provenance concepts and regular memory audits in line with OWASP ASI06, the EU AI Act and GDPR — pragmatically and audit-proof.