Log enough to reconstruct what an AI system did and who allowed it: the identity behind the request, model and version, tool calls with arguments and results, approvals, and the final output. Protect the logs, redact secrets and personal data, and set a retention period before you start collecting.
Why audit logs for AI look different
A normal service log records requests and errors. An agent decides its next step from text, so the sequence of prompts, tool calls and results is the explanation for what happened. Without it, you can say that a database row was deleted, but not why the agent chose to.
The EU Commission lists logging of activity to ensure traceability of results among the obligations for high risk AI systems, which shows how regulators think about it. Even if you are outside that scope, the same record helps incident response.
What should each record contain?
A workable record has these fields: a timestamp; the user or service identity, and the agent identity if separate; the model name and version, or provider alias with the resolved version; the prompt or a reference to a stored prompt; retrieved documents by identifier; each tool call with name, arguments and a result summary; any approval, with approver; the output; and a request identifier linking the lot.
Store large bodies separately and reference them by hash, so the log stays searchable and the sensitive material has its own tighter access controls.
What should you keep out?
Secrets, and personal data you do not need. A tool result may contain a token, and a prompt may contain a customer's details. Redact on write, not on read. Be careful with full transcripts in general logging tools, where more people have access than should.
Decide retention with legal and privacy. Long retention helps investigations and raises exposure. Short retention limits harm and loses evidence. Pick a number, write down the reason and review it.
How do you protect the log itself?
Treat it as sensitive. Restrict reads, record access to the logs, and make writes append only or tamper evident where you can. NIST's secure development profile for generative AI, SP 800-218A, extends the Secure Software Development Framework to AI, and records that support accountability are part of that thinking.
A constructed example
An internal agent with permission to create cloud resources provisions a large cluster overnight. The cost alert fires. The team opens the trace: a user's request, a planning step, three tool calls with arguments, and an approval step that was skipped because the request came through an automation account marked as pre-approved. The cause is a permission design flaw, found in ten minutes because each step was recorded.
What to do
- Define the minimum fields above and make logging part of the agent framework, not each developer's choice.
- Record agent identity separately from the human who started the task.
- Capture tool arguments and result summaries, and store large bodies by reference with a hash.
- Redact secrets and personal data before writing.
- Restrict and log access to the log store, and make records tamper evident.
- Set and document retention with legal and privacy.
- Test: pick a past agent action and time how long it takes to reconstruct it.
- Alert on tool calls outside expected patterns.
Safeguard's MCP Guardrail and guardrails feature give a point to observe and control tool calls, and policies and gates can record decisions. Choose logging storage that fits your own retention rules.
Quick check
Should you log full prompts?
Often yes, by reference and with redaction and tight access, since the prompt explains the action. Set retention first.
What is the most useful single field?
A request identifier that links the prompt, retrieval, tool calls, approvals and output into one trace.
Sources
- European Commission, regulatory framework for AI
- NIST SP 800-218A
- OWASP GenAI, LLM06 Excessive Agency
Last reviewed: 18 October 2026.
