For anyone who follows Resilient Cyber, you already know I’ve been heavily discussing and highlighting the impacts AI is having on the economics of finding vulnerabilities. From frontier labs, startups, and independent researchers all surfacing flaws in mature codebases at a surging rate that the institutional ecosystem of disclosure, triage and patching was never built to absorb.
I’ve written about the discovery side of this in detail, including in a recent piece titled “AppSec in the Age of Agents”, where I advocated for eliminating entire classes of vulnerabilities rather than grinding through them one ticket at a time, and worse, repeatedly remediating the same class of vulnerabilities over and over.
However, there is also a second shift underway that gets a lot less attention than the whole “Vulnpocalypse” narrative, and it is one I want to focus on in this piece.
That is the place where code gets written and how it’s moved. Now, it is often a coding agent running on a development endpoint, with a shell, package manager, credentials and the ability to take actions on its own, and most AppSec programs have no actual control point here at all.
At the same time, remediation is being handed to agents too, which raises questions around concepts such as Human-in-the-Loop (HITL), which I’ve already argued was largely a talking point, in a prior piece titled “The Human-in-the-Loop Illusion”. Having agents both creating code and remediating flaws brings good questions, such as what HITL means when both the code and fix are machine-generated.
In this article, I will walk through both sides of the shift, what they mean for AppSec practitioners and leaders and also use a recent demo and walkthrough I had with the team at Legit Security, a Resilient Cyber partner, as a practical example of how one team is building for this.
So, let’s unpack this often overlooked topic at the intersection of AI and AppSec.
Discovery Went Industrial
The first thing we need to acknowledge is that vulnerability discovery has went industrial in the first half of 2026. Per Vulnerability Research Jerry Gamblin’s mid-year check in, 35,364 CVE’s were published between January 1st and June 30th, a 49.5% increase over the first half of 2025, or one new CVE entry every 7.4 minutes.
His full year projection at the time landed between 71,314 and 72,008, up from 48,185 in all of 2025. FIRST provided their own forecast, which had to be adjusted midyear, showing roughly 66,000 potential CVE’s for the year, from a February baseline of 59,427. In that update, they argued finding isn’t the problem at all.
“The challenge for defenders is no longer the discovery of vulnerabilities; it’s the capacity to verify, coordinate and prioritize them at scale.
Then we have the impact of the frontier labs on the space.
Anthropic’s Project Glasswing update put some large figures in the mix. Across it’s partners, it had surfaced more than ten thousand high or critical severity vulnerabilities, and in open source projects specifically it had identified 6,202 high or critical findings, of which 90.6% of the 1,752 assessed so far proved to be valid true positives. Some partners told Anthropic their rate of finding bugs had increased by more than 10x, and a few asked the lab to slow down disclosures due to needing additional time to design patches.
There’s also OpenAI’s Patch the Planet effort, involve 55 critical open source codebases, which at the time of my writing have found 1,535 issues, with over 1,000 still awaiting a patch.
When I spoke to longtime industry leader Casey Ellis on my show in July, he framed it as AI having collapsed the cost of finding and reporting vulnerabilities at the same time, with signal and noise both up roughly 10x, and the delta between the two getting wider.
His line that I often reference is:
”The Vulnpocalypse was already here, it just sort wasn’t evenly distributed”.
This reframes the situation as an acceleration of a backlog problem we already had rather than a new novel threat. We are seeing the intake side of the ecosystem buckle in real-time, with cURL temporarily pausing its bug bounty program after its confirmation rate fell from roughly 15% to 5% in 2025 (which has now improved due to a surge of high quality AI-driven reporting), and HackerOne’s Internet Bug Bounty pausing new submissions in March. NIST reported that CVE submissions grew from 263% between 2020-2025, and moved most CVE’s to a “not scheduled for immediate enrichment” tier.
With all of that said, Jerry made a point on my show that while the volume curve may have gone vertical, exploitation has not, and still sits flat at around 1-2%. At the time of our conversation only 85 of the CVE’s published in the first half of 2026, or 0.24%, hand landed in CISA’s KEV catalog as of his write-up, which is why FIRST framed it as a “rain versus flood””, meaning practitioners need to not worry about raw finding counts and instead identify what they truly need to remediate.
However, it is admittedly tough for a security program to determine that when new vulnerabilities are hitting them at machine-speed, so they are likely to drown either way, given they need to try and do their best to filter the surge.
The Fix Side is Still Human Speed
So, we’ve discussed the AI-driven machine speed impact on discovery but what about remediation?
That’s the uncomfortable piece of the discussion for most. If you look at both Anthropic’s Glasswing, and OpenAI’s Patch the Planet, both efforts highlight 2/3 or more of the vulnerabilities are yet to have been patched, even when verified as true vulnerabilities. Anthropic spoke to this directly, stating:
”The relative ease of finding vulnerabilities compared with the difficulty of fixing them amounts to a major challenge for cybersecurity”.
That’s essentially a frontier lab describing the exact bottleneck we as practitioners have already lived with for years, but being exacerbated by AI. Cyentia’s research found the typical organization has the capacity to remediate 1/10 vulnerabilities in a given month, and that was before discovery got industrialized.
The 2026 Verizon DBIR, which I covered earlier this year, found the median time to fully patch has grown to 43 days and that only 26% of KEV-listed vulnerabilities were fully remediated, while exploitation became the top initial vector at 31% of breaches.
The labs know this, which is why every discovery capability now ships with a fix capability bolted next to it. That said, those fixes still require a human review before anything merges.
Niels Provos made the case on the show in June that remediation is the bottleneck AI hasn’t cracked, and I largely agree, with one caveat. Generating a patch has become cheap as AI has collapsed the economics there as well.
The hard part is knowing whether the patch is correct, whether it breaks something three services away, whether the finding was even reachable, and who is accountable when an agent-written fix for agent-written code ships to production, and that is an AppSec program design problem more than a model capability problem, and one we haven’t fully figured out yet as an industry.
The Left Moved
This is where I think much of the industry is still looking in the wrong place.
“Shift left” was built for a world where a human typed code into an IDE, opened a pull request, and a pipeline ran scanners against it. That world is ending as industry tech leaders such as Google and Microsoft highlight nearly universal adoption of AI coding tools, with big surges in AI-generated and accepted code.
The important detail is what those tools are. A coding agent is a process on a developer workstation with a shell, a package manager, access to environment variables and credentials, and a set of MCP servers and skills it can call, and it takes hundreds of actions per task that no human reads.
AI coding tools quietly route around your security, ignoring the authenticated route abstractions and hardened libraries your platform team built and writing raw code instead. Every one of those actions is a place where a supply chain compromise, a leaked secret, or a destructive command can happen, and it happens before there is a pull request for anything to scan.
The evidence that attackers noticed is already here. The Nx “s1ngularity” incident in August 2025 shipped malicious packages that, per the maintainers’ own postmortem, “attempted to use local AI tools (like Claude and Gemini)” on the victim’s workstation to hunt for sensitive information.
The Shai-Hulud worm that followed identified other packages maintained by a compromised developer, injected itself, and republished them, with its second wave compromising roughly 700 npm packages using preinstall hooks. Layer on top of that the USENIX Security 2025 research finding package hallucination rates of at least 5.2% for commercial models and 21.7% for open source models, across 205,474 unique hallucinated package names, and you have an agent that will confidently npm install something that doesn’t exist yet and an adversary happy to register it.
The control point for AppSec has to move to where the code is actually created, which now means the agent itself and the workstation it runs on. Additionally, the loop between the coding agent and the security platform has to become agent-to-agent, because there is no human in the middle to read a scanner output and decide.
A Walkthrough with Legit Security
That is the frame I brought into a demo and walkthrough with Legit Security’s CTO and Co-Founder Liav Caspi and CMO Dave Howell recently. Their architecture maps closely onto the two shifts above.
Liav described their approach as three-pronged.
First, use AI to find and fix the flaws traditional static analysis misses.
Second, secure the SDLC and the agent ecosystem around it, meaning the coding agents, MCP servers, and skills developers are actually using.
Third, wrap governance controls around all of it so security teams can set policy and see what is happening.
The platform itself functions as what Liav called a “hive mind,” a central brain for AppSec that maintains a security context model of each application, broken down into components such as APIs and data models, and runs a set of autonomous agents against it while developers keep working.
Those agents cover detection, response, bill of materials generation, triage, and remediation. On the integration side, Legit plugs into the leading AI coding tools, such as Cursor, Claude Code, Copilot, and Codex, and exposes its security context through an MCP server so that a coding agent can trigger checks, ask whether a change is safe to deploy, and get remediation guidance without a human relaying scanner results.
That agent-to-agent interface is the piece I think most teams will be building or buying within the year as we move towards a more AI-native approach to securing the SDLC.
The triage agent is where Jerry’s rain-versus-flood problem gets handled. It runs in the background against findings, weighing code context, static and runtime reachability, and EPSS, and it has the authority to demote or close low-risk items and elevate the ones that matter.
Legit’s own description is that it confirms findings, deduplicates them, and ranks them by exploitability, and the remediation agent then reads the code, plans a fix, and delivers a context-aware fix that matches your code, delivered as a pull request.
Among the more useful parts of the conversation was the discussion of autonomy. Today, the remediation agent opens the pull request, watches it, and reacts to build failures or subsequent code changes, but a human still owns the final merge.
The PR goes to the right code owner, who reviews and approves it. When I asked Liav where this goes, he projected that within a year many engineering teams will move to pipelines where agents merge code without human intervention.
I think he is right, and I think most security leaders are not ready for that transition quite yet, because it means the human-in-the-loop requirement becomes a policy setting rather than an assumption. Deciding which findings, which repositories, and which fix types an agent may merge on its own is going to be one of the more consequential AppSec decisions of the next couple of years and it will look different across organizations, business units and risk tolerances.
VibeGuard at the Endpoint
The second half of the demo is where the “left moved” argument got tangible in their product.
VibeGuard is Legit’s endpoint protection agent for developer workstations, and the current release moved it off the IDE extension model and onto the endpoint itself so it can discover and wrap whichever coding agents are running, currently Claude Code, Cursor, and Copilot.
Liav’s description in the launch was that
“Agentic security needs to happen at the developer endpoint with the goal of enhancing agents rather than blocking”
That’s the right posture to take, since as we painfully know in AppSec, anything that slows developers down gets worked around or uninstalled entirely.
Liav ran the demo live inside Claude Code. He had the agent install Lodash, and VibeGuard intercepted the request, because it proxies package manager installs (npm in this case) and evaluates the library before it lands on the machine. The point is to catch malicious dependencies and hallucinated packages at the moment an agent reaches for them, which is the exact gap the s1ngularity and Shai-Hulud incidents and the slopsquatting research point at.
Policy is granular, so an organization can choose per operation whether to block, warn, or require an approval, and the developer sees the outcome inline in the agent session rather than in a ticket a week later, once the vulnerabilities or malicious packages already enter production and later get picked up by a scanner.
Two other controls struck me as practical, the first of which addresses secrets. Developers paste API keys and tokens into agent prompts constantly, and VibeGuard intercepts that paste and instead offers a secure injection method, so the agent can use the credential without the credential living in the prompt history, the transcript, or whatever the agent decides to write to disk. This also prevents the secrets being sent externally to third-parties, such as frontier labs.
The second is command policy, where administrators can require a fingerprint verification before high-risk bash commands execute, and the example Liav used was gh repo delete, which is exactly the sort of thing an agent operating on a misunderstood instruction, or a prompt injected via a poisoned dependency, would happily run.
On the governance side, VibeGuard gives administrators a centralized view of every developer endpoint, including the ones that are not yet protected, along with event logs covering prompts, secret block attempts, and policy violations.
For anyone who has tried to answer “which of our developers are running which agents with which MCP servers,” that inventory alone is a meaningful step, and it connects back to the critical point that asset inventory remains the unsolved problem underneath all of this.
What This Asks of Security Leaders
I want to close the analysis with what I think this means for the people running AppSec programs, independent of any one vendor.
The first shift is that the agent session, rather than the PR, is the unit of work your program needs visibility into. If you cannot see what an agent installed, what it ran, and what it was given, your pipeline scanners are auditing a summary of a transaction that already happened. Endpoint visibility for developer agents is going to sit alongside EDR as a baseline control or with the innovative agent-centric purpose built security solutions, and I’d argue it belongs to AppSec rather than the endpoint team, since the policies are about code, dependencies, and secrets.
The second is that human-in-the-loop needs to be an explicit design decision. Agents are already opening pull requests for agent-written code. The decision about where a human is required, at the finding, at the fix, at the merge, or at the deploy, should be explicit and tiered by risk, and it should be revisited as your confidence in the tooling grows. Teams that never define it will default to whatever their vendor shipped, and teams that define it as “always” will get routed around by developers who want their backlog gone.
The third is that Niels’s argument about invariants matters even more as agents write more of the code. Reachability, egress control, hardened libraries the agent is told to use, and package allow-lists enforced at the workstation are the controls that hold when neither the developer nor the reviewer is a human. Guardrails at the point of creation are generally cheaper than downstream triage.
Closing Thoughts
This is far from an exhaustive discussion, but the direction is clear enough.
AI has made discovery cheap, remediation is being handed to agents next, and the code itself is increasingly written by a process no human watches. Security once again has a choice between meeting the work where it now happens or bolting controls onto a pipeline that sees a shrinking share of what matters.
It remains to be seen which direction we take as an industry, but the teams building control points at the developer endpoint and agent-to-agent interfaces into their AppSec platforms are, in my view, closer to where this is headed than the ones still tuning their pull request scanners.
The control point gap has a companion problem: in most small software vendors nobody owns it. ENISA's answer so far is guidance rather than tooling. It publishes a Secure by Design and Default Playbook written for SMEs and an SME Cyber Resilience Maturity Assessment Model, both free, both assuming a human reads the output and acts on it. For a firm with no AppSec function that moves the practical question away from which scanner to buy and towards who reviews what an agent committed on a workstation, which is the control point this piece says is missing.
The human-in-the-loop point is the one I'd take to a board. Most teams have it set to "always" on paper and something looser in practice, and nobody has written down which findings or which repos an agent may merge on its own. Making that explicit and tiered by risk is a governance decision before it's a tooling one, and defaulting to whatever the vendor shipped is going to age badly.