The Federal Reserve put machine-speed exploitation in its September 2026 report to Congress. It cites researchers who say frontier models can find previously unknown vulnerabilities, develop working exploits, and chain vulnerabilities together. For banks, the implication is immediate: the path from finding a flaw to assigning and verifying a fix has to move faster.
An attacker with an advanced model can research targets, test possible routes, recover from failed attempts, and adapt an exploit. During those same hours, a bank analyst may be searching an asset inventory or waiting for someone to accept a Jira ticket.
Thirty-day SLAs leave too much room
Vulnerability workflows inside banks pass findings through scanners, asset inventories, spreadsheets, ticketing platforms, change advisory boards, and approved release windows. Each handoff adds another person who needs the right context before work can start.
An analyst checks whether the asset is exposed and which business service depends on it. An application owner assesses the risk of taking the system offline. Infrastructure staff wait for approval, then schedule the patch around other production changes.
The Federal Reserve report describes chains of exploits that could run at machine speed. A remediation policy built around 30-day or 60-day clocks leaves too much room when a flaw is exposed and attackers can already use it.
A critical rating does not show the real risk
Bank security analysts can face many thousands of findings, many marked critical. A score and technical description arrive with each one; reachability and business impact, if known, often live elsewhere.
Two vulnerabilities with the same CVSS score can expose very different parts of the bank. One may affect an isolated test server. Another may provide access to payment operations or privileged credentials. Also, a medium-severity vulnerability can give an attacker the first step in a longer path.
The Fed specifically highlights models capable of chaining vulnerabilities. Analysts therefore have to look beyond a single score to reachability, asset criticality, current threat activity, existing controls, and business impact.
Analysts also have to revise priorities when a new exploit appears or someone connects an asset to a critical service. A spreadsheet sorted by severity does not capture those changes.
Orphaned remediation
Security analysts rarely control the systems they flag. They have to locate the owner who can change the code or patch the server, then provide enough evidence to justify the work.
The CMDB may list a former employee or “TBD” as the owner. An application can sit in one business unit’s cloud account while another group manages the underlying infrastructure. A service provider may control the patch, while an internal product owner controls the maintenance window.
Security staff often send scanner findings into Jira with little information about business impact or available controls. The recipient sees another vulnerability ticket competing with production incidents and planned releases. The ticket moves between groups while each one searches for the person with access.
AI-assisted vulnerability discovery can add to that volume and compress the time available for each decision. When ownership is unclear, the exposure can stay open while teams search for someone with authority to act.
Third-party exposure can reach several banks at once
Federal Reserve officials also focus on the financial sector’s dependence on cloud providers, fintech platforms, managed services, and shared technology. An attacker who compromises one provider may gain routes into several financial institutions.
When a provider controls the patch, the bank still has to decide how to protect its customers and operations in the meantime. Leaders need to know which business processes depend on the service, who owns them, which compensating controls are available, and what happens if they disconnect it.
Security analysts often pull those answers from contracts, architecture diagrams, ticket histories, internal messages, and calls with engineers. The scanner has the vulnerability record. It rarely has enough information to support the decision.
Closure requires evidence
The Fed calls for using available tools to identify and address vulnerabilities before attackers exploit them. Banks have invested heavily in the finding side. The fixing side can still stall on ownership searches, approvals, exceptions, and status spread across several platforms.
Application owners apply patches. Risk managers approve exceptions. Security analysts track deadlines, escalate stalled work, and check the environment after the change. Each person needs the reasoning behind the priority and a clear record of what has already happened.
A ticket may show “resolved” after a patch failed or an asset was missed. Security analysts need to test the environment again and confirm that the attacker’s route has disappeared.
Banks need to close the gap between finding and fixing
Vulnerability prioritization must account for reachability, business impact, current threat activity, and existing controls. Those conditions change. A new exploit can turn yesterday’s backlog item into today’s attack path, while a critical finding on an isolated server may rank lower after validation.
This is the gap Tonic’s agentic exposure management is built to close. It keeps priorities tied to the bank’s actual environment, identifies who can act, moves remediation through approvals and exceptions, and checks the environment after a change. That is continuous threat exposure management (CTEM) in practice: if the route remains open, the work is not finished.
Read the Federal Reserve’s September 2026 Cybersecurity and Financial System Resilience Report.
