Regulation S-P and LLM API Customer Information: Is It Unauthorized Access?

What Regulation S-P requires, as of November 2026

Regulation S-P, codified at 17 CFR 248.30, requires every covered institution to develop, implement and maintain written policies and procedures covering administrative, technical and physical safeguards for customer information. The policies must be reasonably designed to ensure the security and confidentiality of that information, protect against anticipated threats or hazards, and protect against unauthorized access to or use of customer information that could result in substantial harm or inconvenience to any customer.

The written policies must also include a program reasonably designed to detect, respond to and recover from unauthorized access to or use of customer information, including customer notification procedures. When an incident occurs, the program must assess its nature and scope, identify the customer information systems and types of customer information that may have been accessed or used without authorization, and take appropriate steps to contain and control it. The SEC's final amendments added these response-program and service-provider provisions.

The phrase that matters here is "unauthorized access to or use of." The rule text does not define it for transmissions to a third-party API. That gap is why the analysis starts with the institution's own policies.

Why the answer turns on authorization, service provider status and data

Three questions drive the determination, and they should be kept separate.

The first is authorization. Because the rule speaks of unauthorized access or use without defining the term for third-party API calls, each institution should define authorized use of customer information in its written policies: which data, for which purposes, to which destinations, through which approved paths. Counsel, not the engineering team, should own that definition and any incident determination.

The second is service provider status. The rule defines a service provider as any person or entity that receives, maintains, processes, or otherwise is permitted access to customer information through its provision of services directly to a covered institution. An LLM API vendor that processes prompts containing customer information for the institution will often fit that description, and the conclusion should be documented per vendor.

The third is what was actually sent. A prompt containing no customer information raises a different question than one containing account details. The response program's requirement to identify affected systems and types of customer information means payloads must be attributable to data types, systems and destination endpoints.

Likely authorized, gray area or possible incident

The categories below are a working method, not a legal test. Each institution should set its own documented criteria and have counsel confirm how they apply.

• Likely authorized: The vendor is assessed as a service provider, due diligence and monitoring are documented, the data types sent are permitted by policy for that use, and the call follows an approved path and endpoint.
• Gray area: The vendor's status is unassessed or unclear, due diligence is incomplete, the use is not clearly covered by policy, or the data types sent were not recorded. These cases need a documented decision by the responsible owner.
• Possible incident: Customer information reaches an endpoint or vendor outside policy, or a data type that policy prohibits is sent. The response program's assessment, scoping and containment steps apply, and counsel makes the determination.

Service provider oversight and the facts to document

The SEC changed the service provider requirement from its proposal. Rather than requiring a written contract, the policies must be reasonably designed to ensure service providers take appropriate measures to protect against unauthorized access to or use of customer information and to notify the institution. Oversight includes due diligence and monitoring. Contract terms may be one way to meet this, but the institution must be able to show how its policies achieve it.

The provider notice trigger is a breach in security resulting in unauthorized access to a customer information system maintained by the service provider, with notice due as soon as possible and no later than 72 hours after the provider becomes aware. A routine API transmission the institution itself initiates is not clearly described by that trigger, which is another reason the institution's own authorization policy carries weight.

The rule does not list provider retention, training use, zero-retention terms, encryption or endpoint region as criteria. They are still institution-specific facts that bear on whether a disclosure can reasonably be treated as authorized under its safeguards policies, so they belong in the vendor file. The FTC said in 2024 that model-as-a-service companies that break privacy commitments, including promises not to use customer data to train models, may face liability under FTC-enforced laws. That is not a Regulation S-P interpretation, but it shows why vendor commitments should be recorded and monitored.

Separately, the privacy-rule provisions inherited from the Gramm-Leach-Bliley Act restrict disclosure of nonpublic personal information to nonaffiliated third parties, with exceptions for service providers and for transactions a consumer requests or authorizes. Assess those provisions for any LLM disclosure of that information. Customer notification turns on a determination about sensitive customer information, so confirm the final definition and notification provisions with counsel.

Enforcing policy on the data flow at runtime

A written policy that permits some LLM use and prohibits other use needs a technical safeguard where the data actually leaves. The rule frames safeguards as administrative, technical and physical, and it does not require any specific control. A control at the point of the outbound API call is one technical option, because it sees the payload, the destination and the calling path together.

The practical decision at that point is allow, redact or block. Allow when the destination, data types and use match policy. Redact when the request is permitted but certain customer information is not. Block when the destination or data is outside policy. Employee tools, applications and agents use different paths, and tool calls can carry customer information that never appears in a prompt, so the inventory of customer information systems should show which paths can reach external LLM endpoints and enforcement should cover each.

Trussed enforces policy in the execution path across models, agents, tools and MCP servers, applying allow, redact and block decisions to individual interactions and tool calls, with evidence generated by enforcement. Because it is self-managed in the customer cloud with configurable retention and data residency, the institution keeps control over where that evidence lives. The same approach can be implemented with other tooling. What matters is that enforcement happens at runtime, not through review after the fact.