⚠️ Before You Start

Risk: High

Duration: 1-2 hours

Last Validated: Not yet validated (draft)

Kind: Checklist

Risk Note: High (unreviewed memory can hold personal data indefinitely, fail DSR requests, or leak data across tenants)

Memory privacy and retention review checklist¶

Draft outline: not validated

Drafted with AI from official sources on 16 Oct 2026. Verified and expanded under AGT-04-T17 on 23 Oct 2026. Do not use on a live system until it is written, dry-run by someone other than the author and signed off (planned 2026-12-22). Author: Sanjay Sarvesh · dry-run: Yasar · sign-off: James. Work items: AGT-04-T17, AGT-04-T18, AGT-04-T19, AGT-04-T20.

1. Summary¶

This checklist guides a joint privacy, security, and engineering review of an agent's memory architecture prior to production launch and at scheduled annual data protection reviews. It systematically verifies data mapping, automated retention purges, special category filtering, user inspection and erasure endpoints, and cryptographic controls across all memory layers: short-term thread checkpointers, long-term profile stores, episodic vector search indexes, session caches, and observability trace logs. The outcome is documented regulatory compliance with data protection laws (such as UK GDPR and CCPA), prevention of cross-tenant memory leakage, and demonstrable readiness for Data Subject Requests (DSRs).

Risk: High (unreviewed memory stores can retain personal data indefinitely, expose sensitive records across tenant boundaries, or fail statutory erasure obligations). Typical duration: 1-2 hours.

2. When to use and when not to¶

Use it when:

Conducting the pre-production privacy review before launching any agent with state persistence, conversational checkpoints, or cross-turn profile memory.
Conducting scheduled annual privacy reviews with the Data Protection Officer (DPO) and compliance team.
Introducing a new memory layer, caching tier, or vector search backend to an existing agent graph.
Modifying memory extraction prompts, user state schemas, or namespace identifier conventions.
Onboarding an agent into regulated jurisdictions or enterprise customer tenants requiring explicit data retention commitments.

Do not use it when:

Executing a live Data Subject Request (DSR) or GDPR Article 17 erasure for an individual user: follow PB-AGT-04-03.
Running routine operational database maintenance, checkpoint pruning, or state schema migrations: follow PB-AGT-04-04.
Designing the initial multi-tier memory architecture and evaluating database engines: follow PB-AGT-04-01.
Auditing human-in-the-loop decision logs, authorization tokens, or approval trails: follow PB-AGT-05-05.
Conducting the broader technical go-live operational review for deployment infrastructure and evaluation gates: follow PB-AGT-01-05.

3. What you must know first¶

Storage limitation applies to all agent memory layers. Personal data must not be stored longer than necessary for the agent's defined purpose (ICO: Principle (e): Storage limitation). Checkpoints, long-term stores, search indexes, caches, and telemetry sinks each require a justified, documented retention period and an automated purge mechanism.
Agent state stores capture unredacted conversation turns. Checkpointers (PostgresSaver, RedisSaver) record complete graph state at every super-step (LangGraph: Checkpointers). Prompt inputs, tool outputs, and assistant reasoning are saved in persistent storage unless explicitly filtered or serialized with encryption.
Deterministic scoping prevents multi-tenant memory bleed. Namespaces and thread identifiers must strictly embed tenant_id and user_id as hierarchical tuples (for example, (tenant_id, user_id, 'profile')) (LangGraph: Stores). Flat or unstructured keys risk cross-tenant data leakage during vector similarity lookups or prefix searches.
Data subjects have statutory rights of access and erasure. Users must have the ability to inspect what personal facts the agent has memorised and request their deletion without requiring manual database administrator intervention (ICO: Right to erasure).
Observability traces contain conversation payloads. Agent tracing sinks can store full prompts, tool arguments and completions when content recording is enabled. In Microsoft Foundry and OpenTelemetry GenAI instrumentation this is opt-in; confirm the setting for every tracing tool in use (Microsoft Foundry: Agent tracing overview, Foundry client-side tracing, Tracing for agent frameworks). Telemetry retention must match or be shorter than memory store retention, with access restricted via role-based access control (RBAC).
Cloud provider enterprise commitments protect model traffic. Prompts, completions, and stored embeddings in Azure OpenAI and Amazon Bedrock are isolated within customer boundaries and are not used to train or refine foundation models (Azure OpenAI service data, privacy, and security, Data protection in Amazon Bedrock). Azure OpenAI stores prompts and generated content for up to 30 days for abuse monitoring unless modified abuse monitoring is approved for the subscription; record this in the data map. Amazon Bedrock does not store or log prompts and completions.

Prerequisites¶

Memory decision record
Data map
Erasure runbook dry-run evidence

4. Checklist¶

