AI Starts Auditing Code: Chainguard Harness Launches, First Public Trophy a Real vLLM Bug

Today (October 14, 2026), open source supply chain security company Chainguard launched a new product: Chainguard Harness. In one sentence — it turns "hunting vulnerabilities with frontier AI models" from research that only a handful of institutions could do into a purchasable, process-driven service: the model hunts for vulnerabilities in your running application inside an isolated microVM, delivers only reproducible findings, and attaches a ready-to-merge fix to each one.

One clarification to avoid confusion: this Harness is not Harness.io, the DevOps company (which acquired Augment Code last week, as we covered). Same name, completely different lane.

A day before the launch, Chainguard had already shown Harness's "first public trophy": a genuine vulnerability it dug out of the open source LLM inference engine vLLM — an issue that had sat in the issue tracker for four and a half months labeled an "ordinary bug" and rated Low by the project. An AI hunter took a single run to promote it from "ordinary bug" to security incident.

How Harness works

According to Chainguard's official press release (published in the early hours of October 14, US Eastern time), Harness is a "model + scaffolding" pipeline with six steps:

Step 1: code intake. Customers connect repositories through Chainguard's GitHub App (Guardener, read-only access) or upload a source archive. Note the read-only part — Harness never takes write permission to begin with.

Step 2: build. A separate "setup model" builds the application exactly as it ships, fetches dependencies and tooling, gets it running — then suspends the whole microVM. Build and hunt are two models in two phases, a deliberate isolation design.

Step 3: the hunt. Once the microVM resumes, Anthropic's Claude Mythos 5.1 probes the running application. It works from the source code, git history, dependency sources, and build configuration while watching how the live application actually responds, looking for logic flaws, injection vulnerabilities, and resource exhaustion. The containment for this phase is strict: the microVM has no network egress and no credentials inside; the model gets only a shell and Chainguard-built packages. The agent loop runs outside the sandbox, so every tool call and command the model issues is fully logged. And one crucial line: the code under test is treated as untrusted data — guarding against prompt injection hidden in the analyzed code hijacking the hunter model itself.

Step 4: reproduction. This is the most valuable engineering decision in the whole product: every finding is replayed in a fresh, isolated environment until it reproduces every time; anything that doesn't reproduce never makes it into the report. Fix verification is equally strict — the exploit must succeed against the customer's current code and fail against the fix.

Step 5: human review. A named Chainguard engineer reviews and approves every report and every fix before delivery.

Step 6: delivery. The report includes an executive summary, each finding's severity and impact, reproduction steps, and a fix written for the customer's codebase. When a flaw is found in an open source dependency rather than customer code, Chainguard hands it to upstream maintainers through its coordinated disclosure process Athena, and ships patched builds through Chainguard Repository once resolved.

Commercially, Harness is currently beta-waitlist only, and at launch Chainguard engineers operate it on customers' behalf. One detail worth noting: it is listed on the Claude Marketplace by Anthropic — Anthropic handles invoicing, so enterprise customers can buy it against their existing Anthropic commitment. Security capability is starting to ride on the model vendor's bill.

First public trophy: cross-request contamination in vLLM

On October 13, Chainguard published a research post disclosing Harness's first public finding: the vLLM allowed_token_ids vulnerability.

allowed_token_ids is a request parameter that restricts which tokens the model may generate for a given request. The mechanism is clean: in a shared restriction table, when a request finished and its row was reassigned to a later request, the old restriction was never cleared — so the new request inherited the previous client's token restrictions. On a shared inference engine, that means one client could manipulate another client's request output.

The timeline deserves a close look:

On May 28, 2026, the issue entered vLLM's public issue tracker as an "ordinary bug" and sat there for four and a half months. On September 23, Chainguard reported its security impact to the vLLM maintainers; the fix shipped with v0.31.0 on October 2; the advisory GHSA-6cxc-2vcg-w5qc was published on October 6; and on October 13 Chainguard published the research post presenting it as Harness's first public finding. vLLM rated the issue Low severity, and the fix itself was a one-line change plus a related fix. Chainguard says it reproduced the exploit three out of three times.

The run statistics are telling too: a single run lasted 10 hours and 48 minutes, processed about 115 million tokens, and probed 30 parts of the project; 37 candidate findings reproduced on a clean host, and 13 held up to engineering review. Chainguard also disclosed that Harness has been run against more than 65 projects, validating over 680 findings, with a number of them in coordinated disclosure.

Takeaway 1: the offense-defense balance is tilting — "shipping fast" is no longer a moat

The press release's headline is blunt: "Finding vulnerabilities is no longer the hard part." CEO Dan Lorenc is quoted saying that every time they've pointed Harness at code, it found serious, exploitable vulnerabilities — including in software "that's been scanned many times over" and code running critical infrastructure.

Take at least half of that as marketing: Chainguard chose the samples, "every time" carries obvious selection bias, and the denominator behind those 680+ findings (how many runs, how many projects came back empty) was never published. But the direction is real — AI vulnerability discovery is being productized. What used to require frontier-model access plus a dedicated engineering team is now packaged as a "connect your GitHub repo, wait for the report" service.

