How AI-Assisted Exploits Are Reshaping Financial Services Security

NYDFS Section 2.5 highlights the need to monitor third-party code behavior. For financial-services CISOs, protecting customer data requires looking beyond known CVEs to what applications do at runtime.

A bank’s customer onboarding application needs to process identity documents. Its lending platform needs to read financial records. Its payment services need access to transaction systems. Those legitimate responsibilities give applications access to information and capabilities that attackers want.

The code performing that work includes open-source libraries and other third-party components. When a vulnerable or compromised library executes inside an application, the consequences depend on the permissions, data, and connections available to that process.

AI-assisted vulnerability research is increasing pressure on security strategies built around discovering and patching known weaknesses. For financial-services CISOs, the question extends beyond which libraries contain known vulnerabilities to what those libraries actually do with the access their applications give them.

What NYDFS Section 2.5 says about third-party code

On May 21, 2026, the New York State Department of Financial Services issued guidance to organizations and individuals it regulates on responding to a heightened cybersecurity threat environment.

“Enhance monitoring and validation of expected behavior(s) of third-party code, applications, permissions, and practices.”

Source: NYDFS guidance, Section 2.5

The guidance does not establish new legal requirements or prescribe a particular security product. It identifies measures regulated entities should consider based on their circumstances and risks.

For banks evaluating runtime application security, the practical connection is clear. An inventory establishes that a component exists. Monitoring and validation help establish whether its behavior remains consistent with its intended role.

A document parser may need to read an uploaded file. That does not automatically justify launching an operating-system command or opening an unrelated outbound connection.

An approved dependency is a starting point for trust. Its behavior in production is evidence of whether that trust still holds.

Why the issue deserves CISO attention

Recent research illustrates the scale of dependency exposure and the consequences of exploitation.

Sources: Black Duck 2026 OSSRA; Verizon 2026 DBIR; IBM 2026 breach-cost research.

These studies describe different populations. The open-source figure is not a measurement of bank codebases, and the breach-cost average is not a forecast for an individual institution. Together, they establish why dependency behavior belongs in a financial-services security discussion.

AI security includes attacks against ordinary applications

A bank does not need to deploy an AI agent to face AI-assisted exploitation.

In its accompanying May advisory, NYDFS warned that frontier AI models can increase the speed, scale, and effectiveness of vulnerability discovery and exploitation. It recommended reassessing vulnerability-management timelines and reviewing whether existing monitoring is sufficient for the heightened threat. NYDFS frontier AI advisory

For a CISO, this expands the AI security conversation. Protecting models, controlling employee AI use, and governing AI-generated code remain important. So does protecting conventional applications from attackers using AI to investigate their dependencies.

Public source code gives researchers and attackers an implementation they can study. AI can assist that analysis, but public availability alone does not make a library insecure. The risk emerges when a reachable weakness can be combined with capabilities available in a deployed environment.

A hypothetical example is a parsing flaw inside an internet-facing onboarding service. The practical impact depends on what an attacker can make the parser do, which credentials the service holds, and what customer information those credentials can reach. Prioritization improves when those relationships are visible.

Waiting for a CVE leaves a gap attackers can use

A CVE gives security teams a shared identifier for a disclosed vulnerability. It does not determine when that vulnerability becomes exploitable.

An attacker may discover a weakness before it is publicly documented. A malicious dependency may abuse legitimate functionality without needing a software vulnerability at all. In either case, a workflow that begins only when a known vulnerability appears can leave the application exposed.

For banks, that gap matters because the affected code may already execute inside applications with access to customer personally identifiable information, or PII, service credentials, and financial systems. AI-assisted research makes relying on the difficulty of discovering an exploit an increasingly fragile assumption.

Vulnerability management remains essential. But the security strategy must also address what happens before a finding reaches the dashboard: which code is executing, what capabilities it can reach, and whether dangerous behavior can be detected or stopped.

A CVE tells the bank what has been documented. Runtime evidence helps reveal what its applications are doing now.

How a trusted library can become a path to customer PII

Consider an illustrative bank onboarding workflow. A customer uploads a document. The application passes it to a trusted parsing library. The service also has access to a document store containing PII.

