SOC 2 is the buyer-facing artifact most enterprise prospects ask for before they let an AI agent platform near their data. It is also one of the most misunderstood. The report does not certify your AI; it attests that your organization has designed and operated controls against the AICPA Trust Services Criteria for a stated window. Companion to the agent governance and compliance overview, and to the procurement checklist that turns SOC 2 from a buyer ask into a seller deliverable.

This piece covers what SOC 2 covers, what it does not, how the five Trust Services Criteria map to agent-specific risks, the controls auditors press on first, and the gaps most platforms have when an agent layer sits on top of an LLM API.

What SOC 2 actually is

SOC 2 is a service-organization report issued by a licensed CPA firm under AICPA standards. It attests that a service organization has designed (Type I) or operated (Type II) controls relevant to one or more of the Trust Services Criteria. The report is not a stamp on your software; it is a stamp on how you run the company that runs the software (AICPA, 2025).

Two practical implications. First, the auditor cares as much about HR onboarding, vendor reviews, and incident tickets as about your code. Second, no two SOC 2 reports are identical; the scope is defined by you. A report that excludes Availability or carves out a critical subservice is not the same as one that includes them.

Trust services criteria mapped to agent risks

The five categories the criteria cover, with the agent-specific control that maps to each.

  1. Security (required). Logical access, network protection, change management, vulnerability management, incident response. Agent-specific: tool-call authorization, secret management, prompt-injection defenses (OWASP LLM Top 10, 2025).
  2. Availability. Backup and recovery, capacity, monitoring. Agent-specific: model provider failover, queue durability, run resumption after a restart.
  3. Processing Integrity. Inputs are validated, processing is complete and accurate, outputs are reviewed. Agent-specific: eval coverage on a held-out set, output validation against schemas, human-in-loop at defined risk thresholds.
  4. Confidentiality. Designated confidential information is protected. Agent-specific: prompt redaction, memory partitioning, output filtering for cross-tenant leakage.
  5. Privacy. Personal information is handled per your privacy notice. Agent-specific: data subject access response paths, training opt-out, deletion of PII from prompt logs.

For most B2B agent platforms, the right scope on day one is Security plus Confidentiality, with Availability added when you have a measurable SLA to stand behind. Privacy is added when consumer PII is in scope. Processing Integrity is added for high-stakes use cases like financial calculation or clinical decision support.

The five controls auditors check first

Auditors sample, they do not exhaustively test. The samples cluster around five control areas because that is where exceptions surface most often.

  1. Logical access provisioning and deprovisioning. Show a sample of new hires and leavers. The auditor traces the ticket from approval, to identity provider, to actual access grant, to actual revoke. Off-by-one days here are the most common finding.
  2. Change management. A pull request, a peer review, a deploy record, and a link back to a tracked change ticket. Production hotfixes that bypass the flow are the second most common finding.
  3. Vulnerability management. A scanning cadence, a triage SLA, evidence that high-severity findings closed within the SLA. Agent-specific: dependency scanning of the framework, not just OS packages.
  4. Backup and restore. Backups exist, restores are tested, the restore test left an artifact. "We back up daily" without a restore test fails the sample.
  5. Vendor risk management. A vendor inventory, an annual review of each material vendor's SOC 2 or equivalent, evidence that the review was performed and signed.

Agent-specific addition: prompt and run logs. Auditors increasingly ask how prompt content, completions, and tool-call traces are stored, who can read them, and how long they are retained. The control narrative needs an answer.

Shared responsibility with model providers

OpenAI, Anthropic, Google, and AWS Bedrock all publish SOC 2 Type II reports for their enterprise platforms (OpenAI Trust Portal, 2025; Anthropic Trust Center, 2025; Google Cloud, 2025; AWS, 2025). The reports cover their layer: API platform, training infrastructure, internal access. They do not cover the controls you sit on top.

