Chainguard Opens Anthropic-Powered Vulnerability Hunting

Chainguard is opening a limited beta for a service that lets organizations use Anthropic’s Claude Mythos 5.1 to hunt for exploitable vulnerabilities without getting direct access to the model. Called Harness, it builds an application from source, tests the running instance inside an isolated microVM, and delivers findings and proposed fixes reviewed by a Chainguard engineer.

Each reported exploit must reproduce in a fresh environment, then fail against the recommended fix, Chainguard says. That verification requirement is the service’s consequential claim. Customers receive a reviewed security deliverable, not an unrestricted model session.

Harness leads a broader October 14 announcement covering the execution environments, dependency decisions and validation steps around coding agents. Workspaces and Checks are also in beta. Four Model Context Protocol servers, collectively Chainguard MCP, are generally available.

The products address connected security questions: what agents can execute, which credentials they can use, what dependencies they select, how they find vulnerabilities and what evidence allows their changes to merge.

Harness Packages Vulnerability Hunting as a Managed Service

According to the Harness announcement, customers can provide source through a read-only Chainguard GitHub App connection or upload an archive. The service builds and launches the application, then lets Mythos 5.1 probe its behavior using source code, Git history, dependency source and build configuration.

Chainguard names logic flaws, injection and resource exhaustion among its targets. Unlike a static-only scan, the model can observe how the running application responds.

The company describes a verification sequence:

• Replay the exploit in a fresh microVM.
• Exclude findings that do not reproduce consistently.
• Confirm that the exploit succeeds against the original code and fails against the proposed fix.
• Have a named Chainguard engineer review and approve the report and fix.

This is a more useful acceptance criterion than an AI-generated warning alone. It does not establish that a patch preserves every required behavior or that the application contains no other vulnerabilities. Exploit verification and regression testing answer different questions.

Only Chainguard staff operate the model, the company says. Customers cannot instruct it or inspect raw output. Reports contain issue descriptions and confirmation steps, rather than a working attack.

For vulnerabilities in open-source dependencies, Chainguard says it handles coordinated disclosure with upstream maintainers and distributes the patched build through Chainguard Repository once the issue is resolved upstream. Disclosure and remediation are therefore part of the service.

Hunting and Development Have Different Isolation Rules

Harness and Workspaces have different containment requirements.

Harness has two phases. During setup, a separate model builds the application, retrieves dependencies and tooling, and gets it running. The microVM then suspends. During hunting, it resumes for Mythos 5.1 with no network egress and no credentials inside, according to Chainguard.

The agent loop remains outside the sandbox, where model tool calls and commands are logged. Chainguard also says it treats the code under examination as untrusted data to defend against prompt injection. This is a stated safeguard, not independent proof that malicious repository content cannot influence the system.

Chainguard Workspaces serves developers and coding agents that need ongoing access to tools, dependencies and selected services while changing code. Each Workspace runs in a dedicated microVM rather than a shared-kernel container.

Developers connect through chainctl develop, which synchronizes the working tree, including untracked files and uncommitted edits. Sessions can be snapshotted, resumed or split into parallel environments.

Because Workspaces needs that ongoing access, it cannot use Harness’s blanket hunting-phase network restriction. Chainguard describes a host-side proxy that injects short-lived credentials into approved requests. Tools expecting credential files receive encrypted stand-ins rather than reusable secrets.

Outbound restrictions are optional egress policies. Once enabled, the proxy blocks and logs requests to destinations outside the allowlist. Teams should not assume that every Workspace starts with their required network restrictions simply because the control is available.

Chainguard also describes a tamper-proof “flight recorder” covering commands, code changes, network calls and environment state. That could make an agent’s actions reconstructable, provided customers can access and retain the necessary records.

Checks Moves Validation Inside the Agent Loop

Chainguard Checks, also in beta, extends the same execution approach to CI. Developers and agents can invoke checks through the CLI, pre-commit hooks or an in-loop tool call, while the Chainguard GitHub App supports post-commit validation.

In the intended workflow, an agent edits code, calls the configured test suite, receives structured failure logs and tries again before opening a pull request. Inside Workspaces, the environment can suspend while Checks runs, then resume with the results.

Checks uses warm microVM snapshots with dependencies prepared from the lockfile. Chainguard says its runners apply declarative egress controls and host-side credential injection, keeping reusable credentials out of the execution environment.

The launch roundup also describes signed attestations binding the environment, verdict and commit SHA. These could let a merge gate verify that the relevant code passed in the expected environment without relying on the agent’s statement that tests succeeded.

Buyers should check the rollout details. The dedicated Checks post describes configurable merge gates in forward-looking terms, so teams need to establish which attestation-verification and redundant-CI-skipping capabilities are available in their beta.

A signed passing result remains evidence about the configured checks. It cannot compensate for missing tests or an incomplete security policy.

Four GA MCP Servers Inform Dependency Choices

The generally available component is Chainguard MCP, which provides four supported servers:

The servers use OAuth authentication and work with MCP-compatible clients, including Claude Code and Cursor. Chainguard says governance is enforced server-side, with response caps to constrain queries and context consumption.

These servers support dependency decisions; they do not sandbox execution. An agent can check whether an artifact exists or whether an organization permits it before generating a Dockerfile or choosing a dependency. Workspaces constrains execution, while Checks provides validation evidence.

These controls complement Harness’s vulnerability hunting. The announcement does not, however, establish a fully automatic handoff across all four products. Teams still need to define which tools agents must call and which results their workflows enforce.

What Security Teams Should Verify Before Buying

Teams can begin evaluating the products now, though important operational and commercial questions remain unanswered.

• Repository access: Harness supports read-only GitHub access or an archive. Confirm which repositories, history and dependency sources are collected, who can access them, and how deletion works. For Workspaces, review synchronization of untracked files so local material does not cross the boundary unintentionally.
• Isolation boundary: Ask separately about Harness setup, Harness hunting, Workspaces and Checks. They have different network requirements. Establish how private dependencies are fetched, where credential brokers run and which outbound destinations remain reachable.
• Audit logs: Confirm whether customers can export model tool calls, shell commands, network decisions and signed results. Retention periods, administrator access and integration with security monitoring matter as much as the existence of logs.
• Fix verification: Request the reproducibility criteria and patch-validation evidence. Establish whether regression tests accompany the exploit check, how environment differences are handled and who accepts the final change.
• Upstream disclosure: Clarify notification timelines, embargo handling and customer responsibilities when an affected dependency belongs to an external project. Chainguard’s promise to coordinate disclosure should translate into an agreed process.
• Pricing and capacity: The Checks post advertises a free 30-day trial, but the launch materials do not provide a complete paid-price schedule, Harness beta capacity, supported-stack matrix or data-retention terms. Ask how parallel environments, repeated hunts and suspended sessions are billed.
• Claude Marketplace procurement: Chainguard says Harness will be purchasable through Claude Marketplace and that customers may apply part of an existing Anthropic commitment. Confirm eligibility, eligible spend, contracting terms and whether marketplace purchasing is enabled for the specific beta engagement.

Teams can configure the generally available MCP servers or seek beta access to Harness, Workspaces and Checks. Marketplace procurement does not turn Harness into general availability or grant customers direct Mythos access.

The launch materials provide no independent measurements of detection performance, false positives or efficiency. The strongest evaluation would follow one representative application through dependency selection, constrained execution, recorded actions, verified findings and a checkable merge decision. That would test whether Chainguard’s connected stack produces usable security evidence beyond four separate product demonstrations.