Financial services AI security is now a GLBA and SEC issue

At a glance

What this is: This is an analysis of how financial services AI use creates data security and compliance exposure when regulated data enters GenAI tools, AI agents, and embedded AI features.

Why it matters: It matters because IAM, data security, and governance teams need evidence that access, disclosure, and monitoring controls still work when employees and agents move sensitive data into AI systems.

By the numbers:

• Cyberhaven found a 17x difference in AI adoption between the most aggressive financial services firms and the most cautious ones.
• Cyberhaven research found that 32.3% of ChatGPT usage and 24.9% of Gemini usage occur through personal accounts, with Claude and Perplexity higher still at 58.2% and 60.9%.
• Cyberhaven reported that 79.7% of financial services firms are building with agent platforms, and coding assistant use jumped from 16.7% to 42.1% in a single year.

👉 Read Cyberhaven’s analysis of financial services AI security and GLBA exposure

Context

Financial services AI security is about controlling how regulated data moves into and out of AI tools, including GenAI apps, AI agents, and embedded features in approved software. The core problem is not model capability, but governance failure: firms often cannot see which tools are in use, what data they receive, or whether those flows satisfy GLBA and SEC expectations.

The first-order issue is identity and access at the point of data movement. When employees, service workflows, or AI agents submit nonpublic personal information to unreviewed tools, the security model shifts from perimeter enforcement to traceable use, auditability, and policy enforcement. That is where financial services programmes most often fall short.

Cyberhaven’s starting position is typical for a regulated market under pressure: adoption outruns oversight, and the compliance burden follows the data, not the platform brand.

Key questions

Q: What breaks when employees use unapproved AI tools with company data?

A: Governance breaks because the organisation loses visibility into where data and secrets are going, who can access them, and how they are being reused. Unapproved tools can copy credentials into unmanaged workflows, which weakens revocation and makes audit trails incomplete. The result is shadow access outside the main identity programme.

Q: Why do AI agents complicate cloud identity governance?

A: AI agents complicate governance because they turn identity from a static permission holder into an operational decision-maker. Once an agent can reason over cloud data and act through integrations, IAM must govern not only access, but also the conditions under which that access can be used to change systems or initiate work.

Q: How can security teams tell whether AI lifecycle controls are working?

A: They should look for evidence that access requests, policy enforcement, and usage visibility are centrally recorded and current. If those signals are fragmented across platforms, the programme may be documenting governance rather than enforcing it. Continuous traceability is the practical test.

Q: Who is accountable when an AI agent accesses regulated data improperly?

A: Accountability sits with the teams that govern the agent's identity, the data classification, and the policy that allowed the access path. If those controls are disconnected, no single owner can explain why the access existed or why it was not removed sooner. Shared context is what makes accountability traceable.

Technical breakdown

Shadow AI and personal account usage create ungoverned data paths

Shadow AI appears when employees use AI tools outside approved procurement or identity controls, often through personal accounts that enterprise logging never sees. That makes the AI session invisible to security teams even when the user is known. In financial services, the governance problem is not only unsanctioned software, but also the loss of traceability over who submitted customer data, under what identity, and to which service. Without identity-aware monitoring, the organisation cannot reconstruct the exposure path after the fact.

Practical implication: inventory AI usage by account type and enforce controls on personal-account access to regulated data.

Endpoint AI agents expand the access scope of the human identity that launched them

Endpoint AI agents run locally and inherit the access of the user or process that starts them. That means the agent can read files, move content, and interact with systems without going through a separate approval step for each action. From an IAM and data governance perspective, this is a delegation problem: the firm may think it approved a human user, but in practice it has also empowered a software actor to exercise that access. The result is a widened trust boundary around a single session or workstation.

Practical implication: treat endpoint AI agents as delegated identities and restrict the data sets they can reach.

AI features inside approved tools bypass network-centric controls

Many risky AI interactions do not look suspicious on the wire because the traffic is encrypted and the destination is a sanctioned service. That breaks traditional assumptions that network inspection alone can expose exfiltration or policy violations. The more relevant control point is data lineage and content inspection at the moment sensitive information is entered, transformed, or returned. This is where DSPM and AI-aware DLP matter, because they connect identity, data classification, and destination context into a single evidence chain.

Practical implication: apply controls at data entry and output points, not only at the network boundary.

Threat narrative

Attacker objective: The objective is not necessarily intrusion, but uncontrolled access to regulated data that creates compliance exposure, disclosure risk, and loss of evidentiary traceability.

1. Entry occurs when employees or workflows submit nonpublic personal information into AI tools that were not reviewed by security or compliance.
2. Credential and identity exposure follow when personal accounts or delegated endpoint agents operate outside central visibility, making the data path hard to attribute.
3. Impact occurs when regulated data is exposed, retained, or used in ways that create GLBA, SEC, and contractual reporting obligations.

NHI Mgmt Group analysis

AI security in financial services is becoming a data governance problem before it becomes a model risk problem. The article’s core point is that regulated data flows, not model outputs, create the first compliance failure mode. GLBA and SEC obligations follow the information, so organisations that cannot track where customer data went will struggle to defend any downstream AI control claims. The practitioner conclusion is simple: data traceability must be treated as a control requirement, not a reporting convenience.

