The Agent Audit Log: What Goes In, What Comes Out

Auditors will ask. The audit-log schema that satisfies SOC2, PCI, and your own future investigation, with retention policy and access-control notes.

What goes in

Every action: who (agent identity), what (action type and args), when (timestamp), why (the reasoning trace, summarised), where (environment, resource).

Every approval: proposal, approver identity, approval reason, timestamp.

Every refusal: what the agent refused to do, why, what triggered the refusal (which guardrail).

Retention policy

SOC2 typically requires 1 year minimum. Many teams keep 3 years. PCI requires longer for financial actions.

Hot logs (90 days): queryable from the dashboard. Warm logs (1 year): queryable via API. Cold logs (3 years): in object storage.

Document the retention. "This log type is retained for X years per Y compliance framework" is a sentence in your audit binder.

Immutability

Append-only writes. The log infrastructure (Loki, Cloud Logging, S3 with object lock) supports this; use it.

Modifications would themselves be logged in a meta-log. In practice, the original log line is never modified; corrections are new entries.

Auditor satisfaction: the auditor can verify that an entry from 18 months ago has not been altered. Object-store object-locks plus checksums satisfy this.

Access control

Read access: scoped by team. The team that owns the agent reads its logs. Cross-team reads require a documented purpose.

No write access except for the agent service itself. Even admins do not write to the audit log directly.

All reads are logged in a separate (also append-only) read-audit log. "Who looked at what audit data when" is itself audited.

Common audit queries

"All actions taken on resource R in the last 30 days." Standard incident-investigation query.

"All approvals by approver A." Standard approval-pattern audit.

"All refusals in the last week, grouped by reason." Operational query that tells you what your guardrails are catching.