AI Agent Audit Trails for SOC2 Compliance

Your SOC 2 auditor walks you into a meeting room with a single, deceptively simple question: "Show me your access controls and audit logs for AI agents."

You reach for your SIEM dashboard. You pull up a log of API calls. But the auditor isn't looking at API endpoints. They're looking for evidence that your organization enforces what each agent is permitted to do, logs when it does it, and can prove you detected anomalies if they happened. If your answer is "our SIEM logs show API traffic" or worse, "we don't have agent-specific logging," you have a finding.

An audit does not treat an agent differently from any other component reaching production. You are asked to prove the control was in force, not to describe it.

SOC 2 Trust Services Criteria: agents are system components

SOC 2 work maps controls to five categories of Trust Services Criteria, and three of them are where agent governance lands. We are not quoting those criteria and we have not had them in front of us. What follows is what came up in the one auditor conversation we have had. Map it against the criteria you are being audited against, with your own auditor.

CC6: Logical and Physical Access Controls

The questions here are about access: what may reach a system, and how that boundary is enforced. For agents that means each one has an identity you can verify, each one is granted specific tools rather than a role, and the decision is made before the action runs.

In practical terms: if a Claude agent holds a database tool and a filesystem tool, you will be asked to show which tools that agent is allowed, and to show the boundary being enforced at the moment it reached for one.

CC7: System Operations and Monitoring

Operations come next: what is watched, what counts as an exception, and what happens when one is found. For agents that means tracking the actions they attempt rather than the text they produce, and recording whether each one was allowed or denied.

An append-only audit trail with per-agent logging is the artefact an auditor asks for here. Read the criterion you are being audited against; we are not quoting it. A SIEM alert that fires after an agent has already deleted files does not.

CC8: Change Management

Change is the third: who authorized an edit to a policy, when it happened and what it replaced. For agent governance that is the set of tools each agent can reach and the conditions attached, kept under version control.

If a policy that allowed Agent A to call Tool X is removed, your audit trail needs to show when that change was made, who authorized it, and what the old policy was.

What auditors expect as evidence

Evidence for access control enforcement (CC6)

The artefacts asked for are an agent registry showing each agent's identity, the document saying which tools each agent may reach, and rows proving the decision was made at the time and enforced. The questions behind them are which agents are in production, what each one is permitted to do, and show me a deny decision with a timestamp.

Evidence for continuous monitoring (CC7)

Auditors need an exportable audit log of system activity: every action attempted by every agent, timestamped, with the policy decision (allow or deny) recorded alongside it. The log must be append-only and must survive agent process restarts or crashes.

Evidence for change management (CC8)

A change log showing when a policy was modified, what changed and who made the change. For a permission that lets an agent delete files: when it was added, who asked for it, and whether it was approved.

Building an auditor-ready audit trail: step by step

What an audit trail has to hold to answer those questions, in the order you would build it.

Step 1: Register agents with unique identities

Create a central registry of agents in production. Each agent gets a unique identifier: a UUID or API key that travels with every action it takes. This is the foundation of everything that follows. Without it, you cannot attribute actions to specific agents.

Document what each agent is for, who owns it, and what its intended scope is. This becomes the baseline of your audit trail.

Step 2: Route all agent traffic through a policy enforcement layer

Don't let agents call tools directly. Interpose a proxy between the agent and every tool it uses. When the agent attempts a tool call, the proxy evaluates it against your policy layer before forwarding it.

The proxy enforces: is this agent permitted to use this tool? Is the tool call request valid? Are the parameters within expected bounds? If any check fails, block the action and return an error to the agent.

Step 3: Log every decision with rich context

Every allow and deny decision is written to an append-only, hash-chained audit log the moment the decision is made. The log record includes: agent identity, action type, tool name, parameters (sanitized if they contain sensitive data), policy rule that was evaluated, decision (allow/deny), timestamp, and any violation details.

This is the evidence for CC6 and CC7. It's also your forensic tool if something goes wrong.

---

With those three in place you can show an auditor the rows they ask for. Without them you reconstruct the rows under time pressure, which is where findings come from.

Common mistakes that create findings

What of this a proxy log can answer

None of this makes Intercis certified. What your auditor gets is a queryable, hash-chained record of the governed tool calls, and you do not rebuild an agent or a tool to produce it. Assembling the evidence package is still your job.

When you run agents through Intercis, we:

• Register and track agent identity: each agent gets an identity in your Intercis account. A tool a hosted MCP server runs is observed, not governed: it writes one observe row and is never judged or blocked.
• Run the deny list at the proxy layer: we sit between your agents and the LLM API, and each tool call that crosses it is judged before your runtime can act on it.
• Log each decision where the agent cannot reach it: every allow and deny is written to an append-only trail, hash-chained per tenant, with what was attempted, what rule was evaluated, what the decision was and why. Tamper-evident, not tamper-proof.
• Give you the rows: the events table is queryable per tenant, so you can pull an audit window out of it. There is no evidence-package generator and no one-button report.
• Keep pending as a verdict: the audit table holds it for a call that would need human review. No reviewer loop is wired to it, and nothing here scores an agent against a baseline.

You point your agent at our proxy. That is one line of configuration; nothing else in your agent changes.

When your SOC 2 auditor asks what the agent did, these rows answer it. Whether your controls are certified is a separate question, and ours are not.

Starting your agent audit trail

If you're running AI agents in production and you're preparing for a SOC 2 audit (or if you're already in one and your auditor asked about agent controls), start here:

• Inventory your agents. What are they called? What tools do they use? Who owns them?
• Write down what each agent is allowed to do, and what it is not.
• Implement enforcement. Don't let agents call tools directly; route everything through a policy layer.
• Log where the agent cannot reach. Every decision is recorded to a system the agent does not control.
• Prepare evidence. Export logs and policies in a format auditors can review.