Control what memory retains and reveals

An incident report is restricted, but its old summary remains searchable. The next agent can still disclose information from it. Controlling the original document is not enough when copies and derivatives remain usable.

Give retained information an owner and purpose

Before a candidate memory becomes durable, identify why it is needed, who may use it, who maintains it, and when it should be reviewed or removed. A thread checkpoint and a shared organizational fact may need different policies.

Do not let text retrieved from a source authorize new access or rewrite an approved procedure. Stored content is evidence to evaluate, not an instruction to bypass the application's controls.

Check access when writing and reading

Write only to the appropriate scope: this thread, this entity, this team, or a permitted shared store. On retrieval, use the current caller and task authority. Recheck changed membership and permissions. Search previews, explanations, logs, and diagnostic traces must respect the same information boundary.

Govern every write

An attacker does not need write access to poison memory. In the MINJA study, ordinary queries were enough to plant harmful records in an agent's memory (MINJA, arXiv 2503.03704). The tests used lab agents. The rate in production is unknown. Microsoft's own documentation gives the reason. The model decides what to save. So bad input can end up in memory (Microsoft Learn) [vendor].

Treat each candidate memory as untrusted until it passes four checks:

• Check the write. Screen it for instructions, secrets and claims that conflict with a trusted source.
• Record the source. Keep where it came from, when, and whether a person confirmed it.
• Allow rollback. Keep revisions. Then a bad memory and everything derived from it can be removed.
• Expire by type. AWS suggests about 90 days for episodes and no fixed expiry for procedures (AWS, 4 September 2026) [vendor]. The same post says AgentCore Memory has no built-in automatic expiry. The team has to build it.

Old memory can do harm without any attacker. AWS gives the example of a support agent treating a billing dispute settled four months earlier as still open. More on poisoning is in the agent data engineering layer (R14). Sources read 14 October 2026.

Track the derived copies

Maintain links from source versions to extracted facts, indexes, summaries, caches, and retained evaluation copies. A correction, permission change, or removal request should identify the affected material. Mixed-source summaries may require regeneration or more restrictive access.

Test the whole path, including backups and caches under their approved lifecycle policy. Where a retention requirement prevents deletion, restrict use according to that policy instead of letting the model invent an exception.

Make forgetting observable

A successful deletion call is not sufficient evidence that a later query cannot retrieve the content. Test the original question, paraphrases, related entity lookups, and already-open tasks. Verify that stale context is invalidated or safely rebuilt before reuse.

The same test applies when an agent is retired. The retire stage of the agent lifecycle deletes the agent's own memory. A change to its memory policy sends the agent back to evaluation before release.

Review before changing shared knowledge

An agent can propose a useful lesson, but one successful episode does not create a company rule. Check sources, repeated evidence, scope, and an accountable approval before changing procedural memory.

The NIST AI RMF Playbook, reviewed 18 September 2026, provides broader lifecycle and governance guidance. The derivative tracking and removal checks here are proposed implementation practices.

Continue the story: Test whether memory serves the task.