Agent audit trails vs. LLM observability

An agent audit trail is a set of retained records used to reconstruct what an agent did and which decisions allowed or stopped it. LLM observability and agent observability use signals such as logs, metrics, and traces to understand application behavior, performance, usage, and failures.

A trace might explain why an export was slow; an audit record might show who requested it and why access was granted. The same event can serve both purposes, but an investigation may need records that performance monitoring samples out. OpenTelemetry's observability primer introduces traces, metrics, and logs.

Explore Dome: Audit · Docs: Audit events.

Start with the question you need to answer

Suppose a customer record was exported during an agent run. An operator asks why the run was slow. A security reviewer asks which agent requested the export and which decision permitted it. A business owner asks whether the export actually completed.

Distributed tracing follows a request across instrumented components. Audit logging records events intended to support accountability and reconstruction. Audit provenance tells you where those records came from and how the identities and facts in them were verified.

For the export, a correlation ID can connect the gateway's access decision to the backend's result. Document where the ID comes from and how it travels between components. The linked records still need verified identities and a reported outcome; the ID itself supplies neither.

Explore Dome: Audit · Docs: Audit events.

Check for gaps in the records

Sampling can reduce telemetry volume while preserving useful performance information. An investigation into every access attempt has a different requirement. Missing events cannot be treated as evidence that no request occurred.

Write down which routes, event types, identities, and time period the investigation needs to cover. Then check what may be missing because of collection failures, delayed events, pagination, export limits, or retention policies.

Audit completeness depends on which activity the system was meant to capture. A complete export of one gateway's records does not establish that an agent never used another route. A tamper-evident store can help reveal changes to retained records without proving that all relevant events were captured in the first place.

Keep only the prompt, argument, and response data the investigation needs. Logging the full export, for example, could create another copy of sensitive customer records. Restrict who can read the retained data.

Explore Dome: Audit · Docs: Audit events.

Decide what to record before an incident

For the export example, specify the agent identity, represented subject when applicable, resource, action, decision, policy reference, time, correlation information, and known outcome. Mark unavailable fields explicitly rather than filling them with inferred values.

Dome's audit documentation describes event querying, filtering, and export behavior for its governed activity. Use the documented fields and coverage to determine which questions those records can answer. Check the backend to find out what actually happened after the access decision.

For each investigation question, list the records that can answer it and any gaps in their coverage. Incident response explains how to use those sources during an event. Cost allocation explains how usage records contribute to financial attribution.

Explore Dome: Audit · Docs: Audit events.