When AI made flaws cheap to find, banks’ patch queues set the pace

The week

On April 7, 2026, Anthropic announced Claude Mythos Preview, a model it said could find and exploit serious vulnerabilities in widely used software, including every major operating system and web browser. It did not release the model generally. Access went through an initiative called Project Glasswing. It covered a small group of launch partners, among them large technology firms, the Linux Foundation and JPMorganChase, and more than 40 further organizations that maintain critical software. The company pledged up to $100 million in usage credits and $4 million for open-source security groups. The same day, Bloomberg later reported, citing people familiar with the matter, Treasury Secretary Scott Bessent and Federal Reserve Chair Jerome Powell met chief executives of systemically important U.S. banks at Treasury to make sure they understood the cyber risks such models posed. Neither agency gave public details.

The capability claims came from the developer and could not be independently tested by most of the industry, because most of the industry could not use the model. That asymmetry is the useful starting point. A handful of technology companies, open-source foundations and one large bank could run the model against code. Almost every other bank could not. For them, cheaper discovery would arrive second-hand: as advisories, vendor patches and open-source releases, in larger volume and at shorter notice than their processes were built for.

So the question for a bank was less what the model could find and more how quickly the bank could absorb fixes. That depends on who owns the code. We separate it into three parts, which together cover a bank’s software estate: code the bank writes, code it buys, and open-source code it uses but nobody inside owns.

Code the bank writes

For internally developed applications, the bank controls both the finding and the fix. Discovery tools of this class, where a bank can get them, shorten the first step. They do nothing for the second. A fix still needs a developer who understands the application, a test cycle and a release through change management. Most large banks govern releases through change advisory boards built for stability, with freeze windows around month-end and quarter-end.

Those processes were designed for a world where urgent security releases were occasional. If they become routine, the bank needs a defined fast lane. That means automated regression testing good enough that a change board will approve a security release in days. It means criteria for when a fix may bypass the normal calendar, and a named executive who can accept the residual risk of shipping quickly. It also means engineering capacity. Remediation competes with product work for the same developers, and the trade-off should be explicit in planning, not settled informally by whoever shouts loudest.

Triage matters most here, because this is where a bank can generate its own findings. A scanner that produces ten times as many credible results helps only if someone ranks them by exposure and business importance. That ranking depends on an application inventory that records what each system does, whether it faces the internet and who owns it.

Code the bank buys

Most of a bank’s exposure sits in software it licenses: core banking platforms, digital banking front ends, payment and card systems, network and security appliances. Here the bank finds little and fixes nothing. It waits for the vendor to patch, then deploys. The vendors with access to frontier discovery tools were mostly large technology firms. Many specialist banking software providers were not on any published list, so their customers had to ask.

The practical work is contractual and operational. Contracts for critical software should set patch timelines by severity, require notice when a vulnerability is confirmed, and oblige the vendor to say whether it uses AI-assisted code review. Operationally, the bank needs to know how long it takes to deploy a vendor patch to each critical platform, including the testing a core conversion team insists on. For community banks and credit unions running on a core processor or technology service provider, the deploy step belongs to the provider. The question moves into vendor oversight: what the provider’s patch cadence is, and how it would handle a surge.

Compensating controls fill the gap between disclosure and patch. Network segmentation, web application firewall rules and the ability to switch off a non-essential feature all buy time. They work only if they are pre-approved, because a surge is the wrong moment to design them.

Open-source code nobody owns

Open-source components sit inside both the bank’s own applications and the products it buys. The Linux Foundation’s place among the launch partners, and the donations to open-source security groups, signaled where many of the first findings were expected. When maintainers ship fixes, no vendor pushes them into a bank’s internal applications. Someone inside has to notice, upgrade the dependency, rebuild and redeploy.

This is the part of the estate most banks manage least well. A software bill of materials for each internal application tells the bank which components it uses. A named owner for each widely used component makes sure upgrades happen. For components embedded in vendor products, the bank depends on the vendor’s own dependency hygiene, which belongs in due diligence alongside the patch timelines above.

Across all three parts, the metric that matters is time from a credible critical finding to a deployed fix. It should be reported separately for internal, vendor and open-source code, because the levers differ. Scan coverage and raw vulnerability counts say little about that constraint. Examiners have long reviewed whether a vulnerability management program exists and whether critical findings are tracked. The more telling evidence is the age of open critical findings and the share closed within policy. Banks that already report those figures to a risk committee will find supervisory conversations easier.

With hindsight

The April meeting mattered for who convened it. Senior Treasury and Federal Reserve officials briefing bank chief executives about a specific model put AI-driven cyber risk on the financial stability agenda. Supervision moved in the following months, though not toward a single rule. In May, Bloomberg reported that the Federal Reserve and the OCC were pausing some cyber examinations of the largest banks to give them time to strengthen defenses against flaws exposed by the newest models. The OCC’s spring risk report warned that AI was lowering the barrier to entry for attackers. In July, the ECB wrote to the euro-area banks it supervises asking for plans to counter AI-enabled cyber threats by October 31, pointing them toward internet-facing systems, third-party software, open-source components and faster fixes. Euro-area banks had no access to the model.

The public record on attackers gaining comparable capability remains thin, and we would not overstate it. The access gap and the remediation constraint are both well documented, and the ECB’s request reads almost as a list of the three parts above.