Notifications
Clear all
Topic starter
02/09/2026 1:29 pm
TL;DR: Chat history does not provide a defensible record of AI agent behaviour, because it omits tool calls, arguments, authentication, policy decisions, and results; Obot’s guide argues that a per-call audit trail is the practical source of truth for troubleshooting, security review, and compliance. The governance gap is that agent actions can change systems without leaving enough evidence to reconstruct who or what acted.
NHIMG editorial — based on content published by Obot: AI agent audit trails need tool-call records, not chat history
Questions worth separating out
Q: What should teams log for each AI agent tool call?
A: Teams should log the tool-call identity chain, including call ID, session and parent IDs, actor details, server and tool name, arguments hash, result status, timing, authentication, and policy decision.
Q: Why is a per-call audit trail more useful than chat logs for AI agents?
A: A per-call audit trail captures state-changing events, while chat logs capture intent.
Q: Where should AI agent audit logs be stored for security review?
A: Store them at the control point that already sees the request, the identity, and the policy decision, such as a gateway or central log sink.
Practitioner guidance
- Implement per-tool-call audit records Capture a record for every tool invocation with call ID, session ID, parent linkage, actor identity, server, tool, arguments hash, result status, duration, authentication, and policy decision.
- Use hashes to support redaction and integrity Store hashes for arguments and results when the full payload is too sensitive or too large.
- Centralise records in the policy layer Write audit events at the gateway or control plane that already sees the user, the policy, and the tool call.
What's in the full article
Obot's full guide covers the operational detail this post intentionally leaves for the source:
- A copyable JSON schema for one record per tool call, including the fields to log and how to structure them.
- Practical advice on what to redact, what to hash, and how to keep audit records usable for later verification.
- Guidance on where to store records, including gateway-based logging and central sinks such as Loki or a database.
- Examples of how Obot maps gateway policy decisions, request metadata, and LLM gateway telemetry into an audit trail.
👉 Read Obot's guide to AI agent audit trails and tool-call logging →
AI agent audit trails: what should teams log and where?
Explore further
02/09/2026 1:30 pm
AI agent auditability is now an identity control, not a logging preference. Once a system can select tools and alter state through MCP or similar pathways, the question becomes who or what acted, under which identity, and under which policy. That makes the audit trail part of the identity governance stack, alongside authentication, authorisation, and lifecycle control. Practitioners should treat audit design as a control requirement, not an observability afterthought.
A few things that frame the scale:
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface report.
- Only 44% of organisations have implemented any policies to govern AI agents, even though 92% say that governance is critical to enterprise security.
A question worth separating out:
Q: How do organisations keep AI agent audit trails useful without over-logging?
A: Minimise sensitive payloads, but keep the fields needed for traceability, such as hashes, policy decisions, authentication context, and timing. If full results are too large or sensitive, store references and hashes separately with shorter retention. The goal is evidence, not duplication of the entire response body.
👉 Read our full editorial: AI agent audit trails need tool-call records, not chat history
