AI agent audit logs and compliance: what to record for SOC 2
“Can you enumerate every credential your agents accessed this quarter?” For many teams, that question arrives during a SOC 2 audit and gets an uncomfortable answer. Human access is well logged — SSO events, VPN sessions, vault audit trails. Agent access usually is not. An AI agent that reads your source, runs commands, and resolves API keys operates under your existing identity, with no separate audit trail of its own.
Where agents break the audit trail
The SOC 2 trust services criteria care about access to sensitive data and about monitoring that access (the common criteria for logical access and system monitoring). Agents complicate both in specific ways:
- Attribution is fuzzy. Was it the developer, or the agent session they spawned? Commands run by an agent were decided by a model influenced by its context — the record needs the invoking context, not just a username.
- Access comes in bursts. One agent session can resolve dozens of credentials in minutes, headless and at odd hours. Individual resolutions are invisible without per-event logging.
- Shared identity. Agents run as the developer’s user or a service account, so existing logs cannot distinguish “human ran a command” from “agent ran a command”.
What to record
A practical baseline for agent credential access:
- Resolutions — which credential was resolved, when, and by which invocation. Timestamps in UTC; the credential identified by name, never by value.
- Failures — invalid sessions, denied injections, failed unlocks. Failures are early-warning signals: a credential that stops resolving is often revoked, expired, or under attack.
- OAuth lifecycle — login, refresh, reauth_required. A spike of refresh failures indicates revoked tokens or a policy change upstream.
- DLP events — outbound pattern hits, with the mode (log vs mask). A hit in log mode is a secret that almost left the machine.
- Scrub operations — what was redacted and from where, for the erasure layer of your defense.
What to leave out
Never log token values. A log that contains secrets is a new exfiltration
channel, and an auditor will notice. Event records should identify the
credential by name and outcome, not carry the material itself. “The broker
resolved key prod_database at 03:12 UTC” is a compliance record; the value
is not.
Properties of a compliance-ready log
- Append-only. The audited process must not be able to rewrite its own log.
- Restricted. 0600 permissions on the file, or journald for system-managed storage with its own access controls.
- Rotation-safe. The logger should reopen its file on SIGHUP so logrotate does not silently drop events mid-rotation.
- Machine-readable. JSONL feeds SIEM queries and alerting — “three failed unlocks in a row” should be something you can detect, not something you notice in hindsight.
The test
A useful rehearsal: an incident review asks “did an agent access the production key during that session?” If the honest answer requires digging through shell history, you do not have audit logs — you have hope, and a SOC 2 examiner will find the gap.
trustless writes append-only JSONL audit events — proxy.inject, proxy.deny, run.spawn, dlp.redact, oauth.refresh, oauth.fail, oauth.reauth_required — at 0600 with SIGHUP reopen for logrotate, or to journald, and never records token values. The audit command is documented in the command reference.
When the next audit asks what your agents touched, the answer should be a query, not a guess. Have you checked what your agent environment logs today?