Chainguard Workspaces and Checks Put AI Coding Agents Behind a Security Gate

Chainguard launched two beta products that place AI coding agents inside isolated environments, then require verified checks before their work reaches a pull request. Chainguard Workspaces and Checks target a conflict that developer teams can no longer ignore. Agents need broad freedom to work, but that freedom creates a larger security boundary.

Workspaces provides remote development sessions built on dedicated microVMs, which are small virtual machines designed to isolate each workload. Checks runs continuous integration tasks in separate microVMs and returns structured results to the agent. Together, the products create a controlled loop for writing, testing, and revising code.

The launch pressures a familiar development model. Tools such as Claude Code, GitHub Codespaces, and local agent sandboxes already isolate parts of the coding workflow. Traditional CI systems separately validate commits after developers push them. Chainguard wants to connect those stages and make verified testing part of the agent's working loop.

That approach sounds sensible, but the important claim remains unproven at scale. Chainguard must show that stronger isolation and signed results can improve trust without replacing CI delays with policy, configuration, or platform friction.

Chainguard Workspaces and Checks Move CI Inside the Agent Loop

The launch combines an isolated execution environment with a verification service that can govern when an agent considers its task complete.

Chainguard announced Workspaces and Checks at its Assemble London event. Both products entered beta, according to the initial product coverage. They address different stages of the same workflow.

A Workspace is a remote microVM where a developer or coding agent can edit files, install packages, run commands, and maintain active processes. The developer starts a session through Chainguard's command-line tooling and synchronizes a local working tree into the remote environment.

That synchronization can include uncommitted changes and untracked files. Execution moves away from the developer's laptop, but the familiar editor and Git workflow can remain local. This separation matters because a local agent can otherwise reach credentials, browser sessions, background services, and files unrelated to its assignment.

The session can continue after the developer disconnects. Chainguard says it snapshots and parks the environment after an idle period, preserving its disk, memory, processes, and caches. The developer can later resume the session instead of rebuilding the environment.

Workspaces also supports parallel experiments. A developer can start fresh sessions from the same repository and ask several agents to explore different implementations. Each agent receives its own microVM rather than sharing a writable environment with the others.

Checks handles the verification side. A repository defines its required commands in a .chainguard/ci.yaml file or related configuration directory. The service then runs individual checks in fresh microVMs rather than trusting results produced inside the longer-lived Workspace.

That distinction is essential. A Workspace gives an agent a productive environment, but its state changes throughout a task. A clean check provides a stronger test of whether the resulting code works outside that accumulated state.

Developers can invoke Checks through a command line, a pre-commit hook, or a GitHub integration. Agents can call it through an SDK or Model Context Protocol server. MCP is a protocol that lets an AI agent invoke external tools through defined interfaces.

When a check fails, the Workspace can resume with structured failure logs. The agent can revise its change without reconstructing the session or downloading every dependency again. The launch details describe warm snapshots built from the project's lockfile, which records pinned dependencies.

A successful run produces a signed attestation linked to the environment, result, and commit. An attestation is cryptographic evidence describing what ran and what outcome it produced. Chainguard proposes using that evidence at a merge gate instead of blindly trusting the agent's statement.

The event is therefore larger than a remote development environment launch. Chainguard is trying to define a completion rule for autonomous coding. An agent finishes only after an independent system validates the exact change it wants to submit.

The Pressure Falls on Local Agents and Conventional CI

Chainguard is challenging the gap between where agents create code and where organizations decide whether that code is acceptable.

Coding agents need permissions that ordinary chat assistants never required. They inspect repositories, change multiple files, execute shell commands, install dependencies, and communicate with external services. Their usefulness rises when they can complete those actions without constant approval.

The same autonomy expands their potential blast radius. A misleading repository instruction can influence an agent before a developer reviews its behavior. A compromised package can execute during installation. An unnecessary network permission can turn a local secret into data that an attacker can extract.

OWASP describes excessive agency as risk created by excessive functionality, permissions, or autonomy. Coding agents can embody all three conditions. They receive capable tools, operate across complex repositories, and repeat actions with limited supervision.

