SOC 2 Compliance for AI Agents: The Complete Mapping

SOC 2 and AI Agents

SOC 2 (Service Organization Control 2) defines criteria for managing customer data based on five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. When AI agents access, process, or act on customer data, they fall squarely within SOC 2 scope.

The challenge is that most AI agent frameworks were not designed with SOC 2 in mind. They lack built-in audit trails, access controls, and encryption. A control plane fills this gap.

Mapping TSC to Agent Controls

• Security — Encryption at rest (AES-256-GCM) and in transit (TLS 1.3). Gateway key authentication. IP allowlisting.
• Availability — Health monitoring every 5 minutes. Kill-switch for emergency shutdown. Circuit breaker for provider failures.
• Processing Integrity — Immutable audit trail of every agent action. Approval gates for high-risk operations. Token budget enforcement.
• Confidentiality — DLP policies redact PII before LLM calls. Regional data residency (IL/EU/US). Tenant data isolation.
• Privacy — GDPR consent management. Data retention policies. Right to deletion support.

The Audit Trail

The foundation of SOC 2 compliance is the audit trail. Every agent action — every LLM call, every tool use, every approval decision — must be logged in an append-only store. Auditors will ask: Who did what, when, and was it authorized?

-- Example: Query the audit trail for a specific agent
SELECT
  event_type,
  actor_type,
  actor_id,
  description,
  metadata,
  created_at
FROM ds_agents_il.task_timeline
WHERE tenant_id = @tenantId
  AND agent_id = @agentId
  AND created_at BETWEEN @startDate AND @endDate
ORDER BY created_at DESC

Access Controls: 3-Level RBAC

SOC 2 requires that access to systems and data is restricted based on roles. A 3-level RBAC hierarchy ensures least-privilege access:

• Platform level — Global admins manage platform-wide settings and policies
• Organization level — Org owners manage their organization, billing, SSO, and gateway
• Tenant level — 6 granular roles (Owner, Admin, Developer, Operator, Member, Viewer) control workspace access

Encryption Standards

All credentials (LLM API keys, SSO secrets, tenant data) are encrypted with AES-256-GCM using a key derivation hierarchy. The platform KEK is stored in GCP Secret Manager with FIPS 140-2 Level 3 HSM backing. Tenant keys are derived via SHA-256 from the KEK plus tenant ID.

Audit Preparation Checklist

• Verify audit trail retention is set to 365+ days
• Confirm all admin actions require authenticated sessions
• Review RBAC roles — ensure no over-privileged accounts
• Check that all LLM credentials are encrypted (never stored in plaintext)
• Validate data residency — ensure tenant data stays in designated region
• Test kill-switch activation and recovery procedure
• Export audit logs for the review period and verify completeness
• Document change-management procedure for policy and model allow-list updates
• Confirm SSO is enforced for all human users and SCIM deactivation is tested

Frequently Asked Questions

Are AI agents in scope for SOC 2 Type II?

If the agent touches customer data, makes decisions on behalf of the service, or has access to systems used to deliver the service, yes. Auditors will expect evidence of access controls, change management, and monitoring for the agent the same way they expect it for any production service.

Does SOC 2 require human approval for every AI action?

No. SOC 2 requires that controls match the risk. Low-risk, reversible actions can run autonomously with logging. High-risk or production-changing actions should require approval. The control that matters is that the policy is documented, enforced, and auditable.

Can I use Dobby as evidence in a SOC 2 audit?

Yes — the audit trail, RBAC configuration, approval logs, SSO/SCIM events, and kill-switch activations are all queryable and exportable. Most customers pair this with the SOC 2 report for Dobby itself as a sub-processor.