How to pass a SOC 2 audit when you deploy AI agents

Your company ships AI agents. Your auditor has never reviewed an AI agent system. Your existing SOC 2 controls were written when every production action was taken by a human operator or a deterministic cron job. The audit window opens in six months. Now what?

The good news: SOC 2’s Trust Services Criteria (TSC) are technology-neutral. Nothing in the standard says “you can’t use AI.” The criteria care about controls and evidence, not about which kind of process executes the action. The bad news: the default posture of most LLM agent stacks — opaque reasoning, unstructured logs, no enforcement — fails those controls out of the box. This guide walks through exactly what to change.

What an auditor actually asks

A SOC 2 Type II audit tests whether your controls operated effectively over a period (typically 6–12 months). The auditor will not ask abstract questions about “AI safety.” They will ask concrete ones, usually mapped to the Common Criteria (CC) series:

• CC6.1 (logical access): Who or what initiated this action? Was the initiator authorized? How is that authorization enforced?
• CC7.2 (system monitoring): How would you detect that an agent performed an unauthorized or anomalous action?
• CC7.3 (incident response): When an agent misbehaves, how is it contained, investigated, and reported? Show me the last three incidents.
• CC8.1 (change management): How are agent policies, prompts, and tool permissions changed? Who approves? Where is that recorded?

Each question needs an answer backed by artifacts — logs, tickets, sign-offs — that an independent person can sample and verify.

“The model did it” is not an audit answer

The single biggest source of SOC 2 friction for AI-agent teams is the temptation to describe the model as the actor. It is not. The model is a subsystem inside your service, operated on behalf of a principal (a user, a service account, an organization). That principal is who the auditor cares about. “The LLM decided to send the email” is a scope admission, not a control. Every action an agent takes must be traceable to an authorized principal, executed under a policy, and recorded in an append-only audit log. If any of those three properties are missing, you have a finding.

The four evidence artifacts

Strip away the framework-specific language and SOC 2 for AI agents comes down to four artifacts. If you can produce these on demand, the audit is a formality.

1. Policy-decision records

Every tool call an agent attempts must pass through a policy engine, and every evaluation must be logged: which policy fired, with which inputs, what the decision was, and why. This is the control that satisfies CC6.1 (authorization) and is the backbone of every other artifact. The record should be queryable by agent, policy, time range, and outcome (allow / deny / require-approval).

2. Approvals with user identity

When an agent action required human approval, the record must show which human approved it, at what time, and based on what information. Auditors will sample specific approvals and ask for the chain: the original request, the policy that required approval, the human decision, the execution outcome. A Slack message with an emoji reaction does not count; the approval must be durable and tied to an authenticated identity.

3. Incident timelines

CC7.3 wants to see that when something goes wrong, you notice, respond, and document. For agent systems “something goes wrong” means: blocked actions spiked, an injection attempt was detected, a policy was violated, a cost budget was breached. Each incident needs a timeline (first signal → triage → containment → resolution), an owner, and a post-incident writeup. Auditors don’t expect zero incidents; they expect rigorous handling of the ones that happen.

4. Retention of at least 1 year

A SOC 2 Type II audit looks backward over a 6–12 month window. If your policy-decision logs, approval records, and incident artifacts get purged at 30 or 90 days, the auditor cannot sample them. 365-day retention is the effective minimum and is one of the first things asked for during audit kickoff. Some auditors will accept shorter retention for non-critical telemetry if you can show that critical records are preserved elsewhere, but it is far simpler to retain the full trail.

Mapping Trust Services Criteria to platform features

A 90-day readiness plan

Assuming you’re starting from “we have agents in production, no formal controls yet,” here is a realistic week-by-week plan for a team of 2–4 engineers.

Weeks 1–2: inventory

List every AI agent in production. For each: what does it do, what tools can it call, what data does it read, which principal runs it, where are its logs today? This is the scope definition your auditor will work from. Any agent not on the list will appear as a finding later.

Weeks 3–4: instrument

Wire every agent through a governance SDK so every tool call is observed and every policy decision is logged. At this stage enforcement can still be permissive (allow everything, observe only) — the goal is a full, structured audit trail. Confirm you can query the last N agent actions by principal, by tool, and by outcome.

Weeks 5–6: policy

Write policies for the highest-risk tool calls first: anything involving money, external communication, data deletion, or elevated privilege. Move enforcement from permissive to blocking on those. Add human-approval gates where appropriate. Commit policies to version control — auditors will ask for the change history.

Weeks 7–8: incident response

Define what an “agent incident” is (a blocked dangerous action, an injection attempt, a budget breach), wire alerts to an oncall channel, document the runbook. Run a game-day: fake an incident, walk through detection, triage, containment, and writeup. Save the artifacts.

Weeks 9–10: retention and export

Confirm policy-decision logs, approvals, and incidents retain for at least 365 days. Exercise the export path: generate a compliance report for a sample 30-day window and walk through it as if you were the auditor. Fill the gaps before the real audit does.

Weeks 11–13: tabletop and buffer

Run a mock audit. Ideally with someone outside the team who can ask naive questions and spot the gaps. Fix what comes up. Schedule the real engagement only when the mock audit turns up nothing substantive.

Auditor Q&A appendix

Five questions you should be able to answer in the first ten minutes of the engagement, with the artifact each one maps to:

1. “Show me a single action an agent took last Tuesday and walk me through how it was authorized.” → Pull the trace, show the originating principal, show the policy that fired, show the decision record.
2. “How would you know if an agent started calling a tool it isn’t supposed to?” → Show the allowlist in the policy, the blocked-action alert, and the incident that would open.
3. “Who approved the last policy change to production?” → Policy version history with approver identity and timestamp.
4. “Show me every incident you had in the last quarter and how it was resolved.” → Incidents list, filtered by date, with timeline and writeup per entry.
5. “How long do you retain these records?” → 365 days, documented in the data-retention policy, enforced at the platform level.

The shortcut

Every control above can be built from scratch. Most teams shouldn’t. Policy engines, audit pipelines, approval workflows, incident management, and retention infrastructure are months of engineering work that contribute nothing to the product your customers pay for. The point of a governance platform is to deliver all four evidence artifacts — policy decisions, approvals, incidents, retention — on day one, so the audit is about your business logic rather than your plumbing.

Related reading: What is AI Agent Governance? and Prompt injection attacks against AI agents. For the full TSC → control mapping, see the compliance page.