What Evidence Does an AI Agent Actually Need to Leave Behind?
There is a question that keeps surfacing as AI agents move from answering questions in chat to actually doing things, writing code, modifying configs, calling APIs, deploying services.
The question is not "how do we stop them from acting?"
The question is: what evidence do we need after they act?
The Git Commit Problem
The reflex answer is: just look at the diff.
A Git commit shows you what changed. That used to be enough when a human sat behind every change. The human held the context. You could ask them. The commit message, however brief, was a pointer to a person who understood the decision.
With an AI agent, the commit is often the only artifact. And it hides almost everything that mattered:
- What did the user actually ask for?
- What did the agent read before deciding what to change?
- Which tools did it call, and in what order?
- Did it touch secrets, authentication tokens, environment variables, or production config along the way?
- Was there a human in the loop, and if so, did they actually review anything, or just click Allow?
- Can someone reconstruct the full sequence six months from now when something breaks in production?
A commit hash answers none of those questions.
Why This Is the Practical Governance Problem Right Now
We have spent years building approval workflows for human code changes. Pull requests, code review, change advisory boards, ticket numbers in commit messages. These processes assume a human author who can be questioned, who made a conscious decision, who can explain their reasoning.
AI agents break that assumption quietly.
The agent acts faster than review cycles were designed for. It calls ten tools in thirty seconds. It reads a config file, writes a new one, runs a test, opens a PR, and waits, all before anyone noticed it started. The change looks reasonable. The tests pass. The PR gets merged.
Three months later, something unexpected happens in production. You need to understand what the agent knew, what it read, what choices it made, and what a human approved.
If the only record is the commit, you have nothing.
The Minimum Viable Evidence Set
I am not arguing for heavyweight approval workflows on every AI action. That path leads to agents being so throttled they are useless.
But I do think every meaningful AI action, anything that modifies state outside the agent's own scratchpad, should leave enough evidence to answer questions when it matters.
Here is what that looks like in practice:
1. The original intent
What did the user ask for? Not the agent's interpretation, the actual message. This is the anchor for everything else. If the change cannot be traced back to a human request, that is itself meaningful information.
2. The tool call sequence
Which tools did the agent call, in what order, and what did it pass to them? This is the chain of decisions. A file read that preceded a file write tells you the agent saw the old value before replacing it. A secrets lookup before a config change is a different kind of event than a blind write.
3. What the agent read
Before an agent modifies something, it usually reads something. That read context is often the difference between "the agent made a reasonable change given what it saw" and "the agent made a change that only makes sense if it misread something."
4. Sensitive surface contact
Did the interaction touch authentication, authorization, secrets, infrastructure definitions, or production configuration? These are not just higher-risk changes, they are the category of changes that auditors, security teams, and incident responders will ask about first.
5. Human approval record
Was a human shown anything before the change happened? Did they click through a permission prompt, review a plan, or simply let the agent run autonomously? The presence or absence of human review is material. So is the kind of review, "I saw a one-line summary" is different from "I read the full plan and the diff."
6. Reconstructability
Can someone who was not in the room replay the sequence? Not re-run the agent, but follow the evidence trail and understand what happened. This is the test. If the answer is no, the evidence is insufficient.
Where People Draw the Line
In practice, teams end up in one of a few places:
Git history only. Fast, familiar, already required. Works fine when agents are doing what a junior developer would do and the stakes are low. Fails when something goes wrong and you need to explain the decision chain.
Tool-call logs. A step up. You know what the agent touched. You do not always know why, or what it read, or what the user originally asked for. Better for incident response than for governance.
Approval records. Some teams require a human sign-off checkpoint before the agent can modify certain surfaces — production, secrets, auth config. This is reasonable for high-stakes surfaces. It does not help you reconstruct what happened before the approval, or what the agent read to arrive at its proposal.
Full session traces. The full conversation, user messages, tool calls, reads, writes, tool results, stored with tamper-evident hashes. This is the complete evidence set. It is also the most expensive to store and the most sensitive to handle, because it may contain secrets that appeared in tool results.
The honest answer is that the right level depends on the surface. An agent writing unit tests probably does not need a full session trace. An agent modifying IAM policies probably does.
What Chron Is Doing Here
Chron is an MCP server that creates tamper-evident audit logs of AI sessions — stored locally, on your own machine, in a SQLite database you control.
Every tool call is logged with a cryptographic hash chain. The user's original message is captured. The sequence is reconstructable. The database does not leave your environment.
It crossed 9,000 npm downloads this week, which is a signal that the question this article is asking is not just theoretical. People are encountering it in real work and looking for answers.
Chron's position is deliberately minimal: it records, it does not certify. It does not tell you whether a change was authorized or correct. It gives you the evidence to answer those questions yourself, or to hand to someone else who needs to answer them later.
That boundary - recording vs. certifying - matters. The tool that captures evidence should not be the same tool that decides what the evidence means. Those are different jobs.
The Question Worth Asking Your Team
If an AI agent in your environment made a change right now, something it wrote, deployed, or modified, and three months from now you needed to explain that change to a customer, an auditor, or your own security team, what would you show them?
If the answer is "the commit," that is worth thinking about.
Not because commits are bad. Because they were designed for a world where a human sat behind every change, and that world is changing faster than our evidence practices are.
Chron is available as an MCP server: npx chron-mcp. It works with Claude, Cursor, and any MCP-compatible AI tool. The audit database is yours - local SQLite, no cloud egress.
Top comments (1)
Separating recording from certification leaves a second question on the recording side: does anything downstream read the evidence? The six items are a list of what to write out. A signature or hash chain establishes that a field is intact, which is a different property from that field being an input to some decision. Auditing the evidence record by itself cannot surface the gap. You have to look at what consumes it.
I scanned a public event log of 8,002 entries. Of 1,000 delivery records, 917 reported a self-declared
runtime_msof 0, and payment came out at a flat 10 credits across all 991 that paid. The field was signed and intact and fed nothing. In the same log, 1,000 judgment records all carriedscore = 1.0with two distinct reason strings between them, and no later event anywhere referenced a judgment ID.So two checks worth running next to the hash chain: count distinct values per field, and count downstream records that reference each evidence ID. A field collapsed to a constant is a candidate for write-only evidence, not proof of it. Which of the fields you collect today can you trace to a decision whose output changes when the value changes?