If an AI agent sends the wrong message, changes a record or generates unexpectedly high costs, the last model response is not enough to determine what happened. You need a traceable sequence: the task, sources used, model route, tool calls, approvals, errors and result.
A technical trace and an audit log serve different purposes. The trace supports debugging. The audit trail answers who or what caused which effect, when and with what permission.
Which Events Belong in an Audit Trail?
For operational agents, at least the following events are relevant:
- the identity of the user and the agent,
- the purpose and ID of the workflow,
- the model and prompt version used,
- sources retrieved and the permission decision,
- tool name, parameters, result and error status,
- human approval or rejection,
- the final effect in the target system,
- costs, runtime and reason for termination.
Not every detail has to reside in the same log. What matters is a shared trace ID that makes it possible to reconstruct the chain of events.
Raw Prompts Are Not Automatically the Right Answer
Complete prompts and tool outputs make debugging easier, but they may contain personal data, trade secrets or access credentials. Logging everything by default creates a second sensitive data system.
For each field, therefore, define whether it is stored in full, masked, hashed, summarised or not stored at all. For many audit questions, the ID of a source or record is sufficient instead of its full content.
Immutability and Corrections
Audit data should not be silently overwritten after the event. Corrections require a new entry that references the earlier one. Access to logs must be governed separately from access to agent operations.
This does not mean that logs should be retained indefinitely. Retention periods, deletion obligations and legal requirements still apply. Immutability within a defined period and controlled deletion afterwards are compatible.
Separate the Model Response, Tool Effect and Business Outcome
An agent can formulate a correct tool request while the target system rejects it. Conversely, a tool can return a successful response while the business outcome is wrong. Record separately:
- what the model proposed,
- what the runtime allowed,
- what the tool reported,
- what was actually changed in the target system.
This separation prevents a successful HTTP status from being mistaken for a correct outcome.
Use Audit Logs for Evaluation
Well-structured logs are useful for more than incidents. They provide real test cases: repeated retries, frequently rejected approvals, unsuitable sources or expensive routes. These cases can be turned into regression tests.
Use production data only within the agreed data protection boundaries. For evaluations, content can be anonymised or replaced with representative test cases.
What Belongs in Management Reporting?
Executives do not need raw traces. Operational reporting should show:
- the number and type of agent actions performed,
- the proportion of actions approved by humans,
- aborted or blocked attempts,
- errors and recurring causes,
- cost per successful workflow,
- open risks and changes to rules.
This turns the audit trail into a management instrument rather than a data archive opened only after an incident.
Sources
- NIST, AI Risk Management Framework: https://www.nist.gov/itl/ai-risk-management-framework
- OpenTelemetry, Traces: https://opentelemetry.io/docs/concepts/signals/traces/
- OWASP Logging Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Logging_Cheat_Sheet.html
- Federal Data Protection and Information Commissioner: https://www.edoeb.admin.ch/
Next Step
Define ten events that must be visible in the audit trail for one agent. For each field, decide whether to store its content, a reference or a hash. Then simulate an error and verify whether an independent person can reconstruct the sequence without access to the development system.