Chainguard runs coding agents in remote microVMs and proposes signed attestations as the merge gate

The pitch to developers is a shorter retry loop. When Checks runs against a Workspace, the Workspace suspends while tests run. A failed check returns structured logs to the resumed session, and the agent tries another change without reconstructing its environment ^[10]. InfoQ's report quotes Paxton and Phillips describing the aim as letting developers and agents "test, fail, and fix code safely without waiting on slow CI" ^[13].

The queue disappears at the merge gate, if it disappears at all. Sam Katzen said: "Every run produces a signed attestation binding the environment, verdict, and commit SHA, so merge gates can verify a passing result instead of re-running tests." ^[12] InfoQ adds that the design depends on the attested inputs remaining unchanged ^[19].

The warm snapshot pool is rebuilt whenever the lockfile changes ^[18]. We'd expect repositories with frequent dependency bumps to pay that rebuild more often than repositories that rarely touch the file.

Established alternatives cover the pieces separately. E2B puts agent sessions inside Firecracker microVMs, with egress control and credential resolution handled outside the guest ^[14]. StepSecurity Harden-Runner watches what GitHub Actions runners do on the network, in the file system and in their processes, and it can enforce policy on outbound traffic ^[15]. Sonatype Repository Firewall blocks or quarantines malicious and vulnerable packages before builds, and JFrog Curation applies security, licence and package-age policies at download time ^[16]. InfoQ reports that Chainguard's offer combines these areas with signed test results ^[17].

The audit log is the hardest claim to check. Chainguard keeps a log of commands, code changes and network calls that it calls tamper-proof ^[20], and the announcement does not detail how customers should validate that tamper resistance ^[21]. The queue-time claim has its own conditions. It transfers to another pipeline only if the warm pool is hit on most runs and the lockfile changes slowly.

We think host-side credential handling is the strongest piece. Paxton and Phillips say the controls are intended to limit damage from a compromised dependency or a prompt-injected agent ^[22]. With long-lived secrets kept out of the guest, a compromised dependency has nothing long-lived to read ^[3]. It also makes the list of approved requests the control to audit, because anything on that list gets credentials attached.