What you own as the agent platform: how you call the model API (auth, network, secret rotation), what you log around the call (prompt content, completion, redaction), where outputs go (which tools can act, with what authorization), and how memory is partitioned across tenants. Pull the provider's complementary user entity controls (CUEC) section; it tells you what they expect you to do for their report to apply to your stack.

Evidence collection that does not break the team

Type II audits cover 6 to 12 months. The audit fee is bounded; the evidence collection workload is unbounded if you start it the week before fieldwork. Three habits reduce the pain.

  1. Ticket every change, every access grant, every incident, every vendor review. If it is not ticketed, it is not evidenced.
  2. Automate the boring parts. Identity provider exports for access reviews. Cloud-native config exports for infrastructure controls. Vulnerability scanner output for patching. Manual screenshots scale to about 50 employees and no further.
  3. Keep an evidence map that lists each control, the source system, the cadence, and the responsible owner. The day fieldwork starts, the auditor gets one document not twelve.

The five gaps most agent teams miss

  1. Prompt and completion log retention. "Stored indefinitely" fails Confidentiality. Pick a retention; document it; enforce it.
  2. Tool-call authorization. Agents that hit production tools with the agent's identity rather than the user's break access control. The agent needs scoped credentials per user or tenant; see agent security checklist.
  3. Cross-tenant memory isolation. Vector stores that share a namespace across tenants are an audit issue waiting to fire. Tenant-scoped namespaces, with tests that prove isolation, are the control.
  4. Model swap change management. Swapping the underlying model is a change. It needs a ticket, a review, and an eval pass. "We upgraded everyone to the new version" without a record is a change-management exception.
  5. Incident definitions. An agent that hallucinated a refund is an incident even if no human was harmed. Define what counts; route it through the same incident process; document the response.

A 90-day path to readiness

For a small platform aiming at Type I in 90 days, the order that has worked across multiple readiness engagements:

  1. Days 1 to 15. Scope the report (Security plus Confidentiality is the usual starting point). Pick an audit firm; many will run a readiness assessment as a first phase. Stand up an evidence-tracking spreadsheet or a tool like Drata, Vanta, or Secureframe.
  2. Days 16 to 45. Write the policies the auditor needs to see: access control, change management, vendor management, incident response, BCDR, secure development, data classification. Get them signed.
  3. Days 46 to 75. Implement the controls behind the policies. MFA on everyone, SSO on every supported app, logging shipped to a SIEM, vulnerability scanner running, backups verified, vendor reviews completed.
  4. Days 76 to 90. Run the readiness assessment with the audit firm. Remediate. Schedule the Type I as-of date. Begin the Type II observation window the day after.

This timeline assumes a small team with one person owning compliance. Larger teams move slower because of coordination cost; smaller teams move slower because the work has no owner. Pick the owner first; the schedule moves after that.

FAQ

What is SOC 2 and why does it matter for AI agents?
SOC 2 is an attestation report against the AICPA Trust Services Criteria. For AI agents, it tells buyers your platform has audited controls over data, access, and operations.
Is SOC 2 Type I or Type II better?
Type II is the substantive one. It confirms operating effectiveness over a window (typically 6 to 12 months). Enterprise buyers usually require Type II.
Which Trust Services Criteria apply to AI agents?
Security is required. Availability and Confidentiality are common additions for agent platforms. Processing Integrity and Privacy are added when handling regulated or PII data.
Do model providers like OpenAI and Anthropic have SOC 2?
Yes. The report covers their API platform; your agent platform sits above and needs its own attestation for the controls it owns.
What does an auditor actually look at?
Access logs, change management tickets, onboarding and offboarding records, vendor reviews, incident tickets, vulnerability scan output, and evidence that backups restore. They sample, they trace, they look for exceptions.
How long does SOC 2 take and cost?
First-time Type I: 2 to 4 months of readiness, USD 5,000 to 25,000 in audit fees. Type II: a 6 to 12 month observation window plus audit, USD 20,000 to 75,000 typical for a small platform.

Sources