What Is Persistent Prompt Injection?
Persistent prompt injection describes prompt-injection influence that outlives the encounter in which it entered. The content that carried the influence is either written into state the system keeps, or it remains reachable at a source the system reads again, so a later task, a later session, another user or another agent can be affected by material nobody supplied in that later moment.
The entry mechanism is not new. Competing instructions still arrive through an intended input channel, as described under direct prompt injection, or through external content the system retrieves, reads or processes, as described under indirect prompt injection. What this article is about is the lifecycle afterwards: what the system retains, whether and how the provenance of that retained material is preserved, weakened or lost, when it becomes model-visible again, and which decisions stand between reactivation and an actual security effect.
Persistence Is a Lifecycle Property, Not a Third Entry Mode
It is tempting to file persistence next to direct and indirect as if it were a third way in. It is not. Every persistent case begins as one of the two established entry modes and then acquires a second property: the influencing material, or a derivative of it, survives.
| Aspect | Single encounter | Persistent case |
|---|---|---|
| Entry | Direct or indirect | Direct or indirect, unchanged |
| Survival beyond the initial encounter | Influenced state or source does not persist past the encounter | Influenced state or a reachable source survives and can re-enter later contexts |
| Number of context assemblies affected | Contexts reached during the current encounter | Can recur in later contexts or sessions |
| Provenance risk | Provenance can be weakened or lost during transformations in the current encounter | Provenance can be weakened or lost across writes, later retrievals and transformations over time |
| Affected principals | The current user or task | Later tasks, other users or other agents, only if retrieval boundaries permit |
| Remediation | No persistence cleanup once the context or source no longer re-enters, though executed side effects still need normal remediation | Secure or remove the persistent source, locate and invalidate derivatives that actually exist, and remediate any executed effects |
Reading persistence as a property rather than as a class keeps two useful questions separate. First, how did the content enter? Second, what did the system decide to keep, and under which authorization? The second question is where the specific controls of this article live.
Scope and Neighbouring Classes
| Class | Defining mechanism | Relationship to this topic |
|---|---|---|
| Memory and Context Poisoning (ASI06:2026) | Stored or retrievable context is corrupted or seeded with misleading data | The closest current agentic classification for the derived-state family |
| Prompt Injection (LLM01:2026) | Inputs alter model behaviour | The entry mechanism; one-time prompts stay here |
| RAG prompt injection | Retrieved passages carry instructions into context | A retrieval path that can produce persistence, but is not identical with it |
| Data poisoning | Training or fine-tuning data is manipulated | Different lifecycle stage: affects the model, not the runtime state |
| Model poisoning | Model weights or artifacts are manipulated | A supply-chain compromise of the model itself |
| Configuration compromise | Deterministic settings, hooks or instruction files are altered | May be a system compromise in its own right even when the visible effect is persistent model influence |
| Cascading failures | One faulty component drives further failures | A possible consequence pattern, not the definition |
Two Families of Persistence
Persistent prompt injection is broader than memory poisoning, because a system can be repeatedly influenced by the same material without ever writing a memory object. Two families deserve equal treatment.
Long-term memory entries, conversation summaries, compaction artifacts, user preferences and profile state, scratchpads, workflow notes, caches, embeddings and index entries, shared agent memory, and local configuration or hook-like state that is later injected into context.
Attacker-reachable repository files, tickets, wiki pages, documents, mailboxes or web resources that stay in place and are re-read whenever a similar task runs. No write into the application is needed for the influence to recur.
The two families fail differently. Derived state can be less visible and harder to audit for the person affected, and it carries an implicit claim of relevance. Reprocessed sources may be visible depending on the system and workflow, but they keep producing influence until someone changes the source or the retrieval policy. A programme that only hardens memory writes will keep re-reading the poisoned file; a programme that only cleans sources will keep the summary that condensed it. Both are addressed under source code prompt injection and RAG prompt injection from the vector side; here they are treated as persistence surfaces.
The Persistence Lifecycle
Every arrow in that chain is a place where the attempt can end. Content can be model-visible without ever being retained. It can be retained without being retrieved again. It can be retrieved and summarised into something that no longer carries the instruction. It can reactivate influence and still produce nothing but a rejected proposal, because the authorization layer does not consult the model about what it is allowed to do.
Security States That Must Be Kept Apart
| State | What it establishes | What it does not establish |
|---|---|---|
| Placement or write | Controlled content entered a persistent surface | That anything will ever read it again |
| Later retrieval | The stored item was selected into a later context | That the model was influenced by it |
| Re-exposure | The item became model-visible again in its stored form | That behaviour changed |
| Model influence | Output, plan or tool choice measurably changed | That a policy was bypassed |
| Policy bypass | A control that should have stopped the step did not | That an action was executed |
| Unauthorized action | An action outside the authorized scope took effect | The extent of the damage |
| Security impact | A concrete effect on confidentiality, integrity or availability | Nothing further is assumed |
The same discipline applies to the word compromise. A written memory entry containing influenced text is a security-relevant state change and deserves an investigation. It is not, by itself, a compromised system, a compromised user account or a compromised model.
Persistence Surfaces Inventory
Explicit remember, update and delete operations, whether model-proposed or user-initiated.
Condensed history that replaces the original turns once a window fills.
Vector entries derived from influenced text that remain retrievable after the source changes.
Cached answers, fetched pages and grounding snapshots reused for later similar requests.
Retained transcripts replayed into later sessions or shared across devices.
Stored rules about how the system should behave for this user or project.
Notes, plans, tickets and scratchpads that later runs read as working context.
Blackboards and shared stores several agents write to and read from.
In-repo instruction files and hook-like configuration that are loaded into context on later runs.
Documents, pages and tickets that stay in place and are re-read by future tasks.
Provenance Risk in Summaries and Compaction
Compaction can be a major point of provenance loss, and the loss is quiet. If mixed-trust inputs are condensed into a single artifact without per-source lineage and trust metadata, origin distinctions can be lost. If the pipeline stores the summary as one artifact without per-source lineage, material previously labelled untrusted can later reappear as neutral-looking prose apparently produced by the system.
| Property | Original turn | Summary that replaces it |
|---|---|---|
| Source identity | Known per item | Must be carried as a list, not dropped |
| Trust classification | Per item | Preserve source or span level trust where possible; otherwise classify conservatively at the least-trusted input level |
| Writer or producer | The channel that supplied it | The model, recorded as a derived artifact |
| Lineage | Direct source relation available | Must preserve links to all inputs it condensed |
| Scope | The current task | Must not silently widen beyond it |
Provenance and Lineage Requirements
Anything written into a persistent surface should carry enough metadata that a later reader can decide whether to use it, and a later investigator can find every copy of it.
Metadata that should accompany a persistent write
- Original source identifier and channel
- Writer identity, human or agent, and the acting agent's identity if different
- Tenant, user, project and task scope
- Transformation lineage that links derived artifacts to their inputs
- Write reason, that is which step requested the write and why
- Timestamp, version and the policy version in force at write time
- Trust classification and, where used, a confidence value recorded as a signal
- Expiry or revalidation date
- Links to downstream artifacts such as embeddings, caches and index entries
Lineage is especially important for cleanup. Without it, derivatives cannot be enumerated reliably, so deleting a poisoned source leaves open what was derived from it.
Memory Writes Are Security-Relevant State Changes
A write that can shape future behaviour should be treated as a security-relevant, configuration-like state change. It should therefore be governed like one, and the governing decision should not be made by the component that is being influenced.
| Decision | Who should make it | What it answers |
|---|---|---|
| Proposal to remember | The model or agent | This looks worth keeping |
| Authorization to persist | Deterministic policy outside the model | May this writer store this kind of content at this scope, now |
The separation has practical consequences. A proposal can be logged and reviewed without being stored. A rejected proposal is evidence of influence, not of a poisoned store. And an approved write can be recorded with the policy version that approved it, which makes the later audit tractable.
Schema-Bound, Scoped and Reversible Storage
Free-form memory is generally harder to constrain, because any sentence can become an apparent rule. Where the domain allows it, storing typed fields instead of prose can reduce the instruction surface without removing the feature.
- 01Typed schema
Store known fields with known value ranges rather than arbitrary text, and reject writes that do not fit the schema.
- 02Explicit scope
Bind every entry to a user, project, tenant or task and refuse retrieval outside that scope.
- 03Trust labels
Record the classification of the content the entry is derived from and keep it attached through every transformation.
- 04Expiry and revalidation
Give entries a time to live and require revalidation for anything that claims to constrain behaviour.
- 05Versioning and diff
Keep prior versions so that a change can be reviewed and reversed without rebuilding the whole store.
- 06Rollback and targeted purge
Make it possible to remove one entry and everything derived from it, not only to wipe everything.
Retrieval Is a Separate Risk Decision
Even a correctly authorized write should not imply automatic later use. Assembling context is its own decision, made at a different time, often for a different task and sometimes for a different user.
- 01Authorization
Is the current principal entitled to see this entry at all, under the scope recorded at write time?
- 02Provenance
What is this derived from, and is that lineage still intact and still acceptable?
- 03Trust classification
Does the entry carry a class that permits it to be placed in an instruction-adjacent position, or only in a clearly separated data region?
- 04Task relevance
Does the entry relate to the task at hand, or is it being pulled in by similarity alone?
- 05Freshness
Is it within its validity window, and has the policy that approved it changed since?
Retrieval-time checks can prevent a poisoned entry written in one project from shaping an unrelated task. They also give a natural logging point: the fact that an entry was considered and rejected is useful evidence.
Scope and Scope Widening
Persistent state exists at different scopes: a single task, a session, a user, a project, a workspace, a tenant, an agent, or everything. The scope decides who can be affected, and it should be an explicit property rather than an emergent one.
| Scope | Who can be affected | What must be proven before claiming it |
|---|---|---|
| Task | The current task only | That the entry cannot outlive the task record |
| Session | Later turns of the same session | That it is discarded at session end |
| User | All later sessions of one user | That retrieval is bound to that user identity |
| Project or workspace | Everyone working in that context | That membership is the retrieval boundary |
| Tenant | All users of one customer | That a cross-tenant read is actually possible, not assumed |
| Agent or global | Every task the agent runs | That the entry is loaded regardless of principal |
Cross-Session, Cross-User and Cross-Agent Reuse
Reuse across boundaries can widen the potential impact beyond the original task or principal. Three patterns recur and are worth separating.
The same principal is affected again later. The attacker does not need to be present, and the user rarely connects the behaviour to the earlier encounter.
A shared project, workspace or template makes one person's stored state part of another person's context. This requires a shared retrieval boundary and should be demonstrated rather than presumed.
Derived state written by one agent is read by another, which is the persistence face of the propagation problem described under multi-agent prompt injection.
The cross-agent case connects directly to multi-agent prompt injection: propagation moves influence across agent edges within a task, persistence moves it across time, and shared memory is where the two meet.
Delayed and Sleeper Reactivation
Research on memory poisoning in agent systems has examined entries that have no visible effect when written and only shape behaviour in a later conversation under particular conditions. This is a useful pattern to model defensively, because it breaks the assumption that a harmless-looking write is a harmless write.
Four facts to separate in any delayed case
- The write succeeded and the entry exists in a persistent surface
- The entry was later selected into a new context
- The model's behaviour measurably changed in that later context
- An action followed, and whether the authorization layer permitted it
The Persistence Success Chain
For assessment and for reporting, the chain is easier to handle as a sequence of gates, each of which can be observed independently.
Controlled content reaches a surface the system reads or writes.
A source stays in place, or a derived entry is written.
Provenance, scope or expiry is weakened or lost during retention or transformation.
The entry or the source is selected into a later context.
The later context shows measurable influence attributable to that material.
A data or capability path relevant to the influence is reachable in that later task.
The deterministic authorization layer permits or denies the concrete action.
An effect occurs, is contained, or does not occur at all.
The deepest gate reached is the finding. Reporting only the final outcome hides whether the system stopped the chain early by design or late by luck.
Authorized Offensive Assessment
An authorized assessment of persistence answers architectural questions. The value lies in mapping the write and retrieval paths, not in crafting text that a specific model happens to obey.
Questions worth answering in scope
- Which surfaces can a non-privileged principal cause a write to, directly or indirectly?
- Is any write path reachable without an explicit user confirmation, and what is stored there?
- Is stored content free-form prose or schema-bound fields?
- Which metadata survives the write, and which is dropped during summarisation or embedding?
- At retrieval time, which of authorization, provenance, trust class and task relevance is actually checked?
- What is the scope of the entry, and can retrieval be observed outside that scope?
- Which sources are re-read on every similar task, and who can change them?
- After deleting a source, which derivatives remain, and can they still be retrieved?
- Is a write, a retrieval and a use each logged, and can the three be correlated?
- Which actions in a later task are gated deterministically rather than by model judgement?
Worked Synthetic Scenario
The following scenario is synthetic, bounded and reversible. It exists to show which states can be distinguished, not to be reproduced against a live system.
A support assistant summarises customer tickets and may store durable notes about a customer account. A separate billing tool is available to the same assistant in later tasks.
A test ticket authored in the assessment environment contains text framed as a standing account instruction rather than as a customer question.
During summarisation the assistant proposes a durable account note derived from that framing. The write policy accepts the note as an unverified customer claim, at account scope, with source lineage attached.
No further action occurs that day. The session ends and the assessment pauses for a week.
An unrelated later task about a refund question retrieves the note by account scope and task relevance.
The assistant's plan changes measurably: it proposes a billing adjustment that no one in the later session requested.
The billing action requires an entitlement bound to the requesting agent and an explicit approval for the exact amount and account. The policy layer rejects the proposal.
Deepest observed gate: authorization. Persistence, later retrieval and reactivated influence are all confirmed. No unauthorized action, no data left the environment, and the note was removed together with its derived summary and index entry.
Detection and Telemetry
End-to-end reconstruction of persistence requires visibility into writes, retrievals and uses. If a deployment logs only the conversation and nothing about the memory layer, later reconstruction becomes difficult.
- 01Write proposals
What the model wanted to store, with the task and the source material that motivated it, including proposals that were rejected.
- 02Write decisions
The policy outcome, the scope granted, the trust class assigned and the policy version in force.
- 03Transformations
Every summarisation, embedding or copy, with links from the derivative back to its inputs.
- 04Retrievals
Which entries were selected for which task and principal, and which were filtered out and why.
- 05Uses
Whether a retrieved entry was actually placed in context and whether the resulting plan referenced it.
- 06Actions
The concrete action proposed afterwards, the gate that decided it and the outcome.
Deletion and Cleanup Semantics
A common cleanup error is to delete the source and declare the matter closed. Derived artifacts do not follow their inputs unless someone makes them.
| Artifact | Removed with the source? | Required action |
|---|---|---|
| Original document or ticket | Yes | Preserve a forensic copy before removal |
| Conversation summary | Not guaranteed | Locate by lineage and regenerate or discard |
| Memory entry copied from it | Not guaranteed | Delete by lineage, with the deletion recorded |
| Embedding or index entry | Not guaranteed | Remove, then re-embed the corrected source and verify the index |
| Cache or grounding snapshot | Not guaranteed | Invalidate by key and by lineage |
| Shared agent state | Not guaranteed | Purge in each agent's store, then verify |
| Backups and exports | Not guaranteed | Decide explicitly, document what remains |
This is why lineage links belong in the write metadata rather than in a runbook. Without them, cleanup completeness cannot be verified, only asserted.
Defensive Architecture
- Content
- Model decides to remember
- Free-form write
- Similarity retrieval
- Context
- Model-judged action
The model decides what is worth keeping, the store accepts prose without scope or lineage, retrieval is similarity-driven, and the action depends on the same influenced reasoning.
- Content with provenance
- Write proposal
- Policy-gated, schema-bound write
- Scoped retrieval check
- Separated context region
- Deterministic action authorization
Writes are proposals until an external policy approves them, entries are typed, scoped, labelled and time-bound, retrieval re-checks authorization and relevance, and the action is authorized against the concrete parameters regardless of what the context says.
- 01Gated write path
No persistent write without an external authorization decision and a recorded reason.
- 02Immutable provenance and lineage
Source, writer, scope, policy version and derivation links are written once and not editable by the model.
- 03Isolation
Per-user, per-tenant and per-task boundaries enforced at retrieval, not only at write time.
- 04Schema-bound storage and trust labels
Typed fields where possible, preserving granular provenance and trust through transformations; where that granularity cannot be retained, derivatives inherit the least-trusted input class as a conservative fallback.
- 05Expiry and approval for higher impact
Time-limited entries, and human approval for entries that claim to constrain behaviour.
- 06Context separation
Retrieved state is placed in a clearly marked data region, never merged into the instruction channel.
- 07Exact-action authorization
The action is authorized against its concrete parameters and target, independently of the assembled context.
- 08Egress and data-flow control
Outbound paths are constrained so that an influenced plan cannot reach an unapproved destination.
- 09Versioning, diff and rollback
Every change is reviewable and reversible without rebuilding everything.
- 10Observability of CRUD and use
Writes, retrievals and uses are logged and correlatable end to end.
Incident Response for Persistent State
Response steps
- Preserve the original source and the exact model-visible representation before anything is changed
- Identify the write that created the entry, including the task, the principal and the policy version
- Enumerate all derivatives by lineage: summaries, copies, embeddings, caches, shared agent state
- Freeze further writes on the affected path while the scope is being established
- Determine the actual retrieval scope observed, and do not assume wider scope without evidence
- Revoke or narrow affected scoped capabilities only as far as the evidence warrants
- Invalidate and rebuild poisoned state, then verify deletion across every store and index
- Reconstruct the chain from write through retrieval to action and record the deepest gate reached
- Classify the outcome precisely: influence, contained proposal, unauthorized action or confirmed data exposure
- Retest both the write gate and the retrieval gate before closing
Classification discipline matters here for the same reason it matters in agentic cases: a reactivated note that produced a rejected proposal and a note that produced an executed transfer are different incidents with different obligations.
Controlled Testing and Metrics
Persistence testing needs a time dimension, which makes it slower than single-turn testing and much more informative. Each metric below is reported separately, with the denominator stated.
| Metric | Numerator | Denominator |
|---|---|---|
| Persistence Write Rate | Attempts that resulted in a persistent write | Attempts that reached a write path |
| Later Retrieval Rate | Written entries selected into at least one later context | Written entries |
| Re-Exposure Rate | Retrieved entries actually placed in a later context | Retrieved entries |
| Reactivation Influence Rate | Re-exposures with measurable behaviour change | Re-exposures |
| Cross-Session Propagation Rate | Entries observed influencing a later separate session | Entries observed influencing any session |
| Scope-Escalation Rate | Cases where retrieval was observed outside the recorded scope | Cases in which scope widening was explicitly tested |
| Policy Bypass Rate | Reactivated cases where a control that should have stopped the step did not | Reactivated cases reaching that control |
| Unauthorized Action Rate | Actions outside authorized scope that took effect | Proposals reaching the authorization layer |
| Persistent-State Containment Rate | Cases stopped before an effect | Cases with confirmed reactivation |
| Detection Recall | Persistence events detected by telemetry | Persistence events known to have occurred |
| False-Positive Rate | Benign writes or retrievals flagged | Benign writes or retrievals |
| Purge Completeness | Derivatives verified removed | Derivatives known from lineage |
Operational and utility measures reported alongside
- Mean time to purge, from confirmation to verified removal of all derivatives
- Benign task utility, measured separately so that tightening write policy is not mistaken for a security win
- Coverage: which surfaces were in scope for the test and which were not
Standards and Research Context
Reference frameworks
- OWASP
- LLM01:2026 Prompt Injection, Top 10 for Agentic Applications 2026 (ASI06 Memory and Context Poisoning), Project commentary on memory as an attack surface
- NIST
- AI 100-2e2025 terminology
- Microsoft
- AI memory and context poisoning technique catalog, Manage AI memory safety in agentic systems
- Vendor case study
- Cisco, persistent memory compromise in Claude Code (2026)
OWASP LLM01:2026 supplies the injection mechanism. The OWASP Top 10 for Agentic Applications 2026 entry ASI06 covers stored and retrievable information, naming conversation snapshots, memory tools, expanded context, summaries, embeddings and RAG stores, and excluding one-time input prompts, which remain under LLM01:2026. Accompanying OWASP project commentary from May 2026 discusses memory as a feature that is also an attack surface; it is expert commentary from the project, not a normative requirement. NIST AI 100-2e2025 provides the adversarial machine learning terminology used here.
Microsoft's technique catalog entry on AI memory and context poisoning describes long-term context stores, grounding caches, user preference memories, vector databases and conversation histories as durable attack surfaces, and its guidance on managing memory safety in agentic systems treats memory as a configuration layer for the system, recommends governing writes, isolating state, treating retrieval as its own decision, and keeping lifecycle observability with versioning, auditing and rollback. These are vendor recommendations and are cited as such. Where that guidance mentions sanitization or trust scoring, this article treats those as probabilistic layers rather than as authorization.
As a disclosed product-specific case, Cisco published research in April 2026 describing a method to compromise the memory of Claude Code and maintain persistence beyond the immediate session, across projects and sessions and after reboots, in the version they evaluated; they report that, after working with Anthropic's application security team, a change was pushed in Claude Code v2.1.50 that removes the capability they abused from the system prompt. The lesson taken here is about trust boundaries around memory and instruction-layer state, not a general property of every memory system, and no part of the exploit path is reproduced.
On the research side, a systematic study of memory poisoning attacks in agent systems and work on delayed, sleeper-style memory poisoning examine how untrusted input becomes trusted memory and how effects can surface in later conversations. Later 2026 work continues in the same direction. All of it is attributed research, with results belonging to the authors' evaluated configurations; none of it is generalised here. Related site material covers the entry paths under indirect prompt injection and RAG prompt injection, the agent loop under AI agent prompt injection, the response side of tools under tool output injection, and the control architecture in the defense area.
Frequently Asked Questions
Is persistent prompt injection the same as memory poisoning?
No. Memory poisoning is the largest part of it, but persistence also occurs when an attacker-reachable source stays in place and is re-read by future tasks, without any memory object being written.
Is Persistent Prompt Injection an OWASP class?
Not under that name. The closest current classification is ASI06 Memory and Context Poisoning in the OWASP Top 10 for Agentic Applications 2026, with the injection mechanism itself under LLM01:2026.
Is a successful memory write already an incident?
It is a security-relevant state change and should be investigated. It is not yet retrieval, influence, policy bypass or unauthorized action, and a report should say which of those were observed.
Does deleting the source clean the system?
Usually not. Summaries, copied memory entries, embeddings, caches and shared agent state survive the source unless they are located by lineage and invalidated deliberately.
Is a poisoned vector store the same as RAG prompt injection?
They overlap but are not identical. RAG prompt injection describes influence arriving through retrieved passages; persistence describes the fact that the influencing material remains retrievable for later, unrelated tasks.
Can persistent state cross users or tenants?
Only if a shared retrieval boundary makes it possible. Scope widening is a separate property that has to be observed and measured; it should not be inferred from the existence of a stored entry.
Do time-to-live settings solve this?
They limit exposure and are worth having, but they do not decide whether a write should have happened or whether a retrieval is authorized. They are one layer among several.
Is delayed or sleeper activation realistic?
It is documented in attributed research, with results specific to the evaluated configurations. Defensively the useful conclusion is that an entry showing no immediate effect cannot be assumed harmless.
How is persistence measured separately from influence?
With separate rates and stated denominators: how often a write occurred, how often the entry was retrieved later, how often retrieval produced measurable behaviour change, and how often anything reached an action.
What should be reported after a contained reactivation?
Both facts: that a persistent entry reactivated influence in a later context, and that the authorization layer denied the resulting proposal, including which gate decided and under which policy version.
References
- LLM01:2026 Prompt InjectionOWASP GenAI Security Project · GuidanceReviewed 2026-09-20
- OWASP Top 10 for Agentic Applications 2026 (ASI06 Memory and Context Poisoning)OWASP GenAI Security Project · GuidanceReviewed 2026-09-20
- Memory Is a Feature. It Is Also an Attack Surface (project commentary)OWASP GenAI Security Project · Guidance · 2026-05Reviewed 2026-09-20
- AI Memory / Context Poisoning (Corruption), AI attack technique catalogMicrosoft Learn · GuidanceReviewed 2026-09-20
- Manage AI memory safety in agentic systemsMicrosoft Learn · GuidanceReviewed 2026-09-20
- Least privilege for AI agentsMicrosoft Learn · GuidanceReviewed 2026-09-20
- Identifying and remediating a persistent memory compromise in Claude Code (disclosed product-specific case)Cisco · Technical documentation · 2026-04Reviewed 2026-09-20
- Adversarial Machine Learning: A Taxonomy and Terminology of Attacks and Mitigations, NIST AI 100-2e2025NIST · Standard · 2025-03Reviewed 2026-09-20
- From Untrusted Input to Trusted Memory: A Systematic Study of Memory Poisoning Attacks in LLM AgentsarXiv · Research paper · 2026-06Reviewed 2026-09-20
- Hidden in Memory: Sleeper Memory Poisoning in LLM AgentsarXiv · Research paper · 2026-05Reviewed 2026-09-20
- When Agents Remember Too Much: Memory Poisoning Attacks on Large Language Model AgentsarXiv · Research paper · 2026-07Reviewed 2026-09-20