Log the user, the agent and version, the repository, each tool call, each file changed, and each approval granted or denied. Keep action records longer than raw prompts, because prompts often contain sensitive text. Set retention by what an investigator or auditor will need, not by what is easy to store.
Two kinds of log
Action records say what happened: command run, file written, tool server called, approval given. They are small, structured, and rarely sensitive.
Content records say what was said: prompts, model replies, pasted logs. They are large, and they can contain secrets, personal data, and proprietary code. OWASP's sensitive information disclosure guidance names security credentials and source code among the data types at risk, which is a fair reason to treat content logs with care.
Treating them differently solves most of the retention argument.
Suggested fields and retention
| Record | Fields | Suggested handling |
|---|---|---|
| Session start | User, agent, version, repo, time | Keep with action records |
| Tool call | Tool, arguments summary, result status | Keep with action records |
| File change | Path, commit or diff hash | Keep with action records |
| Approval | Prompt shown, answer, who, when | Keep with action records |
| Prompts and replies | Full text | Shorter window, restricted access, redact known secret patterns |
Pick the actual durations with your legal and compliance owners. Common drivers are your incident response needs, customer contract terms, and any framework you are assessed against. This post does not set a number because the right one depends on those inputs.
Steps to set it up
- Check what the tool emits. Some tools produce telemetry, some do not. Write down which fields exist before promising anything.
- Send action records to the same place as other security logs so responders do not need a second console.
- Restrict content logs. Fewer people, an access log of its own, and a defined delete date.
- Test a lookup. Pick a recent change and trace it from commit back to the session and approval. If you cannot, fix the gap before rollout.
- Write down who may read content logs and why. Developers will ask, and a clear answer builds trust.
What logging will not do
OWASP is plain on this point: logging, monitoring, and rate limiting will not prevent excessive agency, but they can limit the damage it causes. Logs shorten the time to understand an incident. They do not replace permissions and review. Pair this post with agent audit log fields for tool calls for a deeper field list.
A note on privacy
Logging a person's prompts is monitoring. Tell developers what you collect, who sees it, and how long it stays. Silent collection costs more in trust than it returns in safety.
Safeguard offers compliance and evidence automation and agent identity, which can help you tie actions to an identity and keep the evidence tidy.
Quick check
Do we need to keep full prompts?
Usually not for long. Keep action records, and keep prompts only as long as your investigation needs justify, under tighter access.
What if the tool has no logs at all?
Log what you can around it: git history, proxy logs, and CI records. Treat missing logs as a finding when you evaluate the tool.
Sources
Last reviewed: 19 October 2026.
