Introducing Chainguard Workspaces

Today, we are introducing Chainguard Workspaces to provide developers and agents with Chainguard-hardened, microVM-based environments that accelerate agentic development while maintaining the strict isolation and safeguards that enterprise security demands.

Software engineering is increasingly a joint effort between human developers and AI agents. Across the industry, and in our own engineering team at Chainguard, it is common for a developer to run 5 or 6 parallel agent sessions at once across different branches of a repository to work on separate tasks or to explore competing strategies. On a local developer machine, these parallel sessions quickly collide, fighting over ports, processes, and build caches.

When these collisions occur, developers have to stop what they’re doing and become system administrators. This cleanup eats into the time savings gained by delegating work to agents in the first place.

Worse, to get their jobs done, agents need to install packages, run arbitrary shell scripts, and edit configurations. Running unconstrained machine execution on a developer laptop holding corporate credentials, SSH keys, and production access creates a massive supply chain risk. 

Chainguard Workspaces resolves both issues, enabling developers and agents to build rapidly while keeping local laptops and secrets fully protected. We’ve partnered with organizations operating at the highest levels of data security and regulatory scrutiny to ensure Workspaces provides that strict isolation while boosting developer productivity.

Among them is Cuscal, which banks and fintechs across Australia rely on to move money safely. As Brad McCoy, Senior Manager of Cloud Platforms, put it:

"For agent sandboxing, we need an environment where AI agents can iterate quickly without risking core systems. 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."

A persistent workspace for agents and developers

A Chainguard Workspace is defined declaratively.

#insert example
version: 1
environment:
  packages:
    - go-1.27~1.27.1          # keep in step with env/default.yaml
    - git
    - golangci-lint~2.13.2
    - curl
    - claude                  # Claude Code
    - chainctl
    - apk-tools               # so agents can apk add in a session

Developers and agents interact with the Workspace directly through chainctl develop. Running the command drops you into an interactive PTY shell inside a remote microVM pre-configured with your repository, git history, and required toolchains:

# Open an interactive sandbox session for the current directory
$ chainctl develop
# Broker local credentials (Claude, GitHub, OCI) through the host-side proxy. 
# They never enter the microVM.
# Resume a specific named session or run checks inside the environment
$ chainctl develop attach my-project/feature-sandbox

When you attach to a Workspace from a local Git directory, chainctl develop synchronizes your working tree, including untracked files and uncommitted edits, directly into the Workspace. When you detach, the entire session is automatically snapshotted and parked. Re-running chainctl develop from the same repository resumes your PTY shell in seconds with all files, background daemons, and shell context intact. This means fast starts for you and your agent.

Rather than forcing an agent through slow, linear trial-and-error, trying one approach, failing, reverting, and starting over, you can use --fresh to fan out multiple independent Workspaces for the same repository without wrestling with multiple git worktrees or duplicate heavy dependency directories (like node modules or build caches). From there, you can assign different AI agents to explore competing strategies simultaneously in isolated Workspaces, iterating on the same problem in parallel to derive solutions faster.

Chainguard Checks: CI gating for autonomous loops

When paired with Chainguard Checks, agents in workspaces can prove their work passes CI before a pull request is created, preventing broken code from being pushed. 

When an agent calls CI from a workspace, Checks runs your CI suite against the change, and returns a verdict.

Configure your agent loop to require a passing Checks verdict, and the agent can't exit its workflow or open a pull request on a guess. While Checks runs, the Workspace suspends to a snapshot and uses no additional compute. If a check fails, the Workspace resumes in seconds with warm caches intact and the failure logs injected straight into the session, so the agent keeps iterating until CI passes.

Here is how the underlying architecture delivers that balance of speed, lifecycle control, and security:

Key Pillars of Chainguard Workspaces

The foundation: Chainguard-hardened microVMs 

Every Workspace boots as a dedicated, Chainguard-hardened microVM rather than a shared-kernel container. The guest image is apko-built directly from source using minimal, zero-CVE Chainguard OS Packages. Because the execution environment is content-addressed, every Workspace environment is reproducible, verifiable, and, if needed, FIPS-compliant.

Rapid start: Warm snapshot pools and background reconcilers

Before a developer or agent ever runs a command, background reconcilers maintain a warm pool of suspended VM snapshots built from your lockfile and rebuilt in the background whenever it changes. Starting or attaching to a Workspace is a resume of a warm microVM, keeping developers and agents in flow without waiting on cold boots. Because everything in your lockfile is pre-baked into the warm snapshot, dependencies load straight from disk, so your loop skips registry downloads for them and cuts fetch delays.

