The Question
Your organization has a SOC 2 Type II report. Your auditor reviewed your security controls, your availability commitments, and your data handling practices. You passed.
Does that report cover your AI deployments? Does it address the security of your LLM applications, your AI agents, your model infrastructure? Does it say anything meaningful about whether your AI systems are protected against prompt injection, data exfiltration through model outputs, or agentic escape?
Almost certainly not. And if your customers, partners, or regulators are relying on your SOC 2 as evidence that your AI systems are secure, there is a material gap in that assurance.
The gap maps directly to OWASP LLM02: Sensitive Information Disclosure and LLM04: Data and Model Poisoning — two of the most serious AI risk classes that SOC 2's Trust Services Criteria were never designed to assess.
Why This Matters Now
SOC 2 was designed around a set of Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy — that describe controls appropriate for traditional SaaS applications: access controls, encryption, change management, incident response, vendor management.
These criteria have not been updated to address AI-specific risks. A SOC 2 audit conducted today will assess whether you have MFA enabled, whether your logs are retained, whether your penetration testing is annual. It will not assess whether your AI applications are vulnerable to prompt injection. It will not evaluate whether your LLM outputs can be manipulated to exfiltrate sensitive data. It will not examine whether your AI agents have been granted excessive permissions that create a blast radius far beyond their intended function.
The assurance gap is not hypothetical. In 2024, a major enterprise SaaS provider — SOC 2 Type II certified — had its AI assistant feature exploited to surface data from other tenants' conversations through a prompt injection vulnerability. The SOC 2 certification was accurate and current. The AI vulnerability was entirely outside its scope.
When a customer asks "are you SOC 2 certified?" and you say yes, they may believe that covers your AI security posture. It does not.
What the CURVE™ Data Shows
The 2026 Stackcurve AI Security CURVE™ Report notes this gap explicitly in the AI Governance & Compliance section. The vendors in that category — including Credo AI, ValidMind, OneTrust, and TruEra — are building compliance management tooling that extends beyond traditional audit frameworks to address AI-specific risk categories.
The most relevant emerging standards that attempt to fill the SOC 2 gap for AI are NIST AI RMF 1.1 and the EU AI Act's high-risk AI system requirements. Neither maps cleanly to SOC 2's audit structure, and neither yet has the market penetration that SOC 2 has achieved — but both are what sophisticated enterprise buyers are beginning to ask about in vendor assessments.
The full vendor rankings are in the 2026 AI Security CURVE™ Report — free to download.
AICPA, the body that governs SOC 2, has published guidance on AI considerations — but the core Trust Services Criteria have not been formally updated to include AI-specific controls as of this writing. Some auditors are adding AI-specific procedures as supplemental testing; most are not. The result is significant inconsistency in how AI risk is treated across SOC 2 engagements.
The Gap Most Buyers Miss
SOC 2 assesses the controls you have implemented against the Trust Services Criteria. It does not assess whether those criteria are sufficient for your risk profile. For most organizations in 2022, they were. For organizations running AI applications in 2026, there are at least five material risk categories that SOC 2 does not address:
Prompt injection defense — SOC 2 has no criterion for whether your AI applications are protected against malicious input manipulation. An organization could have zero prompt injection controls and pass a SOC 2 audit with flying colors.
AI output security — SOC 2 does not assess whether your AI systems can be manipulated to produce outputs that leak sensitive data, violate data residency requirements, or generate content that creates regulatory exposure. The confidentiality criterion covers data at rest and in transit; it was not designed for data that surfaces in AI-generated responses.
Agentic permissions and containment — SOC 2 access controls are built around human user accounts and service principals. They have no framework for assessing whether AI agents have appropriate tool-use permissions, whether their autonomy is bounded, or whether their actions are auditable at the semantic level.
Model and training data security — SOC 2 does not assess whether your model weights are protected against theft, whether your training data was sanitized against poisoning attacks, or whether your fine-tuning pipeline has appropriate access controls.
AI-specific incident response — SOC 2 assesses whether you have an incident response plan. It does not assess whether that plan addresses the five agentic threat classes or includes procedures for containing a goal misgeneralization event in a production AI system.
Questions Your Buying Team Should Be Asking
1. Does your SOC 2 engagement include any AI-specific testing procedures? Ask your current auditor directly. Some progressive audit firms are adding supplemental AI procedures even without formal AICPA guidance. Know what your current report covers — and what it does not.
2. Are you preparing for NIST AI RMF or EU AI Act compliance? For organizations subject to EU AI Act requirements — particularly those running high-risk AI systems as defined by the Act — SOC 2 will not be sufficient evidence of compliance. Understanding your regulatory exposure determines which AI-specific frameworks you need to prepare for.
3. What do your enterprise customers' vendor assessments ask about AI security? If your customers are asking about AI security controls in their vendor questionnaires — and most large enterprise customers have already added AI security sections — you have a practical, near-term driver to close the gap regardless of regulatory requirements.
4. How are you documenting AI security controls for customer assurance purposes? In the absence of a formal AI security certification, the practical response is documented AI security controls — a security white paper or shared responsibility document that explicitly addresses the AI risk categories your SOC 2 does not cover. Several governance vendors offer frameworks for this documentation.
5. What is your plan for when a customer asks specifically about AI security posture in their vendor assessment? Have this conversation before a customer asks, not during a sales cycle. Know what you can assert, what documentation you can provide, and where the gaps are.
The Stackcurve Take
SOC 2 remains valuable and worth maintaining. It addresses a real and important set of security controls, and enterprise customers rely on it. The problem is not that SOC 2 is wrong — it is that the AI risk landscape has grown beyond what SOC 2 was designed to assess, and neither buyers nor vendors have fully reckoned with the gap.
The near-term practical response has two parts. First, internally: assess your AI security posture against the OWASP Top 10 for LLMs and the five agentic threat classes. Identify which risks have controls and which do not. Build a remediation roadmap. Second, externally: document your AI security controls explicitly — in a white paper, a shared responsibility matrix, or a vendor security questionnaire response — rather than allowing customers to assume your SOC 2 coverage extends to AI.
The medium-term trajectory: AI-specific security certifications and audit frameworks will emerge and become market requirements, likely within 24–36 months. The organizations building AI security controls now will be prepared to certify against those frameworks when they arrive. The organizations waiting for the certification to define the requirement will be behind.
The 2026 Stackcurve AI Security CURVE™ Report covers the AI Governance & Compliance vendor landscape for organizations building toward formal AI security compliance. Download it free →
Stackcurve Advisory Briefs are independent research. No vendor pays for placement, tier assignment, or editorial influence. The CURVE™ methodology is disclosed in full at stackcurve.net/research/methodology.