CrewAI Memory and the Reg S-P Disposal Rule: How to Purge Customer Information From Short-Term, Long-Term, and Entity Memory

What the disposal rule asks of an agent platform

The SEC published final amendments to Regulation S-P on June 3, 2024. As of November 2026, 17 CFR 248.30(b)(1) requires covered institutions, other than notice-registered broker-dealers, to properly dispose of consumer information and customer information by taking reasonable measures to protect against unauthorized access to or use of the information in connection with its disposal. Paragraph (b)(2), headed written policies, procedures, and records, requires written policies and procedures that address proper disposal.

Two points matter for engineering. First, the standard is reasonable measures, not a prescribed technical method, so no particular purge technique is mandated and your procedure has to be defensible on its own terms. Second, the rule is framed around records in paper, electronic or other form that a covered institution maintains or that are maintained on its behalf. For planning purposes, any electronic store that holds customer records should be treated as in scope, and an agent memory store is one.

The final amendments also add service provider oversight, including due diligence, under written policies and procedures. If your memory backend or vector store is hosted by a third party, that provider belongs in the same review.

Treat each memory type as a separate data store

CrewAI exposes short-term, long-term and entity memory. As the names suggest, short-term memory holds context tied to a current run, long-term memory holds material intended to carry across runs, and entity memory holds records about people, organizations or other things extracted from agent activity. Each can be backed by a vector store, a SQLite file or another storage backend, depending on how your deployment is configured.

That difference in purpose changes the disposal problem. Short-term data is often assumed to be transient, but if it is persisted it needs the same treatment as anything else. Long-term memory is the most likely place for customer information to outlive the task that produced it. Entity memory is the hardest to reason about because it holds derived records. A customer's name or account details can reappear as an extracted entity even if the original text is later removed elsewhere.

Start with an inventory. For each memory type in each deployment, record the configured backend, where it is hosted, who operates it, what identifiers or keys let you find a given customer's records, and whether copies exist in backups, snapshots or replicas. Without this map, a disposal procedure has nothing to attach to.

Design a purge and verification procedure for each store

Write one procedure per store rather than one for "agent memory." Each procedure should name the trigger, the purge mechanism, the verification step and the record produced. Use the reset or delete mechanism that your CrewAI version and chosen backend actually provide, and test it in a non-production environment before relying on it.

• Define retention triggers: Set triggers in policy, such as closure of the customer relationship, end of the business purpose, or a scheduled sweep. Reg S-P does not tie you to the retention clock of another regime, so state your own rationale.
• Choose the purge unit: Decide whether you purge a whole store or selected records by customer key. Whole-store resets are simple but remove unrelated data. Targeted deletion needs identifiers stored with each record.
• Purge the backend, not only the application view: Confirm that deletion reaches the underlying vector collection, database file or table, and that dependent indexes are updated.
• Cover copies: Include backups, snapshots, replicas and exported files in the procedure, or document the reasonable measures that protect them until they expire.
• Verify with queries: After purging, query the store directly using known identifiers and semantically similar phrasing. Treat any hit as a failed purge.
• Record the outcome: Retain the store, trigger, operator, time, method and verification result for each disposal action.

Verifying embeddings and derived entity records

Verification is where most teams cannot produce evidence. A vector store holds embeddings, which are not human-readable, so an exact-match search on a customer name proves little. A practical engineering approach is to combine several checks: count records before and after the purge, search by the metadata keys you stored, run semantic queries built from the original text, and inspect the entity store for records that reference the customer.

A canary test strengthens this. Seed a non-production environment with synthetic customer records, let agents write them to memory, run the purge, and confirm the synthetic identifiers cannot be retrieved from any store. Repeat the test whenever you change the backend, the CrewAI version or the purge code.

These are engineering practices, not regulatory requirements. The rule asks for reasonable measures, so the goal is a method you can explain and repeat, with a record showing that it ran and what it found.

Memory-layer controls versus execution-path controls

Memory-layer controls act on data that is already stored: retention triggers, purge jobs, access restrictions on the backend, encryption and backup handling. They are necessary because some customer information will legitimately be written, and you must be able to remove it. Their weakness is that they are reactive. Every record written is a record you must later find, delete and prove deleted.

Execution-path controls act before the write. Customer information reaches memory through agent interactions and tool calls, such as a prompt that includes an account number or a tool result that returns a customer profile. Enforcing policy at that point lets you allow the content, redact the sensitive fields, or block the call, so less customer information is persisted and less needs disposal.

The tradeoff is coverage and precision. Redaction rules that are too narrow miss customer information, and rules that are too broad degrade what agents can do. Most teams need both layers. Use execution-path enforcement to keep customer information out of memory by default, and memory-layer disposal for what remains and for data that predates the control.

Where Trussed fits

Trussed is not a memory deletion tool and does not purge CrewAI stores. It operates in the execution path, where it enforces policy at runtime, not reviewed after the fact, on individual agent interactions and tool calls. Policy can allow, redact or block customer information before it reaches memory.

The same enforcement produces audit-ready evidence of what was allowed and what happened. For a disposal program, that evidence shows which customer information was kept out of memory at the point of entry, which complements the purge and verification records you keep for the stores themselves. Trussed supports self-managed deployment in the customer cloud, with configurable retention and data residency, which matters when evidence itself contains sensitive material.