For vibe coders, that signal matters more than the product itself: the code your AI generates in a day can be audited by someone else's AI in a day. "Shipping fast" was the biggest dividend of AI coding; once auditing is AI-driven too, that dividend depreciates fast, and the new dividing line becomes "can it survive an AI audit." Before your next side project goes live, ask yourself: if a Harness ran against my repo overnight, would I be nervous?

Takeaway 2: from static scanning to runtime hunting is a generational leap

The biggest problem with traditional security scanners isn't missed bugs — it's false positives. They analyze static code and flag piles of issues that "may never be reachable," and engineers burn hours triaging noise. Harness's answer is crude but effective: only test the running application, and nothing unreproducible enters the report.

That "reproducible or it doesn't ship" standard, plus two-way verification — the exploit must succeed on the original code and fail on the fix — is the most valuable engineering design in the whole announcement. It turns a security report from a "risk list" into "actionable fixes." Anthropic's head of commercial cyber Daniela Hurtado put it well in the release: models can surface vulnerabilities that went unnoticed for years, but "how that capability is deployed matters as much as the capability itself" — isolation, reproduction, and human review are three layers of scaffolding, and none is optional.

But a bucket of cold water: Harness is currently operated entirely by Chainguard engineers, regular developers are still on the waitlist, and pricing hasn't been announced. In the short term it's an enterprise procurement item, not an indie developer tool. Its real significance is the pricing and delivery model — once "AI vulnerability hunting" has a priced beta product, the track has moved from papers and internal tools into commercial competition.

Takeaway 3: the most stinging lesson of the vLLM case — "Low" is being redefined

The most interesting part of this case isn't the bug itself but the string of misjudgments: four and a half months in the issue tracker with nobody seeing it as a security issue; an official Low rating; a one-line fix.

From an AI hunter's perspective, those three misjudgments are one blind spot: human reviewers estimate risk by "size of the code change," while AI estimates risk by "exploitability." A one-line fix corresponds to "tenants on a shared inference engine can manipulate each other's output" — on a multi-tenant inference service, that is anything but Low. It's a reminder to every open source maintainer: severity rating systems may need a patch for the "AI perspective," and those legacy issues sitting in trackers labeled "ordinary bugs" deserve a rescan with fresh eyes.

The flip side is maintainer burden. We recently covered Anthropic's OSS Scanner (AI scanning open source projects for free, emailing reports with no human review). Put the two together and the trend is clear: a wave of AI-generated vulnerability reports is coming, and open source maintainers will soon need to learn how to "take reports from AI" — telling true findings from hallucinations and from known issues in new clothes. Harness's "reproduce or don't report" at least offers a methodological filter.

Takeaway 4: two ecosystem signals worth writing down

Signal one: security products are riding the model vendors' distribution. Harness listing on the Claude Marketplace and billing through Anthropic means the enterprise procurement path for AI security is changing — no longer a separate security budget and vendor negotiation, but "an add-on to the model bill." Claude is evolving from "model vendor" into "AI services distribution platform," with security among the first categories listed. No immediate impact on indie developers, but a clear channel signal for anyone building security tooling.

Signal two: "agent = model + scaffolding" made concrete. We previously covered the Stack Overflow discussion (the model is maybe ten percent; everything else is scaffolding), and Harness is that sentence in product form: Claude Mythos 5.1 is just the "eyes" — the actual product is the microVM isolation, the suspend/resume two-phase design, the full audit logging outside the sandbox, the replay-verification pipeline, and human review. Vibe coders building AI apps can copy this thinking directly — in your agent product, the model provides the intelligence and the scaffolding provides the trust, and it's usually the latter that customers pay for.

Three action items for vibe coders

First, prefer hardened artifacts for dependencies. Harness's launch motion is telling: run against the open source artifacts Chainguard itself distributes first, then ship patched builds via Chainguard Repository. The logic is blunt — you can't stop AI hunters from scanning open source code, but you can choose to be on the side that gets patched builds first. Put "security update velocity" into your base-image and dependency selection criteria.

Second, give AI-written code a runtime security perspective. The biggest security debt in vibe coding isn't "ugly code" — it's "nobody thought about what it looks like when it runs," which is exactly what Harness tests. Add security constraints to your prompts (input validation, least privilege, no secrets in code), and run at least a baseline scan before launch. Those habits cost far less than one incident.

Third, watch disclosure channels like Athena for "AI found a vuln in your dependency." A library your project depends on could be named by some AI hunter tomorrow. Actually turn on automated dependency updates — npm audit, Dependabot, whatever your stack uses — instead of installing them and ignoring them. In the age of AI hunting, your dependency "patch lag" is your exposure window.

One honest closing note: Harness is not an indie developer's toy today — it's an enterprise beta product. But it announces one thing: the second half of AI coding is AI auditing code. And the first to be audited by AI will always be the open source projects running on shared infrastructure. vLLM is just the first to be named publicly. It won't be the last.