What should you log from AI prompts and tool calls for audit?

For audit, log who triggered an AI action, which agent and model acted, which tool it called with what arguments, what came back, and the outcome, all with timestamps and a correlation ID. Store raw prompt text only where you have a reason, because those logs can hold secrets and personal data.

Why log tool calls at all?

When an agent changes something, the question afterward is what exactly happened. The model's own account is not evidence. A record written by the system that executed the call is. NIST SP 800-92 treats log management as a discipline with its own generation, storage, analysis and disposal steps, and that applies here as much as to servers.

NIST SP 800-61 Revision 3 on incident response also depends on having data to investigate. Teams that skipped logging find themselves guessing.

What fields belong in each record?

Think of one record per event, with these fields:

• Time, in UTC, with a unique event ID and a trace ID that ties a whole run together.
• The human or system that started the run.
• The agent identity and the model name and version.
• The tool name and the arguments passed.
• The result status, and a summary or hash of the response, not always the full body.
• Any approval: who approved, when, and what they saw.
• Policy decisions: allowed, blocked or escalated, and which rule fired.
• Token counts and cost if you track them.

A constructed example

A finance agent drafts payment batches. An auditor asks who approved a batch last Tuesday. With good logs you find the trace: user A asked, the agent called the draft tool with a batch ID, a policy required approval, user B approved at a recorded time, and the payment API returned success. Without the approval field and the trace ID you would be piecing it together from chat history.

What about prompt text?

Full prompts help debugging and investigation, but they can contain customer data, credentials or confidential code. Options, in order of caution: log metadata only, log a hash so you can confirm a known text later, log redacted text, or log full text for a short window with tight access. Choose by risk, and tie the period to your retention policy. GDPR Article 5 storage limitation is a useful reminder not to hold personal data longer than needed.

How do you protect the logs?

Treat them as sensitive. Restrict read access, send them to a store the agent cannot write to or alter, record access to the logs themselves, and sync clocks. If an attacker or a misbehaving agent can edit its own trail, the trail proves little.

How to implement

1. Define the event schema above before writing code.
2. Emit logs from the tool or gateway layer, not from the model's output.
3. Generate a trace ID at the start of each run and propagate it.
4. Redact secrets and obvious personal data before storage.
5. Write to an append only or access limited store.
6. Set retention by log type: metadata longer, raw text shorter.
7. Alert on blocked calls and unusual volume.
8. Test by asking an audit question and answering it from logs alone.

Safeguard's MCP Guardrail and audit related features are designed to record and control tool calls passing through them; confirm coverage for your setup.

What should you alert on?

Start with blocked tool calls, since a blocked call means a model tried something outside policy. Add sudden volume changes per agent, first time use of a sensitive tool, calls outside normal hours, and repeated failures. Also watch for approvals granted unusually fast, which can indicate rubber stamping. Review a small sample of runs by hand each week; reading real traces teaches more than dashboards. Keep alert rules in version control so changes are reviewed, and test them by replaying a known bad run to confirm the alert fires.

Quick check

Sources

• NIST SP 800-92, Guide to Computer Security Log Management
• NIST SP 800-61 Rev. 3
• GDPR Article 5

Last reviewed: 18 October 2026.