Audit log

A chronological record of security- or business-relevant events in a run, including the actor, operation, target, result, time, and correlation identifiers needed for investigation.

An audit log records the events a team has chosen to make reconstructable. An inbox run might log which account and rule labeled a message, whether the provider accepted the request, and the run identifier that connects the event to its inputs. A useful record distinguishes requested actions from completed effects and preserves failures and skips. It should also redact secrets and limit access, because logging entire prompts or records can create a second copy of sensitive data.

Builder example

Audit records support incident investigation, compliance evidence, debugging, anomaly detection, and rollback decisions. They are stronger when the agent cannot silently rewrite them and when external system identifiers confirm the effect. No log is complete by default: missing events, clock drift, sampling, retention limits, or a compromised logger can leave gaps.

Common confusion: Logging observes and records; it does not necessarily block an action. Approval gates, permission checks, transaction controls, and rollback solve different parts of the problem. A workflow may need any combination of them based on the consequence and evidence required.