Closing the audit-trail bar that async coding agents miss.

what · the · bar · is

The bar a regulated platform team asks for.

When a platform-security lead at a regulated org sits down to evaluate an automated coding agent, the question is almost never "how well does it write code?" It is "what does it leave behind on the pull request?" Three asks cover the bar every time: a per-PR record row a regulator can replay from trigger source to approver chain, a signature over the commit that survives a key rotation, and an SBOM document a downstream compliance tool can ingest without translation. An agent that misses any of the three cannot ship into a regulated VPC — and the three are co-dependent, because the signature has to bind the SBOM hash and the record row has to bind the sandbox run that produced the diff.

where · async · agents · fall · short

Where async coding agents fall short.

In-IDE assistants — Copilot, Cursor, Claude Code inside an editor — stop at the diff. They propose a patch and then a human opens the PR; the assistant never owns the audit-trail row, so the record a regulator needs is whatever the human remembers to copy across. Full delegations — Devin, Copilot Coding Agent, Simular, and the OpenHands-style runs — own the diff end-to-end but break the three asks differently: they ship inside their own ephemeral sandbox rather than a customer-controlled one, they sign with the vendor key rather than the customer KMS-resident key, and they emit an SBOM only as a courtesy, not as a signed artefact a downstream tool can verify. The bar is not whether the agent ships a diff; it is whether the diff arrives with an auditable provenance chain.

what · driftlock · records

What Driftlock records on every audit-linked PR.

Driftlock writes the same seven-column row on every PR. Each column has a single owner — the watcher, the sandbox, the signing controller, or the SBOM signer — and a single retention tier. The vocabulary matches the /governance explainer one-to-one, so a reader cross-checking this post against the live page reads the same field names.

• Trigger sourceThe originating signal — Dependabot advisory GUID, CI job URL, on-call incident id, or NVD / OSV / GHSA record pulled into the watcher.
• Triage recordReachability call, call-graph path, and the rule the watcher applied to mark the diff in-scope.
• DiffBytes-stable patch, pinned to the sandbox run id that produced it; reruns yield byte-identical output.
• Sandbox test resultsToolchain identity, hermetic-build hash, the failing test that triggered the run, and the full sandbox log.
• Approver chainEvery reviewer who comments, approves, requests changes, or merges the PR — GitHub identity, timestamp, and the review verdict, signed at each handoff.
• SignatureCosign / Sigstore signature over the commit, including the Rekor transparency-log entry and the OIDC claim payload tying it to the sandbox run.
• SBOM hashSHA-256 of the CycloneDX document emitted in the same run, plus the signature over the SBOM itself — so a reviewer diffs the lockfile and the SBOM hash together.

sandboxed · runs

Sandboxed runs are replayable by run id.

Every Driftlock run executes inside a hermetic Nix/Bazel sandbox inside the customer VPC. The sandbox boundary is the unit of replay: the same trigger re-invoked against the same run id reproduces the diff byte-for-byte, the test result byte-for-byte, and the SBOM byte-for-byte. Bounded VPC egress keeps the sandbox reachable only to the customer-owned artifact registry, the customer KMS, and the GitHub App endpoints — there is no third-party egress path that an auditor has to add to the trust boundary.

rotation · and · replay

Rotation, replay, and the Rekor-logged claim.

The signing key lives in the customer KMS — Enterprise swaps to an HSM, same wire format — and rotates on the customer clock, not Driftlock's. Every signature carries a Rekor claim payload (trigger · sandbox run · SBOM hash · approver); the claim itself is logged to the Sigstore Rekor transparency log. When the signing key rotates, the older signatures still verify against the corresponding Rekor entry — a buyer months into a rotation cycle does not lose its previous signed PRs. Replay is a function of the run id, not the key, so a rotated key does not relocate an already-approved handoff.