AI can now find and weaponize software vulnerabilities faster than most teams can patch them. Beating it takes an AI that can see the whole system before it touches anything.

The game has changed

AI-driven threats like Anthropic’s “Claude Mythos” can discover software vulnerabilities and chain complex exploits at machine speed, making traditional enterprise remediation timelines obsolete. To keep pace, organizations have a new option on the table: combining portfolio-wide visibility and architectural dependency mapping with frontier AI models. This would give AI agents the context they need to automate fixes without breaking the systems they change.

The exposure is bigger than the triage list

Most vulnerability programs triage by severity: fix critical and high now, file medium and low away for later. That logic assumes an attacker looks at each vulnerability on its own. A model that can reason across an entire codebase can connect information across files, functions, and components to identify vulnerabilities that local analysis would miss. Vulnerability chaining – combining several individually low-severity issues into one working exploit – isn't new; security researchers have written about it for years. What's new is a system that can do this at the scale of a whole application, faster than a human red team working through the same list.

A portfolio that's closed every critical and high CVE and left the mediums for later can still hand an attacker exactly what it needs, one overlooked finding at a time. Severity should still sequence the work, paired with evidence of active exploitation (CISA's Known Exploited Vulnerabilities catalog) and how much the application matters to the business. It can't be the whole test anymore.

Open-source leaves open doors

A lot of what's running in your production environment was written by strangers. It's open source, pulled in as a dependency of a dependency, sitting inside applications whose original engineers have long since forgotten it's there. When a new CVE hits a popular component, it doesn't show up in one application. It shows up in every application that includes it.

A component scanned clean six months ago can carry a disclosed vulnerability today, whether or not anyone has touched that repository since. Across a portfolio of a few thousand applications, finding every place a component shows up becomes its own research project before anyone's written a line of the fix.

AI alone doesn't close the gap

Stanford AI Laboratory

Does AI Actually Boost
Developer Productivity?

Download the Study

AI coding assistants write code fast. The real question is how much of that speed survives contact with a large, live, already-running application instead of a fresh repository. Stanford's Software Engineering Productivity Research Group measured this directly, combining git-history analysis with cross-sectional data across more than 600 companies and 100,000-plus engineers. Across 136 teams at 27 companies, AI coding assistants lifted output by a mean of 31% on simple, greenfield work, and by 7% on complex, brownfield work – which is most of what enterprise remediation is (“Does AI Actually Boost Developer Productivity?”, Stanford AI Laboratory). The same lab's modeling, labeled illustrative, shows why: as codebase size climbs from a thousand lines to ten million, the productivity gain available from current AI capability drops from around 58% to roughly 5%. The bigger and older the system, the less AI has to offer it, and remediation work happens entirely in bigger, older systems.

Some of that is a context window problem, not just a complexity one, and handing a model more source code doesn't solve it. A benchmark of long-context performance in frontier models found accuracy falling by about half once context length passed 32,000 tokens (Modarressi et al., 2025). Past that point, more code in the prompt adds noise, not signal. The fix is a shorter, more relevant context window, not a bigger one.

Developer perception doesn't settle this either. A controlled study of experienced open-source developers found they believed AI assistants had sped them up by about 20%. Measured, the actual result was a 20% slowdown (Becker, Rush, Barnes & Rein, 2025). That's why the numbers in this piece are measured results, not developer sentiment.

Two maps make all the difference

Closing known vulnerabilities at AI speed requires two different maps. One maps exposure across the portfolio, showing where vulnerable components appear and which applications should be addressed first. The other maps the dependencies inside each application, giving an AI agent the context it needs to plan the fix with visibility into downstream impacts.

CAST Highlight keeps a live inventory at the portfolio level: which applications carry which open-source components, which of those components have known vulnerabilities, what the upgrade paths look like, and which applications the business would actually notice going down. That turns a spreadsheet of CVEs into an ordered list of decisions.

