Chainguard sells frontier-model flaw hunting as a service its own staff run for customers

A developer juggling a dozen agents can end up clicking "allow" all day, SiliconANGLE wrote in its account of Chainguard's launch ^[17]. Those agents run lengthy migrations under the permissions of whoever started them, close enough to touch cloud keys and production systems ^[17]. Approval prompts work only as long as the agent sticks to the rules ^[17]. A review process built on those prompts assumes every click was a decision.

Workspaces is Chainguard's answer. The real credentials stay outside the remote machine, and a tool that needs one on disk gets an encrypted, short-lived stand-in ^[13]. Teams can switch on egress policies that block any connection they have not approved ^[13]. Dan Lorenc, Chainguard's co-founder and chief executive, described the result as an isolated machine "with nothing in it worth stealing" ^[14].

Checks targets the backlog that builds up when agents push code at a rate continuous integration systems were never built to handle ^[15]. Every run begins from a warm snapshot, dependencies preinstalled ^[15]. While an agent in a workspace is being tested, its session is paused; it resumes afterward with any failure logs loaded directly into its context ^[15].

Harness is where the pitch and the delivery part. The pitch is frontier-model vulnerability hunting for organizations that want it without direct access to the models ^[8]. Chainguard says access to those models has so far been limited mostly to a handful of defensive security groups, and that static scanners miss logic flaws that only surface once an application is running ^[8]. The delivery, for now, is Chainguard's own staff running Harness for customers ^[10], with an engineer signing off on every report and fix before it reaches the customer ^[9]. In the view of Daniela Hurtado, head of commercial cyber at Anthropic, the way a model like Mythos 5.1 is deployed "matters as much as the capability itself" ^[5].

Lorenc made the broad claim for the service: "Every time we've pointed Harness at code, it has found serious, exploitable vulnerabilities, including in software that's been scanned many times over and code that runs critical infrastructure," he said ^[20]. The quote does not say how many codebases that covers.

The reporting rule is narrower. According to Chainguard, nothing is reported until it reproduces in a fresh environment on every replay ^[9], so a flaw that reproduces on some replays and not others does not meet the bar ^[19]. We think that trades coverage for trust. The customer gets no unconfirmed findings to triage, and a clean report means only that nothing reproduced every time.

Harness looks for flaws in software a company already ships, and the two agent products work earlier, while the agents are still writing code ^[18]. We would put isolation ahead of hunting for any team whose agents can reach keys, because Workspaces changes what an agent can touch and Harness reports after the fact. The cost of that order is that the logic flaws static scanners miss ^[8] stay unexamined until Harness work is scheduled. To place a given team, answer two things: whether its agents can reach cloud keys or production under a developer's permissions, and whether the code it ships has cleared static scanners and still worries you.

- Agents reach keys, shipped code worries you: Workspaces first, Harness second. - Agents reach keys, shipped code does not worry you: Workspaces and Checks. - Agents cannot reach keys, shipped code worries you: Harness. - Neither: Libraries, and only if the team writes Go or .NET, the newest audience for Chainguard's vetted open-source dependencies ^[7].