On October 14, 2026, Bank of America CEO Brian Moynihan told CNBC that the bank had brought in about 1,000 external contractors in the second quarter to help fix software vulnerabilities exposed by advanced AI models, including Anthropic's Claude Mythos. They are still working alongside roughly 3,000 people already assigned to the area. The bank's reported costs also cover anti-money-laundering work, so they cannot be pinned on AI-related remediation alone.
The scale still tells a story. If a bank with deep security resources needs that many people to keep up, a startup with a handful of engineers needs a plan before the same problem reaches its codebase.
The short answer
AI is making vulnerabilities cheaper to find, so the limit on security is no longer finding them. It is how fast your team can decide which ones matter, fix them safely and prove the fix worked. Leaders should measure the time from discovery to verified fix, and shorten it with continuous scanning, risk-based priorities, reviewed fixes and clear human accountability.
Key takeaways
- Advanced AI models can find, and in research settings exploit, software flaws at a scale manual review cannot match.
- Finding more issues does not make you safer. Fixing the important ones quickly does.
- Prioritize by real risk: exposure, ease of exploitation, impact and evidence of attack, not severity labels alone.
- AI-written fixes still need tests, review and an accountable human.
- Track time to fix and overdue critical findings, not the number of findings.
What happened, and what Anthropic has said
Anthropic's published research describes Claude Mythos Preview as able to find and exploit previously unknown vulnerabilities in major operating systems and web browsers when directed to by a user. It reports bugs that had gone unnoticed for 16 and 27 years, and says the model's abilities came from broader gains in coding and reasoning rather than specific security training. Anthropic does not plan to make the model generally available. It runs Project Glasswing instead, which gives limited access to critical software maintainers and industry partners so they can fix problems first.
In an update on expanding the program, Anthropic said partners had found more than 10,000 high- or critical-severity flaws. These are counts of findings in controlled work. They do not mean every flaw is exploitable, or that every company faces the same exposure.
Why finding is no longer the hard part
Discovery is speeding up. Remediation is not. CISA's June 2026 note on prioritizing security updates cites the Verizon 2026 Data Breach Investigations Report: only 26% of vulnerabilities on CISA's Known Exploited Vulnerabilities list were fully fixed in 2025, down from 38% the year before, and the median time to full resolution rose to 43 days.
That is the gap this series has described before. The earlier post on the security remediation gap shows where fixes stall between detection and deployment. What is new is the pressure: more findings arrive faster, and the same people have to fix them.
What an AI-era attacker changes
The same skills that help a defender understand code can help an attacker. Anthropic says it is limiting Mythos Preview for that reason and expects similar capabilities to spread over time.
That does not mean every AI system can break into every application. Real attacks still depend on configuration, access and the type of flaw. The safer assumption is that a flaw nobody has noticed for years is not a flaw nobody will notice. Plan to fix important issues sooner than you used to.
A six-step plan for leaders
- Scan continuously. Run checks on every pull request and on a schedule, so new code and new dependencies are covered as they appear instead of at an annual review.
- Prioritize by real risk. CISA's framework weighs four things: public exposure, whether exploitation can be fully automated, whether it gives full control of the system, and evidence of real-world exploitation. Fix the findings that score high on those first. Defer the rest on a written schedule.
- Generate fixes, not just reports. For common classes such as dependency upgrades and standard code flaws, use tooling that proposes a change with an explanation and tests, so developers start from a draft instead of a blank page.
- Validate before merging. Run your test suite and security checks on every proposed fix. A fix that breaks the product or leaves the flaw open is worse than no fix.
- Keep humans accountable. A person reviews and approves security-sensitive changes. Give automated agents narrow permissions and an audit trail, especially near production systems and secrets.
- Measure fixing, not finding. Track the median and 90th-percentile time to fix critical findings, how many are overdue, how often the same weakness returns and what share of fixes pass verification. The backlog business case shows how to size these with your own data.
What a startup can do this month
- Turn on dependency and secret scanning in your code host if it is not already on.
- Export your open critical and high findings and sort them by exposure and exploitability.
- Pick one owner for remediation and agree a target time to fix critical findings.
- Sample your last ten fixes to learn the real hours per fix.
- Run a short trial of automated fixing on two or three repositories, scored against that baseline. The 30-day pilot guide gives a scorecard you can copy.
If you would like to try this on your own repositories with our team, see our design partner program. Orbis AppSec scans repositories and opens fix pull requests for your engineers to review.
Questions to ask your team this week
- How many critical findings are open, and how old is the oldest?
- How long did our last critical fix take from discovery to deploy?
- Who is accountable when a critical finding is overdue?
- Which fixes could be proposed automatically, and who reviews them?
- Could we show a customer or auditor proof that a specific flaw was fixed?
Frequently asked questions
Does Claude Mythos mean my software is vulnerable? No. Mythos Preview is a restricted research model, and findings in Anthropic's work do not apply to every codebase. It does show that discovery is getting faster, so waiting for problems to surface on their own is a weaker plan than before.
Do small companies need to worry about AI-driven attacks? Treat the risk as real, in proportion to what you hold. If your software handles customer data or payments, an unfixed critical flaw is a business risk at any size. Start with the basics above and measure how long fixes take.
Do we need to hire contractors like Bank of America? Probably not. A bank's scale and regulatory load are very different from a startup's. A better first step is shortening your own time to fix, with automation for repetitive fixes and clear ownership for the rest.
Can AI fix vulnerabilities safely? It can draft fixes for many common flaws, but a draft is not proof. Require tests, security checks and human review before merging, and measure how many proposed fixes pass.
What should we measure? Time from discovery to verified fix for critical findings, the number overdue, repeat findings and the share of fixes that pass verification.
Sources and further reading
- CNBC, October 14, 2026: Bank of America and Anthropic Mythos
- Anthropic: Assessing Claude Mythos Preview's cybersecurity capabilities
- Anthropic: Expanding Project Glasswing
- CISA: Patch Smarter, Not Harder
This guide is general guidance. Use AI security tools only in environments you are authorized to test, and validate AI-generated findings and fixes before deploying them.