Your AI agent took an action. Who can prove it, and when?
That question is the whole SOC 2 audit, compressed. An auditor does not care that your agent is smart. They care whether you can show, after the fact, what it did, on whose behalf, and against what data. Most agent deployments cannot answer this. The logs were never designed for it.
This post is about the gap between "the agent works" and "the agent is auditable." They are not the same project. We learned this building agents in production, and it is the part teams skip until an auditor or a customer security review forces the issue.
What the auditor is actually asking
A SOC 2 auditor maps to a handful of controls. For agents, three matter most.
Access. Who or what triggered this agent run, and were they authorized? The agent is a new principal in your system. It has credentials. It calls APIs. The auditor wants those credentials scoped, rotated, and attributed to a real identity, not a shared key in an env var.
Activity. What did the agent do, step by step, with timestamps? Not just the final answer. The tool calls. The data it read. The action it took on an external system. If your agent can send an email or update a record, that write needs a log line.
Change. Who changed the agent's instructions, and when? The system prompt is config. A prompt edit can change behavior more than a code deploy. If it lives in a Notion doc with no history, you have a finding.
None of this is exotic. It is the same access-activity-change triad you already apply to humans and services. Agents just slipped in without it.
Why agent logs are usually wrong
Most teams log the wrong layer. They capture the LLM request and response, because that is what the SDK hands them. That tells you what the model said. It does not tell you what the system did with it.
The thing an auditor cares about is downstream. The agent decided to call `refund_order`. Did it? With what arguments? Did the call succeed? Who could see that it happened? A transcript of model tokens answers none of those.
Three failure modes show up over and over.
The log stops at the model boundary. You have prompts and completions, no record of the tool execution that followed.
The agent runs as one shared service account. Every action attributes to "the bot." You cannot tie a run back to the user or job that started it.
The system prompt is untracked. It changes with no diff, no author, no timestamp. The auditor asks "what was the agent told to do on March 3," and nobody knows.
Each of these is fixable. None of them fixes itself.
What good looks like
Aim for an audit trail that reads like a story without you reconstructing it.
Give every agent run a correlation ID. Stamp it on the trigger, every tool call, and every downstream write. One ID, end to end, so the run is queryable later.
Log tool calls as structured events, not prose. Capture the tool name, the arguments, the result status, the principal, and the timestamp. Store them where they cannot be edited after the fact.
Scope the agent's credentials tight and per-purpose. A read-only agent gets read-only keys. An agent that writes to one table gets exactly that. Least privilege is easier to log because the log surface is smaller.
Version the system prompt in git. Treat instruction changes like code changes, with review and history. Now "who changed it and when" has an answer you can hand over.
Retain the events long enough to cover your audit window, in storage your auditor trusts. Append-only is the goal. CloudTrail, an immutable log bucket, or a dedicated table all work.
Build it in, not on
The cheap time to do this is before the agent ships. Retrofitting audit logging onto a live agent means re-plumbing every tool call. Building it in costs days. Bolting it on costs weeks and a stalled deal while a customer's security team waits.
We build agents this way by default. Our OpenClaw Installation stands up an agent with the trail wired in: correlation IDs, structured tool-call events, scoped credentials, versioned prompts. One agent we built answers support questions in 12 minutes, down from 4 hours, and every action it takes is attributable. Fixed price, you own the code, we exit. No retainer holding your logs hostage.
We are a 2-person team, ex-AWS, with 17 cloud certifications between us. We have shipped 10 production products in 7 months, so this is the day-job pattern, not a slide.
If your agent works but cannot survive a security review, that is a known, finite fix. Book a free 30-minute call and we will tell you exactly which of the three gaps you have.