AI-Discovered Vulnerabilities: What Bank of America's 4,000-Person Cleanup Means for Your Business

On 14 October, Bank of America's CEO Brian Moynihan said something on an earnings call that should make every business owner with a software product sit up. The bank has hired around 1,000 outside contractors to fix AI-discovered vulnerabilities in its software — security flaws found not by hackers, and not by its own security team, but by an AI model.

The model in question is Anthropic's Mythos, which the company released in April 2026 to a small group of banks, tech firms and government agencies under a programme called Project Glasswing. The idea was simple enough: let a powerful AI hunt for vulnerabilities in critical systems before criminals get the chance. It worked, arguably too well. The contractors join roughly 3,000 of the bank's own staff who were already working on the same cleanup, and Moynihan put the quarter's remediation costs at "a couple hundred million dollars plus".

So one of the largest banks in the world now has about 4,000 people fixing problems a machine found in code that had passed every conventional test for years. If that is happening at Bank of America, it is worth asking what the same kind of tool would find in your systems. Let's sink in!

What actually happened at Bank of America

The timeline is short and quite dramatic. Anthropic opened access to Mythos in April. By May, JPMorgan's Jamie Dimon was saying his bank had hundreds of people working full-time on AI-discovered flaws, and US regulators had paused some cyber examinations so the largest banks could concentrate on fixing what the model had found. In July, Moynihan warned that the model would significantly increase the workload for banks. By October, he was disclosing contractor numbers and costs to analysts.

The flaws were not exotic. Most of those found across the banking sector were rated low to moderate severity, and Moynihan noted they sat in code used both by the bank itself and by its outside vendors. That last detail matters. The problem was not one badly written internal system. It was ordinary code, spread across an ordinary mix of in-house software and third-party components, that had simply never been examined this thoroughly before.

Because the hired workers are consultants, they are "not in the headcount", as Moynihan put it. That is an accounting nicety. In practice, the bank's engineering capacity has grown by a third overnight just to deal with the backlog.

Why AI-discovered vulnerabilities are different

Companies have been running penetration tests and automated scanners for decades, so a reasonable question is what changed. The answer is the depth of analysis. Models like Mythos read and reason about code rather than just pattern-matching against known vulnerability signatures. In demonstrations, the model found and exploited weaknesses without needing a security expert at the keyboard.

The results elsewhere give a sense of scale. AI-driven analysis has turned up thousands of previously unknown vulnerabilities across major operating systems and browsers, including a flaw in OpenBSD that had gone undetected for 27 years and a bug in the FFmpeg video library that had survived five million automated test passes. These are codebases reviewed by some of the most capable engineers in the world. The bugs were always there. The machine just made them visible.

And that is the uncomfortable part for everyone else. The code running your online store, your booking system or your customer portal has almost certainly had far less scrutiny than OpenBSD. Whatever an AI reviewer would find there, it will find quickly.

Finding bugs fast does not mean fixing them fast

Here is the asymmetry that explains the 4,000 people. An AI model can produce findings in hours. Fixing those findings still runs at human speed: someone has to confirm the bug is real, work out a patch, test that the patch does not break anything, and push it through release processes that exist for good reasons. In the banking sector, remediation windows reportedly shrank from weeks to days as the findings piled up, simply because attackers may soon have access to similar tools.

This creates a queue problem rather than a discovery problem. Bank of America did not suddenly acquire more vulnerabilities in April; it acquired a very long, very well-documented list of the ones it already had. Every business that points a capable AI reviewer at its own code will go through a smaller version of the same moment: a sudden, uncomfortable jump in known issues, followed by months of prioritisation and patching.

The sensible response is to treat that list as a budgeting exercise. Not everything needs fixing at once. Flaws in internet-facing systems that handle money or personal data come first, internal tools with limited access come later, and some low-severity findings in isolated systems may reasonably wait.

Regulators are not waiting around

The other reason this story matters beyond banking is the speed of the official reaction. The US Treasury Secretary and the Federal Reserve Chair have already convened the chief executives of systemically important banks to discuss AI-driven cyber risk. The European Central Bank has told euro area banks it wants plans for AI-enabled threats in place by the end of October. Regulators on both sides of the Atlantic are now questioning banks directly about AI agents and cyber exposure.

Finance is always the first industry to feel this kind of pressure, but rarely the last. The pattern we saw with GDPR and with operational resilience rules is that expectations formed for banks drift outwards to their suppliers, then to anyone handling sensitive data. If your company sells software or services to regulated businesses, questions about AI-assisted security testing are likely to start appearing in vendor questionnaires sooner than you might think.

There is also an insurance angle. Once AI review becomes a cheap, standard practice, "we never checked" stops being a defensible position after an incident. Known-but-unpatched flaws are already a sore point in cyber insurance claims, and AI discovery will multiply the number of flaws that count as known.

What this means for businesses building digital products

Most companies reading this do not have 3,000 security staff, and will never need them. But a few practical lessons from the Bank of America story translate directly to businesses of any size that run websites, apps or custom software.

First, assume your code contains flaws that current testing has not caught. The FFmpeg example settles that argument: five million test passes missed a bug an AI found. Plan a proper review of your most critical systems rather than hoping your stack is special.

Second, start with an inventory. Moynihan's point about vendor code is the one most small businesses miss. Your real attack surface includes every plugin, library, integration and no-code platform you depend on, and you cannot patch what you have not listed. Ask your key vendors what they are doing about AI-assisted vulnerability discovery, and keep the answers on file.

Third, budget for remediation, not just for scanning. The expensive part at Bank of America was never running the model. If a review of your product turns up forty issues, you will need developer time to triage and fix them, and it is much cheaper to plan that capacity than to buy it in a panic. For many firms, a retained development partner who already knows the codebase is the practical middle ground between doing nothing and hiring a security team.

Getting outside help without creating new risk

There is a certain irony in the bank's solution: to fix flaws in code partly written by outside vendors, it hired a thousand outside contractors. For most businesses that will also be the realistic path, since specialist security and remediation skills are scarce and expensive to keep in-house.

Bringing in external developers to patch security issues does raise the stakes on vetting, though. Whoever does this work will see your weakest points in detail. Check that any partner has verifiable company history, named engineers, and references you can actually call, and give them access through proper accounts you can revoke rather than shared credentials. The recent wave of fraudulent remote developers has shown how cheaply identity can be faked, and security remediation is the last project where you want surprises about who is really doing the work.

It is also worth asking a prospective partner how they themselves use AI tools in review and testing. A team that already works with AI-assisted analysis will find and fix more, faster, than one that treats it as a novelty.

Final notes

The Bank of America story is not really about banking. It is an early look at what happens when AI makes software flaws visible faster than organisations can repair them: remediation backlogs, emergency hiring, regulator attention and a couple hundred million dollars in unplanned costs. Big banks got the first wave because they got the tool first.

The practical response for everyone else is calmer. Know what software you actually run, get your most critical systems reviewed properly, budget real developer time for fixes, and be careful about who you let into your code. The businesses that treat this as routine maintenance, started now, will experience the AI security era as a series of small bills instead of one very large one.

If you want help auditing or hardening your web product before the tools arrive at your door, Davydov Consulting's development team is happy to take a look.