GLBA AI Compliance: How the Safeguards Rule Applies When Customer Data Reaches an LLM
The FTC Safeguards Rule under GLBA requires financial institutions to run a written information security program with access controls, monitoring of authorized user activity, and oversight of service providers. When an employee or an AI agent pastes customer nonpublic personal information into an LLM prompt, that data becomes AI traffic to a third party, and the Safeguards Rule follows it there. This piece walks the specific Safeguards Rule provisions that land on AI inference traffic, where standard controls miss it, and how to enforce access and produce the audit record the rule expects.
The FTC Safeguards Rule under the Gramm-Leach-Bliley Act, codified at 16 CFR Part 314 with its amended provisions effective June 9, 2023, requires a financial institution to maintain a written information security program that controls access to customer information, monitors the activity of authorized users, and oversees service providers that touch that data. The rule text is published by the FTC. None of it mentions large language models, and all of it applies the moment a loan officer pastes a customer's financial profile into a chatbot. That prompt is nonpublic personal information moving to a third party. I want to walk the Safeguards Rule provisions that land directly on AI traffic and show where the standard controls stop seeing it.
The Safeguards Rule provisions that touch AI traffic
Three requirements in the amended rule apply squarely to prompts sent to an LLM.
Access controls. The rule requires you to limit access to customer information to authorized users and to what each user needs. A model endpoint that any authenticated employee can send any customer record to fails this, because access to the AI channel is not scoped to role or data sensitivity.
Monitoring of authorized users. The rule requires monitoring the activity of authorized users to detect unauthorized access or use of customer information. A record that an employee used an internal AI tool, without what data they sent, does not meet that bar.
Service provider oversight. The rule requires you to select and oversee service providers capable of maintaining safeguards. An external model provider receiving customer data through prompts is a service provider in the path of NPI.
Where standard controls miss the AI channel
A bank invests in network DLP, a CASB, and identity management, and each operates at a layer that the AI prompt slips past. Network DLP inspects traffic underneath TLS and sees an encrypted POST to a model API, not the customer profile inside it. The CASB governs sanctioned application access and does not parse the content of a prompt. Identity management authenticates the employee and grants coarse access, and it never evaluates whether this specific prompt should carry this specific customer record to an external model. The AI channel is a first-class data path, and the tools a financial institution already owns were built for documents and web traffic rather than prompt content.
The access decision the rule actually requires
Meeting the access-control provision for AI traffic means deciding, per request, whether a caller may send this data to this model. That decision has to run on the request path, before the prompt leaves for the provider. A raw call from an internal tool looks like this:
A policy decision point in front of the model reads the caller identity, classifies the content as NPI, checks policy, and returns a verdict before the provider is reached:
The monitoring record examiners expect
The monitoring provision needs a record that survives a look back. An examiner reviewing how a bank supervises AI usage wants to see, for a sampled interaction, who the authorized user was, what customer data the prompt carried, which policy applied, and what the system did. Application logs written by the AI tool itself fail this on two counts: they usually lack the customer-data classification, and the system generating the AI decision is also writing its own record, which is the self-attestation problem regulators reject elsewhere. An independent, identity-bound record produced on the traffic answers the monitoring provision directly. Related sector coverage sits in PCI DSS AI and DORA AI compliance.
DeepInspect
This is the gap DeepInspect closes for financial institutions. DeepInspect is a stateless proxy that sits inline in front of your AI traffic and is model-agnostic, so one layer covers OpenAI, Anthropic, Bedrock, Vertex, Azure OpenAI, and self-hosted endpoints. For every request it evaluates the caller identity and role, the data classification in the prompt, and organizational policy, then returns a pass or block decision before the traffic reaches the model. Enforcement adds under 50 milliseconds in internal testing, and the default on ambiguity is deny, which is the posture the Safeguards Rule access provision favors.
For every decision it commits an identity-bound audit record before the response returns, written independently of the calling application. That record gives an examiner the access and monitoring evidence the Safeguards Rule expects for customer information, on the AI channel that DLP and CASB tooling cannot see. DeepInspect does not replace your information security program. It enforces the access and monitoring provisions on the traffic where customer data reaches a model. Let's talk today.
Frequently asked questions
- Does GLBA apply to data sent to AI tools?
Yes, customer nonpublic personal information does not lose its protection because it is pasted into a prompt. The Safeguards Rule access, monitoring, and service-provider provisions follow that data to the model endpoint receiving it.
- Why does network DLP miss AI prompts under GLBA?
Network DLP inspects traffic beneath TLS encryption and sees an encrypted call to a model API, not the customer information inside the prompt. The data it is meant to protect travels in a payload it does not parse, so the AI channel needs enforcement that reads prompt content.
- Is an external model provider a service provider under the Safeguards Rule?
When customer information reaches it through prompts, it sits in the path of NPI, which brings the rule oversight expectations into play. Controlling and recording what data reaches that provider is part of meeting the service-provider provision.
- What monitoring record does a GLBA examiner expect for AI usage?
For a sampled AI interaction, who the authorized user was, what customer data the prompt carried, which policy applied, and what the system did. A generic log that an AI tool was used, without the data context, does not satisfy the monitoring provision.
- Can application logs meet the GLBA monitoring requirement for AI?
They usually fall short, because they lack customer-data classification and are written by the same system that made the AI decision. An identity-bound record produced independently on the AI traffic is the stronger evidence for the monitoring provision.