AI Security Compliance Obligations Under SOC 2 and ISO 27001

Traditional software security is, at its core, a boundary problem. Authenticate who can enter, encrypt what leaves, patch the holes. The mental model is a building: walls, doors, locks, a visitor log. AI systems are less like buildings and more like cities, with supply chains, subcontractors, and residents who periodically import malware from neighborhoods you didn't know existed.

The specific vectors matter here because they map directly to the control categories that follow.

Training data integrity is the first one most organizations underestimate. CyLab research from 2025 found that corrupting as little as 0.1% of a model's pre-training dataset is sufficient to launch effective data poisoning attacks. SOC 2's data controls govern who can access data; they say nothing about whether that data's content was quietly corrupted before the model ever touched it. There is no checkbox for that.

Prompt injection is stranger still. A malicious input can redirect an agent's behavior without touching a single line of code. Firewalls do not inspect intent. There is no clean precedent for this in traditional application security, and the people claiming otherwise are usually trying to sell you a product that doesn't fully solve the problem.

Then there's credential and secrets leakage. AI coding assistants and agentic tools routinely brush up against environment variables, configuration files, and API tokens in the normal course of their function. CVE-2025-62615 (AutoGPT SSRF), CVE-2025-23317 (NVIDIA Triton remote code execution), and a cluster of MLflow credential flaws share the same root cause: weak control boundaries around how AI platforms handle the secrets they need to operate. Same class of error, repeating.

Shadow AI compounds everything. Nearly half of generative AI users access tools through personal accounts, completely bypassing enterprise controls, per Netskope's 2026 research. The system being audited is not the full system in use. That gap will eventually be conspicuous to someone whose job it is to notice gaps.

Finally, agentic autonomy. An agent making sequential decisions across five systems in a single workflow creates an accountability chain that static application logging was never designed to reconstruct. When those actions come into question later, the logs either tell the story or they don't. In my experience, they usually fail to, precisely at the moment you most need them to succeed.

None of this means AI is uniquely dangerous or fundamentally ungovernable. It means AI systems stress specific control boundaries that compliance frameworks weren't written to harden. The frameworks still apply. Applying them just requires more deliberate translation than most programs budget for.

What SOC 2's Trust Service Criteria Actually Require When AI Systems Are In Scope

SOC 2 is organized around five Trust Service Criteria: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Security is mandatory. The others are selected based on services offered. For most AI platforms, Processing Integrity and Confidentiality are where auditors start asking the questions organizations are least prepared to answer.

Processing Integrity requires that the system processes data completely, accurately, and as authorized. For an AI model, that translates roughly to: can you demonstrate that outputs are reliable, and can you document the provenance of the training data shaping them? Most organizations cannot say yes to both, and the ones who think they can often haven't looked closely enough. Processing Integrity was written with transactional systems in mind; applying it to a probabilistic model requires deliberate interpretation, not wishful equivalence.

Confidentiality requires that designated confidential data is protected. An LLM that surfaces confidential customer information in its outputs, or an agent passing sensitive context to a third-party model API, creates a direct Confidentiality exposure. Both technically and legally.

Several Common Controls generate the most friction in practice. CC6 (Logical and Physical Access Controls) must cover not just human users but AI agents and service accounts. If an agent can call an internal API, that agent needs a scoped identity, scoped permissions, and a revocation path. "The model doesn't count as a user" is not a defensible audit position, and auditors who specialize in this area have stopped letting it slide.

CC7 (System Operations) covers monitoring and detection. For AI systems, this means logs of model invocations, tool calls, and output anomalies, not only network events and server metrics. Auditors will ask to see them. Absence is conspicuous.

CC8 (Change Management) is where things get interesting. It covers model updates, prompt template changes, and tool definition changes. The "rug pull" attack vector, where a remote MCP server silently alters its tool behavior after installation, is a CC8 failure by definition. If changes to AI system behavior bypass the change management process applied to code deployments, the control is incomplete. The finding writes itself.

CC9 (Risk Mitigation) requires vendor risk assessments covering the full supply chain: model providers, orchestration layers, and third-party APIs are all in scope. A terms-of-service agreement is not a vendor assessment, and the distinction is not subtle.

