SOC 2 for AI Agents: A Practical Field Guide

SOC 2 was not written with autonomous agents in mind, but the Trust Services Criteria translate to agent stacks more cleanly than most teams expect. The trick is to stop thinking of agents as a novel category and start treating each one as a non-human identity with its own access reviews, change logs, incident playbooks, and accountable owner. Every framework concept you already apply to service accounts and CI/CD pipelines extends — the controls are familiar; only the behaviors are new.

This field guide is written for the GRC lead, security engineer, or compliance program manager preparing for a Type II audit that includes one or more production AI agents. It draws on findings, draft reports, and auditor conversations from cycles we have supported over the past year. Use it as a worksheet: each section names the criterion, the control intent, the evidence auditors are asking for in 2026, and the most common ways teams fail.

Map agents to Common Criteria 6 (logical access)

Every agent needs a documented owner — a named human accountable for its behavior, capability scope, and incident response. Every agent needs a least-privilege role tied to a non-human identity in your IAM system, not a shared service account. Every agent needs a quarterly access review that confirms the tools it can call and the data it can read are still appropriate to its purpose. Auditors want the artifacts: an inventory CSV with owner, role, and last review date; the IAM policies attached to each identity; and the ticket trail or signed attestation from the quarterly review.

The most common CC6 finding is the agent that grew capability without a corresponding access review. A prompt update added a new tool, the new tool unlocked access to a new data set, and the access review schedule never caught up. The fix is procedural: every prompt or tool change that affects scope triggers a re-review, automated through your change-management pipeline. WatchTower customers wire this trigger into the policy-as-code commit hook so the review request is filed before the change ships.

Map agents to Common Criteria 7 (system operations)

CC7 covers monitoring, detection, and incident response for the systems in scope. For agents this means three artifacts: an immutable audit record for every tool call (prompt, policy decision, outcome, timestamp, identity), a detection capability that alerts on anomalous behavior, and an incident response runbook that names containment steps specific to autonomous systems. Auditors will ask to walk through a sample incident — they want to see how a runaway agent gets quarantined and how the post-incident review feeds back into policy.

The CC7 trap is over-reliance on application logs. Logs that capture only successful tool calls miss the entire denied set, which is where the security signal lives. Auditors in 2026 are asking specifically for evidence of denied actions and the policies that produced the denials — proof that your control is enforcing, not just observing. If your platform only logs allowed events, you have an evidence gap; fix it before the audit.

Confidentiality, Privacy, and the data-flow question

When agents touch customer data, the Confidentiality and Privacy criteria activate. The questions auditors ask: what categories of data can each agent read, where does that data flow when the agent calls a tool, and how is it protected in transit and at rest in the agent's reasoning context? The data-flow diagram you produced for your last audit probably does not show the agent. Add it, including every tool the agent can call out to and every retrieval source it can read from. The diagram itself becomes evidence.

Pay special attention to model providers. If an agent's reasoning runs through a hosted LLM and the prompt includes customer data, that provider is a sub-service organization in scope. You need either a carve-out, an inclusive review of the provider's SOC 2, or a contractual control. The right answer depends on materiality; the wrong answer is to ignore the question and hope it does not come up.

Evidence auditors actually want in 2026

Three artifacts come up in nearly every report: a signed, append-only audit log of agent actions that can be exported to the auditor without engineering involvement; a policy-as-code repository with full commit history showing who changed what and when; and quarterly evidence that high-risk autonomous actions were reviewed by a human or by a documented automated control. WatchTower generates the first two automatically and surfaces the third in a single dashboard, but you can assemble the same evidence from primitives if you build it yourself — the requirement is the evidence, not the vendor.

The agent-as-identity model

Modern auditors are comfortable with the framing 'every agent is a service account with a brain.' That single sentence unlocks the rest of the program: provision them, rotate them, scope them, and revoke them the same way you would a Kubernetes service account. The behavior is novel; the controls are not. Use the framing explicitly in your control narrative — it makes the auditor's job easier and signals that your program understands the actual risk surface.

Common findings to pre-empt before fieldwork

The three findings we see most often: missing owner for an agent that touches customer data; no change-management trail for a prompt update that introduced a new capability; and no evidence of review for high-risk autonomous actions. Each of these is solvable with tooling and process. None of them is solvable with policy language alone — a written policy that nobody operationalized is itself a finding.

A fourth finding gaining steam in 2026: vendor risk for the model provider. If you cannot answer where customer data goes when your agent calls a hosted LLM, expect a qualified opinion. The fix is a documented data classification policy that names which categories of data are permitted in which model endpoints, and a runtime control that enforces the policy on every call.

A 90-day SOC 2 readiness sprint for agent stacks

Days 1–14: inventory every production agent, owner, tool, data scope, and model provider. Days 15–30: implement signed audit logging for tool calls and the policy decisions that gated them. Days 31–60: stand up policy-as-code with commit history, peer review, and a change-management trigger that opens an access review when scope changes. Days 61–75: produce the quarterly access-review evidence retroactively and forward, and document the human-review workflow for high-risk actions. Days 76–90: dry-run the audit walkthrough internally, fix the gaps, and brief the executive sponsor. Teams that complete this sprint enter fieldwork without surprises.