Reg S-P Sensitive Customer Information in LLM Prompts: What to Block, Redact, or Allow

What the definitions put in scope

As of November 2026, Regulation S-P as amended in 2024 is in effect. It defines sensitive customer information as any component of customer information, alone or in conjunction with any other information, the compromise of which could create a reasonably likely risk of substantial harm or inconvenience to an individual identified with the information. The phrase "in conjunction with any other information" is the operative difficulty for prompts. Sensitivity can come from a combination of fields, so a prompt can be harmless field by field and sensitive as a whole.

Customer information is broader. For most covered institutions it means any record containing nonpublic personal information about a customer, in paper, electronic or other form, that the institution possesses or that is handled or maintained by it or on its behalf. The definition is record-based, not channel-based. A user-typed prompt, a document returned by retrieval, and a tool-call payload are all potentially in scope. The "on its behalf" language also suggests that externally hosted models fall within the same reading, though that is interpretation, not rule text.

Two scoping points shape the policy. The SEC described the adopted definition as covering identifying information combined with authenticating information, such as a partial Social Security number, an access code, or a mother's maiden name. It also covers identifiers such as Social Security numbers, driver's license numbers, and biometric records that could create a substantial risk of harm even without other identifying information. Separately, the subpart applies, except for § 248.30(b), only to information about individuals who obtain financial products or services primarily for personal, family or household purposes. Whether to apply uniform handling to business-purpose individuals is a firm decision.

A starting map from data category to action

The table below is a practitioner design, not regulatory text. Each row keys on a category the definitions support. Defaults should be tuned to the task, the model path, and the institution's risk appetite.

• Identifiers sensitive on their own (Social Security numbers, driver's license numbers, biometric records): Block by default. Redact when the task can run without the value. Allow only on a named, approved path, with escalation if the path is new.
• Authenticating elements (access codes, mother's maiden name, partial Social Security number): Block. No model task usually needs a credential or a security answer, and leaving it in a prompt creates the exposure the definition describes.
• Names, addresses, phone numbers alone: Not automatically sensitive under the SEC's reading. Allow or redact based on task need, and re-evaluate when anything else is added.
• Identifier plus authenticating or account-access information: Redact the authenticating element if it can be separated cleanly. Block the whole request if it cannot.
• Retrieved context and tool-call payloads: Classify with the same rules as typed prompts, at retrieval time and again before each tool call.
• Ambiguous or novel combinations: Escalate for human approval. The substantial-harm standard is judgment-based, so some cases need a named approver.

Edge cases and the redaction versus blocking trade-off

Redaction keeps a workflow running, but it has technical limits. Detectors can miss values, especially in free text, pasted documents, or unusual formats. A redacted prompt can still allow re-identification through surrounding context, for example when a rare circumstance narrows a record to one person. Removing or masking a value can also degrade output quality if the model needed it to answer. None of these effects is quantified here, so measure them in your own environment before relying on redaction as the default.

A useful rule is to block when the cost of a missed detection is high and the model has no legitimate need for the value. Authenticating elements fit that description. Redact when the value is incidental to the task, such as a Social Security number inside a pasted correspondence thread where the model only needs to summarize the complaint. Allow when the data is necessary, the path is approved, and the decision is recorded.

Combination logic is the second edge case. Per-field pattern matching will pass a name in one field and a security answer in another. Policy should evaluate the assembled prompt, including everything retrieval appended, not each field in isolation. Where the assembled request cannot be classified confidently, escalation is safer than a guess in either direction.

Turning the framework into enforceable runtime policy

A framework in a document is not a control. It becomes one when rules are expressed as policy, evaluated on every interaction, and applied before data leaves the institution's boundary. The steps below keep the build tractable.

• 1. Inventory data elements from the definitions: List authentication-capable elements, identifiers sensitive alone, and identifiers sensitive only in combination. This is the classification vocabulary for policy.
• 2. Establish individual scope: Decide whether policy distinguishes personal, family or household customers from business-purpose individuals, or applies one standard to both.
• 3. Write rules per category and per path: Specify the action for each category on each model, agent, and tool, including internal models, since records handled on the institution's behalf are covered either way.
• 4. Cover retrieval and tool calls: Evaluate retrieved documents and outbound tool payloads with the same rules as user input.
• 5. Define escalation criteria and approvers: Name who approves ambiguous combinations and what information they see when deciding.
• 6. Version the policy: Track rules and thresholds so every decision can be tied to the policy version in force at that moment.

Why runtime enforcement differs from after-the-fact review, and what evidence it produces

Acceptable-use policies and periodic prompt review describe intent and sample outcomes. They cannot show what a specific interaction was permitted to receive, and by the time a reviewer sees a prompt, the data has already reached the model. Enforcement in the execution path decides before the data moves, and the decision itself becomes the record. That distinction matters because the response program under Reg S-P turns on whether sensitive customer information was, or is reasonably likely to have been, accessed or used without authorization. Notification of affected individuals follows unless a reasonable investigation finds substantial harm is not reasonably likely. Prompt-level records can support that investigation, though whether they suffice is a determination for the institution and its counsel.

For each interaction, a defensible record would include the policy version applied, the action taken, the data category detected, a timestamp, and the actor, whether a user, an agent, or an approver. These fields are a practitioner proposal and the regulation does not specify them. They should also record the model or tool involved and, for escalations, the approval outcome. Retention should be configured to the institution's own recordkeeping obligations and be exportable for examiners. Because prompts can contain the very data being protected, decide deliberately what the evidence stores: the decision and category, or also the redacted content.

NIST's draft Cyber AI Profile, which is non-binding, points in the same direction. It refers to runtime redaction for sensitive data in prompts and to versioning and tracking of prompts, thresholds, and rules.