The 'Left' in Shift-Left has moved: coding agents, VibeGuard and the new AppSec perimeter

Chris Hughes's article starts from a thesis he has already developed in earlier pieces of his newsletter: AI has industrialized vulnerability discovery at a pace the institutional ecosystem of disclosure, triage and patching was never designed to absorb. But the focus of this text is not that 'Vulnpocalypse', but a second shift that, according to the author, gets far less attention: where code is written and how it moves, now that this code is increasingly produced by an agent running directly on the developer's workstation.

On the discovery side, the author cites several sources to show the scale of the phenomenon. Researcher Jerry Gamblin noted that 35,364 CVEs were published between January 1 and June 30, 49.5% more than in the same period of 2025 — that is, a new entry every 7.4 minutes, with an annual projection of between 71,314 and 72,008 CVEs versus 48,185 for all of 2025. FIRST, for its part, adjusted its mid-year forecast to around 66,000 CVEs, starting from a base of 59,427 in February, and argued that the real problem is no longer finding vulnerabilities but having the capacity to verify, coordinate and prioritize them at scale.

The text adds data from the AI labs themselves: Anthropic's Glasswing project says it has identified more than ten thousand high- or critical-severity vulnerabilities among its partners, and specifically 6,202 high- or critical-severity findings in open source projects, of which 90.6% of the 1,752 already assessed turned out to be true positives; some partners reported a more than tenfold increase in their bug detection rate, to the point of asking Anthropic to slow down disclosures. OpenAI's 'Patch the Planet' effort, focused on 55 critical open source projects, had found 1,535 issues at the time of writing, of which more than 1,000 remained unpatched. Researcher Casey Ellis sums it up in a line the author reproduces: AI has collapsed the cost of both finding and reporting vulnerabilities at once, with signal and noise multiplied tenfold and a widening gap between the two, so that 'the Vulnpocalypse was already here, it just wasn't evenly distributed'.

That pressure is already breaking the ecosystem's absorption capacity: cURL temporarily paused its bug bounty program after its confirmation rate fell from 15% to 5% in 2025 (later improved thanks to higher-quality AI-generated reports), and HackerOne's Internet Bug Bounty halted new submissions in March. NIST, for its part, recorded 263% growth in CVE submissions between 2020 and 2025 and moved the majority to a 'not scheduled for immediate enrichment' status. Even so, Gamblin qualifies that, although the volume curve has soared, actual exploitation remains flat, between 1% and 2%: only 85 of the CVEs published in the first half of 2026 (0.24%) had entered CISA's KEV catalog, leading FIRST to describe the situation as 'rain versus flood': the focus must shift away from raw volume and toward what actually needs remediating, although the author acknowledges that in practice it is hard to make that distinction when vulnerabilities arrive at machine speed.

The second part of the article addresses remediation, which still runs at human speed. Both Glasswing and Patch the Planet show that two thirds or more of the vulnerabilities detected, even verified ones, remain unpatched. Anthropic puts it this way: 'the relative ease of finding vulnerabilities versus the difficulty of fixing them poses a greater challenge for cybersecurity', a phrase the author reads as a frontier lab acknowledging the same bottleneck practitioners have suffered for years, now aggravated by AI. He also cites Cyentia data indicating that a typical organization can only remediate one in ten vulnerabilities per month — and that was before discovery was industrialized; and Verizon's DBIR 2026, which puts the median time to full patching at 43 days, with only 26% of KEV-listed vulnerabilities fully remediated, while exploitation became the most frequent initial vector, accounting for 31% of breaches.

According to the author, generating a patch has become cheaper thanks to AI just as detection did, but the real problem is knowing whether the patch is correct, whether it breaks something three services away, whether the finding was even exploitable in practice, and who is responsible when a fix written by an agent for code also written by an agent reaches production. He cites Niels Provos, who argues that remediation is the bottleneck AI has yet to solve, and agrees with nuances: it is, he says, a problem of AppSec program design rather than model capability.

The core of the article is the idea that classic 'shift left' was built for a world where a person wrote code in an IDE, opened a pull request and a pipeline ran scanners against that change. That world, the author argues, is ending, pointing to the near-universal adoption of AI coding tools reported by companies such as Google and Microsoft. The important detail is what those tools really are: a coding agent is a process running on the developer's machine, with access to the shell, package manager, environment variables and credentials, and to a set of MCP servers and 'skills' it can invoke, executing hundreds of actions per task that no human ever reads. These tools, he notes, can bypass the authenticated-path abstractions and hardened libraries a platform team may have built, and write code without going through them. Each of those actions is a point where a supply chain compromise, a secrets leak or a destructive command can occur, and all of it happens before there is any pull request to scan.

As evidence that attackers have already noticed, the article reviews several incidents. The 's1ngularity' case at Nx, in August 2025, distributed malicious packages that, according to the maintainers' own post-mortem, 'attempted to use local AI tools (such as Claude and Gemini)' on the victim's machine to search for sensitive information. The Shai-Hulud worm, which came later, identified other packages maintained by a compromised developer, injected itself into them and republished them, and in its second wave compromised some 700 npm packages via preinstall hooks. To this is added research presented at USENIX Security 2025 that found package hallucination rates of at least 5.2% in commercial models and 21.7% in open source models, across 205,474 unique hallucinated package names, opening the door for an agent to confidently install a package that does not exist and that an attacker rushes to register (what the community calls 'slopsquatting'). The author's conclusion is that the AppSec control point has to move to where code is actually created — that is, to the agent itself and the workstation where it runs — and that the dialogue between the coding agent and the security platform must become agent-to-agent, because there is no longer a human in the middle reading a scanner's output and deciding.