The AICPA has signaled that AI governance controls, including model governance and training data provenance, are moving toward formal SOC 2 criteria. For B2B AI vendors specifically, approximately 66% of B2B buyers now require a SOC 2 report before engaging, so this is a commercial reality before it becomes a regulatory one. Organizations building these controls now are ahead of what auditors will formally require. That window doesn't stay open indefinitely.

What ISO 27001 Requires When AI Is Part of the Information Security Management System

ISO 27001's governing logic is risk-based, not checklist-based. Identify risks to information assets, select controls to treat those risks, and demonstrate through a systematic ISMS that the process is continuous and improving. This means AI systems must appear in the asset inventory and the risk register. If they don't, the ISMS is describing a version of the organization that doesn't exist.

The Annex A control domains most directly implicated: A.8 (Technology Controls) covers access control to systems and data. AI agents and automated systems need documented identities and access logs, exactly as human users do. Shared service accounts with excessive privilege are a finding, regardless of whether the account holder can pass a Turing test. That framing occasionally produces uncomfortable laughter in audit walkthroughs, but the finding stands.

A.5.23 (Information security for use of cloud services) applies to every cloud-hosted model API in the AI stack. "We use OpenAI" is a starting point for a conversation, not the conclusion of an assessment.

A.8.9 and A.8.32 (Configuration and Change Management) are both implicated by model versioning, prompt configuration, and tool definition updates. An undocumented change to AI system behavior is a nonconformity. This is the same conclusion as CC8 under SOC 2, which illustrates why the control overlap between these frameworks runs 60 to 70%; working seriously toward one produces meaningful groundwork toward the other.

A.5.7 and A.8.16 (Threat Intelligence and Monitoring) extend continuous monitoring obligations to AI behavior. Unexplained spikes in API calls, unusual output patterns, and unauthorized tool invocations are security events. They must be detected, logged, and investigated.

ISO 27001's supplier management requirements (A.5.19 through A.5.22) demand documented assessment of every supplier handling organizational information. For AI, that scope includes the model provider, the training data pipeline, any orchestration layer, and every MCP server the organization deploys or consumes. The scope is broader than most organizations have mapped, and the gap between what's assessed and what's actually in use tends to be embarrassing when surfaced.

The ISMS audit cycle has a useful property that's worth appreciating: AI risks identified in the risk register must have treatment plans, and those plans must demonstrate progress at each management review. The framework doesn't punish organizations for having AI risks; it punishes organizations for pretending they don't. That distinction matters considerably more than it might initially seem.

ISO 42001, the dedicated AI management systems standard, is emerging as a complement for organizations wanting certification specifically addressing AI governance. Organizations already operating a mature ISO 27001 ISMS have most of the organizational infrastructure ISO 42001 also requires: documented policies, internal audits, management reviews, risk treatment procedures. The marginal effort is real but not prohibitive.

Access Control Obligations and the Specific Problem of AI Agent Identity

Both frameworks require that access to systems and data be granted on a least-privilege basis, tied to authenticated identities, and revocable. None of that becomes optional because the accessor is an AI agent. The frameworks have no non-human exception. They were never designed to accommodate one.

The identity gap in most enterprise AI deployments is significant. Agents are typically treated as applications rather than principals; they run under shared service accounts, use long-lived credentials stored in environment variables, and produce no individual audit trail. This fails CC6 under SOC 2 and Annex A.8 under ISO 27001 on their face. IBM's Cost of a Data Breach Report 2025 found that among organizations reporting an AI-related security incident, the vast majority lacked proper AI access controls. That is the baseline condition, not an outlier.

What compliant AI access control actually looks like in practice: each AI agent or MCP server carries its own identity rather than a shared service account; permissions are scoped to the minimum required for the agent's defined function; identity is federated through the organization's existing identity provider via OIDC or SAML, so provisioning and deprovisioning follow the same lifecycle as human users. OAuth tokens are managed centrally, not stored in client configurations or hardcoded in files. That last pattern is exactly what produced the MLflow and NVIDIA Triton CVEs, and it keeps recurring because treating agents as exempt from credential hygiene has been the de facto standard for long enough that it feels normal. The MCP specification's June 2025 update made OAuth 2.1 the standard authentication requirement for remote MCP endpoints. Compliance means implementing it, not acknowledging it in a policy document.

