Better detection can mean more work
AI in cybersecurity can increase costs in the short term, even when it delivers exactly what it promised. A tool that finds vulnerabilities faster does not guarantee that the organization can fix them faster. When detection outpaces remediation, the result is a longer backlog, more pressure on engineering teams, and requests for additional budget.
According to reporting by Nicole Kobie in ITPro, Bank of America brought in 1,000 additional cybersecurity contractors following a wave of remediation work prompted by vulnerabilities identified using Anthropic’s Claude Mythos. They joined roughly 3,000 existing security staff. For enterprise leaders, the important story is not just the model’s capabilities. It is the gap those capabilities exposed between finding a problem and resolving it.
- 1,000 additional security contractors, according to the report.
- 3,000 existing security staff.
- Approximately 33% additional staffing relative to the existing security workforce.
These figures describe an expansion in security staffing, not proof of declining productivity. The bank may now be seeing problems it could not previously detect. That is meaningful progress, but it requires an operating plan, not just a software license.
The model did not necessarily create the debt. It made it visible.
Legacy systems accumulate outdated software components, vendor dependencies, excessive permissions, and temporary workarounds that become permanent fixtures in production. Some issues are known; others escaped earlier assessments. A stronger detection tool can bring forward the moment when management has to address them.
That makes it essential to distinguish between the cost of using AI, the cost of remediating existing security debt, and the cost of changing how work gets done. Without that distinction, leaders may conclude that the model is too expensive when it has actually exposed an operational liability the business already carried.
The opposite mistake is equally dangerous. Not every finding is an exploitable vulnerability, and not every vulnerability warrants interrupting product development. Findings need validation, exposure assessment, and an evaluation of business impact. Alert volume alone is not a useful measure of success.
The value of AI in cybersecurity is not how many problems it surfaces. It is whether the organization can reduce risk without bringing operations to a halt.
This distinction matters especially where the same engineers handle product development, maintenance, and security fixes. Every urgent remediation competes with a customer commitment or a new feature release. That is a business decision, not simply a security team decision.
The bottleneck moves from detection to execution
After an alert arrives, someone must determine whether it is valid, identify the system owner, prepare a fix, test for regressions, secure change approval, and verify that the risk has actually decreased. Sensitive systems also require a rollback option.
If AI accelerates only the first stage, the rest of the process can stall. Before purchasing a tool, ask: What happens when it finds more problems than our teams can handle?
The difference between a detection-led deployment and a risk-reduction-led deployment becomes clear across five areas:
- Success metric: A detection-led deployment counts findings; a risk-reduction-led deployment measures risk that has been validated and reduced.
- Accountability: A detection-led deployment leaves responsibility with security; a risk-reduction-led deployment assigns a system owner and a remediation team.
- Budget: A detection-led deployment funds licensing and operation; a risk-reduction-led deployment also funds remediation, testing, and oversight.
- Automation: A detection-led deployment generates alerts; a risk-reduction-led deployment advances remediation through controlled workflows.
- Human oversight: A detection-led deployment requires review of every item; a risk-reduction-led deployment focuses human attention on exceptions and sensitive decisions.
This is not an argument against detection. It is an argument for connecting detection to ownership and execution capacity. A tool that does not fit into the remediation workflow risks becoming another system that generates work for everyone else.
Keep humans in the loop, not in every approval
Human judgment is critical in security workflows. But if every finding requires an analyst to read, copy, document, and route information manually, the organization will preserve its bottleneck and add another technology layer on top.
The better approach is risk-based oversight. An AI agent can gather context, suggest a system owner, draft a remediation ticket, and assemble supporting evidence. All of this must operate within permission boundaries, data protection requirements, and quality checks. Sensitive production changes and decisions to accept business risk should remain under clearly defined human authority.
- Validate the finding: Confirm that the vulnerability exists and is relevant to the environment rather than relying on model output alone.
- Prioritize by business exposure: Assess exploitability, data sensitivity, and the business processes that depend on the system.
- Advance remediation under controls: Use automation to gather context, route work, and prepare fixes within explicit permission boundaries.
- Escalate sensitive decisions: Refer significant changes, exceptions, and material uncertainty to a human decision-maker.
- Verify closure: Confirm that remediation reduced the risk, rather than merely closing a ticket.
This concentrates human oversight where it matters. The goal is to increase the volume of work a professional can manage without turning that person into a rubber stamp or giving an agent unrestricted autonomy.
Doing this requires an organizational foundation for managing agents: separate identities, least-privilege access, action logs, quality evaluation, and the ability to stop execution. It also requires AI literacy so employees know how to assess recommendations, recognize uncertainty, and report failures. Agent development and workforce training are complementary investments.
The CFO must separate promises from cash flow
According to the report, Bank of America’s leadership projected savings of $300 million in the year under discussion and $700 million in the following year. Those are forecasts, not realized savings. The report also described quarterly software remediation spending in the hundreds of millions of dollars. The entire amount should not automatically be attributed to a single model.
Enterprises should track the initial investment, ongoing operating costs, and measured benefits separately. Time saved does not necessarily translate into cash savings. Sometimes it allows a team to handle more work without reducing its budget. That is valuable, but it needs to be described accurately.
Useful measures include the time from a validated finding to remediation, expert hours per remediation, the rate at which issues are reopened, and the impact on system availability. Security measures must sit alongside throughput measures so that fast ticket closure does not come at the expense of quality.
The vendor finding the problem should not decide the remedy alone
The report also raises a commercial question: what happens when the technology vendor identifying problems also sells capabilities to address them? That does not prove an improper conflict of interest, but it does create an incentive that calls for clear procurement governance.
Even when recognizing Anthropic’s innovation and Claude’s capabilities, organizations should not substitute confidence in a brand for professional assessment. Decisions about which findings to fix, in what order, and at what cost must rest on evidence and the organization’s interests.
Separate diagnosis from purchasing decisions: Require the ability to export findings and supporting evidence, and independently assess their severity before expanding the engagement. Do not let one vendor determine both the scale of the problem and the budget for solving it.
In practice, a qualified internal team can provide that separation, with an independent external assessment for material cases. Those leading the work need deep AI knowledge, a relevant academic foundation, and experience operating systems and business processes. Familiarity with a new tool is not a substitute for those qualifications.
Before the next pilot, decide who will close the findings
The lesson from Bank of America is not to avoid AI. Quite the opposite: finding vulnerabilities earlier can be enormously valuable. The lesson is to plan for what happens when the tool succeeds.
Before scaling a deployment, make sure every finding has an owner, every risk level has a remediation path, and the budget covers testing and fixes, not just detection. Keep the pilot within a scope the organization can absorb, and evaluate the workflow from end to end.
If a pilot proves only that the model can find problems, it has not yet proved that the organization can extract value from it. That proof comes when risk falls, remediation times shorten, and the team can manage more work without losing control.