Evidence note: this article rests on primary vendor and project announcements — repository documentation written by the projects themselves, and engineering blog posts published by Docker, Microsoft, Google and Stack Overflow. Those are kept distinct from independently corroborated facts throughout. Where a source describes its own product’s behaviour, the attributable fact is that the project published the claim; no independent audit, reproduction or third-party test of any tool named below was located as of 19 October 2026. Every specific capability claim carries its evidence level at the point it is made. The comparison proposed at the end has not been run.
Four kinds of safeguard are being marketed to the same reader at the same time: an undo-snapshot recorder, a sandbox, an audit trail, and a post-deployment sweeper. Each vendor describes one product. None of them sorts the four against each other. The useful ordering is not by feature list but by when the evidence is created relative to the damage — before the command, around the run, after the deployment, across services. Sorted that way, a selection rule falls out, and so does a shared blind spot.
What an AI coding agent is actually permitted to run on a developer machine
The premise under all four safeguards is that the agent holds a real shell. Project documentation for Kintsugi, a local command interceptor, frames the problem in terms of agents executing destructive commands directly — recursive deletes, force pushes, table drops, raw disk writes and direct writes to files (project repository; evidence level: the project’s own README, uncorroborated — no independent survey establishes how often agents issue such commands in practice). Docker’s security write-up groups the exposure under three headings — prompt injection, excessive autonomy and credential exposure (Docker’s blog on AI agent security risks; evidence level: vendor analysis, not independently verified).
Treat that as the stated threat model rather than a measured incident rate. What is checkable is narrower and still decisive: if an agent runs with the developer’s own shell permissions, it inherits the developer’s own blast radius. That alone is enough to make the four safeguards worth sorting.
No undo, and you find out afterward
The failure mode the snapshot tools are built around is specific: a destructive command issued on a hallucinated path, on an instruction injected through retrieved content, or on a confident wrong guess — with no undo, discovered only after the fact (Kintsugi’s own description of the problem it targets; evidence level: project’s own framing, uncorroborated).
The second half of that sentence is the load-bearing part, and it is the part that generalises past any one product. A wrong rm is recoverable with backups. A wrong rm nobody noticed is not, because recovery decisions are made on a timeline the developer never entered. Detection latency, not destructiveness, is what each of the four safeguards is really competing on.
Before the command: a pre-execution snapshot, a log the user owns, and a rollback
Kintsugi’s repository states that it writes every command every agent ran to an append-only, hash-chained log owned by the user, and that it makes destructive agent actions reversible by snapshotting state before the command runs, with kintsugi undo rolling the action back (project repository). The fact here is that the project publishes those claims; whether the snapshot and rollback hold under adversarial conditions — a partial write, a command that escapes the interceptor, a log file an agent can reach — is open, and no third-party test of it was found.
Two properties are worth separating, because they catch different things. The hash chain is a tamper-evidence mechanism: it makes after-the-fact edits to the record detectable, which matters precisely when the entity under investigation is also the entity writing to disk. The pre-command snapshot is a recovery mechanism, and it is the only one of the four safeguard classes positioned earlier than the damage. An earlier PlayAgit piece on local-first agent guardrails and the log that outranks an agent’s "done" covers the interceptor category in more depth.
Local-first, and it records the human too
Kintsugi’s documentation also states that the tool is local-first — no cloud, no account, nothing leaving the machine — and that a passive shell recorder for bash and zsh logs commands a human types onto the same tamper-evident log, snapshotting destructive ones just in time (project repository). Again: the project’s own attested description, with independent verification open.
The human-recording detail is the more interesting one, and it is easy to skim past. Post-incident, the hardest question is usually not what did the agent do but who did this. A log that records only the agent’s side cannot answer it, and will quietly imply the agent’s innocence or guilt by omission. The symmetric log can at least place both actors on one timeline. For readers weighing the local-only posture itself, PlayAgit’s earlier look at a local-first product whose own agent still was not local is a reminder to check which component the "local" label actually covers.
Around the command: MicroVM sandboxes, and the network policies an eval runner defines on top
The second class does not try to reverse the command; it tries to make the command land somewhere that does not matter. Docker describes Docker Sandboxes as MicroVM environments for running coding agents — Claude Code, Codex and Cursor are the ones named — safely and autonomously (Docker’s Harbor and Sandboxes announcement; evidence level: vendor announcement, uncorroborated). The same post describes Harbor running every evaluation task inside those sandboxes with custom network policies defined per task, for evaluations the vendor characterises as fair and reproducible. Docker has separately described extending the same sandbox model from laptop to cloud (cloud sandboxes announcement; evidence level: vendor announcement).
The network policy is the part that converts a containment feature into a measurement feature. Isolation stops the agent reaching production. A declared network policy additionally fixes what the agent could reach, which is what makes two runs comparable at all.
After the run: a complete audit trail from first draft to final decision
A third position is after the work is finished but before anyone trusts it. The eklavya-agent project states that in its system every run leaves a complete audit trail from first draft to final decision (project repository) — the project’s own attested claim, with no independent review of the trail’s completeness located.
This record answers a question the other two cannot touch: not what command ran but why this output rather than another. Reliability work on agent tool-calling has pushed in the same direction, toward instrumenting the decision path rather than the final answer alone (NVIDIA’s write-up on agent reliability and tool-calling efficiency in chip design workflows; evidence level: vendor engineering report, uncorroborated).
The regression that never touched the filesystem
Here is where the first three safeguards fail together, and it is the point of sorting them.
Suppose the agent issues no destructive command, stays inside its sandbox, respects the network policy, and logs every step honestly — and the answers it returns get worse. The snapshot recorder has nothing to snapshot. The sandbox contained a run that needed no containing. The audit trail faithfully records a chain of reasoning that was simply wrong. All three mechanisms are command-centric: their evidence is created by an action against the machine. A quality regression performs no such action.
Google’s engineering blog describes an Ambient Quality Agent, AQuA, built for this gap: it is presented as sweeping and verifying failure clusters against conversation transcripts, and diagnosing root causes anchored to the exact deployed source snapshot, as an open-sourced reference implementation running beside a production agent in Google Cloud (Google’s post on the outer loop; evidence level: vendor announcement, uncorroborated). Note what the described design implies: the evidence is the transcript, not the command log, and the anchor is the deployed snapshot, not the machine state.
Why a status code stopped being evidence
The same source states that silent quality regressions in a production agent can return HTTP 200 OK, so the failure is not visible in response status (Google’s post on the outer loop; evidence level: vendor claim, uncorroborated). Two further claims sit underneath it: that agents are non-deterministic, which is itself the central difficulty in applying conventional observability to them (Stack Overflow’s piece on agent observability, published 9 October 2026; evidence level: industry commentary, uncorroborated), and that agents tend to produce plausible yet incorrect artifacts (reported in the same vendor and commentary sources; evidence level: uncorroborated).
If those hold, the monitoring consequence is unusually clean to state: a green dashboard is evidence that the service responded, and evidence of nothing else. Diagnosing this class takes more than one pass, which PlayAgit’s own account of four wrong diagnoses before the real one illustrates at small scale.
The same blind spot pointing the other way: a correct answer found lying on the machine
The inverse case is sharper, and it is the one most likely to mislead a small team. Microsoft’s developer blog argues that a coding agent producing a correct answer during an evaluation may have found that answer somewhere on the machine rather than known it — which invalidates the measurement (Microsoft’s post on evaluation sandboxes; evidence level: vendor analysis, uncorroborated).
Put beside the regression that returns 200, the pattern is one blind spot read from both directions. A wrong answer with a success status is invisible; a right answer with a contaminated environment is worse than invisible, because it is counted as a win. Neither leaves a destructive command behind. Both are what the declared network policy and the controlled sandbox image in the Harbor description are structurally positioned to constrain — not by catching the bad answer, but by removing the places a free answer could be lying.
Stitching the moments together: end-to-end request tracing
The fourth position is across services rather than at any single moment. Google states that Apigee hybrid 1.17.0 supports tracing end-to-end agent requests using W3C trace context headers (Google’s announcement of MCP support in Apigee hybrid; evidence level: vendor announcement, uncorroborated).
The specific version number and the specific standard are what make this more than a slogan. W3C trace context is a propagation format, not a quality signal: it can tell a team that one user request crossed a gateway, three tools and two models, in that order. It cannot tell them the answer was right. Its value is joining the other three records into one timeline — which is exactly the thing none of them does alone.
Reading the four records side by side
| Safeguard | Evidence created | Failure it can see | Gap it leaves |
|---|---|---|---|
| Pre-command snapshot + hash-chained log | Before the command | A destructive action on a wrong path; after-the-fact tampering with the record | Any failure that issues no destructive command |
| MicroVM sandbox + declared network policy | Around the run | Blast radius; a contaminated or unequal evaluation environment | Wrong output produced entirely inside the sandbox |
| Run audit trail, draft to decision | After the run, before trust | Why this output and not another; which step diverged | Nothing, if the reasoning is wrong but internally consistent and never reviewed |
| End-to-end request tracing | Across services | Where in a multi-service path a request went, and in what order | Whether the result was correct |
Read down the right-hand column and one entry appears three times: a quality regression that performs no destructive action and returns success. The post-deployment sweeper is the only one of the five described mechanisms positioned against it, and its capabilities rest on a single vendor’s account.
Developer takeaway, and the comparison not yet run
For a team picking one or two safeguards this month, the ordering suggests a rule rather than a ranking:
- Pick by the failure that would actually hurt, not by coverage breadth. If the repository is the irreplaceable asset, the pre-command snapshot and the user-owned log are the only class whose evidence exists before the damage.
- Pick the sandbox if a number is going to be trusted. Isolation is the visible benefit; the declared network policy is the one that makes a measurement mean anything, and it is also what the contaminated-answer argument points at.
- Do not let a status code count as a health check. If the agent faces users, treat the transcript as the primary signal; status-based monitoring is reported to miss this class entirely.
- Add tracing when the path crosses more than two services, not before. It locates; it does not judge.
- Treat every capability above as a published claim. Vendor and project documentation is the only evidence located for all of them. PlayAgit’s breakdown of three headline agent numbers and what each would take to verify sets out why that distinction matters before installation, not after.
A proposed follow-up, not a result
The comparison this article cannot make is the one a reader most wants: a single agent task, run four times under the four safeguards, to see which records the same induced failure. A proposed design would induce two failures — one destructive command on a wrong path, one silent quality regression returning a success status — and record, for each safeguard, whether the failure appears in its output at all and how long after the fact. Nothing in that design has been executed; no environment has been built, no run attempted, no figure produced. It is stated here only as a proposal, and any result from it would have to be reported separately with its method, versions, date and sample size before it could be treated as evidence.