Memory poisoning tests
Examine whether persistent memory can carry attacker-controlled instructions
Agents save summaries or facts for use in future sessions. The decision is how to examine whether persistent memory can carry attacker-controlled instructions. The work begins with your actual workflow and looks for the evidence that separates intended behaviour from a consequential exception. It is particularly relevant to memory system owners and product security teams. A useful outcome is an explicit account of what was examined, what remains uncertain, and which decision the evidence can support.
The agent security relationship
- Memory write paths
Establish the basis for write eligibility.
- Stored provenance
Preserve source and authority with the entry.
- Memory poisoning test record
Retain the scoped finding and its unresolved dependencies.
Decision
Frame the decision around write eligibility
Questions and the evidence they need
- Write eligibility
- Inspect memory write paths for the relevant constraint or observation.
- Stored provenance
- Inspect provenance for the relevant constraint or observation.
- Later influence
- Inspect retrieval rules for the relevant constraint or observation.
The decision is how to examine whether persistent memory can carry attacker-controlled instructions. This is relevant to memory system owners and product security teams when agents save summaries or facts for use in future sessions. Name the affected workflow, the consequence of a wrong decision, and the owner who can act on the result. The initial discussion should establish which evidence is already available and which uncertainty is material enough to investigate.
The specific failure hypothesis is that an untrusted interaction creates a durable instruction that influences later unrelated tasks. It remains a hypothesis until examined in the deployment. Existing internal tests or operating records may already resolve it; identify the uncovered question before commissioning additional work.
Mechanism
Memory poisoning must be followed into later tasks
Relationships within agent security
- Write eligibility
- Challenge whether untrusted content may be retained.
- Stored provenance
- Preserve source and authority with the entry.
- Later influence
- Inspect retrieval, action, and correction behaviour.
What this specialty examines
Memory poisoning work examines persistence of influence across sessions. Identify who can write entries, how provenance is retained and why an entry is retrieved later. Distinguish stored facts, preferences and executable instructions in the proposed memory policy.
The review should introduce harmless poisoned entries in a test memory store and observe selection, use and removal. Identify the normal route, relevant exceptions and the authoritative record of the outcome. Inspect the relevant business-system record, enforcement event or process evidence alongside any reported status. Keep incomplete cases visible, with an explanation of what their absence prevents the owner from concluding.
The tradeoff to make explicit
For this decision, memory improves continuity while persistent influence needs provenance and correction mechanisms. Compare the available design or operating choices against the same intended outcome. If one option removes a required control or changes the task boundary, describe that difference before treating its apparent simplicity, speed or lower effort as an improvement. The decision should expose the tradeoff instead of burying it in an aggregate score.
Preparation
Connect the working inputs to the boundary being examined
Evidence packet for write eligibility
Illustrative working format
- Memory write paths
- Establish permitted access, provenance, and which task conditions it represents.
- Provenance
- Connect the deployed artefact to its inputs, approval, and verifiable revision.
- Retrieval rules
- Confirm the applicable revision and who resolves disputed interpretation.
- Correction controls
- Identify provenance and the specific decision this material can inform.
Start with memory write paths, provenance, retrieval rules and correction controls. Identify the owner, revision and operating context of each source. Sanitised examples may support initial design, but differences from actual conditions should remain explicit. Where direct access is unsuitable, a customer-controlled evidence or execution route may be considered, with agreed handling and retention.
The scope also needs the security decision owner, agreed expectations for a representative threat scenario, and the authority to inspect the relevant boundary. Specify what evidence would distinguish the failure in which an untrusted interaction creates a durable instruction that influences later unrelated tasks from acceptable behaviour. If stakeholders disagree about intended behaviour, resolve the interpretation before classifying the observed difference as a defect.
How the work proceeds
Carry write eligibility through to an accountable finding
From the scoped material to a decision record
- Memory write paths
Define the hypothetical attacker’s starting influence.
- Stored provenance
Apply the scoped check to later influence.
- Memory poisoning test record
Record the evidence, open dependencies, and the owner’s next decision.
Define the controlled threat scenario
Review memory write paths, provenance, retrieval rules and correction controls with memory system owners and product security teams. State what the hypothetical attacker controls, the protected action and the systems included in the authorised exercise. Prepare synthetic records and harmless markers where appropriate, with stopping conditions for unexpected effects. The preparation output is a scenario brief that distinguishes an influence attempt from a prohibited action actually reaching a business resource.
Challenge the path and review effects
Introduce controlled false entries and track their lifecycle through retrieval, correction and removal. A successful deletion response is incomplete evidence if cached or summarised copies continue to influence behaviour. Include later-session checks within the agreed scope.
Select a control response and retest
Build a memory poisoning test record spanning write, retrieval, influence and cleanup from the reviewed observations. Separate agent behaviour, application enforcement and the resulting resource state so the recommended change reaches the responsible layer. Choose a bounded retest that reproduces the original condition and checks legitimate behaviour after remediation. If the required investigation exceeds the agreed technique or expertise, retain the unresolved path and identify the qualified review needed.
Indicative artefact
Make the memory poisoning test record usable by its owner
Memory poisoning test record
Illustrative working format
- Memory poisoning test record
- Identify the assessed workflow, revision, and decision boundary.
- Write
- Link supporting and contrary observations to inspectable evidence.
- Retrieval
- Name the unresolved condition, next action, and accountable owner.
A useful decision artefact is a memory poisoning test record spanning write, retrieval, influence and cleanup. Supporting material may include selected cases, configuration or process records, evidence references, a disagreement log and prioritised actions. Retain the case selection rationale and material disagreements alongside the result; otherwise the result may be mistaken for complete coverage.
Illustrative scenario
Examine later influence through a constructed exception
A constructed case and its decision paths
Illustrative scenario
- Write eligibility
A harmless planted instruction is stored and resurfaced in a later task.
- Stored provenance
Run a later legitimate task after the planted memory write.
- Later influence
Verify correction and removal as well as immediate poisoning behaviour.
Consider a fictional situation: a support conversation stores a false preference that later causes the agent to send updates to an unapproved address. The scenario is illustrative, with no client engagement, executed test or measured improvement implied.
For the false notification preference, determine whether the agent treats it as a verified user choice. A corrective design might require provenance and current approval before changing recipients. The test should show whether later tasks still consult the poisoned entry.
Scope and next action
Keep the conclusion within the agreed threat scenario
Confirm fit before the next commitment
- Write eligibility
- This review is limited to the agreed threat scenario.
- Memory write paths
- The relevant owner must confirm access and the intended operating conditions.
- Memory poisoning test record
- A bounded challenge cannot establish exhaustive protection.
Authorised scenario testing is not a claim of exhaustive penetration testing or guaranteed protection. Intrusive security work requires qualified specialists and a separately agreed scope. Any engagement depends on an agreed scope, qualified team, authorised access and confirmed availability. Bring the affected workflow, its current configuration or process, the triggering change and the evidence already available. The immediate scope question is prompted by the situation in which agents save summaries or facts for use in future sessions; confirm which missing observation would change the owner’s next action.
Ways to engage
Related engagement scopes
Agent Release Readiness Review
The Agent Release Readiness Review is a fixed-scope, three-week independent test of one AI agent workflow that shows a release board what the agent does, what it is allowed to do and what happens when it is wrong, and ends in a signed recommendation.
AI Agent Runtime Security Review
Make every delegation explicit. Examine who the agent acts for, where it can execute and which tools it can reach when instructions alone are not enough.
AI Agent Red Team
Challenge the boundaries that matter to your workflow. Test agreed attack scenarios against agent instructions, tools and data access.
Continue exploring
Related insights and resources
The permission boundary behind every agent action
An agent can only be evaluated in the context of what its tools allow. Examine identity, delegated authority and action boundaries before you put a workflow in motion.
Before your agent can act, define its authority
A working paper for the moment an AI system moves from advice to action. Map identity, permissions, approvals and recovery into an authority model your team can review and test.
Running an AI-agent incident tabletop exercise
A useful tabletop follows one plausible agent failure through detection, containment, evidence, business recovery and accountable return to service.