OpenAI Agents SDK Sessions and the Reg S-P Disposal Rule: How to Delete Customer Data From Conversation History
Treat deletion as a lifecycle design problem. Inventory every place session content lands, not only the primary session store. Write a disposal procedure for each layer with a trigger, an owner and a verification step. Minimize what enters history in the first place. Keep evidence of the controls that applied and the deletion tests you ran, separate from the customer content. This is engineering guidance, not legal advice, and no tool delivers Reg S-P compliance on its own.
- 1
Primary session store
The database or hosted record holding conversation items. Verify item-level removal, session clearing and record deletion separately.
- 2
Backups and snapshots
Copies persist until they expire or are overwritten. Define a backup retention period and document how deletion applies to it.
- 3
Application logs
Request and response logging often captures message content. Reduce or mask content at the logging layer.
- 4
Tracing and telemetry data
Traces can include prompts, tool inputs and outputs. Decide what is captured and how long it is kept.
- 5
Tool outputs and retrieval stores
Results written to vector stores, caches or downstream systems are derived copies with their own lifecycle.
- 6
Model provider and hosting vendors
Third parties may hold content. Review retention terms and contract language, including the 72-hour service provider breach notice.
- 7
1. Define the trigger
Choose events that end the need for the data: session closure, a retention period expiring, an account closing, or a verified customer request. Document the reasoning, since the standard is a documented judgment.
- 8
2. Partition by customer
Key sessions so that one customer's history can be located and removed without touching others. Avoid shared sessions that mix customers.
- 9
3. Delete the primary record
Use the removal operation that matches the trigger: an item, a session, or the full record. Clearing contents does not necessarily delete the record, so confirm which you performed.
- 10
4. Propagate to copies
Run deletion or expiry against logs, traces, retrieval stores and caches. Let backups age out on a defined schedule and record that schedule.
- 11
5. Verify
Confirm the item is absent from the primary store and each copy location. Keep the test result as evidence without keeping the content.
What to write into the disposal procedure
- Each agent mapped to its Session implementation and backing store, with an owner.
- Deletion triggers and retention periods, with the rationale recorded and reviewed on a schedule.
- Supported removal operations per store: item, session and record.
- Handling for backups, logs, traces, retrieval stores and tool outputs.
- Vendor and service provider terms, including 72-hour breach notice to your institution.
- Verification tests, results retained as evidence, and decommissioning steps for storage media and equipment.
What the disposal rule asks of a session store
Under 17 CFR 248.30(b)(1), a covered institution must 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. Under (b)(2), it must adopt and implement written policies and procedures that address proper disposal to that standard. Notice-registered broker-dealers are excluded from this provision, so confirm applicability for your institution. These descriptions reflect the regulation as of November 2026.
The standard is reasonable measures, not a fixed retention period. That makes the institution's documented judgment central. The text addresses discarding or abandoning information and the sale, donation or transfer of media on which it is stored. Conversation history in an agent deployment is customer information whenever a customer's details appear in it, so it belongs inside the written procedures.
The FTC Safeguards Rule uses a two-year-after-last-use benchmark for institutions under FTC jurisdiction. It is a different rule and not the Reg S-P standard, but some teams use it as a point of comparison when setting a retention period.
Separating deletable content from retained evidence
Deleting conversation content does not mean losing the ability to show what happened. The two should be stored as separate record types from the start. Customer content is the message text, tool inputs and outputs, and any identifiers within them. It is deleted on its trigger. Evidence is the record that a control applied, what decision it made, when, and under which policy version. It contains no customer content and can follow its own retention period.
This split also keeps the evidence store out of the disposal problem. If evidence records embed raw prompts, they inherit the same obligations as the history you are trying to delete. Use references such as policy identifiers and decision types instead of copied text.
In the 2023 proposing release, the SEC said the proposed recordkeeping requirements were not intended to require documenting every act of disposing of an item of information. That is proposal-stage text and should be checked against the final rule, but it is consistent with keeping policy-level records of the disposal procedure and its verification instead of item-level logs.
Retained copies stay exposed to unauthorized access until disposed of. That is where disposal meets the incident response requirement: a program to detect, respond to and recover from unauthorized access, including assessing scope and identifying affected systems and types of customer information. A current inventory of storage layers makes that assessment faster.
Reducing what reaches session storage
The cheapest data to dispose of is data that was never written. Minimization can happen in application code, but policy enforced at runtime in the execution path applies the same rule to every agent and tool call instead of relying on each team's implementation.
Trussed enforces policy in the execution path for individual interactions and tool calls, with allow, redact and block outcomes. When a policy redacts customer data from an interaction before it is written to history, the session store and its downstream copies hold less customer information, which shrinks the disposal scope. Blocking prevents a disallowed interaction from proceeding at all. Enforcement happens at runtime, not in a review after the fact, so the redaction decision is made before content is persisted.
Each enforcement decision also produces audit-ready evidence that can be retained independently of the deleted content. Trussed supports self-managed deployment in the customer cloud with configurable retention and data residency, so evidence retention can be set separately from conversation retention. Runtime enforcement reduces exposure but does not replace a written disposal procedure, and it does not by itself establish Reg S-P compliance.
From session write to verified disposal
Minimize
Redact or block customer data before it is written to history.
Store
Know which Session implementation and backing store hold each conversation.
Delete
Remove items, sessions and copies on a defined trigger.
Evidence
Retain control and deletion-test records, not customer content.
Reduce what your agents store, and keep the evidence
Discuss how runtime policy enforcement and audit-ready evidence fit alongside your session retention and disposal design.
Explore Agent and Tool-Call EnforcementHow does your AI governance program compare?
See where your program has gaps in less than 2 minutes.