Bank of America’s AI-Exposed Software Flaws

What Bank of America disclosed

Moynihan discussed the contractor figure in a CNBC interview after Bank of America reported its third-quarter results on 14 October 2026. He also addressed the work on the bank's earnings call. In his account, about 1,000 consultants joined during the second quarter, alongside roughly 3,000 existing employees working on the effort.

The contractors-vs-employees distinction matters, mostly because it affects how you picture the resourcing. Moynihan said the outside workers were consultants and were not counted in the bank's headcount. That doesn't mean the work was minor - it just tells you how the bank staffed it. If remediation has to move quickly, temporary specialist capacity can be added without turning it into permanent headcount.

Moynihan said the weaknesses were reportedly found in code used both by Bank of America and by external vendors. That's a familiar problem in big organisations: security boundaries don't end at your own repositories. Systems run on supplier software, integrations, and components maintained elsewhere. Fixing a vulnerability can mean coordinating across ownership, access, testing, release timing, and accountability - not just having a developer ship a patch.

Moynihan told analysts the quarter included "a couple hundred million dollars plus" in remediation costs. He said the spending covered two buckets: work associated with Mythos and repairs to anti-money-laundering controls. The company's account doesn't split out the Mythos portion, so you shouldn't treat the full amount as the cost of addressing AI-discovered vulnerabilities from Mythos alone. Moynihan also said he expected the Mythos-related share to decline as the extra workers came in.

This wasn't the only compliance issue in the news cycle. On 13 October, US Treasury penalties totalling more than $1.21 billion were announced in connection with the bank's anti-money-laundering controls. Federal regulators said Bank of America failed to report suspicious transactions worth $5 billion and didn't complete steps ordered in 2024. Those enforcement matters help explain why the bank had more than one remediation program underway at the same time - and why you shouldn't blur them together as if they were all driven by Mythos.

Bank of America's quarter also combined revenue growth with pressure on earnings and its share price. Revenue rose about 3% to nearly $30 billion, while adjusted earnings of $1.08 per share missed analyst forecasts. The stock closed almost 5% lower. Those figures don't prove AI-driven remediation caused the market reaction. But they do underline the basic point: big security and compliance work competes with everything else for money, people, and management attention, while investors keep grading day-to-day performance.

Why Mythos changes the remediation equation

Anthropic made Mythos available in April to a limited group of companies, banks, and government agencies through Project Glasswing. The stated goal was to help participating organisations find and patch software weaknesses before attackers could exploit them. The real shift isn't that AI removes the need for security professionals. It's that a capable model may surface weaknesses at a pace and scale that changes how much work an organisation has to triage and complete.

Even when the output is good, finding a flaw is only the start of remediation. A security team still has to validate that the finding is real, decide how severe it is, identify which systems and vendors are affected, pick a fix, test it, and deploy it without breaking production. In a bank, that often means dealing with multiple system owners, different risk levels, and a patch that may be quick in one place but slow elsewhere. Some changes can be shipped fast. Others require controlled releases, additional approvals, or coordination with a supplier.

That's why a model's output shouldn't be treated like a ready-to-execute work order. Automated discovery can generate useful leads, but teams have to verify what those leads mean in their specific architecture. A serious-sounding weakness might not even be reachable in a given deployment. A less dramatic issue can still be important if it sits in a widely used service. Priorities have to be based on real exposure, impact, exploitability, plus the cost and risk of changing the system.

On paper, finding more flaws faster looks like an obvious win. In practice, it can shift the bottleneck. If discovery speeds up but validation, ownership, and patching stay slow, you end up with a bigger queue - not a safer environment. Contractors can add execution capacity, as Bank of America's disclosure suggests, but hiring alone doesn't solve unclear ownership or slow vendor response.

There's also a dual-use angle. Tools that help defenders locate weaknesses can also appeal to people looking for ways into systems. Project Glasswing's limited-access setup was designed to keep the capability aimed at defensive work. It's not a substitute for solid security operations, but it does reflect the need to manage who gets access to powerful discovery tools and how findings are handled.

So if you're thinking about similar tools, the practical question isn't just, "Can this model find vulnerabilities?" It's, "Can we turn those findings into verified, prioritised fixes quickly enough - and safely enough - before risk builds up?" That takes a prepared response process, not just access to a model.

