Evidence note: this article surveys how a set of publicly listed projects describe their own designs. Almost everything below comes from primary self-description, meaning a project’s own repository page or a vendor’s own blog post, read as of 12 September 2026. That is a real source for what a project claims to do, and it is not the same thing as an independent test of whether it does it. Nothing here has been benchmarked, installed, or reproduced by a third party for this piece, and no performance figure below has been confirmed by anyone other than its author. Claims that lack even that primary attestation are marked where they appear.
Reconstructing a run after it ends
The simplest thing an agent leaves behind is wreckage: a diff, a log, some files that were not there before. RErun, according to its own repository description, is an experiment in reconstructing what happened during an agent run from exactly those traces. The framing matters more than the tool. It treats the record as something to be recovered rather than something that was captured, which is an admission that most agent runs are not instrumented while they happen.
That admission is easy to confirm from the outside. PlayAgit’s earlier look at 303 agent runs that built three Roblox games found a record rich in what was changed and nearly silent on what the agent understood. Reconstruction after the fact inherits that ceiling. No amount of forensic work adds a fact the run never wrote down.
Audit trails treated as a deliverable
A second family of projects moves the record from afterthought to product requirement. The eklavya-agent project states that every run leaves a complete audit trail running from first draft to final decision (per its repository). The Proof Gradient protocol is described by its authors as leaving a proof artifact behind for every agent run (project repository); what that artifact contains, and what it proves to someone who was not present, is not established by any source available here. Ombre describes a fixed eight-agent pipeline that fires on every request, one member of which is a tamper-proof audit trail component (project repository).
The shared design bet is that auditability degrades if it is optional, so it is wired in as a step that cannot be skipped. Whether these implementations hold up to an adversary is an open question. "Tamper-proof" is a strong word, and none of these projects has been independently audited in any source cited here.
The commands no trace can walk back
There is a category of action where a good record arrives too late by construction. Removing a directory tree, force-pushing over a branch, dropping a table, writing raw blocks to a disk device: the argument is that without an interception layer these have no undo, and the user learns about them only afterwards. That argument is widely repeated in the tooling space and is not independently corroborated here, so treat it as a design premise these projects share rather than a measured finding.
It is at least consistent with observed behaviour. This site’s account of 27 failed agent runs, 11 of which had already written to the repository showed that a run can leave durable changes behind before anyone judges whether it succeeded. A log tells you that happened. It does not put the file back.
Snapshot first, run second
Kintsugi answers that gap by inverting the order. Its authors state that the tool makes destructive actions reversible by taking a snapshot before the command runs, with rollback available through a single kintsugi undo (project repository). The snapshot is the whole idea: it converts an irreversible action into a reversible one at the cost of taking the precaution every time, before anyone knows whether it will be needed.
No evidence available here establishes what that costs in practice, which matters because snapshot systems typically trade disk and latency for safety. The project’s own description does not answer it, and independent measurements do not appear to exist.
A hash-chained log the user owns
Kintsugi’s second claim is about custody rather than recovery. Its documentation states that every command every agent ran is written to an append-only, hash-chained log that the user owns, so the record survives independently of the agent process. Hash chaining makes silent edits detectable; independent ownership means the process being investigated is not the process holding the evidence.
Both properties speak to a specific failure mode: a record kept inside the agent’s own runtime is worth only as much as the runtime’s integrity. A crashed, confused, or compromised agent is exactly the case where the log matters most, and exactly the case where a log it controls is least trustworthy. Whether the implementation achieves the independence it claims has not been verified outside the project.
A tool with the opposite design goal
Not every project is trying to leave more behind. Agent_0_Thumb_Install is described by its author as a portable setup designed to leave no trace on the host computer (project repository). Read next to the audit-trail projects, it is a clean statement of the opposing requirement: forensic recoverability and host cleanliness pull in opposite directions, and a tool has to pick one.
The choice is not obviously wrong in either direction. Portability serves shared machines, borrowed hardware, and anyone who wants an agent to be removable. It simply means the accountability story has to live somewhere other than the host filesystem, and the project’s description does not say where.
What the record is worth when the operator is also on it
An audit trail that only covers the agent answers a question nobody asked in isolation, because the interesting incidents usually involve both parties. Kintsugi’s authors state that the tool also records commands a human runs, through a passive shell recorder for bash and zsh with no agent involved, placing those commands on the same tamper-evident log and snapshotting the destructive ones just in time.
That closes a real hole. When something is destroyed on a machine shared by a person and an agent, a one-sided log tends to produce the wrong answer with great confidence. The same-ledger approach is uncommon in the projects surveyed here, and no independent assessment of its coverage exists.
Refusing the request instead of reconstructing it
Prevention is a different posture from recovery. Trollbridge is presented as an HTTP/S proxy placed in front of a coding agent, enforcing allow lists and deny lists and supporting realtime approve-or-deny decisions (project site); this description has not been independently corroborated. The network layer is a useful chokepoint because it sees exfiltration and remote calls that a filesystem guard never touches.
The cost is the one every interception layer pays. A deny list is only as good as its authors’ imagination, and a realtime approval prompt is only as good as the attention of whoever answers it at the fortieth interruption of the afternoon.
Isolation and its edges
Coarser isolation trades precision for confidence. One reported approach runs an autonomous coding agent inside a local sandbox built on Incus virtual machines, on the argument that a container firewall alone forces repeated exception-adding and cannot distinguish one HTTP verb from another. That last detail is the sharp one: a firewall that permits a host permits reads and writes to it alike. This account is uncorroborated here and should be read as a practitioner’s reported experience rather than an established limitation.
Docker’s own material on YOLO mode covers the adjacent question of running an agent without permission prompts and what it takes to do so safely (Docker’s blog). The general claim that skipping permission prompts carries risk requiring specific countermeasures is not independently verified here, though it is the stated rationale behind most of the tools in this survey.
Designs where nothing acts unapproved
At the far end sits the design where the agent never acts on its own. Alfard is described by its authors as running AI agents locally, where nothing acts without user approval and no data leaves the machine (project repository). RunFlow Agent takes a narrower version of the same stance: it reads local RunFlow data and produces validated suggestions, leaving execution under the user’s control (project repository), a description that has not been corroborated independently.
Suggestion-only designs sidestep the entire audit problem by never creating the events that need auditing. What they cannot sidestep is throughput. Every action waits on a human, which is fine for a system that produces a handful of recommendations and unworkable for one that touches hundreds of files.
Evaluation without a bill or a mutated database
Testing an agent creates its own hazard. Microsoft’s developer blog covers how to test agent skills without hitting real APIs (the post). The underlying premise, that evaluating a skill against a live API means every run either costs money or mutates production data unless the API is mocked, is not independently corroborated here, but it follows from how most billed and stateful APIs behave.
The practical consequence is that the evaluation environment deserves the same design attention as the production one. An agent that is safe in production and reckless in its test harness has only moved the blast radius.
Runtime hygiene as part of the record
The last piece is unglamorous and easy to skip. The vibe-agent-runtime states that it separates polling from processing so that no poll is ever left unparked by the runtime (project repository). A dropped or stranded poll is a hole in the record that looks identical to nothing having happened, which is the worst shape a gap can take.
Across the whole survey, that is the recurring seam. The projects that promise the most complete trail and the one that promises to leave no trace at all are answering the same question from opposite ends, and none of the answers here has been tested by anyone but the people who wrote them.