Originally published at ReclaimLLM.
Reconstruct an AI coding session from tool calls, policy decisions and results. Know what the evidence proves, and where the record stops.
AI coding audit trails: what did the agent do in your repo?
Updated November 14, 2026.
An agent has changed a configuration file. A developer remembers approving a command. The final chat message says the tests passed. Security asks whether the agent also read a credentials file.
Those statements describe different parts of the session. To answer the question, you need a sequence that connects a requested action to a policy decision and an observed result. A useful AI coding audit trail also makes its missing evidence visible.
Start with one session and one question: what can we establish about this file read, command or change?
Keep the request, permission and result separate
Treat these as separate records when you design or evaluate capture:
- Requested action: the tool and arguments the agent proposed.
- Policy response: what a configured control allowed, denied or changed.
- Human approval: an independently recorded decision by a person, if available.
- Observed outcome: the tool result, error or resulting file change.
A policy response of allow does not prove that someone clicked an approval button. A proposed command does not prove execution. A successful command does not prove that its output was safe to send elsewhere.
Preserving those distinctions prevents an investigation report from claiming more than the evidence supports.
Use identifiers to join events
A session is not one row. It is a set of events that must join on shared identifiers, in time order.
At minimum, a record needs a session ID, a sequence number or timestamp, a tool name and action, a target path, the policy response, and the observed result. Cursor staff stated that the platform has no audit trail linking a proposed tool call, the user's decision and the execution result into one record, and that approval-card decisions are not passed through hooks (Cursor forum, t/156247/10). When the vendor does not provide that join, you cannot reconstruct it from the vendor's UI alone.
Identifiers matter across tools. If a developer uses Cursor for one task and Claude Code for the next, you need a way to connect those sessions to the same person, repository and time window. That is usually a join on user identity, repository and commit time. It is not built into the tools.
The Cursor hook reference describes what hooks receive. Claude Code documents the same pattern in its monitoring docs and hooks reference.
Walk through one session
Take one real session and test whether you can answer the questions in the table.
| What the record shows | What it proves | What it does not prove |
|---|---|---|
The agent proposed cat ~/.aws/credentials | The agent requested the file | Whether the file was read, or whether its contents left the machine |
The policy response was allow | The control did not block the request | Whether a person reviewed it |
| The user approved the command | A person approved the action shown | Whether the approval covered a different command than the one that ran |
| The command returned the file contents | The file was read by the command | Whether the contents were pasted into a prompt or sent to a model |
| A file changed at 14:02 | The file changed | Who or what changed it, without the preceding events |
| The session record stops at 14:03 | The capture ended | Whether the agent continued in another session, a headless CLI run or a cloud agent |
If the record shows the request but not the policy response, you cannot claim the action was authorized. If it shows the policy response but not the outcome, you cannot claim the action happened. If it shows the outcome but not the request, you cannot claim it was the agent's doing.
That is the value of the table: it turns a vague claim ("the agent did it") into a set of testable statements.
Investigate gaps rather than smoothing them over
Every capture system has gaps. The useful question is which ones apply to this investigation.
Cursor's Cloud Agent runs on the backend and is not visible to project hooks. See the cloud hook documentation. Headless CLI mode does not yet run the stop, beforeSubmitPrompt or afterAgentResponse hooks. If the session you are investigating used either path, the record will be incomplete in a specific, documentable way.
Do not fill the gap with an assumption. Record it as a gap: "No hook events exist for the Cloud Agent pull-request tool in this window. The vendor's documentation says those events are not emitted." That statement is itself evidence.
Collect enough context without creating another secret store
An audit trail that stores every prompt in plain text becomes a second place secrets live. That is the wrong trade-off.
Redact secrets and personal data before the record is stored, and keep the original only where you have a reason and a control for it. ReclaimLLM applies local redaction before upload, so the stored record does not hold the secret. See where AI coding transcripts keep secrets.
The record still needs enough context to be useful: the file path, the command, the policy response and the result. A redacted prompt that keeps the tool call and the file path is more useful than a complete prompt stored without access controls.
Where ReclaimLLM helps
ReclaimLLM captures AI coding sessions from Cursor, Claude Code, Copilot, Codex and Antigravity through hooks, and makes them searchable. It records the prompt, the tool calls, the files read and written, and the approval decisions. Search and replay lets you reconstruct a session from those events.
It does not capture what the hooks do not see: the Cloud Agent pull-request tool, headless CLI runs, and any other path the vendor does not instrument. Detection of secrets and external egress in captured sessions runs on an hourly or daily sweep and raises alerts; it does not block. The SOC 2 evidence guide shows what auditors usually ask for (SOC 2 evidence guide).
Review your AI coding evidence coverage.
Read the original article at ReclaimLLM.
