Introducing Chainguard Checks

Today, we are launching Chainguard Checks in Beta so developers and AI agents can test, fail, and fix code safely without waiting on slow CI. Checks turns CI into a fast pre-commit check, callable from anywhere. When used alongside Chainguard Workspaces, agents and developers can bring CI checks straight into their development loop, cutting wait times and speeding up delivery.

At Chainguard, we operate thousands of autonomous AI agents alongside our human engineering team to continuously build, patch, and maintain software at scale. As part of that, our agents run in loops: writing code, running tests, and refining fixes based on feedback. Pushing every single agent iteration through traditional GitHub Actions queues broke our workflows.

 Traditional CI failed in three ways:

• Wasted setup time and compute: Every pipeline run re-downloads the same packages and dependencies (e.g., apt-get, npm ci, go mod download) before a single test runs, burning unnecessary time and compute.

• Lost active reasoning context: Long feedback cycles interrupt the agent’s active reasoning context while waiting for results, making bug fixing slower, token-heavy, and far less efficient.

• Broad attack surface: Runners combine long-lived secrets with untrusted code execution. A single prompt-injected agent or a malicious install script can exfiltrate static keys from memory.

We couldn’t let slow CI queues bottleneck our development velocity, so we set out to fix it ourselves by making secure CI available as a tool call and shifting validation left. After we shared this approach with customers, they asked for access to it as well. Expanding into CI was the natural next step in securing the software supply chain, so we began working with design partners facing the same challenges, including Cuscal. As Brad McCoy, Senior Manager of Cloud Platforms, put it:

"Banks, fintechs, and corporates across Australia rely on Cuscal to move money safely. As we expand our digital payments infrastructure, giving engineers fast, secure workflows for AI adoption is a top priority. For CI, agents are exposing the flaws in traditional systems, from broken security models that give runners ambient access to secrets to inefficiencies like cold setups and delayed post-commit validation. We're excited to work hand-in-hand with Chainguard as an early design partner to shape the future of software development end-to-end." 

Let’s look under the hood at how Chainguard Checks works. 

Runtime architecture: from invocation to attestation

Transitioning your repository to Chainguard Checks requires two simple steps:

1. Download and install the Chainguard App.

2. Add a declarative configuration file (.chainguard/ci/workflow_name.yaml) to your repository root. You can write this manually or generate it automatically from your existing CI workflows by running chainctl develop migrate.

.chainguard/ci/workflow_name.yaml
environment:
  packages: [go~1.25, nodejs~22, postgres-17, docker]   # Chainguard OS, apko-built
  resources: {cpus: 8, memory: 16Gi}
warm:                        # snapshot point — everything below is pre-baked
  - go mod download
  - npm ci --prefix web
checks:
  lint: golangci-lint run ./...
  test: go test ./...
  e2e:  {run: make e2e, needs: [test]}
egress:
  allow: [proxy.golang.org, registry.npmjs.org]
  # everything else is denied. secrets: none — the proxy injects them in flight.

Once configured, Chainguard Checks handles execution through three distinct stages. 

Stage 1: Invocation and Context

A long-standing frustration with GitHub Actions is that you can’t use it locally. Testing changes means pushing a speculative commit, waiting on a remote queue, and repeating the cycle.

Checks gets rid of that blind spot. Developers and agents can trigger the exact production CI test suite via the chainctl CLI or a git pre-commit hook, catching broken code early.

When running inside a Chainguard Workspace, this feedback loop is seamless. An agent invokes Checks directly as an in-loop tool call. While tests execute, the Workspace automatically suspends to a snapshot while waiting for a verdict, burning zero compute while preserving the agent’s reasoning context, file tree, and warm build caches.

For post-commit validation, the Chainguard app integrates directly with your GitHub repos, ensuring every push is validated against the exact same standard before merge.

Regardless of whether invocation starts in a local shell, an agent sandbox, or a GitHub webhook, execution moves into Chainguard’s hardened runners.

Stage 2: Warm Execution and Isolation

Every workflow step spins up inside warm, isolated microVMs built from zero-CVE Chainguard packages, including FIPS-compliant toolchains. They come preloaded with only the necessary dependencies, and boot from warm snapshots, bypassing cold setup phases. Background reconcilers continuously rebuild these warm snapshot pools whenever your lockfile changes, ensuring the heavy installation cost is paid once per dependency in the background, rather than on every commit. 

