SOC 2 Compliance for AI Agents: Requirements Guide

SOC 2 Compliance and AI Agents: What Auditors Are Actually Asking

SOC 2 compliance requirements for AI agents are no longer a future concern — they're showing up in audit cycles right now. Security auditors at firms like Schellman, A-LIGN, and Prescient Assurance are already asking pointed questions: Which systems did your AI agents access? What governed those actions? Can you show me the logs?

Most engineering teams building with agents aren't ready. They've bolted agents onto existing infrastructure without thinking carefully about how autonomous, non-human actors fit into the Trust Services Criteria (TSC) that SOC 2 is built around. The result is a compliance gap that gets expensive fast — either you scramble before an audit, or you rebuild after one goes badly.

This guide covers what SOC 2 compliance actually requires for AI agents, which Trust Services Criteria are most affected, and what concrete controls your team needs to implement before an auditor asks.

Why AI Agents Create New SOC 2 Compliance Requirements

SOC 2 is built on five Trust Services Criteria: Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P). Almost every production AI agent deployment touches at least three of these — usually Security, Confidentiality, and Processing Integrity.

Traditional SOC 2 controls were designed for human users and static software systems. An agent is neither. It takes autonomous actions, holds credentials, makes API calls, reads and writes data, and can chain multiple operations in a single run — often without a human in the loop. That creates compliance surface area that existing control frameworks didn't anticipate.

According to Gartner's 2024 AI Agents Market Guide, by 2028, 33% of enterprise software applications will include agentic AI. That means the compliance questions aren't hypothetical — they're about infrastructure that's either already deployed or coming soon.

The core problem: SOC 2 auditors look for evidence that access is granted on a least-privilege basis, that access is logged, that changes to access are reviewed, and that credentials are protected. AI agents routinely violate all four of these if they're not governed correctly.

The Non-Human Identity Problem

AI agents are non-human identities (NHIs) — software actors that hold credentials and take actions in systems. NHIs are explicitly in scope for SOC 2, but most teams manage them poorly. API keys get hardcoded into agent configurations. OAuth tokens get shared across agents. Permissions get set broad and left that way. Our non-human identity management guide for AI agents covers this in depth, but the SOC 2 angle is specific: you need to demonstrate to auditors that every agent credential is inventoried, scoped, rotated, and revocable.

The Audit Trail Gap

CC7.2 of the SOC 2 Common Criteria requires that organizations detect and log security events. For AI agents, this means capturing not just "the agent ran" but what it did: which tools it called, what data it accessed, what external APIs it hit, and what the outcome was. Most agent frameworks produce logs oriented toward debugging (token counts, latency) rather than compliance (who accessed what, when, with what authorization). That's a gap auditors will find.

SOC 2 Trust Services Criteria Most Affected by AI Agents

Not every TSC is equally impacted. Here's a practical breakdown of which criteria your AI agent architecture needs to address most urgently, and what evidence auditors expect.

Trust Services Criterion	Relevant Control Areas	AI Agent Risk	Evidence Auditors Expect
CC6 — Logical Access	Least privilege, credential management, access reviews	Agents hold overprivileged API keys; credentials not rotated	Inventory of agent credentials, scope restrictions, rotation logs
CC7 — System Operations	Monitoring, anomaly detection, incident response	Agent actions not logged at operation level; no alerting	Audit trail of agent tool calls, anomaly alerts, incident records
CC8 — Change Management	Authorized changes, testing, rollback	Agent capabilities added without formal change process	Change records for agent tool access grants, approval workflows
PI1 — Processing Integrity	Complete, accurate, timely processing	Agents take unintended actions that corrupt data	Rate limits, approval gates, action validation logs
C1 — Confidentiality	Data classification, access restriction	Agents access confidential data beyond their task scope	Scope definitions per agent, data access logs, access denials

CC6: Logical Access Controls Are the Hardest to Get Right

CC6 is where most teams struggle most. CC6.1 requires that access to systems is based on authorized roles. CC6.3 requires that access is removed when no longer needed. CC6.6 requires protection of credentials. AI agents routinely fail all three by default.

A typical pattern: a developer creates an agent with broad API access to get it working, ships it to production, and never revisits the permission scope. The agent accumulates access it no longer needs. Credentials never rotate. There's no formal process to revoke access when the agent's role changes.