Local permission prompts provide an incomplete answer. Prompts interrupt the workflow, while repeated approvals encourage users to stop evaluating each request carefully. Anthropic reported that users approved roughly 93 percent of Claude Code permission prompts before it introduced additional automated controls.

That pattern helps explain the shift toward enforced boundaries. Anthropic's own containment approach emphasizes limiting what an agent can reach instead of trying to predict every unsafe action. Chainguard follows the same broad principle, although it packages isolation with external CI verification.

Conventional CI faces a different problem. It usually operates after a developer or agent pushes a change. Every attempt can enter a queue, rebuild an environment, fetch dependencies, and return logs through a separate interface.

That sequence works when humans make relatively few deliberate changes. It becomes more expensive when agents generate and test many revisions. Parallel agents can multiply the number of builds without improving the quality of the final submission.

Chainguard's model moves verification earlier. An agent can call Checks while it still has the task context and can immediately respond to a failure. The company wants successful evidence to travel with the eventual commit.

This creates pressure for established CI providers, but it does not make them obsolete. Large organizations rely on mature integrations, deployment approvals, audit histories, custom runners, and complex test matrices. A beta service must fit those systems before it can replace any part of them.

The pressure also reaches hosted agent vendors. Anthropic already offers filesystem and network isolation for Claude Code, including cloud sessions that keep important credentials outside the agent's sandbox. GitHub Codespaces supplies remote development environments and repository-scoped tokens.

Those products can isolate execution, but Chainguard is making a narrower security argument. It wants the workspace, dependency environment, check configuration, and merge evidence to form one chain. That chain is the company's primary point of differentiation.

Developers should read the launch as a contest between two workflow designs. One design combines a local or hosted agent with separately configured security and CI systems. The other makes isolation and verification parts of the agent's default execution path.

Isolation Matters More Than Asking the Agent to Behave

Chainguard's central bet is that enforceable infrastructure controls can contain mistakes that prompts and model policies cannot reliably prevent.

Each Chainguard Workspace runs in a dedicated microVM rather than a shared-kernel container. This architecture places a virtualization boundary between untrusted code and the underlying host. Each Checks task also receives a fresh microVM.

The company says no host directory is mounted into these machines. Repository contents are streamed into the environment instead. That choice reduces the chance that a compromised process can walk from the project directory into unrelated host files.

Chainguard also treats repository code as hostile. This assumption is useful because an agent can encounter instructions through source files, documentation, generated output, dependencies, and connected tools. A trustworthy user does not make every artifact inside a repository trustworthy.

The system's security model separates persistent credentials from the guest environment. When software needs authenticated access, a component outside the microVM adds the credential to an approved request.

For some services, code inside the Workspace communicates through a local hostname. The external proxy then authenticates the outbound request. Chainguard says tools that expect credentials on disk can receive encrypted stand-ins that have no value outside the active session.

This design reduces direct credential theft, but it does not eliminate credential misuse. Code inside the VM may still use the authority attached to an approved request. A malicious agent could create a lasting resource if the connected identity has excessive privileges.

Chainguard acknowledges this boundary in its documentation. It advises customers to grant workload identities only the access each check needs. Teams must also review session credentials before allowing unattended work.

Network controls add another layer. Checks receive no network access by default when the configuration omits a network rule. Repository owners can allow specific hosts or permit public network access when a task requires it.

Workspace defaults deserve closer attention. Chainguard's documentation says a session can reach the open internet when no check-specific egress restriction applies. Teams seeking a default-deny posture must therefore configure the session around a check with an allowlist.

This difference illustrates why isolation is not a single switch. A microVM can separate kernels while still allowing sensitive network actions. A proxy can protect credential values while still authorizing damaging requests. A signed result can prove that tests passed without proving those tests were sufficient.

The model becomes stronger when the controls reinforce each other. The VM limits local reach. Egress rules limit external destinations. Host-side credentials reduce secret exposure. Fresh checks test code outside the mutable development session.