These runners aren’t just fast to start. They are also safe enough to execute untrusted code within. Network traffic is governed independently by declarative egress policies defined in your configuration. If untrusted code or a compromised dependency attempts an unauthorized connection to an unapproved endpoint, the proxy automatically denies the request or destroys the microVM.

Additionally, the microVM runners hold no credentials on disk or in memory. When a workflow step requires authentication to an external service, an intercepting host-side proxy injects ephemeral credentials into outbound request headers in flight. For tools that expect a credential file on disk, the step receives a short-lived, encrypted stand-in instead, so even if it's exfiltrated, there's nothing usable to steal.

Stage 3: Verdict and Merge

Agents rarely get it right on the first go. They often need several iterations to get tests passing. Running that feedback loop against standard GitHub Actions queues produces a trail of broken commits that clogs the pipeline for the rest of the team.

When paired with Chainguard Workspaces, those broken iterations remain contained. The Workspace unfreezes instantly with failure logs loaded into memory, allowing the agent to course-correct on the next iteration without burning extra tokens to rebuild context. Only when there is a passing verdict does the agent exit its loop to open a pre-validated PR.

Teams will also be able to configure merge gates to verify these passing verdicts directly, allowing repositories to recognize validated code and safely skip redundant CI runs to cut compute costs.

Get started with Chainguard Checks today

Securing the software supply chain requires securing both the artifacts you deploy and the environment that builds them. We started by making container images and packages trustworthy by default.

With Chainguard Checks, we are extending that same model to the execution environment itself, turning slow, vulnerable CI pipelines into fast, secure pre-commit tool calls that give agents and developers immediate, in-context feedback, so every PR is born green.

If you’re curious about what fast, secure-by-default CI for developers and agents is like, Chainguard Checks is available today in beta. Get started free with a 30-day trial.

FAQ

Why microVMs instead of containers?

A container is just process isolation on a shared kernel. A microVM boots its own dedicated kernel for every build step. That hardware-level boundary prevents untrusted code or compromised dependencies from reaching outside their sandbox or inspecting adjacent workloads. 

What happens to my existing GitHub Actions workflows?

You can convert workflows by hand, or start from a draft that the chainctl checks migrate command writes for you.

How do we handle custom toolchains or specific system packages?

Environment specs are defined in .chainguard/ci/demo.yaml using declarative package lists built on Chainguard OS. Because images are assembled using apko, you declare the exact tools, language runtimes, and background services (like PostgreSQL or Redis) your build requires. The background warmer builds a content-addressed, reproducible microVM base image directly from source, giving you complete supply chain visibility. 

Does Chainguard Checks work with local pre-commit hooks or IDE tools?

Yes, you can integrate it into git pre-commit hooks, terminal scripts, or AI coding tools like Claude Code. It allows developers or coding agents to obtain identical merge gate verdicts before opening a pull request.

Do I need Chainguard Workspaces to use Checks?

No. Checks works on its own. Developers can run it from the chainctl CLI or a git pre-commit hook; pull requests can use it through the GitHub App; and agents can call CI via the MCP server or SDKs in tools like Claude Code. Every path runs the same checks in the same warm, isolated microVMs and returns the same signed verdict.

Workspaces add a tighter feedback loop for autonomous agents. When an agent inside a Workspace calls CI, the Workspace suspends to a snapshot, so it uses no compute while the checks run. It then resumes with structured failure logs injected straight into the live session, so the agent keeps its full context and file state while it fixes the problem. Checks give agents a verdict they can't fake, and Workspaces give them a safe place to act on it.

Can Chainguard Checks support my compliance requirements?

Checks are built with compliance in mind. Environments are built from Chainguard OS Packages, including FIPS packages, and every run executes in a hardware-isolated microVM that produces a signed attestation of what ran. If you have specific regulatory, data residency, or framework requirements, schedule time with our team [link] to discuss them.

How will Chainguard Checks be priced? 

Chainguard Checks is priced based on compute consumed. The underlying architecture is built specifically to minimize that consumption:

• Warm Snapshots: Dependencies are pre-baked into warm microVM snapshots, cutting billable setup time. 

• Attestation Gating: Downstream CI suites don't re-run passing code, saving expensive runner minutes in GitHub Actions or legacy CI.

All of these result in higher security, faster feedback, and lower total compute costs.