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:
| Server | Information it supplies |
|---|---|
cg-oci | Whether an OCI image tag or digest exists |
cg-apk | Exact Chainguard package equivalents by name |
cg-versions | Whether a version is current or end of life |
cg-api | Organization policy, entitlements and attestation data |
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.
Sources
- October 14 announcementchainguard.dev
- Harness announcementchainguard.dev
- Chainguard Workspaceschainguard.dev
- Chainguard Checkschainguard.dev
