SOC 2 for AI shifts scrutiny to boundaries, evidence, and dependencies

At a glance

What this is: This is a governance guide on applying SOC 2 to AI-enabled services, with the central finding that AI does not create a new SOC 2 category but changes how scope, evidence, dependencies, and control testing must be defined.

Why it matters: It matters because IAM, PAM, NHI, and AI governance teams need a defensible control boundary for model access, prompts, data flows, and third-party dependencies before audit evidence can stand up.

Context

SOC 2 for AI starts with a familiar but easy-to-misstate problem: the service boundary has to match the actual control environment, not the marketing description of the product. In AI-enabled services, that boundary often includes model providers, retrieval systems, prompts, embeddings, APIs, and support processes, all of which can affect what the report can honestly claim.

The governance challenge is not whether the system uses AI. The challenge is whether the organisation can show which AI components are in scope, which controls are customer responsibilities, and which dependencies are operated by a subservice organisation or external provider.

Key questions

Q: How should security teams scope SOC 2 Trust Services Criteria for a SaaS business with cloud and AI data flows?

A: Start with Security as the mandatory baseline, then add Availability, Confidentiality, Processing Integrity, or Privacy only when customers, regulators, or the business model require them. Scope should follow actual risk and evidence burden. For cloud and AI-heavy environments, map controls to data access, monitoring, retention, and incident response so the audit reflects real operations, not just policy statements.

Q: Why does AI make SOC 2 evidence harder to defend?

A: AI introduces changing dependencies, probabilistic outputs, and data flows that can move outside traditional application controls. Evidence has to show how the service validates inputs and outputs, manages provider dependencies, and preserves reliable records across the examination period.

Q: What breaks when a SOC 2 report overstates AI coverage?

A: Readers may assume controls cover the whole AI stack when the report only covers part of it. That creates assurance gaps around model providers, retrieval pipelines, tenant isolation, and data handling, which can undermine customer trust and audit credibility.

Q: What should teams consider when using a model provider in SOC 2 scope?

A: They should assess data retention, incident notification, training-use terms, access controls, and whether the provider’s controls are actually part of the examined system or only a dependency. If those terms are unclear, the report needs explicit carve-outs and complementary controls.

Technical breakdown

How AI changes the SOC 2 system boundary

In a traditional SOC 2 engagement, the system description usually follows a fairly stable product and infrastructure boundary. AI complicates that because the service may depend on a model provider, retrieval pipeline, context construction layer, and prompts that change the system’s behaviour without changing the surrounding application code. That means the control environment has to describe not only the application, but also how data moves into the model, how outputs are validated, and which parts are owned by the provider versus the examined service. For auditors, the boundary question is really a trust question: what exactly is being evaluated, and what is outside the report’s evidence set? See the SOC 2 Guide.

Practical implication: Map AI components and dependencies into the system description before fieldwork starts.

Why processing integrity is harder with probabilistic outputs

Processing integrity asks whether processing is complete, valid, accurate, timely, and authorised in context. AI can still support that criterion, but only if the service defines what “correct” means for the use case and what checks exist when the model returns partial, inconsistent, or probabilistic output. That often requires input validation, output checks, schema enforcement, reconciliation for asynchronous workflows, and human review for consequential decisions. The important point is that SOC 2 does not require perfect model accuracy. It requires evidence that the service’s control design and operating effectiveness match the commitments made to users.

Practical implication: Define task-specific acceptance criteria and evidence for model outputs, not generic model quality claims.

Where third-party model providers change the control story

AI services often inherit risk from cloud hosts, model providers, and data platforms that sit outside the company’s direct control. In SOC 2 terms, those dependencies must be described honestly, and any complementary user-entity controls must be stated clearly so that readers understand who is responsible for configuration, access, and retention decisions. This is especially important when prompts or retrieved documents contain sensitive data, or when provider retention and training terms affect confidentiality and privacy commitments. The report should show how the organisation manages that dependency, not pretend the dependency does not exist.

Practical implication: Document subservice responsibilities and customer controls explicitly, especially where data handling is shared.

Threat narrative

Attacker objective: The objective is to exploit unclear AI control boundaries to expose data, bypass validation, or undermine the reliability of the service’s assurance story.

1. Entry occurs when users, prompts, retrieved documents, or model-provider interfaces bring sensitive data into the AI-enabled service boundary.
2. Escalation occurs when the service lacks validation, access controls, or retention governance and model outputs can influence downstream actions without sufficient review.
3. Impact occurs when the organisation cannot demonstrate authorised processing, confidentiality protection, or reliable evidence across the examination period.

Breaches seen in the wild

