SOC 2 readiness for AI agents

AI agents are now in scope for your audit, whether or not your last report mentioned them. An agent that can move money, change records, or send mail as your company is a system that touches the same Trust Services Criteria as any other production component — and an auditor who understands that will ask how it’s controlled. This guide maps agent governance to SOC 2 and lists the evidence you’ll need.

This is practical guidance, not legal or audit advice. Your auditor’s interpretation governs. Use it to prepare the conversation, not to replace it.

Why agents land in SOC 2 scope

SOC 2 is about the controls protecting systems that handle your data and operations. An autonomous agent with real capabilities is exactly such a system — arguably a higher-risk one, because it acts fast, at scale, and can be steered by untrusted input. The relevant criteria are the ones you already know: logical access (CC6), change management (CC8), and monitoring (CC7). Agents just need those controls applied to a new kind of actor.

Mapping scope · guard · log to the criteria

The good news: if you’ve governed agents with scope, guard, and log, you’ve already built most of what an auditor wants. Here’s the mapping.

Logical access — CC6 (Scope + RBAC)

The control objective is least privilege and authorized access. For agents that means:

• Least privilege. Each agent has only the capabilities its job requires; new agents start at zero. Evidence: role definitions, the role→capability matrix.
• Role-based access. Permissions are granted via roles, not per-agent snowflakes. Evidence: roles and their assignments.
• Provisioning & deprovisioning. Agents are created and revoked through a governed process tied to identity. Evidence: SSO/SCIM integration, a revocation you can demonstrate.
• Periodic access review. Someone reviews agent access on a cadence. Evidence: a signed quarterly review of roles and assignments.

Change management — CC8 (Guards + role versioning)

Auditors want changes to be authorized, reviewed, and traceable:

• Policy changes are reviewed. Editing a role or a guard goes through review and is version-controlled. Evidence: change history on roles/guards, with who and when.
• Approval gates for risky actions. High-impact agent actions require human sign-off. Evidence: approval-threshold config and a log of approvals/denials.
• Change-freeze enforcement. Destructive actions are blocked during freezes. Evidence: the guard config and a denied action during a freeze window.

Monitoring & audit — CC7 (Log)

The heart of the audit, and where agent governance shines:

• Complete action logging. Every action, allowed and denied, is recorded in the path. Evidence: the immutable action log.
• Tamper-evidence. Records are append-only and hash-chained. Evidence: storage configuration; the hash chain itself.
• Attribution. Each action ties to an agent and an accountable human. Evidence: log entries showing owner attribution.
• Active monitoring. Logs stream to your SIEM with detections on anomalies. Evidence: the SIEM pipeline and alert rules — see the SIEM guide.

The evidence checklist

Walk into the audit with these ready and the agent portion goes smoothly:

1. Agent inventory — every agent, its owner, its role, its status.
2. Role catalog — each role’s capabilities and the guards bound to it.
3. Role→capability matrix — one page showing who can do what.
4. Access-review record — a recent, signed review of roles and assignments.
5. Change history — versioned record of role and guard changes, with author and timestamp.
6. Approval log — high-impact actions that were approved or denied, with the human decision-maker.
7. Immutable action log sample — entries showing who/what/when/verdict/attribution.
8. SIEM integration proof — the pipeline plus at least one tested detection rule.
9. Revocation demonstration — show an agent’s access revoked in one action across every tool.

Questions auditors are starting to ask

Be ready for these specifically — they’re the new ones:

• “How does this agent get its permissions, and who approved them?” → Roles, version-controlled, reviewed.
• “If this agent were compromised or prompt-injected, what’s the maximum impact?” → Scoped capabilities + caps + approval gates bound the blast radius.
• “Show me everything this agent did last quarter.” → Query the immutable log, attributed to the owner.
• “How would you revoke this agent right now?” → Demonstrate the kill switch live.

A readiness mindset

Treat agents as first-class systems under your existing control framework rather than a special exception. The scope-guard-log model isn’t a separate compliance project bolted on at audit time — it generates SOC 2 evidence as a byproduct of operating safely day to day. Govern agents well continuously, and “SOC 2 readiness” becomes a matter of exporting what you already have rather than scrambling to build it.