Auditors will ask for an inventory of every non-human identity, its current access scope, when that scope was last reviewed, and how credentials are protected. If you can't produce that, CC6 findings are almost certain. Our AI agent access control guide covers the technical implementation in detail.

CC7: Operational Monitoring at the Action Level

CC7.2 and CC7.3 require that organizations monitor system activity and detect security events. For AI agents, this requires logging at the operation level — not just "the agent ran successfully" but which specific tools were called, with what parameters, and what data was accessed or modified.

This is a higher bar than most teams set. Typical observability tooling (Datadog, CloudWatch) captures infrastructure metrics but not semantic agent actions. You need a layer that captures structured records of every agent action: tool name, input parameters, output summary, timestamp, agent identity, and authorization context. Our AI agent audit trail guide walks through what that structure needs to look like for compliance purposes.

Practical SOC 2 Controls for AI Agent Deployments

Here's what you actually need to implement. These aren't theoretical controls — they're the specific things auditors will look for evidence of.

1. Maintain a Non-Human Identity Inventory

Every AI agent that holds credentials or takes actions in systems needs to be registered in an NHI inventory. This should capture: agent name and purpose, owner, creation date, credential types held, access scope, last access review date, and current status. A spreadsheet works for small teams; most compliance-mature teams use a dedicated NHI management system or tag resources in their identity provider.

The inventory isn't just documentation theater — it's the foundation for access reviews. CC6.3 requires periodic reviews of user access. That requirement extends to agents. Quarterly reviews are the most common audit expectation.

2. Implement Least-Privilege Scoping per Agent

Each agent should have access scoped to exactly what its current task requires — nothing more. This means defining explicit allow-lists of tools, APIs, and data sources per agent identity, rather than granting broad access and relying on the agent's judgment to self-limit.

Practically, this requires a governance layer that sits between the agent and the services it calls — something that enforces permission boundaries at runtime rather than trusting that the agent will stay in bounds. This is the same pattern described in our AI agent permission management guide.

3. Rotate and Vault Credentials

Hardcoded API keys are an automatic finding in any serious audit. CC6.6 requires protection of credentials, which means: keys stored in secrets managers (AWS Secrets Manager, HashiCorp Vault, similar), rotation on a defined schedule (90 days is common), and no credentials in source code, environment variables shipped to production, or agent configuration files.

For agents specifically, credential rotation is harder because agents may be long-running and need credentials refreshed without restart. This requires either short-lived token patterns or secrets injection at runtime. Our AI agent key management and rotation guide covers the implementation patterns.

4. Build Approval Workflows for High-Risk Actions

Processing Integrity (PI1) requires that system processing is complete, valid, accurate, timely, and authorized. For AI agents taking consequential actions — sending emails, modifying records, executing financial transactions — "authorized" is the key word. Someone or something needs to explicitly authorize high-risk agent actions before they execute.

This means building approval gates: a mechanism where an agent pauses before executing a defined class of action and waits for explicit human (or policy-based) approval. The approval record becomes compliance evidence. Auditors want to see that consequential actions have an authorization trail, not just an execution log.

5. Produce Structured Audit Logs at the Operation Level

The audit log requirement is non-negotiable. Every agent action that touches external systems, reads sensitive data, or modifies state needs a structured log entry that includes: timestamp, agent identity, action type, target system, parameters (redacted where necessary for confidentiality), outcome, and authorization context.

These logs need to be tamper-evident, retained for at least 12 months (longer if your customers require it), and queryable — auditors will ask for specific event records, not just confirmation that logging exists.

SOC 2 Compliance Requirements vs. Common Agent Governance Tools

Teams evaluating tools to meet SOC 2 compliance requirements for AI agents are looking at a range of options. The space breaks down roughly by what problem each tool solves.

Tool / Platform	Primary Focus	Audit Trail	Least Privilege Enforcement	Approval Workflows	Agent Superpowers
Handler	Enablement + governance	Yes — operation-level	Yes — per-agent rule engine	Yes — owner-defined	Yes — 200+ services
Okta AI Agent Identity	Enterprise IAM for agents	Partial (identity events)	Partial (IAM-layer)	No	No
Astrix Security	NHI security	Partial (connection events)	Yes	No	No
Oasis Security	NHI governance (CISO-focused)	Yes	Yes	No	No
Microsoft Agent Governance Toolkit	DIY CLI toolkit	DIY	DIY	DIY	No
AgentControl.dev	Open-source control plane	Yes	Yes	Partial	No