Endpoint AI agents create a delegated identity problem that most IAM programmes still under-model. These systems inherit human access, act locally, and can move data without a distinct review workflow for each action. That means the organisation is effectively extending human privilege into software behaviour without a separate lifecycle, which is exactly where IAM and NHI governance overlap. The practitioner conclusion is to treat AI agents as identities with scope, logs, and offboarding requirements.

Shadow AI is a visibility failure, not just a procurement failure. Personal accounts, embedded AI features, and unsanctioned tools all create data paths that central controls miss. That makes inventory, lineage, and detection the real control stack, with NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 aligning most closely to the operational need. The practitioner conclusion is to prove where data moved before asking whether policy was written.

Financial services will increasingly be judged on provable AI governance, not stated AI policy. Regulators and auditors care whether firms can explain the data path, the access model, and the notification timeline when AI is involved. That shifts the security conversation from acceptable use language to evidence quality, incident readiness, and identity-aware monitoring. The practitioner conclusion is that governance artefacts must be demonstrable under examination, not merely documented.

Data lineage is emerging as the named concept that connects AI adoption to regulated identity control. In practice, lineage is the missing bridge between what a user or agent touched and what the firm can prove after the event. Without that bridge, AI governance remains aspirational. The practitioner conclusion is to make lineage visible across approved tools, personal accounts, and embedded AI features.

What this signals

AI adoption in regulated sectors is collapsing the gap between human identity controls and machine behaviour. Financial services teams should expect AI usage to keep expanding faster than policy enforcement unless they can bind data movement to identity, classification, and traceability. That makes lifecycle visibility for AI agents and endpoint workflows a practical governance priority, not a niche research topic.

Data lineage is the control concept that will matter most to examiners and incident responders. If a firm cannot reconstruct what entered an AI system, which identity sent it, and where the output went, it will struggle to defend compliance decisions. The operational signal is whether the programme can produce evidence quickly, not whether the policy language sounds complete.

The 98% deployment expectation from our research on AI agents suggests that financial services will face more delegated access paths, not fewer. Teams should prepare now by tightening oversight on approved tools, personal accounts, and embedded AI features before those paths become routine. The relevant control question is whether the organisation can prove every AI data exchange across regulatory and audit perspectives.

For practitioners

• Build a complete AI tool inventory Catalog standalone GenAI apps, embedded AI features, endpoint agents, and personal-account usage so security can see every data path that may involve regulated information.
• Classify regulated data before AI use Map nonpublic personal information, account data, and trading data to approved AI workflows so teams can block or flag submissions before they leave the controlled environment.
• Enforce identity-aware controls at data entry Apply AI-aware DLP and DSPM where data is entered into a tool, not only at the network boundary, because encrypted sessions hide the meaningful control point.
• Treat endpoint AI agents as delegated identities Assign scope, logging, review, and offboarding to AI agents running on endpoints so their actions are governed like any other privileged software actor.
• Prepare audit-ready evidence for GLBA and SEC inquiries Document which tools process regulated data, what controls apply, and how incidents are detected and reported so materiality and notification decisions can be defended quickly.

Key takeaways

• Financial services AI risk is primarily a governance and evidence problem, because regulated data can move into AI tools faster than teams can track it.
• The strongest warning signs are unmonitored personal accounts, endpoint AI agents, and embedded AI features that bypass network-centric controls.
• Programmes that can prove data lineage, identity attribution, and incident readiness will be better positioned for GLBA and SEC scrutiny.

Key terms

• Shadow AI: AI agents, copilots, or connected tools operating without full visibility or governance from security teams. Shadow AI becomes an identity problem when those systems authenticate with unmanaged tokens, service accounts, or OAuth apps that can reach production resources.
• Data Lineage: The record of how data moves across systems, applications, and workflows. In security operations, lineage shows where sensitive data propagates, which identities touch it, and how a compromise could spread across connected environments.
• Delegated Identity: Delegated identity is when one actor acts on behalf of another with explicit permission and bounded authority. In AI-assisted commerce, it requires clear consent, limited scope, and traceable records so the retailer can distinguish authorised delegation from unauthorised automation.
• Nonpublic information: Data that a regulated organisation is expected to protect from unnecessary exposure, including sensitive customer, financial, or operational records. In this context it defines the systems and workflows that require stronger access control, logging, and auditability.

What's in the full article

Cyberhaven's full article covers the operational detail this post intentionally leaves for the source:

• A breakdown of how its Data Lineage approach records data movement into and out of AI tools across sanctioned and unsanctioned environments.
• Specific examples of how AI Security visibility works for GenAI applications, AI agents, and embedded AI features.
• How DSPM and DLP are positioned to support audit-ready records for GLBA, SEC, and contractual obligations.
• The article’s own description of Linea AI and how it prioritises high-risk tools and user populations.

👉 Cyberhaven’s full article covers the AI data flow controls, regulatory mapping, and audit evidence details.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, agentic AI identity, and machine identity security. It helps practitioners connect identity controls to broader security and compliance programmes.