Security boundary: host-side credential injection and configurable network policies

Inside the microVM, no secrets exist on disk or in memory. When an agent makes a network request, such as calling an LLM gateway or fetching dependencies, a network proxy validates the request and the host injects short-lived credentials in flight. Tools requiring keys on disk receive encrypted stand-ins that are useless outside the active session.

Teams can also add an optional egress policy. Once it's enabled, the proxy blocks and logs any outbound request to an endpoint you haven't explicitly allowed. A compromised dependency can't phone home, a prompt-injected agent can't leak your source code, and an agent can't wander into systems it has no business touching.

Lifecycle control: point-in-time snapshotting and logs 

Giving AI agents autonomy means accepting that they won't always get it right. When an execution loop goes in a direction you didn't intend, or you simply change your mind, you need a fast, foolproof way to reset and try again. That’s why every Workspace comes with a dedicated lifecycle management layer. Before an agent or developer runs a loop, it records the environment state. You can restore the entire filesystem branch, including system package changes, edited configurations, and untracked files, without touching your local machine or any other Workspace. It also allows for strict enforcement of CPU and memory limits, automatically terminating runaway background commands and their parent tasks. The entire time, there is an active flight recorder capturing the environment, commands run, code changes, network calls, and, where applicable, Checks results, in a tamper-proof log, providing security teams with deep visibility. 

No guessing: pause and resume for developer input 

Most frameworks give you two bad options: the agent guesses, or the agent dies, and someone re-runs it from scratch. Workspaces give agents another option: asking a developer. 

When an agent encounters a decision above its pay grade, the Workspace avoids both guessing and burning unnecessary compute. A question is routed to the developer across whatever channel you choose, including a PR comment, an issue, or a review queue. To keep prompt context cached and enable low-cost resumes if the developer answers quickly, the workspace remains active for 10 minutes. If the wait extends past that window, the entire environment, including active process trees, memory state, and warm caches, suspends to a snapshot, stopping compute spend while it waits. Once answered, the loop wakes in seconds, resuming execution at the exact paused state.

Sign up

Software development is evolving rapidly, and developer execution environments need to keep pace. Chainguard Workspaces bridges the gap between AI developer velocity and enterprise supply chain security, providing Chainguard-hardened microVMs where human engineers and AI agents can build safely side by side.

Try Chainguard Workspaces for yourself today to keep your agents moving while meeting your enterprise security demands. The beta is open now, with a free 30-day trial to get you started. 

FAQ

Does the AI agent run inside the Workspace or outside it?

Both modes are fully supported:

• Agent running outside (Client / Local mode): The agent runs on your local laptop. It sends tool calls, shell commands, and file edits into the remote Workspace over an interactive PTY session via chainctl develop.

• Agent running inside (In-VM execution): The agent process runs directly inside the Workspace microVM. Even with the agent running inside the sandbox, Chainguard's host-side proxy handles credential injection out of band, ensuring that API keys and Git secrets never touch disk or memory inside the VM.

In either setup, all execution remains isolated inside the Workspace.

Do I need Chainguard Checks to use Workspaces?

No. Chainguard Workspaces is a completely standalone product. You can use chainctl develop for interactive developer sandboxing, agent isolation, and parallel hypothesis testing without ever enabling Checks.

Adding Chainguard Checks is optional, but it provides value to both human developers and AI agents:

• For developers: Checks provides fast, pre-commit clean-room validation directly inside your Workspace, allowing you to verify your build and run full test suites locally without pushing unverified commits or waiting on long CI queues.

• For AI agents: Checks can act as a strict loop-exit gate, preventing agents from submitting a pull request or exiting their task on a guess.

Which AI agents does it support?

Workspaces can be used with Claude today, with support for additional agents coming soon. 

Does my code run locally or in the cloud?

Workspaces are remote microVMs. chainctl develop syncs your local working tree, including uncommitted changes, into the Workspace, so you keep your editor and git workflow while execution happens off your machine.

Can Chainguard Workspaces support my compliance requirements?

Workspaces are built with compliance in mind. Environments are built from Chainguard OS packages, including FIPS packages, and every run executes in microVMs that produce 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 Workspaces be priced?

Workspaces will be priced based on compute consumed. The underlying architecture is built specifically to minimize that consumption:

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

• Idle Pausing: Compute stops when a Workspace suspends to a snapshot, including while Checks run and after 10 minutes waiting on developer input.