Tools like Okta's AI Agent Identity extend enterprise IAM to agents, which helps with CC6 identity management but doesn't address operation-level audit trails or approval workflows. Astrix and Oasis focus on NHI security — good for credential inventory and scope enforcement, but neither is built to give agents the capabilities they need to do real work.

The gap most tools leave is the combination: governance and the integrations that make agents useful. A SOC 2-compliant agent deployment needs both. You can't satisfy auditors with a secure credential vault if the agent's actions themselves are ungoverned, and you can't build useful agents if governance locks down everything they need to do.

Handler takes a different approach — combining a governed runtime for agent actions with 200+ pre-built integrations (web search, email, B2B data, financial markets, and more). Every action goes through owner-defined rules, produces structured audit logs, and can require approval before execution. For teams building agents that need to do real work and pass audits, that combination matters. Try Handler free to see how it fits your compliance requirements.

If you're evaluating the broader governance landscape, our 2026 AI agent governance platforms buyer's guide covers the full field.

What to Prepare Before Your SOC 2 Audit

If an audit is coming in the next 6-12 months and you have AI agents in production, here's the preparation checklist that maps to the controls auditors will test.

Documentation to Prepare

• NHI inventory: Every agent, its purpose, owner, credential types, and access scope
• Access scope definitions: Written documentation of what each agent is and is not permitted to access
• Credential management policy: How agent credentials are stored, rotated, and revoked
• Change management records: Evidence that agent capability changes went through a defined approval process
• Access review records: Evidence of periodic reviews of agent access (quarterly is the common expectation)
• Incident response procedures: What happens when an agent acts anomalously or a credential is compromised

Technical Evidence to Collect

• Audit log samples showing operation-level agent actions with timestamps and authorization context
• Alerts or monitoring dashboards showing anomalous agent behavior detection
• Secrets manager configuration showing agent credentials are vaulted and rotated
• Approval workflow records for high-risk agent actions
• Examples of access denials — showing that least-privilege enforcement is active, not just documented

The last point is one teams often miss. Auditors want to see evidence that controls are working — not just that they exist. A log showing an agent's request was denied because it exceeded its defined scope is strong evidence. A policy document saying agents should only access what they need is not.

Frequently Asked Questions

Do AI agents need to be explicitly listed in a SOC 2 audit scope?

Yes, if they access systems that are in scope for the audit. AI agents are non-human identities that interact with in-scope systems — they're subject to the same logical access controls (CC6) and monitoring requirements (CC7) as human users and automated processes. Auditors at modern firms increasingly ask specifically about AI agent access as part of system description reviews.

Which SOC 2 criterion is most commonly violated by AI agent deployments?

CC6 (Logical Access Controls) is the most common source of findings. The specific issues are: overprivileged agent credentials, no formal access review process for agents, and credentials not stored in approved secrets management systems. CC7 (System Operations) is the second most common gap, specifically the lack of operation-level audit trails for agent actions.

Can I use an AI agent framework's built-in logging to satisfy SOC 2 audit trail requirements?

Usually not on its own. Framework logs (LangChain traces, OpenAI Agents SDK logs) are oriented toward debugging — they capture token usage, latency, and error states. SOC 2 audit trails need to capture authorization context, data access scope, and action outcomes in a tamper-evident, retained format. You typically need a dedicated governance or observability layer on top of framework logging.

How does least-privilege work for AI agents that need broad tool access to function?

Least privilege for agents is defined per-agent and per-task, not globally. An agent that legitimately needs to search the web, read CRM records, and send emails can have those specific capabilities granted — but it shouldn't have access to financial records or code deployment pipelines unless those are also part of its defined task. The key is explicit allow-lists rather than implicit broad grants. Governance platforms enforce these at runtime, so even if the agent is prompted to access something outside its scope, the action is blocked and logged.

What's the difference between SOC 2 compliance requirements for AI agents and the EU AI Act?

SOC 2 is a voluntary attestation standard focused on the security and availability of services — it's primarily about demonstrating controls to customers. The EU AI Act is a mandatory regulatory framework that categorizes AI systems by risk level and imposes requirements including transparency, human oversight, and accuracy testing. They overlap in areas like audit logging and access controls, but the EU AI Act adds requirements around AI-specific risks (bias, transparency, incident reporting) that SOC 2 doesn't address. Our EU AI Act compliance guide for agents covers the differences in depth.