Reg S-P 72-Hour Service Provider Notification Clauses for LLM Vendors Behind CrewAI and OpenAI Agents SDK

What the amended rule requires of you

As of November 2026, 17 CFR 248.30(a)(5) requires a covered institution's incident response program to include written policies and procedures for overseeing service providers, including through due diligence and monitoring. Those policies must be reasonably designed to ensure that service providers take appropriate measures to notify the institution as soon as possible, and no later than 72 hours, after becoming aware that a breach in security has occurred resulting in unauthorized access to a customer information system the provider maintains. The SEC moved this deadline from 48 hours in the proposal to 72 hours, citing the time providers need to investigate and produce more accurate notices.

Three consequences follow for contract drafting. First, receipt of a provider's notice obliges the institution to start its incident response program. Second, the institution's customer notice duty runs separately: notice is due as soon as practicable, and no more than 30 days, after the institution becomes aware that unauthorized access to or use of customer information has occurred or is reasonably likely to have occurred. Third, that duty applies to incidents at a service provider that is not itself a covered institution. The institution may be excused only if, after a reasonable investigation, it determines that sensitive customer information has not been and is not reasonably likely to be used in a way that results in substantial harm or inconvenience.

A provider can be engaged by written agreement to send customer notices on the institution's behalf. The rule does not displace the institution's own obligation, so the institution still needs the facts.

Mapping an agent's execution chain to service provider questions

Start from the data flow, not the procurement list. In a typical CrewAI or OpenAI Agents SDK deployment, customer information can leave the institution's environment at several points. The table below is an analytical screen, not regulatory text. Reg S-P oversight attaches to parties that handle customer information on the institution's behalf, and the FTC Safeguards Rule, a separate regime, uses a similarly broad access-based test: a person that receives, maintains, processes or is permitted access to customer information through services provided to a financial institution. Use that as a prompt for review, then have counsel confirm classification under the SEC rule.

Agent frameworks are often adopted by engineering teams, so check whether each relationship already sits inside an existing vendor contract. Do not assume it does.

• Model API vendor: Receives prompts, retrieved context and tool results. Treat as a recipient of customer information. Confirm data-use and retention terms and the notification commitment.
• Hosted tool provider: Receives tool inputs such as account lookups or document text. Classify by what it receives and retains.
• MCP server operator: Receives tool calls and returns outputs. A third-party operator is a separate relationship from the model vendor and needs its own review.
• Memory or vector store: May hold customer information across runs. Whether it is a provider system or your own changes who must notify whom.
• Subcontractors of any of the above: May also touch customer information. Flow-down terms determine whether you hear about their incidents.
• The framework itself: An open-source library running in your environment is different from a hosted service. Classify by where data goes, not by the framework name.

Core elements of the 72-hour notification clause

The rule gives the clause its anchor: a deadline of no later than 72 hours after the provider becomes aware, tied to a breach in security resulting in unauthorized access to a customer information system the provider maintains. Everything else in the clause is a drafting choice, not regulatory text. The federal procurement clause structures LLM flow-down differently, but it belongs to another regime and should be read only as an example of how others handle it.

A workable clause covers the following elements. Evaluate vendor paper against each, because standard LLM vendor terms and data processing addenda may not address them in the form you need.

• Trigger definition: Track the rule: awareness of a breach in security resulting in unauthorized access to a customer information system the provider maintains. Decide deliberately whether the contract also covers broader events, and state what counts as awareness so the clock start is unambiguous.
• Notification content: Specify what the notice must contain, such as the systems affected, the time of discovery, the nature of access and the categories of your data involved to the extent known, with a duty to update as the investigation proceeds.
• Contact path: Name a monitored security contact on each side, with a channel that works outside business hours. A 72-hour window is consumed quickly by a notice sent to an unattended account.
• Subcontractor flow-down: Require the provider to bind any subcontractor that receives or can access your customer information to equivalent notification duties, and to disclose which subcontractors those are.
• Cooperation on scoping: Require the provider to preserve relevant records, share logs that identify your data, and support your investigation. Add retention periods long enough to cover your harm determination.
• Notice on your behalf: If a provider will send customer notices for you, put that in a written agreement and keep the underlying decision with your incident response team.

A vendor's notification does not scope the incident

The 72-hour trigger concerns the provider's system. A provider's notice therefore describes the provider's breach, and it may not tell you which of your customers' information was involved. This is an inference from how the trigger is written, but it matches the practical position: the vendor knows what reached its systems only to the extent it kept records, and those records may be organized by account or API key, not by your customers.

That gap matters because your own obligations depend on facts. Your 30-day customer notice clock runs from your awareness, and the exception for harm requires a reasonable investigation of whether sensitive customer information was involved. Governance should state who conducts that investigation and which records support it. The rule also frames oversight as due diligence and monitoring, which points to evidence you hold, not only terms you negotiated.

The record you need has two halves. The first is what each vendor was permitted to receive: the policy. The second is what each vendor actually received: the evidence. Contract language establishes neither. If an agent can pass a full customer record to a model API or an MCP server when only a few fields are needed, the permitted scope is wider than the business purpose, and after an incident you cannot narrow it without records.

Where runtime policy enforcement supports the clause

The contract clause is one control among several. Runtime enforcement addresses a different problem: limiting and recording what customer information reaches a vendor in the first place.

Trussed enforces policy in the execution path on individual interactions and tool calls. For a given request to a model API, or a call to a tool or MCP server, it can allow, redact or block based on policy. A policy might permit an account identifier to go to a tool but redact a government identifier from a prompt, or block a call to a vendor that has not been approved for customer information. Because enforcement happens at runtime, not in a review after the fact, the vendor receives only what policy allowed.

Each enforcement decision produces audit-ready evidence of what was sent and what policy applied. When a vendor notice arrives, that evidence lets the institution ask which interactions and tool calls involved that vendor, and which customer information was permitted or redacted. It supports the scoping cooperation described above from the institution's side, so the investigation does not depend only on the vendor's logs. Trussed can be self-managed in the customer's cloud, with configurable retention and data residency, which bears on how long the evidence is available for a harm determination.

The scope is deliberate. Trussed works at the level of interactions and tool calls. It does not replace the contract clause, the service provider classification, or the legal judgment about notification, and this page is not legal advice.