Meeting the Regulation S-P 30-day customer notification deadline when an OpenAI Agents SDK agent exposes customer data

What the 30-day requirement means for an agent exposure

As of November 2026, 17 CFR 248.30, as amended by the 2024 final rule (89 FR 47688), requires a covered institution to notify each affected individual whose sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization. The clock runs from the point the institution becomes aware that unauthorized access or use has occurred or is reasonably likely to have occurred. Certainty is not required. A reasonable likelihood is enough to start the period.

The 30 days is an outside date, not a target. The SEC stated that an institution may still be remediating after 30 days but must notify within the period so individuals can take protective measures. Notice must be clear and conspicuous and delivered by a means designed to ensure each affected individual can reasonably be expected to receive it.

There are two scoping rules that matter most for agents. First, notice is not required if the institution determines, after a reasonable investigation, that sensitive customer information has not been and is not reasonably likely to be used in a way that would result in substantial harm or inconvenience. Second, if the institution cannot identify which specific individuals were affected, it must notify all individuals whose sensitive customer information resides in the customer information system that was, or was reasonably likely to have been, accessed. An individual can be excluded only where the institution reasonably determines that person's information was not accessed or used. Every exclusion is a decision that needs a supporting record.

Mapping the incident timeline to the agent

Treat the four phases below as an operating sequence with owners, not a legal abstraction. Each phase depends on records that must exist before the incident.

• Detection: A privacy report, a monitoring alert, an enforcement event or a customer complaint indicates an agent may have disclosed customer data. Detection is operational. It is not yet a legal conclusion.
• Awareness: Compliance determines whether the institution has become aware that unauthorized access or use has occurred or is reasonably likely to have occurred. Record the timestamp and the basis. The 30 days run from this point.
• Scoping: Reconstruct which customers, data elements and time window were involved, and what the agent was permitted to do. Document the reasonable investigation behind any harm determination.
• Notification: Prepare and deliver notice within the period, using a means designed to reach each affected individual. Do not wait for remediation to finish.

Where an agent touches customer data, and why scoping stalls

An agent built with an agent framework such as the OpenAI Agents SDK handles customer data at four points. Model inputs carry prompts, retrieved records and conversation history. Tool calls pass arguments out and return results in, often from systems of record. Handoffs move context from one agent to another. Outputs deliver text or structured results to a user or downstream system. Any store that retains conversation content, such as session memory or trace data, also belongs in the inventory of the customer information system.

Scoping stalls when records describe that something happened but not what it contained. Application logs often show that a tool call succeeded, with a timestamp and a status, but not which customer record was returned or which fields were included in the model input or output. Without that, the institution cannot name affected individuals or data elements. The rule's fallback then points toward notifying everyone in the affected system, which is a larger population than the incident may justify.

The practical test is whether, for any interaction in a given time window, you can answer four questions from retained records: which customer, which data elements, what the agent did with them, and what policy applied at that moment. If any answer requires interviewing engineers or re-running the agent, the 30-day period is at risk.

Coordinating service provider obligations

The notification duty covers incidents at the institution and at a service provider that is not itself a covered institution. The institution must provide the notice or ensure that it is provided. If a model provider, hosted tool or external tool server handles customer data on behalf of the agent, its records of the affected system and individuals are an input to your scoping.

This is a design decision to make before an incident. Identify which providers touch customer data in each agent, and confirm contracts and oversight arrangements support timely incident notice to you and access to the information needed to scope. Align internal timing language as well. Reg S-P uses an awareness standard, and the separate FTC Safeguards Rule uses a discovery standard with its own 500-consumer threshold and notice content. If the FTC rule also applies to your institution, track those clocks separately rather than assuming they coincide.

Runtime enforcement and the evidence it produces

Enforcement in the execution path reduces what can be exposed, and the same enforcement produces records that narrow scope afterward. Trussed enforces policy in the execution path across models, agents, tools and MCP servers, at the level of individual interactions and tool calls. The actions are allow, redact, block, rate limit and escalate for human approval. Enforcement happens at runtime, not in review after the fact.

Each action maps to a scoping benefit. A redacted field is a field that did not reach the model or the output, which can support a reasonable determination that a specific individual's information was not exposed. A blocked tool call is a documented non-event. A rate limit bounds how many records a misbehaving agent can retrieve in a window. An escalation records who approved a sensitive action and when. Each decision generates audit-ready evidence tied to the interaction or tool call, including what policy applied and what was done.

• Redact: Removes or masks customer data elements before they reach a model, tool or output. The record shows what was redacted and under which policy.
• Block: Stops an interaction or tool call that violates policy. The record supports a determination that no exposure occurred for that call.
• Rate limit: Caps volume of retrieval or tool use, bounding the potential population in a time window.
• Escalate for human approval: Holds a high-risk action until a person decides. The record captures the approver and the decision.
• Allow: Permits the action under policy and records that it was permitted, which documents what the agent was allowed to do.