If an attacker exploits that library, the malicious activity may execute within the same process used for legitimate requests. Unless isolation or other controls intervene, the attacker may be able to abuse some of that process’s existing access. The process name can remain unchanged while its behavior becomes dangerous.

Illustrative attack flow

*Illustrative attack path, not a report of a specific bank incident. Outcomes depend on the vulnerability, application privileges, isolation, and deployed controls.

The privacy issue extends beyond a database permission. Sensitive information may pass through document processors, API clients, caches, and reporting services. Controls protecting stored data remain essential, but applications also need to process that data during legitimate operation.

Customer data can be exposed through software that already has permission to handle it. Runtime security must examine how that permission is used.

What expected library behavior looks like

Expected behavior must be defined in the context of the application. A network connection may be essential for an API client and unusual for a local file parser.

These are investigation hypotheses, not universal blocking rules. Some applications legitimately use subprocesses or dynamic destinations. Security and application owners need to establish expected behavior, test exceptions, and choose appropriate enforcement.

The distinction also separates visibility from prevention. Observing an unexpected action helps explain an incident. Preventing it requires a supported enforcement point and an appropriate policy or detection decision.

Runtime evidence strengthens the controls banks already use

Software composition analysis identifies dependencies and known vulnerabilities. Secure development practices reduce the likelihood of introducing weaknesses. WAFs inspect application traffic, while EDR and infrastructure controls help detect activity around processes, hosts, and containers.

Runtime application security adds context inside the executing application. A process-level alert may show that a service launched a command. Library and call-path evidence can help identify which component initiated it and how execution reached that action.

That context supports investigation and remediation. Security can connect suspicious activity to an affected service, while engineering can focus on the relevant component and execution path.

For systems handling PII, collecting that evidence also requires care. Teams should assess whether telemetry captures sensitive content, who can access it, and how long it is retained. More execution context should not create an unnecessary second repository of customer data.

Five questions financial-services CISOs should ask

Start with a customer-facing application that handles sensitive information and ask the team to demonstrate the answers.

1. Which third-party components execute in this application?

Connect the software inventory to the deployed service and observed execution. Lack of activity during an observation period does not prove a component can never run.

2. What sensitive capabilities are available to that code?

Map access to customer records, credentials, file systems, subprocess creation, and network destinations.

3. How do we recognize behavior outside the application’s intended role?

Establish expectations with application owners and exercise legitimate exceptions.

4. What happens when an exploit changes execution?

Demonstrate detection, investigation, and any configured prevention in a controlled test. Include paths that do not launch a shell.

5. Can we explain the outcome to engineering and incident response?

Preserve the relevant application, component, call path, attempted action, and control outcome.

The result should be a reproducible demonstration of coverage, with known limitations and an accountable owner.

How Raven connects runtime visibility to prevention

Raven’s Application Detection and Response capabilities observe execution at the library, function, and call-path level. That context helps security teams investigate abnormal execution inside trusted application processes and understand which code contributed to an observed action.

For a bank, this can support investigation of a suspicious action in an onboarding service, customer portal, or other application that handles sensitive information. The objective is to connect the event to the code responsible, rather than leaving responders with only a process name.

Raven Runtime Prevention is designed to prevent abnormal library behaviour associated with exploitation without requiring a signature for every underlying vulnerability. It complements patching by adding protection during execution while teams remediate affected software.

Applied to the behavioral focus of Section 2.5, the evaluation is concrete: can the team observe relevant component behavior, identify a dangerous deviation, and demonstrate the response in its own environment?

Coverage should be validated against the bank’s languages, frameworks, deployment models, and critical workflows. No individual product establishes regulatory compliance or removes the need for least privilege, secure development, and timely patching.

Customer trust depends on what trusted code does next

Banks must trust software to serve customers. That trust should be accompanied by evidence about how the software behaves when it runs, especially when it has access to identity records, financial information, or transaction systems.

The most useful next step is to select one critical application and test that visibility. Trace its third-party code to the sensitive capabilities it can reach. Then demonstrate what happens when execution deviates from the intended workflow.

That turns runtime security from a product category into an operational capability the CISO can evaluate.

Explore Raven in your environment and see how library-level visibility and runtime prevention can help protect applications that handle customer PII.