The article devotes its central section to a demo with Legit Security, a newsletter partner, through a conversation with its CTO and co-founder, Liav Caspi, and its CMO, Dave Howell. According to Caspi, their approach has three fronts: using AI to find and fix the bugs traditional static analysis misses; securing the SDLC and the agent ecosystem around it (the coding agents themselves, the MCP servers and the 'skills' developers use); and wrapping all of it in governance controls that let security teams set policy and see what is happening. The platform works, in Caspi's words, as a 'hive mind', a central AppSec brain that maintains a security context model of each application, broken down into components such as APIs and data models, and that runs a set of autonomous agents for detection, response, component inventory generation (SBOM), triage and remediation while developers keep working. Legit integrates with tools such as Cursor, Claude Code, Copilot and Codex, and exposes its security context through an MCP server so that a coding agent can ask whether a change is safe to deploy and get remediation guidance without a human having to relay scanner results to it.

The triage agent is the one that tackles the 'rain versus flood' problem: it weighs code context, static and runtime reachability, and the EPSS score, with authority to downgrade or close low-risk findings and escalate the ones that matter; per Legit's own description, it confirms findings, deduplicates them and ranks them by exploitability. The remediation agent, for its part, reads the code, plans a fix and delivers a context-aware correction in the form of a pull request. Today that agent opens the PR, monitors it and reacts to build failures or subsequent changes, but a human remains ultimately responsible for merging it, and the PR goes to the relevant code owner for review and approval. Asked where this is heading, Caspi anticipated that within a year many engineering teams will move to setups where agents merge code without human intervention, something the author thinks likely, though he warns that most security leaders are not ready for that shift, because it turns the 'human in the loop' requirement into a policy parameter rather than a baseline assumption.

The second half of the demo focuses on VibeGuard, Legit's endpoint protection agent for developer workstations. Its current version has stopped operating as an IDE extension and installs directly on the machine itself, so it can detect and wrap any running coding agent — currently Claude Code, Cursor and Copilot. According to Caspi, 'agentic security has to happen on the developer endpoint with the goal of empowering agents, not blocking them', a stance the author endorses by recalling that, in AppSec, any control that slows developers down ends up being bypassed or uninstalled.

In the live demo inside Claude Code, Caspi had the agent install Lodash, and VibeGuard intercepted the request, since it acts as a proxy for package manager installs (npm, in this case) and evaluates the library before it reaches the machine — precisely the kind of control that would have intercepted the attack pattern seen in the Nx and Shai-Hulud incidents, or in the hallucinated package research. Policies are granular: the organization can decide, operation by operation, whether to block, warn or require approval, and the developer sees the result directly inside the agent session, not in a ticket that arrives a week later, once the vulnerability or the malicious package has already reached production and a scanner picks it up.

The article highlights two other VibeGuard controls. The first, on secrets: developers constantly paste API keys and tokens into agent prompts, and VibeGuard intercepts that paste and instead offers a secure injection method, so the agent can use the credential without it being stored in the prompt history, in the transcript or in any file the agent decides to write to disk, while also preventing those secrets from being sent to third parties, such as the frontier labs themselves. The second is a command policy that can require fingerprint verification before running high-risk shell commands, with the cited example of 'gh repo delete' — exactly the kind of action an agent that has misread an instruction, or that has been manipulated via a prompt injection through a poisoned dependency, could simply execute. On governance, VibeGuard gives administrators a centralized view of all development workstations, including those not yet protected, along with event logs on prompts, blocked secret attempts and policy violations, which the author values as a significant step against the still-unsolved problem of knowing which developers are using which agents with which MCP servers.

The article closes with recommendations for AppSec leaders, regardless of vendor. First, the agent session, not the pull request, becomes the unit of work a security program needs to be able to see: if you cannot know what an agent installed, what it ran and what credentials it was handed, pipeline scanners are auditing the summary of a transaction that already happened; endpoint visibility over development agents should sit alongside EDR as a basic control, and the author argues that this responsibility should fall to AppSec rather than the endpoint team, because the policies are about code, dependencies and secrets. Second, 'human in the loop' must become an explicit design decision: define at which point (finding, fix, merge or deploy) human intervention is required, calibrate it by risk and revisit it as confidence in the tools grows, because teams that do not define it will end up defaulting to whatever the vendor ships, and those that impose 'always human' will be bypassed by developers wanting to clear their backlog. Third, Provos's argument about invariants gains weight the more code agents write: reachability, network egress control, the hardened libraries the agent is told to use and package allowlists enforced on the workstation itself are the controls that still work when neither the developer nor the reviewer is human, and guardrails placed at creation time are generally cheaper than triage after the fact.

The author concludes that the industry's direction looks clear to him: AI has made discovery cheap, remediation is being delegated to agents, and the code itself is increasingly written by a process no human directly supervises. He sees security facing a choice between positioning itself where the work now actually happens or continuing to add controls to a pipeline that sees an ever smaller slice of what matters, and argues that teams building control points on the developer endpoint and agent-to-agent interfaces within their AppSec platforms are, in his view, closer to where the industry is heading than those still tuning their pull request scanners. It is worth noting that this article includes a collaboration/demo with a vendor (Legit Security), which is also a commercial partner of the author's newsletter — a relevant fact when weighing the favorable tone toward that particular product.