APRF-04 · Memory Management

Purpose

Govern what the system remembers across turns and sessions—including user memory, agent state, and shared multi-agent memory—with retention, isolation, and integrity controls.

Mandatory checks

Gate controls. Each check is pass/fail via artifact + pass condition. Expected from the annotated capability level when the system meets the minimum criticality tier.

MEM-M1L3 · DefinedTier 2 · ProductionhybridE3
AI memory stores (conversation, durable, and retrieval/vector memory) shall enforce tenant isolation—and user isolation where policy requires it—proven by automated attack tests with zero successful unauthorized reads or writes.
Artifact
Inventory or scope note of in-scope AI memory APIs (conversation, durable, vector/retrieval) + Cross-tenant (and cross-user where required) isolation attack suite results for those memory APIs
Pass condition
0 successful cross-tenant (and cross-user where required) memory reads/writes across ≥10 automated attack cases covering in-scope memory APIs (suite evidence measuredAt ≤90 days). If no tenant or user AI memory is retained (conversation, durable, or vector/retrieval), score NOT_APPLICABLE.
Why this control exists
Threat map
Prevent AI memory from being read or influenced across tenant and user boundaries.
Threats mitigated
Unauthorized Memory AccessData ExfiltrationMemory PoisoningSensitive Information Disclosure
Protects
MemoryDataContextUsers
MITRE: ATLAS AML.T0080 · ATLAS AML.T0080.000 · ATLAS AML.T0085 · ATLAS AML.T0092 · ATT&CK T1213
Shared memory stores let one principal's content surface in another's context, which is simultaneously a disclosure and a poisoning vector. Tested isolation boundaries prevent cross-tenant memory reads and cross-user chat history manipulation.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
MEM-M2L3 · DefinedTier 2 · ProductionhybridE3
Every in-scope AI memory class shall have a documented retention period and an executable TTL or deletion job; a test shall show sample records older than retention are absent after the job runs.
Artifact
Retention policy naming periods per AI memory class (conversation, durable, vector/retrieval, or equivalent) + TTL or deletion job config covering those memory classes + Successful deletion/TTL test record showing older-than-retention samples absent after job run
Pass condition
Policy documents retention periods per memory class; a TTL/deletion job succeeds in test and sample records older than retention are absent after the job run (policy/job/test evidence measuredAt ≤90 days). If no in-scope AI memory class is retained (conversation, durable, vector/retrieval, or equivalent), score NOT_APPLICABLE.
Why this control exists
Threat map
Ensure AI memory is retained only as long as policy allows and can actually be deleted.
Threats mitigated
Sensitive Information DisclosureUnauthorized Memory AccessRepudiation
Protects
MemoryDataUsers
MITRE: no technique mapped — this control addresses governance or assurance rather than a specific adversary technique.
Memory retained indefinitely expands the blast radius of any future compromise and breaks deletion obligations. Executable retention limits reduce the data available to an attacker; the primary driver is regulatory.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
MEM-M3L3 · DefinedTier 2 · ProductionhybridE3
Writes to durable/long-term AI memory shall be gated by a policy that enumerates allowed writers and content classes; unauthorized writers shall be denied at 100% in automated tests.
Artifact
Write policy for durable/long-term memory naming allowed writers and content classes + Write-policy enforcement config (middleware, gateway, or store gate) + Automated deny tests showing 100% rejection of unauthorized writers
Pass condition
Policy enumerates allowed writers and content classes for durable/long-term memory; unauthorized writers are denied at 100% in automated tests (policy/test evidence measuredAt ≤90 days). If no durable/long-term AI memory exists (ephemeral session context alone does not count), score NOT_APPLICABLE.
Why this control exists
Threat map
Ensure only authorized principals and validated content can write to durable AI memory.
Threats mitigated
Memory PoisoningData and Model PoisoningPrompt InjectionMisinformation
Protects
MemoryContextDataUsers
MITRE: ATLAS AML.T0080 · ATLAS AML.T0080.000 · ATLAS AML.T0080.001 · ATLAS AML.T0099
Memory poisoning requires a write path, and unvalidated writes let injected content persist and influence future sessions long after the original request ends. Enforcing who and what may write is the primary preventive control against durable context poisoning.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
MEM-M4L5 · OptimizingTier 3 · Mission CriticalhybridE3
Critical AI memory classes shall be inventoried and protected with cryptographic or signed integrity controls; the latest verification for those classes shall succeed.
Artifact
Inventory of critical AI memory classes requiring integrity protection + Integrity/signing design or config for those classes (MAC, signature, sealed object, or equivalent) + Latest verification sample showing successful integrity/signature checks for inventoried classes
Pass condition
Critical memory classes are inventoried; cryptographic verification or signature checks succeed for 100% of those classes in the latest check (inventory/verification evidence measuredAt ≤90 days). If no AI memory classes are designated critical, score NOT_APPLICABLE.
Why this control exists
Threat map
Make tampering with critical memory records detectable.
Threats mitigated
Memory PoisoningUnauthorized Memory AccessRepudiation
Protects
MemoryDataAudit Trail
MITRE: ATLAS AML.T0080.000 · ATLAS AML.T0092 · ATT&CK T1565
Signed memory records let the system detect modification that occurred after the write-policy check, including direct changes to the underlying store. Integrity protection is detective, so it complements rather than replaces MEM-M3.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

Evidence required

Data retention schedule for AI memory stores
Isolation test results
Deletion and export procedure evidence

Recommended checks

Strengthen posture beyond the gate. Same measurable structure; non-blocking unless elevated by organizational policy.

