AI Agent Audit Logs: What to Record and Example Log Entries

AI Agent Audit Logs: What to Record and Example Log Entries

An AI agent audit log is the record that lets someone answer, weeks later, a plain question: what did this agent do, for whom, with what permission, and what happened? Most teams that search for an AI agent audit log example are not short of logging. They have application logs, model traces and cloud activity logs. What they lack is one consistent entry per agent action that a reviewer can read without reconstructing it from five systems.

This guide is a field-by-field schema with a synthetic example you can adapt. It complements our earlier post on the AI agent audit trail, which covers the design principles. Here the focus is the concrete shape of each entry.

One entry per action, not per conversation

Log each tool call or decision as its own entry. A conversation is a poor unit for audit: it is long, it may contain personal data, and it hides which step caused an effect. Link entries together with a shared identifier instead.

A useful entry answers these questions:

• Who acted: the agent's own identity, such as a service principal or managed identity name, and its version or build.
• On whose behalf: the human or system that started the task, and the customer or tenant scope it was bound to.
• What was attempted: the tool or operation name, taken from a fixed catalogue rather than free text.
• With what inputs: a summary of the parameters, not the raw payload.
• What happened: the outcome, an error code if any, and the size of what was returned.
• Who approved it: the reviewer and decision for any action that changes something.
• Which rule allowed it: the policy decision and the policy version that produced it.
• How to join it up: a timestamp in UTC and a correlation ID shared by every step of one task.

A synthetic example

The entry below uses invented names, a documentation-range IP address and placeholder identifiers. It describes an agent that was asked to disable a stale account and needed approval first.

{
  "timestamp": "2026-10-31T09:42:17Z",
  "correlation_id": "task-7f3a2c91",
  "event_id": "evt-000412",
  "actor": { "type": "agent", "id": "helpdesk-agent", "version": "1.4.2" },
  "on_behalf_of": { "user": "a.example@contoso.example", "scope": "tenant-contoso-demo" },
  "tool": "directory.disable_account",
  "inputs_summary": { "target": "user:j.sample", "reason_code": "stale-90d" },
  "policy": { "decision": "allow_with_approval", "rule": "write-needs-human", "version": "2026-10-01" },
  "approval": { "required": true, "approver": "b.example@contoso.example", "decision": "approved", "at": "2026-10-31T09:41:55Z" },
  "result": { "status": "success", "changed": 1, "error": null },
  "source_ip": "203.0.113.25"
}

Every value is fictional. The point is the shape: a reviewer can see the agent, the person behind it, the single account touched, the rule that permitted it, who said yes and when, and that exactly one object changed.

Field notes

Actor and delegation. Keep the agent identity separate from the person. If both collapse into one "user" field, you cannot tell whether a person did something or an agent did it for them. This is also where least privilege becomes checkable: if the actor's permissions are narrow, the entry should only ever show narrow tools. Our post on AI agent identity and least privilege covers how to scope that identity.

Tool name. Use stable, namespaced identifiers such as directory.disable_account. A fixed catalogue lets you query "every write by any agent this month" and lets you alert on a tool name you did not expect.

Inputs summary. Record identifiers and reason codes, not message bodies, file contents or tokens. If a reviewer genuinely needs the full input, store it in a separate, access-controlled location and reference it by ID.

Result. Record status, counts and error codes. A "success" with zero changed objects is different from one that changed fifty. If results were truncated or paged, say so, so nobody mistakes a partial read for a complete one.

Approval. For read-only tools the field can say required: false. For changes, record the approver, the decision and the time separately from the execution time. An approval that arrives after the action is a finding, and you can only see it if both timestamps exist.

Policy. Store the decision (allow, deny, allow with approval) and the version of the rule set. Without the version, you cannot explain later why an action was allowed under rules that have since changed.

Correlation ID. Generate it when the task starts and pass it through every tool call, model request and downstream API call that supports it. It is the single most useful field for investigations.

Denied and failed actions. Log them too. A denied attempt is often more interesting than a successful one, and an audit log containing only successes cannot show that a control is working.

What not to record

Do not log credentials, access tokens, API keys, session cookies or full prompts that may contain them. Redact before writing, not afterwards. Be careful with prompts and model outputs in general: they can contain customer data, personal data and secrets pasted in by users. Our guide to redacting secrets before AI processing shows a local approach.

If you want a record of prompts for review, treat an AI prompt audit log as a separate store with its own access list, a shorter retention period and a documented purpose. Do not merge it into the general audit log that many engineers can search.

Retention, integrity and access

There is no universal retention number. Choose it from your legal, contractual and investigative needs, and write down why. Longer is not automatically safer, because stored logs are themselves personal and sensitive data. Decide who can read the logs, who can delete them (ideally nobody on the team being audited) and how you would notice tampering, for example by writing to append-only or write-once storage. If you operate under a specific regulation or customer contract, check its logging requirements directly rather than relying on a general guide.

Keep clocks synchronised and always use UTC, otherwise correlating an agent entry with a cloud activity log becomes guesswork.

Check your own entries

Paste a few redacted or synthetic entries into the AI agent audit log checker. It runs in your browser and reports which of the expected fields are present, such as actor, delegation, action, result, timestamp, correlation ID, approval and policy decision, and suggests a schema based on the names you already use. It cannot tell whether your log is complete, tamper-resistant or compliant with any standard, so treat it as a quick gap check, not an assessment. Use synthetic or redacted data only.

A short review checklist

• Does every action produce exactly one entry with a correlation ID?
• Can you tell the agent apart from the person who started the task?
• Are denied and failed actions logged?
• Is every write linked to an approval record with its own timestamp?
• Are secrets and raw payloads excluded?
• Is retention written down, with an owner and an access list?

If you can answer yes to all six for a sample of real entries, you have a usable audit trail. If not, fix the schema before adding more tools to the agent.