Walk through the checklist items jointly with the Data Protection Officer (DPO), GenAI engineer, and Security engineer. Attach concrete evidence, configuration links, and test results to each item before signing off. Raise an action for every gap, with an owner and due date, then sign off or block go-live.

Section 4.1: Memory surface inventory and data mapping¶

Comprehensive data flow map: The architecture diagram and data catalogue document every persistent and transient memory sink:
Short-term conversational checkpointer (e.g. PostgreSQL checkpoints and checkpoint_blobs tables).
Long-term profile and semantic memory store (e.g. LangGraph Store or PostgreSQL store table).
Episodic memory vector search index (e.g. Azure AI Search index or Amazon OpenSearch domain).
Session and tool response cache (e.g. Azure Cache for Redis or DynamoDB).
Observability and trace sinks (e.g. Azure Log Analytics workspace or LangSmith project).
Provider-side abuse-monitoring store (e.g. Azure OpenAI 30-day prompt and completion retention unless modified abuse monitoring is approved).
Verify: Compare the application deployment code against the architecture document; confirm no undocumented caching or logging layers exist.
Hierarchical namespace and thread scoping: Every thread ID and store namespace incorporates tenant and user identifiers as structured tuples:
Thread ID format: ${TENANT_ID}:${USER_ID}:${SESSION_ID}.
Store namespace format: (${TENANT_ID}, ${USER_ID}, 'profile') or (${TENANT_ID}, ${USER_ID}, 'episodes').
Verify: Inspect state records in staging; confirm no keys use bare session IDs or omit tenant scoping.
Third-party LLM boundary verification: Confirm all model API endpoints are enterprise-contracted instances (such as Azure OpenAI Service or Amazon Bedrock) with confirmed zero-training commitments.
Verify: Inspect model configuration files and API gateway routing; confirm requests do not route to public, unmanaged model endpoints. Record the abuse-monitoring status of each Azure OpenAI resource (default or approved modified abuse monitoring) in the data map.

Section 4.2: Storage limitation and automated retention policies¶

Checkpointer retention policy: An automated maintenance job purges or archives inactive conversational threads after the approved business retention window.
Verify: Check scheduled cron jobs or Azure Automation runbooks executing thread deletion queries (delete_thread or SQL pruning per PB-AGT-04-04); verify execution logs covering the latest scheduled runs.
Session cache time-to-live (TTL): All transient session keys stored in Redis or in-memory caches have explicit TTLs enforced via the EXPIRE command.
Verify: Query cache keys with TTL ${CACHE_KEY} in staging; confirm every key has a finite positive time-to-live and no persistent unbounded keys exist.
Long-term fact deprecation and curation: Long-term memory records track created_at and last_accessed_at timestamps. A curation routine flags or removes memories unaccessed beyond the documented retention threshold.
Verify: Inspect store item metadata schema; verify timestamp fields are populated on write and update.
Trace content recording: Content recording (for example OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT) is off in production, or its use is approved by the DPO with matching retention and access controls.
Verify: Inspect production environment settings and a sample production trace.
Observability trace retention alignment: Retention in Azure Log Analytics, Application Insights, or LangSmith is configured to the approved retention period required for debugging, never indefinite.
Verify: Check the workspace data retention setting in Azure Portal or workspace configuration templates (az monitor log-analytics workspace show --resource-group ${RESOURCE_GROUP} --workspace-name ${WORKSPACE_NAME} --query retentionInDays).
Backup and point-in-time restore (PITR) documentation: Backup retention schedules (e.g. 7 to 35 days) are recorded and accepted by the DPO. A documented procedure ensures any database restore replays recent Data Subject Request erasure actions.
Verify: Review disaster recovery runbook; confirm DSR replay step is included after restoring a database snapshot.

Section 4.3: Data minimisation and sensitive category guardrails¶

Extraction prompt constraints: Prompts tasked with extracting long-term user facts and preferences contain explicit negative instructions prohibiting extraction of special category personal data (e.g. health data, racial or ethnic origin, political opinions, religious beliefs, sexual orientation, or trade union membership) unless explicit consent is established.
Verify: Review memory extractor prompt templates; confirm forbidden categories are explicitly listed with negative constraints.
Pre-storage PII redaction: Sensitive data filters (such as Microsoft Presidio or Azure AI Language PII detection) sanitise payment card numbers, passwords, government identifiers, and credentials before state serialization or semantic embedding.
Verify: Execute a test run submitting synthetic credit card and National Insurance numbers; confirm extracted memory and checkpoint blobs do not contain the unmasked values.
State schema minimisation: Graph state definitions (AgentState) store only operational fields necessary for reasoning, excluding raw request headers or unnecessary user metadata.
Verify: Inspect Pydantic state model definitions; confirm non-essential fields are omitted from state persistence.

