Audit logs are records of important system actions, decisions, and access events. For an agent, that means capturing who initiated a task, what the agent accessed, which tools it called with which arguments, what policy checks ran, what approvals were required, and what changed as a result. The audience is someone reconstructing events later, a different reader from the engineer debugging a failure this afternoon.
Traces show the technical execution path. Audit logs show the governance path. They overlap heavily in an AI system, and the reason to keep them distinct is that their requirements differ: a trace can be sampled, kept for a short window, and read by the whole team, while an audit record has to be complete for the events it covers, retained on a schedule someone chose deliberately, and readable only by people who should see what it contains.
Key takeaways
- Log the events that carry consequence: every tool call with side effects, every data access, every policy decision, every approval, every configuration change.
- Append-only storage with separate credentials is the difference between a record and a set of editable rows. If the application can rewrite history, the log proves less than it appears to.
- The audit log of an AI system holds the prompts and outputs, which is usually the sensitive data itself. That makes it a protected store rather than a byproduct.
- No log makes a system compliant. It produces evidence, which is worth having on its own terms.
What to record
Each event answers a small set of questions. The fields that carry them:
- Who. The authenticated user or upstream system that initiated the work, plus the agent identity that acted. In a delegated setup, both.
- What. The action, the tool or endpoint, the resource identifier, and the arguments that mattered. For a write, the before and after or a reference to them.
- When. A timestamp from a trusted source, with a sequence number so events sharing a millisecond still have an order.
- Under what rule. The policy decision that permitted or blocked the action, the rule that fired, and the policy version in effect.
- With whose approval. If a human approved, who, when, and what they were shown.
- What resulted. Success, failure, or partial completion, and the error if there was one.
- Where to look next. The trace or session identifier, so the event leads back to the execution it came from.
That last field keeps the two systems from duplicating each other. The audit event says a refund of a given amount was issued for a given account by a given agent on behalf of a given user. The trace holds the reasoning, the retrieved documents, and the intermediate calls. Shared identifiers make the jump possible, which is one reason the span, trace, and session vocabulary is worth adopting before you have two incompatible logging schemes.
Immutability and integrity
An audit log is a claim that events happened as recorded, and the claim is only as strong as the reason to believe nothing was altered. Hence the mechanics:
- Append-only by construction. The application writes; it does not update or delete. Use credentials that permit writes and nothing else.
- A separate store. A different database, bucket, or account from the one the application administers, so a compromise or a bad migration in the primary system does not reach the record.
- Tamper evidence. Sequence numbers reveal gaps. Hash chaining, where each record includes a digest of the previous one, reveals edits. Some object stores enforce write-once retention at the storage layer.
- Access logging on the log. Reads of an audit store are auditable events too, and this is usually the last thing anyone implements.
- Deletion as an exception path. Deletion requests and legal holds both reach this store, so deletion has to exist, stay narrow, and leave a record.
Retention has no universal number to copy. The common convention is to decide it deliberately with whoever owns legal and privacy questions, write it down, and enforce it with a job rather than an intention. The pressure runs both ways: keeping records long enough to answer questions about past behavior pulls against keeping personal data no longer than necessary.
The problem specific to AI systems
A useful audit log of an agent contains the prompts, the retrieved context, the tool arguments, and the model’s output. That content is frequently the sensitive material: customer messages, account details, health or financial information, internal documents. The record built to show careful handling of sensitive data is now a well-indexed, long-retained copy of it.
There is no clean escape, only choices with costs:
- Redact or tokenize at write time. Effective, and it degrades the record. A redacted log may not answer the question an investigation actually asks.
- Split content from metadata. Keep the who, what, when, and decision for a long window and the full text for a short one. Most questions are answered by metadata, and the ones that are not tend to arrive soon after the event.
- Tighten access instead of content. Keep the full record, restrict who can read it, and audit those reads. This shifts the burden onto access control being right.
Whichever mix you choose, the store inherits the sensitivity of what it holds, including retention obligations, a deletion path, and residency requirements. That is why the question of where AI telemetry physically lives and who administers it becomes a governance question rather than an infrastructure preference. Regimes such as the EU AI Act and GDPR may apply to what you keep here, and which ones do is a determination for counsel rather than something to infer from a definition page.
FAQ
What should an AI audit log contain that a normal application log does not?
The model and prompt version in effect, the input the model received including retrieved context, the output it produced, the tool calls with their arguments, every policy or guardrail decision, and any human approval. Application logs record that a request happened. For an AI system the content of the request and response is the behavior under review, so a log that omits it cannot answer the questions people will ask.
What is the difference between an audit log and a trace?
Purpose and guarantees. A trace exists to debug execution: detailed, often sampled, short-lived, and readable by the team. An audit log exists to establish what happened: a narrower set of consequential events, never sampled, retained on a deliberate schedule, access controlled. The same instrumentation can feed both, so treating a trace store as an agent observability layer is compatible with deriving audit events from it, as long as the audit path gets its own retention and permissions.
Do we have to store prompts and completions?
For most oversight purposes, some form of them, since the alternative is a record that cannot show what the system did. The real question is which fields, for how long, and who can read them. Field-level redaction, shorter retention for full text than for metadata, and strict read access are the usual controls. Decide it with the people who own privacy questions rather than defaulting to keeping everything forever.
Can an audit log tell us whether the agent behaved correctly?
Only partly. It shows what happened and which rules fired. Whether the outcome was good is a judgment from evaluation and human review, and those verdicts are worth writing back as their own events so a later reader sees the action and the assessment together.