• DeepSeek database exposure 2025: An unauthenticated DeepSeek ClickHouse database exposed over a million log lines with plaintext chat history and API keys in 2025.
• Microsoft SAS token exposure 2023: An over-permissive Azure SAS token in a Microsoft AI GitHub repo exposed 38TB, including workstation backups and Teams messages, for 3 years.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SOC 2 for AI is a boundary problem before it is a model problem. The article correctly treats AI as a change in system description, dependencies, and evidence handling rather than as a new certification category. That matters because audit scope fails first when teams cannot explain which AI components belong inside the examined service and which remain outside it. Practitioners should treat scope definition as the control that determines whether the rest of the report is credible.

AI-specific assurance depends on translating probabilistic behaviour into control objectives. SOC 2 does not certify that outputs are accurate, fair, or safe in the abstract. It evaluates whether the service has designed and operated controls that make the AI behaviour acceptable for the commitments it makes. That is a material shift for governance teams that are used to deterministic application evidence and need to document review, validation, and escalation instead.

Vendor and subservice dependencies are part of the assurance story, not an appendix. A model provider, cloud host, or retrieval layer can materially affect confidentiality, availability, and processing integrity even when the examined company does not control every component directly. SOC 2 Guide is useful here because the service organisation still has to disclose boundary assumptions, complementary user-entity controls, and any carve-outs that change how readers interpret the report. The practitioner lesson is to govern dependencies as first-class controls, not hidden exceptions.

Named concept: AI assurance boundary. This is the point where AI-specific technical risk becomes auditable only when the organisation can tie model behaviour, data flow, and evidence to a defined service scope. Without that boundary, the report can drift into either over-claiming coverage or under-describing the controls that actually matter. The practical result is that governance teams need a single accountable view of identity, data, and model dependencies before they can claim assurance.

What this signals

SOC 2 programmes that touch AI are shifting from document review to dependency governance. The practical question is no longer whether a model is present, but whether the organisation can prove which parts of the AI stack are in scope, which are excluded, and which are controlled by a provider outside the audit boundary.

AI assurance boundary: the next wave of AI governance will be about proving where the service ends and the evidence begins. That will force IAM, security, and compliance teams to align access control, data handling, and vendor oversight around one auditable service description.

For practitioners

• Define the examined service boundary List the user-facing product, APIs, model-serving layer, retrieval systems, data stores, support processes, and third-party providers that are actually in scope.
• Map AI risks to specific Trust Services Criteria Translate model behaviour, prompt handling, and output validation into security, availability, processing integrity, confidentiality, or privacy controls where they truly apply.
• Document complementary user-entity controls State which settings, access decisions, and retention choices belong to customers or other parties, and describe how the service depends on them.
• Test controls with evidence from the period under review Retain samples, logs, approvals, and review records that show the control operated during the audit window, not just that it was designed correctly.
• Review provider terms and retention behaviour Check model-provider data use, deletion, incident notification, and audit provisions before relying on their controls in the SOC 2 narrative.

Key takeaways

• AI does not create a separate SOC 2 regime, but it does force tighter control over scope, dependencies, and evidence.
• The hardest part of AI assurance is showing how provider services, prompts, retrieval layers, and downstream decisions fit the audited boundary.
• Teams that cannot map AI-specific risks into concrete controls will struggle to defend both the system description and the resulting report.

Related NHI Mgmt Group resources: SOC 2 Guide · Agentic AI Compliance Guide · AI Security Maturity Model

Key terms

• SOC 2 for AI: An informal label for applying SOC 2 examination methods to an AI-enabled service. It is not a separate official certification. The practical work is to define the service, identify relevant Trust Services Criteria, and show that AI-specific risks are controlled within the audit boundary.
• System boundary: A system boundary is the defined scope that separates a system from external users, services, networks, and supporting components. Security teams use it to decide what must be authorised, monitored, tested, and protected. If the boundary is unclear, controls, responsibilities, and threat assessments can be incomplete or inconsistent.
• Complementary User Entity Controls: Complementary User Entity Controls are the customer-side controls that must be in place for a provider’s controls to work as intended. They usually cover configuration, access management, monitoring, and other responsibilities assigned to the customer. If they are missing, the provider’s assurance does not fully translate into compliance for the customer.
• Processing Integrity: Processing Integrity is an optional SOC 2 Trust Services Criterion that asks whether systems process data completely, accurately, timely, and with proper authorization. It matters most where incorrect output creates business risk, such as billing, payments, or regulated workflows. Evidence often includes input validation, reconciliation, error handling, and audit logs.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM, security, or compliance programme, it is worth exploring.