Section 4.4: Data subject rights and user transparency¶

User-facing memory inspection endpoint: An authenticated API endpoint or user interface permits data subjects to view all active facts, preferences, and summaries the agent has stored about them.
Verify: Call GET /api/v1/users/${USER_ID}/memory with a test user token; confirm returned items match all store entries for that user namespace.
User-initiated memory deletion endpoint: An authenticated interface allows users to delete individual memory entries or clear their entire profile without filing a manual support ticket.
Verify: Call DELETE /api/v1/users/${USER_ID}/memory/${MEMORY_ID} and confirm the specified item is purged from both the primary store and vector index.
Automated DSR erasure runbook dry-run: The complete user erasure procedure (PB-AGT-04-03) has been executed successfully in a non-production environment, demonstrating complete removal across checkpointer, long-term store, search index, cache, and telemetry.
Verify: Review signed dry-run execution report from PB-AGT-04-03; confirm zero residual records remained across all stores for the test user ID.

Section 4.5: Cryptographic protection and access governance¶

Encryption at rest: All database servers, storage accounts, vector search indexes, and cache clusters enforce customer-managed (CMK) or platform-managed AES-256 encryption.
Verify: Check resource properties in Azure CLI or infrastructure-as-code definitions (az postgres flexible-server show, az search service show).
Application-layer checkpoint serialization security: For deployments handling confidential workloads, graph checkpointers evaluate or implement payload-level encryption (e.g. EncryptedSerializer in LangGraph or EncryptedSession in OpenAI Agents SDK) to protect conversation turns from database administrator visibility.
Verify: Review checkpointer serialization configuration; record whether payload encryption or database-level encryption is selected, with DPO sign-off.
Role-based access control (RBAC): Access to memory databases, search indexes, and trace workspaces uses managed identities and least-privilege role assignments. Direct developer access to production memory tables is prohibited.
Verify: Audit Azure RBAC role assignments; confirm no personal developer accounts have read access to production memory tables or trace stores.

Draft Snippet: Memory Privacy and Retention Review Sign-Off Template¶

# Memory Privacy and Retention Review Sign-Off

## 1. Review Metadata
- Agent Name / Service: ${AGENT_NAME}
- Environment: [ ] Staging  [ ] Production
- Review Date: ${REVIEW_DATE}
- GenAI Lead: ${GENAI_LEAD_NAME}
- Data Protection Officer (DPO): ${DPO_NAME}
- Security Reviewer: ${SECURITY_REVIEWER_NAME}

## 2. Memory Surface Inventory
| Memory Tier | Technology / Store | Retention Window | Automated Purge Mechanism |
|---|---|---|---|
| Short-term checkpointer | PostgreSQL Flexible Server | ${CHECKPOINT_RETENTION_DAYS} days | Scheduled SQL pruning job |
| Long-term store | LangGraph Store (Postgres) | ${STORE_RETENTION_DAYS} days | Timestamp curation script |
| Episodic vector index | Azure AI Search | ${SEARCH_RETENTION_DAYS} days | Index filter delete batch |
| Transient cache | Azure Cache for Redis | ${CACHE_TTL_HOURS} hours | Redis EXPIRE command |
| Observability traces | Azure Log Analytics | ${TRACE_RETENTION_DAYS} days | Workspace retention setting |
| Provider abuse monitoring | Azure OpenAI Service | ${PROVIDER_RETENTION_DAYS} days (0–30) | Provider-managed purge (or approved modified monitoring) |

## 3. Compliance Gates
- [ ] Data map covers all memory layers, caches, telemetry sinks, and provider stores
- [ ] Namespaces and thread IDs strictly embed tenant_id and user_id
- [ ] Model endpoint provider guarantees zero customer data foundation model training and abuse-monitoring status is recorded in data map
- [ ] Automated purge jobs verified active and running within retention limits
- [ ] Trace content recording disabled in production or explicitly DPO-approved
- [ ] Special category personal data explicitly excluded in memory extraction prompts
- [ ] Pre-storage PII redaction active and validated with synthetic test data
- [ ] User memory inspection endpoint (`GET /memory`) verified functional
- [ ] User memory deletion endpoint (`DELETE /memory`) verified functional
- [ ] Erasure runbook (PB-AGT-04-03) dry-run evidence attached and signed
- [ ] Backup PITR window documented with DSR replay requirement
- [ ] Encryption at rest confirmed on all underlying storage resources
- [ ] Production memory database access restricted to managed service identities

## 4. Sign-Off Decision
- Status: [ ] APPROVED FOR GO-LIVE  [ ] BLOCKED PENDING ACTIONS
- Remediation Actions (if blocked):
  1. ${ACTION_1} (Owner: ${OWNER_1}, Due: ${DUE_DATE_1})
