{"slug": "what-evidence-does-an-ai-agent-actually-need-to-leave-behind", "title": "What Evidence Does an AI Agent Actually Need to Leave Behind?", "summary": "A developer argues that AI agents making real changes to code, configs, and infrastructure leave insufficient evidence behind, since a Git commit alone cannot show what the user asked for, which tools the agent called, what context it read, or whether a human approved the action. The piece proposes that every meaningful agent action outside its own scratchpad should leave a replayable trail covering the original request, tool-call sequence, read context, risk category, and type of human review.", "body_md": "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.\n\nThe question is not \"how do we stop them from acting?\"\n\nThe question is: **what evidence do we need after they act?**\n\nThe reflex answer is: just look at the diff.\n\nA 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.\n\nWith an AI agent, the commit is often the *only* artifact. And it hides almost everything that mattered:\n\nA commit hash answers none of those questions.\n\nWe 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.\n\nAI agents break that assumption quietly.\n\nThe 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.\n\nThree 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.\n\nIf the only record is the commit, you have nothing.\n\nI am not arguing for heavyweight approval workflows on every AI action. That path leads to agents being so throttled they are useless.\n\nBut 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.\n\nHere is what that looks like in practice:\n\nWhat 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.\n\nWhich 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.\n\nBefore 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.\"\n\nDid 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.\n\nWas 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.\"\n\nCan 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.\n\nIn practice, teams end up in one of a few places:\n\n**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.\n\n**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.\n\n**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.\n\n**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.\n\nThe 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.\n\n[Chron](https://www.npmjs.com/package/chron-mcp) 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.\n\nEvery 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.\n\nIt 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.\n\nChron'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.\n\nThat 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.\n\nIf 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?\n\nIf the answer is \"the commit,\" that is worth thinking about.\n\nNot 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.\n\n*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.*", "url": "https://wpnews.pro/news/what-evidence-does-an-ai-agent-actually-need-to-leave-behind", "canonical_source": "https://dev.to/sirinivask/what-evidence-does-an-ai-agent-actually-need-to-leave-behind-2b02", "published_at": "2026-09-23 09:28:39+00:00", "updated_at": "2026-09-23 09:58:41.520062+00:00", "lang": "en", "topics": ["ai-agents", "ai-safety", "developer-tools", "mlops"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/what-evidence-does-an-ai-agent-actually-need-to-leave-behind", "markdown": "https://wpnews.pro/news/what-evidence-does-an-ai-agent-actually-need-to-leave-behind.md", "text": "https://wpnews.pro/news/what-evidence-does-an-ai-agent-actually-need-to-leave-behind.txt", "jsonld": "https://wpnews.pro/news/what-evidence-does-an-ai-agent-actually-need-to-leave-behind.jsonld"}}