Reg S-P service provider 72-hour notice: contract terms for LLM and agent platform vendors

What the amended rule requires of the institution

Under 17 CFR 248.30, a covered institution's incident response program must include written policies and procedures, established, maintained and enforced, that are reasonably designed to require oversight of service providers, including through due diligence and monitoring. Those policies must be reasonably designed to ensure providers take appropriate measures to protect against unauthorized access to or use of customer information. They must also ensure providers notify the institution as soon as possible, but no later than 72 hours after becoming aware of the breach described above.

Two details shape contract drafting. First, the final rule dropped the proposal's requirement that policies mandate a written contract. The obligation is oversight reasonably designed to produce the provider behavior, so a contract is the practical way to evidence that oversight rather than a clause the rule prescribes. Second, the trigger is worded around a breach in security resulting in unauthorized access to a customer information system the provider maintains. That is narrower than the common shorthand of a breach affecting customer information, and the contract should be drafted against the regulatory wording while stating the vendor's duties precisely.

When the notice arrives, the institution must initiate its incident response program. Individual notice is a separate duty: as soon as practicable, and not later 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, subject to limited exceptions. The vendor's notice starts your clock for assessment, so what it contains matters. This guide is not legal advice, and counsel should review any arrangement.

Scope: which AI data and systems the contract covers

Standard vendor templates were written for databases and file stores. LLM and agent platforms move customer data through more places, and the contract should name them rather than rely on a general definition. Whether each of the following counts as customer information is a definition question the contract must settle, so list them: prompts, retrieved context passed into a prompt, tool-call inputs and outputs, model outputs, agent memory, and logs or telemetry that contain any of those.

Do the same for systems. The notice duty attaches to a customer information system the provider maintains. Specify which vendor components are in scope: the model API, the orchestration layer, memory or vector stores, and any hosted tool or MCP server. If a component is excluded, the contract should say so, and your oversight file should record how that risk is handled another way.

Also address use. The vendor's duty to take appropriate measures against unauthorized access to or use of customer information should cover use by the vendor itself, including retention of prompts and outputs and any use for model improvement. Make permitted uses explicit and default the rest to prohibited.

Awareness triggers and notice content

The 72-hour period runs from when the provider becomes aware, so the definition of awareness decides how much protection the clause gives. A vendor holding only model-layer telemetry may see request volumes and error rates but not whether a given request exposed customer data. Without a definition, the vendor can argue it was never aware.

A workable clause defines awareness as the point at which any employee or agent of the vendor, or any sub-processor, knows or has reason to believe a qualifying breach occurred, and it should not depend on completed internal investigation or classification. It should state that 72 hours is an outer limit and that notice is required as soon as possible. It should oblige the vendor to maintain detection suitable for the telemetry it holds, and to treat anomalous access to stored prompts, context, memory or logs as events requiring prompt triage.

Notice content should let you start your incident response program and later describe the incident in general terms and identify the type of sensitive customer information involved. Ask for the systems and components affected, the time window, the categories of data involved, whether the data was accessed, copied or only exposed, the sub-processors involved, containment steps taken, and a named contact. Require updates as facts develop, without waiting for a complete picture before the first notice.

Sub-processors, evidence and cooperation

LLM and agent platforms often chain parties: the platform vendor, a model host, and one or more tool or MCP server operators. Your oversight policies need to say how those parties' awareness and notice reach you. The practical term is a flow-down: the vendor must bind each sub-processor that maintains systems holding customer information to equivalent notice and safeguard duties, must disclose the list and notify you of changes, and must treat a sub-processor's awareness as its own for the purposes of the clock. Without that, a model host's discovery can sit unreported while the platform vendor remains technically unaware.

Evidence terms are where AI contracts are most often silent. Require the vendor to retain, for a stated period, the records relevant to scoping: access records for the affected systems, request and response metadata, tool-call records, and retention and deletion records for stored context and memory. Require it to preserve them once an event is suspected, and to deliver them in a usable form within a set time. Include cooperation duties: access to technical staff, support for your forensic review, and assistance with any individual notices.

If you delegate individual notices to a vendor, the rule allows a written agreement for that purpose. Your own duty to ensure notification and the 30-day individual notice obligation remain, so the agreement should specify content review, timing and approval rights.

What the contract can assure and what you must evidence yourself

A vendor notice only covers systems the vendor maintains. Access events inside your own AI execution path, such as your gateway, orchestration and tool calls, will not appear in it. After a notice you must still work out whether unauthorized access or use occurred or is reasonably likely, and which sensitive customer information was involved. That depends on knowing what your AI systems were permitted to reach and what they actually did. Contract terms can allocate the vendor's notice, retention and cooperation duties. They cannot create records of your agents' behavior.

This is where Trussed fits. Trussed enforces policy in the execution path, with allow, redact, block, rate limit and human-approval outcomes applied to individual interactions and tool calls, and it produces audit-ready evidence from that enforcement. Redacting or blocking data before it reaches a vendor also reduces what the vendor holds. Trussed can be deployed self-managed in your cloud, with configurable retention and data residency. It supports your own incident scoping and does not certify or confer Reg S-P coverage.

• Vendor notice within 72 hours: Contract: notice duty, awareness definition, content and updates. Institution runtime: not applicable, but you must be able to act on the notice.
• Sub-processor awareness: Contract: flow-down, disclosure and imputed awareness. Institution runtime: records of which external tools and models your agents called.
• Vendor-held evidence: Contract: retention, preservation and handover of vendor records. Institution runtime: your own interaction and tool-call records.
• What data reached the vendor: Contract: permitted uses and storage limits. Institution runtime: policy enforced before data leaves, with evidence of allow, redact and block decisions.
• Incident scoping decisions: Contract: cooperation duties and technical access. Institution runtime: evidence of what AI systems accessed and did, to support notification decisions.