Gartner found that only 13% of IT application leaders strongly agreed they had the right governance structures to manage AI agents. That number would surface directly in a SOC 2 or ISO 27001 audit if auditors ask the right questions. They are increasingly doing so.

Platforms like Speakeasy address this at the architectural level, enforcing role-based access control through existing identity providers, assigning each agent a scoped identity, and centralizing credential management. The value proposition is straightforward: apply a well-understood access control model to a deployment pattern that most organizations have been treating as exempt from it.

Audit Logging Obligations and Why AI Systems Make Them Harder to Satisfy

SOC 2 (CC7) and ISO 27001 (A.8.15, A.8.16) both require that security-relevant events be logged, retained, and reviewable. Standard application logging captures user authentication, data read and write operations, configuration changes, and errors. All of that still applies. AI systems also generate categories of events that standard logging architectures were not designed to capture: which user issued which prompt to which model; what tools or APIs the model invoked and with what parameters; what data was included in the context window at the time of invocation; what the model returned, including any PII surfaced in outputs; whether tool definitions changed between invocations.

Agentic systems compound this materially. A multi-step agent making five API calls on behalf of a single user creates a chain of events that must be traceable back to the original authorization. If any link in that chain goes unlogged, the audit trail is broken. Auditors call this a completeness problem. It is also an accountability problem, because without the chain, you cannot reconstruct what happened or why, which is precisely the moment you will most need to.

Shadow AI makes detection harder still. IBM's 2025 research found that shadow AI-related breaches averaged 247 days to detect, six days longer than standard breaches. The detection gap maps directly to the logging gap: events running outside your perimeter go unlogged, and you cannot detect what you cannot see. The math is unforgiving.

What auditors will look for: log completeness (does the architecture capture AI-specific events, or only infrastructure-level events?), log integrity (are logs tamper-evident and retained for the required period?), and alerting (are there detection rules for anomalous AI behavior, or are logs collected and never reviewed?). Amazon reduced audit findings by 90% through continuous monitoring. Automated, real-time log analysis outperforms periodic manual review for catching AI-specific incidents before they become audit findings. Anyone who has sat through a manual log review exercise covering weeks of AI invocation data will find that conclusion unsurprising.

Risk Management and Vendor Assessment Obligations as AI Supply Chains Grow

Formal risk assessment is required under both frameworks. The risk register must include AI systems; each AI-specific risk must have a documented treatment plan. This is where most organizations handle things poorly, because it requires acknowledging exposures that are considerably easier to minimize than to manage.

The EY Responsible AI Pulse Survey, conducted across 975 C-suite leaders in 21 countries, found that 99% of organizations reported financial losses from AI-related risks, with the majority losing more than a million dollars and average losses from realized AI risks reaching $4.4 million. A risk register that doesn't reflect this exposure is not an accurate risk register. It is a document that will embarrass someone during an audit, and auditors tend to remember the documents that do.

AI supply chain risk operates at several layers simultaneously. The foundation model provider is a relationship most organizations have at least nominally assessed; if the vendor changes model behavior, retains prompt data, or suffers a breach, the downstream organization carries the exposure. ISO 27001's supplier management controls (A.5.19 through A.5.22) require a documented assessment of that relationship. A terms-of-service checkbox is not an assessment. Auditors who specialize in this area have stopped accepting it as one.

The training data pipeline is a risk surface that standard vendor assessments don't address at all. Data provenance and integrity are Processing Integrity concerns under SOC 2; most organizations using third-party or fine-tuned models cannot document the lineage of the data used to train them. This is not a hypothetical gap. It is a consistent finding across assessments, and it tends to produce uncomfortable silences in audit conversations.

Third-party MCP servers and plugins are where supply chain risk becomes most acute and least governed. A scan of over 500 MCP servers conducted by Adversa AI in early 2026 found that 38% had no authentication on critical endpoints and 43% were vulnerable to command execution. Any organization consuming third-party MCP servers without a formal assessment is accepting supply chain risk that their risk register does not reflect and their auditors will eventually surface.

The practical obligation is straightforward even when execution is not: every AI system, model API, and third-party tool in the stack needs to appear in the asset inventory, be subject to vendor assessment, carry documented risks, and feed into a treatment plan with a named owner. This is not an AI-specific requirement. It is the same risk management discipline both frameworks have always demanded, applied to a supply chain that grew considerably faster than most compliance programs noticed.