Observability and Audit Logging for AI Agents

When a conventional service fails, you read a stack trace. When an agent produces a wrong or harmful result, there is no stack trace: the "logic" was a series of model decisions. Without detailed records of what the agent saw, decided and did, you cannot debug it, you cannot investigate an incident, and you cannot show an auditor what happened. This guide explains what to log and how to do it responsibly.

Three purposes, one data source

• Debugging and quality: why did the agent choose that tool, and where did the reasoning go wrong?
• Security: was this action the result of an injected instruction, and what else did that session do?
• Compliance and accountability: who authorized what, and can we prove it?

A single well-structured trace serves all three.

What a trace should contain

Model each task as a trace made of spans, one per step. A common structure follows the OpenTelemetry approach: a root span for the task and child spans for each model call and tool call, all sharing a trace ID.

For every model call record:

• Model name and version, parameters (temperature, max tokens)
• Prompt template version
• Input and output token counts and latency
• The inputs and outputs themselves (subject to the redaction rules below)
• Finish reason (stop, length, tool call)

For every tool call record:

• Tool name, server or version
• Arguments (validated) and result (or a reference to it)
• Duration and error status
• The authenticated user and agent identity
• Whether human approval was required, who approved, and when

For the task record:

• Task ID, user, tenant, start and end time
• Total steps, tokens and cost
• Outcome (success, failure, canceled, hit limit)

{
  "trace_id": "9f2c...",
  "span": "tool.send_email",
  "user": "u_1842",
  "agent": "support-actor",
  "args": { "to": "customer@example.com", "template": "refund_confirm" },
  "approval": { "required": true, "by": "u_1842", "at": "2026-10-10T14:03:11Z" },
  "result": "ok",
  "duration_ms": 412
}

Correlation is everything

Use one ID that follows the task through every component: the user request, each model call, each tool call, and downstream service logs. In multi-agent systems, include the parent span so you can reconstruct who delegated to whom (trust boundaries). Without correlation you will have thousands of unlinked log lines.

Protect sensitive data in logs

Agent logs contain prompts, documents and tool results, so they can hold personal data, business secrets and credentials.

• Redact secrets and credentials before writing, with pattern-based scrubbing and by keeping secrets out of the model context in the first place.
• Mask personal data where you do not need it, or store it in a separate, more tightly controlled store referenced by ID.
• Control access to logs as you would to the underlying data. Not every engineer needs to read customer conversations.
• Define retention. Keep full content for a limited period (for example, weeks), and keep metadata such as tool calls and approvals longer for audit needs. Align with your privacy commitments.
• Make audit logs tamper-resistant. Send them to append-only or write-once storage so they cannot be edited after an incident.

Detect problems with the data

Turn logs into alerts:

Review a sample of traces regularly. Reading real runs reveals failure patterns that dashboards miss.

Feed logs back into testing

Every significant failure becomes a test case in your evaluation suite (evaluating agents). Store anonymized failing traces so you can replay them after a fix.

Compliance value

Auditors for frameworks such as SOC 2 want evidence that access is controlled and changes are reviewed. Agent logs showing identities, approvals and actions are direct evidence, and can be collected automatically (SOC 2 evidence automation).

Starting point

If you do nothing else, log for every task: who, what the agent was asked, each tool called with arguments, each approval, the result and the cost, all under one trace ID, with secrets redacted and a retention period. That small set answers most of the questions you will be asked after something goes wrong.