CAST Imaging works one level in. It reads the source code itself and builds a deterministic map of the application – every function, procedure, and method; every data object, down to the schema, table, field, and property; every framework involved; and every relationship connecting all of it, inside each layer of the stack, across layers, and across applications. What comes out is an actual call graph, current and specific to the code as it stands today. It gives an AI agent visibility into what a change will touch before the change is made. That’s the blast radius and knowing it ahead of time is the difference between a fix that’s actually safe and one that simply hasn’t broken anything yet.

CAST doesn’t write the fix. It gives whoever – or whatever – writes it the system context to do it correctly the first time.

Field results

A global property data and analytics company – the kind that turns real estate, lending, and insurance records into decision tools – got a mandate from its CISO and CIO: remediate every SCA vulnerability across thousands of repositories, in six months. Manual patching was running six to ten hours per application, which meant the six-month target was unrealistic before the work even started.

The team piloted first, on 13 applications, before committing to the approach. CAST Highlight flagged which applications carried SCA vulnerabilities. CAST Imaging mapped each vulnerability’s blast radius at the application level. Claude Sonnet used that context through MCP to generate the fixes, which were then applied, tested, and validated automatically.

The pilot found 170 vulnerabilities and fixed 161 of them – 94.7% overall, and 100% of the ones with an available fix, with zero errors. Total effort across the 13 applications dropped from 10–16 days to about 6.5 hours, a 92% reduction. The customer’s Head of Engineering put it simply: “With CAST, we’ve cut per-application remediation from 6-10 hours to 30 minutes.” (Read the full case study)

It’s not a one-off. Marsh got a 93% first-time success rate on AI-generated fixes accepted straight into production, at 78% less effort than doing it by hand, using the same kind of architectural intelligence for technical debt work (Marsh case study). A Fortune 500 industrial manufacturer running a custom .NET application saw accuracy jump 40 percentage points and token spend drop 85% on a technical debt and risk-reduction engagement.

Applying it in your enterprise

The pattern is the same across each of these cases, and none of it requires building something new:

• An SCA or vulnerability-finding product (CAST Highlight, or whatever’s already in your stack) identifies what’s vulnerable and where, and stays current as new disclosures land against components you’ve already scanned.
• Findings route into a coding agent tasked with proposing the fix – an internal AI assistant, a CI/CD-integrated agent, or an equivalent setup.
• That same agent pulls architectural context – dependencies, data flows, call graphs, blast radius – from CAST Imaging through the CAST Imaging MCP Server, instead of reconstructing the system from scratch on every request.
• The agent proposes the change; your existing test, review, and deployment pipeline verifies it before anything ships – and a follow-up scan confirms the fixed build actually reached production, since a clean repository alone doesn’t prove that.

Taking the first steps

First, decide the policy, since the pipeline handles the work: what risk level auto-merges without a human, who approves exceptions, and who's accountable if something shipped needs to come back out.

Then, it is critical to rapidly establish the baseline: the inventory components, current exposure, and set regular scans and vulnerability notifications.

Pilot one remediation path: pick a supported upgrade, assemble the context, and test the full handoff – human or agent – end to end.

Measure what actually moved: time to triage, time to deployed fix, overdue high-priority findings, rework, token use. Expand automation where the numbers earn it.

This doesn't catch a zero-day, and it doesn't replace the rest of a security program – that's a different part of the budget. What it solves is narrower and more tractable: vulnerabilities that are already public, already sitting in your dependency tree, that somebody could be exploiting today. That doesn't require trading speed for safety. It requires context.

Conclusion

Mythos raised a real question: can AI find and exploit problems faster than an organization can fix them? Right now, in some cases, yes. But there is the other side of coin: armed with architectural context AI can close 94.7% of a portfolio's known exposure, at a fraction of the cost of doing it by hand. The real contest isn’t AI versus people. It's AI with the right context versus AI without it – and only one of those is worth trusting with the fix.