Checks also protects parts of its policy from the change under review. According to Chainguard, a pull request cannot immediately weaken its own blocking requirements. Removing a required check or making it advisory takes effect only after the relevant change merges.

That detail closes an obvious bypass. An agent should not be able to edit the policy that judges its work and receive approval under the weaker policy. The base branch remains the authority for which checks must run.

A clean verification environment also resists accidental success. An agent may install an undeclared package or alter a service during development. Its code can appear functional inside that Workspace, then fail for everyone else.

Running Checks in fresh microVMs exposes those hidden dependencies. The result resembles a traditional clean CI build, but the service returns the evidence directly to the active agent loop.

Signed Checks Change the Meaning of Agent Completion

The most consequential feature is not the remote Workspace. It is the attempt to make independently verified evidence the agent's exit condition.

Most coding agents decide they are finished through a mixture of model judgment and tool output. The agent sees a test command pass, summarizes its edits, and opens a pull request. That sequence contains several trust gaps.

The agent may run the wrong test. It may overlook a failure, use stale output, or test an environment that no longer matches the submitted commit. It may also describe the result more confidently than the evidence permits.

Chainguard Checks creates a separate authority. The agent requests a defined verification run, receives a verdict, and can continue only when the required checks pass. The system can bind a successful result to a particular commit SHA, environment, and check outcome.

That turns CI into a control inside the autonomous loop. A failed run supplies structured logs, which the agent can use for another iteration. A successful run produces evidence that another system can evaluate.

The mechanism matters for teams running background maintenance agents. Consider an agent asked to update an outdated dependency across several repositories. It can modify manifests, regenerate lockfiles, and run compatibility tests without accessing a developer's laptop.

If a check fails, the session resumes with its prior state and warm caches. The agent can inspect the failure and try a narrower version change. It does not need a human to copy logs from a separate CI interface.

The same pattern applies to legacy refactoring. Several agents can test competing changes in separate Workspaces. Only the candidate that passes the repository's defined checks should advance toward a pull request.

Signed attestations can also help downstream governance. A merge service can verify that the submitted commit matches the tested commit. That is stronger than accepting a comment saying that an agent ran the tests.

However, an attestation only establishes facts about the process it records. It cannot establish that the test suite covers every security flaw. It cannot determine whether the product requirement was correct. It also cannot guarantee that a passing change deserves deployment.

The approach therefore narrows the trust problem rather than solving it. Teams no longer need to trust an agent's report about a test run. They still need to trust the test definition, policy configuration, execution service, and signing infrastructure.

That boundary is reasonable, but buyers need to understand it. The phrase "cryptographic proof" can sound broader than the underlying assurance. The evidence proves a defined check produced a defined result for identified inputs.

Chainguard is also entering a field where security controls increasingly sit inside coding tools. Anthropic's sandboxing system combines filesystem limits with network restrictions. GitHub provides scoped repository access and remote environments through Codespaces.

Chainguard's earlier Cursor integration focused on steering generated projects toward vetted packages and container images. Workspaces and Checks extend that strategy from dependency selection into execution and verification.

The broader competition is not simply Chainguard against one vendor. It is a race to control the trusted boundary around agent-generated code. Model companies, developer platforms, CI providers, and security vendors all have plausible claims on that layer.

The Beta Still Has Security and Adoption Questions

Chainguard's architecture addresses credible risks, but its strongest operational claims still need independent evidence from real enterprise workloads.

Both products remain beta releases. Chainguard describes Workspaces as a technology preview, and current documentation says Claude Code receives integrated model credential support. Other agents can run in a session, but the same credential workflow does not yet apply to them.

That limitation matters because enterprise agent fleets are becoming heterogeneous. A team may use one agent for implementation, another for reviews, and specialized tools for migration or testing. Security policy becomes harder when every agent requires different integration behavior.

Performance is another open question. Warm snapshots and prebuilt dependencies should reduce repeated setup work. However, the announcement does not provide comparative benchmarks against established CI services or other remote development environments.