MEM-R1L4 · Quantitatively ManagedTier 2 · ProductionhybridE3
The adversarial or memory eval suite should include at least five memory poisoning scenarios—including cross-tenant write, prompt-in-memory, and stale trusted fact—executed within 90 days, with critical fails blocking promotion or requiring documented risk acceptance.
Artifact
Memory-poisoning cases in the adversarial/eval suite covering the required scenario types + Latest suite run report with pass/fail per case and gate or risk-acceptance disposition for critical fails
Pass condition
≥5 memory-poisoning scenarios are executed (including cross-tenant write, prompt-in-memory, and stale trusted fact); critical fails block promotion or have documented risk acceptance (suite evidence measuredAt ≤90 days). If no poisonable AI memory exists (conversation, durable, or vector/retrieval), score NOT_APPLICABLE.
Why this control exists
Threat map
Verify that memory write and retrieval controls actually resist poisoning attempts.
Threats mitigated
Memory PoisoningPrompt InjectionMisinformation
Protects
MemoryContextUsers
MITRE: ATLAS AML.T0080 · ATLAS AML.T0080.000 · ATLAS AML.T0070
Memory controls are easy to specify and easy to regress silently, because normal traffic never exercises the boundary. Adversarial memory tests in the eval suite keep poisoning resistance measured on every relevant change.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.
MEM-R3L3 · DefinedTier 2 · ProductionhybridE3
Working (short-lived) memory should be separated from durable memory; promotion into durable stores should require an explicit rule; recent promotions should record rule ID and actor; and TTL should differ by memory class.
Artifact
Memory architecture doc or config showing distinct working vs durable stores + Promotion rules that gate working→durable writes + Sample promotion audit (≥10 recent promotions with rule ID and actor) and TTL config differing by memory class
Pass condition
Working memory cannot silently become durable without a promotion rule; the last 10 promotions show rule ID and actor; TTL differs by memory class (architecture/audit evidence measuredAt ≤90 days). If only one class exists with no promotion path, score NOT_APPLICABLE.
Why this control exists
Threat map
Prevent transient session content from becoming durable knowledge without an explicit promotion decision.
Threats mitigated
Memory PoisoningUnauthorized Memory AccessMisinformation
Protects
MemoryContextData
MITRE: ATLAS AML.T0080.000 · ATLAS AML.T0080.001
When working and durable memory share a store, anything said in a session persists by default and can resurface for other users. A promotion boundary confines thread-level poisoning to the session in which it occurred.
Informative threat context — mappings reduce exposure and do not guarantee mitigation; not certification.

More detailPhilosophy, failures, practices, validations, examples, crosswalks, and evolution

Engineering philosophy

Memory is persistent attack surface and privacy liability. Default to minimal retention, strict tenancy isolation, and verifiable write paths. Memory that cannot be deleted or audited is not production-ready.

Why it matters

Poisoned or leaked memory causes lasting incorrect behavior, cross-tenant data exposure, and compliance failures. Autonomous agents amplify memory risk by writing their own state.

Common failures

Shared memory stores without tenant isolation
No user-facing or admin deletion path
Agents write unverified 'facts' into long-term memory
Memory reused across products without re-consent or reclassification

Severity & risk

Severity: high; Impact if violated
Risk level: high; Typical residual risk (impact × likelihood)

Engineering best practices

Classify memory types: ephemeral session, user profile, agent scratchpad, org knowledge
Require confidence or human confirmation before promoting scratch facts to durable memory
Encrypt memory at rest; restrict operational access
Log memory writes for audit without logging raw sensitive values when avoidable

Automatic validations

Automated tenant isolation tests
TTL enforcement jobs
Write-policy middleware on memory APIs

Manual validations

Privacy review of memory schemas
Red-team attempts to poison shared agent memory

Examples

A personal assistant forgets user preferences on request within SLA
Multi-agent systems use namespaced memory; one agent cannot read another's private scratchpad

References

Crosswalks

Show 16 peer mappingsexpand

Privacy-Enhanced Privacy-Enhanced
NIST AI Risk Management Framework · aligns-with
LLM02 Sensitive Information Disclosure
OWASP Top 10 for Large Language Model Applications · supports
LLM04 Data and Model Poisoning
OWASP Top 10 for Large Language Model Applications · supports
LLM08 Vector and Embedding Weaknesses
OWASP Top 10 for Large Language Model Applications · supports
C1.1 Training Data Origin & Data Security
OWASP AI Application Security Verification Standard (AISVS) · supports
C1.3 Training Data Quality and Security Assurance
OWASP AI Application Security Verification Standard (AISVS) · supports
C3.2 Model Validation & Testing
OWASP AI Application Security Verification Standard (AISVS) · supports
C5.2 AI Resource Authorization & Classification
OWASP AI Application Security Verification Standard (AISVS) · supports
C7.3 Output Safety
OWASP AI Application Security Verification Standard (AISVS) · supports
C8.1 Access Controls on Memory & RAG Indices
OWASP AI Application Security Verification Standard (AISVS) · supports
C8.2 Embedding Sanitization & Validation
OWASP AI Application Security Verification Standard (AISVS) · supports
C8.3 Memory Expiry & Revocation
OWASP AI Application Security Verification Standard (AISVS) · supports
C11.1 Model Alignment, Safety, and Robustness Testing and Training
OWASP AI Application Security Verification Standard (AISVS) · supports
C12.1 Request & Response Logging
OWASP AI Application Security Verification Standard (AISVS) · supports
L2 Data Operations
CSA MAESTRO (Multi-Agentic Threat Model) · supports
C1 Confidentiality
SOC 2 Trust Services Criteria · evidence-for

Future evolution

Portable memory consent receipts and cross-vendor memory export formats with integrity proofs.