- Signatures:
  - DPO: ___________________________ Date: ____________
  - Agent Lead: ____________________ Date: ____________

Snippets to add¶

snippets/checklists/memory-privacy-review.md: Complete markdown review template with evidence capture fields (markdown)
snippets/privacy/verify_retention_ttl.py: Automated audit script checking Redis TTLs and PostgreSQL checkpoint ages against configured limits (python)

5. Known issues and fixes¶

Symptom	Likely cause	Fix
Observability trace sink stores full prompt conversations indefinitely	Default workspace retention configured without limit	Set Log Analytics workspace retention to the approved retention period; enable trace-level PII masking in telemetry exporter.
Inadvertent trace content recording in production	Content recording flag left enabled from development (`OTEL_INSTRUMENTATION_GENAI_CAPTURE_MESSAGE_CONTENT=true`)	Disable content recording in production environment settings; if required for diagnostics, obtain DPO sign-off and enforce strict retention.
User memory inspection endpoint missing or incomplete	Memory stores lack user-indexed query APIs	Implement user-scoped search endpoint querying `(tenant_id, user_id)` namespace before promoting agent to production.
Memory extraction prompt captures sensitive health or financial data	Unconstrained LLM extraction prompt extracts whatever the user mentions	Add strict negative prompt constraints forbidding health, political, religious, or credit card details; route extracted facts through a PII NER scrubber.
Redis cache memory consumption grows indefinitely	Application writes session state without calling `EXPIRE`	Ensure session write logic sets an explicit TTL (SET with EX, or EXPIRE). Eviction is a memory safeguard, not a retention control; if one is needed for keys without TTL, use an allkeys-* policy.
Incomplete erasure during user offboarding	Agent stores data across multiple stores without a central mapping	Maintain an authoritative store registry; execute validated erasure runbook PB-AGT-04-03 covering all registered stores.
Restored database backup reinstates previously deleted user memory	Database snapshot taken prior to Data Subject Request was restored	Maintain an immutable DSR audit log of deleted user IDs; configure post-restore automation to re-purge all IDs recorded since the snapshot timestamp.

6. Monitoring and alerts¶

Signal	Alert when	Action
Memory stores without an automated retention job	Any store (>0) detected in quarterly compliance audit	Agent Lead assigns engineering action to deploy automated purge job within 30 days.
Overdue annual memory privacy review	Current date exceeds 365 days since last sign-off	DPO notifies Agent Lead; block major feature deployments until review is completed.
Redis cache keys without TTL	Count of unexpired keys without TTL >0 in staging or production scan	Inspect session creation code; enforce TTL on all session and tool caching keys.
Checkpoint age exceeds retention limit	Oldest checkpoint in database > `${MAX_RETENTION_DAYS}` plus the agreed grace period (TO VERIFY)	Checkpoint pruning job failed; inspect Azure Automation runbook or cron job execution logs.
Unredacted PII detected in memory sample	Any match (>0) in the scheduled memory scan (frequency TO VERIFY)	Quarantine memory record; update extraction prompt constraints and PII scrubber rules.

7. AWS and open-source equivalents¶

AWS Equivalents¶

Amazon Bedrock AgentCore Memory: Managed short-term and long-term memory with built-in session isolation and automated lifecycle management (Add memory to your Amazon Bedrock AgentCore agent). Bedrock does not store or log customer prompts and completions.
Amazon DynamoDB TTL: Built-in automatic item expiration that purges expired session records without consuming write throughput or requiring custom cron jobs.
Amazon CloudWatch Logs Retention: Configurable log group retention ensuring telemetry and agent trace spans do not persist indefinitely.
AWS KMS Encryption: Customer Managed Keys (CMK) providing fine-grained access control and envelope encryption for S3, DynamoDB, and OpenSearch stores.

Open-Source Equivalents¶

LangGraph Checkpointers (PostgresSaver, RedisSaver): Open-source persistence layers supporting thread-level checkpoint management and custom serialization serializers (LangGraph: Checkpointers).
OpenAI Agents SDK (EncryptedSession): Application-layer session encryption and TTL handling built into the open-source Agents SDK (OpenAI Agents SDK: Sessions).
Microsoft Presidio: Open-source PII detection and anonymization library for identifying and redacting sensitive entities prior to storing memories.
PostgreSQL pg_cron / Partitioning: Native PostgreSQL extensions used to automate partition drops or scheduled thread deletions based on timestamp columns.

8. Validation record¶

Pending. Planned dry-run scenario: A second reviewer applies the checklist to a sandbox agent with unbounded trace retention and no user delete endpoint, and must flag both. (Missing Redis TTLs and unredacted extraction may be added as extra seeded faults.)