The business and governance lessons for other organisations

Bank of America's response isn't a staffing benchmark. The bank has its own size, technology footprint, regulatory obligations, supplier network, and risk exposure. A smaller organisation shouldn't assume it needs thousands of contractors. The more useful takeaway is to understand the full cost and capacity needed to move from discovery to remediation.

Start with an inventory. You need to know what systems and codebases are in scope, who owns them, which suppliers support them, and how changes actually reach production. If the inventory is incomplete, a technical finding turns into an investigation - teams first have to figure out whether the code is theirs, where it runs, and who can approve a fix. That drag can matter more than the time it took to identify the flaw.

Next, set up a triage path before a big batch of findings arrives. At minimum, teams need a consistent way to record and verify findings, assess severity and real-world exposure, assign an accountable owner, and set deadlines or escalation routes. The process has to distinguish between a confirmed vulnerability, a potential issue that needs investigation, and a finding that doesn't apply to the deployed environment. Without that separation, organisations either panic over noise or miss issues that actually need attention.

Vendor relationships have to be part of the same process, too. Contracts and operating procedures should spell out how findings are reported, how quickly suppliers must respond, what evidence they provide for a fix, and how the organisation verifies the change. Supplier assurance can help, but for high-impact systems it may not be enough on its own. Customers - and regulators - usually want to see evidence that remediation happened and that updated software was deployed in the places where it matters.

Staffing is a capacity decision, not a replacement for governance. Temporary specialists can clear a backlog, fill skills gaps, or work through a defined remediation window. But the organisation still needs internal owners who understand the systems and can make decisions after the contractors leave. Otherwise, the help may close tickets without improving the process that created the backlog.

A practical management view should track more than how many findings are "closed." Useful measures include:

• Time from discovery to validation and from validation to deployment.
• The number of high-priority findings without an accountable owner.
• Fixes delayed by a supplier, release window, or dependency.
• The share of remediations that pass verification after deployment.
• Repeat findings that point to a systemic engineering or configuration problem.

Those metrics keep the work legible to executives without turning security into a single headline number. They also show whether additional capacity would help - or whether the real blockage is process, ownership, or a vendor dependency.

Finally, keep budgets and reporting separate for distinct programmes. Bank of America's disclosed remediation cost covered both Mythos-related work and anti-money-laundering repairs. Combining them may be convenient for a quarterly conversation, but it makes it harder to understand what each programme is costing and whether it's actually moving the needle. For boards and finance teams, separate scopes, accountable leaders, milestones, and risk indicators produce a clearer picture.

What regulators and the wider banking sector are doing

Bank of America isn't the only large bank preparing for AI-enabled security work. In May, JPMorgan Chase chief executive Jamie Dimon said his bank had hundreds of people working on the issue full-time. That's not proof every bank needs the same model, but it does suggest large financial institutions are treating the work as an ongoing operational effort rather than a one-off experiment.

Regulatory responses are also taking shape. According to the source report, US regulators paused some cyber examinations in May to give the largest banks time to address findings associated with Mythos. That's described as a temporary adjustment in the reporting, not a general exemption from cyber obligations. Separately, US and European supervisors are asking banks about AI agents and cyber risks. The European Central Bank is seeking plans for AI-enabled threats by the end of October.

For banks, the regulatory question isn't just whether they use AI tools. Supervisors want to know whether institutions can identify and manage the risks those tools create - or reveal. That includes understanding which systems are affected, how vulnerabilities are prioritised, how third parties are involved, and how remediation is tested. A policy document without operational evidence won't answer those questions.

There's also a broader governance problem. AI-assisted testing can uncover weaknesses in software supplied by another company or built years earlier by a team that no longer exists. The organisation that runs that software may still carry the operational risk. That makes supplier oversight, incident communication, and clear remediation responsibilities more important. It also adds pressure for companies to keep software inventories and records up to date - things that often feel like "admin work" until a critical finding forces them to matter.

The sensible stance isn't to dismiss AI security tools as hype, or to assume a model's output gives a complete picture of risk. The capability can be useful, but its findings still need human review, controlled access, and a response process with real ownership. Regulators and executives should focus on whether the organisation can act on findings reliably - not simply whether it tried the latest model.