For an AI agent, log who asked, which tool it called with what arguments, what came back, whether a human approved, and which identity the action ran as. Keep the records tamper resistant and reviewable. OWASP advises logging and monitoring extension activity so undesirable actions can be caught.
Why log at the tool boundary first?
A model's chat text is the least reliable record of what happened. The tool call is the event that touched a database, a ticket system or a file. If you can only log one thing, log that.
OWASP's guidance on excessive agency treats logging as damage limiting. It says to log and monitor the activity of LLM extensions and downstream systems so undesirable actions can be identified and responded to. It lists other controls first: minimise extensions, minimise their functions and permissions, avoid open ended tools such as shell access, run actions in the user's context, require human approval for high impact actions, and enforce authorization in downstream systems. Logs do not replace those. They tell you when those controls were not enough.
What fields does each record need?
Think of one tool call as one record. A useful minimum:
- A timestamp from a trusted clock, and a unique id for the call.
- A session or run id that ties the call to the request that started it.
- The human or service identity behind the request, and the identity the tool actually ran as. These are often different, and the gap is where trouble hides.
- The agent name and version, and the model identifier in use.
- The tool name and its arguments. Redact secrets and personal data at write time.
- The result status, and a size or hash of the output rather than the full output when it is sensitive.
- The approval record when a human gate applied: who approved, when, and what they were shown.
- The policy decision, such as allowed, denied or escalated, and which rule decided.
What should you not log?
Raw prompts and tool outputs often contain customer data, credentials and internal documents. Writing all of it to a log store creates a second copy of your most sensitive material, with weaker access controls than the original. Decide per field. Hash or truncate where you can. Store full content only where you have a reason and a retention limit.
Where does older log guidance still help?
NIST SP 800-92, the guide to computer security log management from 2006, is general rather than AI specific. It covers setting up log management infrastructure and running the processes around it, and says it is not a step by step guide to any logging technology. It still gives you the shape of the job: generation, transport, storage, analysis and disposal. Your agent logs are logs, so those fundamentals apply to them.
How do you make the trail trustworthy?
A trail you can edit is a story, not evidence. Send records off the agent's host as they happen. Give the agent's own credentials no permission to delete or rewrite them. Use append only storage if your platform offers it, and set retention to match your regulatory and investigation needs, written down in advance.
Also record denials. An agent that tried something and was refused is the most useful signal you will get.
What do you review, and how often?
Logging nobody reads is storage cost. Pick a few questions and run them on a schedule.
- Which tools are used most, and are any unused ones still enabled?
- Which calls ran as a more privileged identity than the requester?
- Which approvals took under a few seconds, suggesting rubber stamping?
- Which calls were denied, and from which sessions?
- Which arguments contain patterns that look like secrets?
Alert on a short list: a first use of a sensitive tool, a burst of calls, and any action against a system outside the agent's stated purpose.
What to do
- Inventory every tool each agent can call, and remove what it does not need.
- Define the record fields above and agree them with whoever will investigate incidents.
- Log at the tool boundary, with identity, arguments, result status and approvals.
- Redact secrets and personal data before writing.
- Ship logs off host to storage the agent cannot modify.
- Set and document retention.
- Log denials and escalations as well as successes.
- Schedule a weekly review using the questions above, and test it with a drill.
Quick check
What is the single most useful thing to log?
The tool call: which identity ran it, with what arguments, and what status came back. That is the event that touched a real system.
Does logging replace limiting what the agent can do?
No. OWASP lists minimising extensions, permissions and open ended tools, and requiring human approval for high impact actions. Logging helps you detect and respond when those fall short.
Sources
- OWASP LLM06:2025 Excessive Agency, fetched 18 October 2026.
- NIST SP 800-92, Guide to Computer Security Log Management, fetched 18 October 2026.
Last reviewed: 18 October 2026.