Teams need measurements across realistic repositories. Useful evidence would include cold-start time, warm-resume time, cache hit rates, concurrent session behavior, and the delay between a failed check and resumed agent work.

Reliability matters as much as speed. A verification service becomes a development bottleneck when agents cannot complete tasks without it. Organizations will want service-level commitments, regional availability, failure recovery behavior, and clear rules for degraded operation.

The signing system also needs scrutiny. Customers must know how keys are protected, rotated, audited, and revoked. They need a method to verify attestations independently and decide which issuers their merge gates trust.

InfoQ noted that Chainguard had not published details showing how customers should validate the claimed tamper resistance of its logs. That does not invalidate the design. It identifies a required part of evaluating a security product.

Workspace credentials create another subtle risk. Keeping a token outside the VM prevents code from reading its raw value. It does not prevent code from asking the proxy to perform an authorized action.

A compromised agent could misuse GitHub access, cloud permissions, or an LLM credential through allowed routes. The defense depends on narrow scopes, request validation, egress restrictions, and monitoring. Teams cannot delegate that policy work to the microVM.

Host-side integrations also deserve attention. Security researchers have shown that a sandbox can lose its value when a trusted host component consumes attacker-controlled output. A modified configuration file might trigger privileged behavior after it leaves the sandbox.

Chainguard's streaming and proxy architecture reduces some host exposure, but customers should test the complete data path. That includes local synchronization, Git operations, IDE extensions, MCP servers, merge automation, and any notification system receiving agent output.

There is also an adoption tradeoff. Developers want agents to install tools, search documentation, call APIs, and explore unfamiliar code. Tight egress and credential policies can interrupt those tasks. Broad permissions restore convenience while weakening containment.

The product must make secure policies easier to maintain than ad hoc local configurations. Otherwise, teams may create permissive allowlists, reuse oversized identities, or bypass the system for urgent work.

Chainguard's use of a shared configuration for Workspaces and Checks can reduce duplication. Yet organizations still need to map every repository's dependencies, services, and test requirements. That migration effort will shape adoption as much as the underlying technology.

The cautious conclusion is straightforward. The architecture contains several thoughtful controls, especially fresh verification environments and credentials kept outside the guest. The beta has not yet established how those controls perform across diverse production pipelines.

Three Signals Will Show Whether the Model Works

The next test is whether Chainguard can turn a coherent security design into repeatable evidence, broad agent support, and practical enterprise adoption.

The first signal is published technical validation. Chainguard should provide reproducible benchmarks for startup time, check execution, cache behavior, and parallel sessions. Independent assessments of the credential proxy, attestation system, and log integrity would carry even more weight.

Strong results would support the claim that security controls can enter the agent loop without slowing it beyond practical use. Missing or narrowly selected results would leave the core performance argument unresolved.

The second signal is broader agent integration. Workspaces currently gives Claude Code the clearest documented path, while support for additional agents remains planned. Native support for other widely used coding agents would test whether the architecture is genuinely agent-neutral.

That expansion must preserve the same security properties. A longer compatibility list means little if some agents require secrets inside the VM or bypass the intended verification path.

The third signal is evidence of routine enterprise use. The strongest case studies would show agents completing dependency updates, refactors, or maintenance work across many repositories. They should report failure rates, human interventions, policy exceptions, and time saved.

Customer behavior will reveal whether signed checks become genuine merge gates or merely another status badge. It will also show whether security teams can maintain useful restrictions without turning every new tool into a policy ticket.

Chainguard Workspaces and Checks arrive as the industry shifts from supervising agent behavior toward limiting agent capabilities. That direction matches guidance from agent vendors and security groups. It does not guarantee that this particular implementation will win.

Developers evaluating the beta should begin with a contained repository and a narrow identity. They should define explicit egress rules, require clean checks, and verify that a submitted commit matches its attestation. Engineering teams can also document these findings in a shared technical knowledge base.

The final question is operational rather than philosophical. Can the system let agents work independently while keeping credentials, policy, and merge authority outside their control? The answer will emerge from verification data, integration breadth, and customer practice, not from the launch announcement alone.