SOC 2 Trust Services Criteria Applied to AI Agent Systems

SOC 2 for AI agents is a test of whether an organization can control autonomous work and prove those controls operated. Organizations should map agents to the existing Trust Services Criteria, then build evidence into access, monitoring, change, and vendor controls. A policy authorizing AI use is not proof that an agent’s next action was authorized.

Why the 2017 Trust Services Criteria still govern AI agents in 2026

The AICPA has released no AI-specific SOC 2 criteria, AI points of focus, or authoritative AI addendum. Examinations still use the 2017 Trust Services Criteria, with points of focus revised in 2022. There is no separate AI module to await. The AICPA describes its AI-specific SOC publication, Technical Q&A 9561, listed September 11, 2026, as nonauthoritative, so it does not supply a replacement rulebook.

The criteria describe outcomes in technology-independent terms. Agents therefore fit within their scope even when they complicate the examination. An agent that reads customer data, changes records, or runs production code is another actor that needs controls on its access and behavior. Its autonomy is not a compliance exemption. KPMG’s September 22, 2026 webcast indicated that criteria changes for emerging technologies, including AI, are expected, but organizations must prepare against the criteria their auditor will actually use.

How an organization's role as User, Provider, or Producer determines the audit's scope and depth

Before auditors apply each criterion, they need a written account of how the organization uses AI. A User consumes AI outputs internally, such as staff using Copilot or ChatGPT to draft or summarize. A Provider operates someone else’s AI within its own product or service, while a Producer builds or trains models, including fine-tuning an LLM. These roles are not mutually exclusive. A Producer faces heavier model governance and testing expectations than an organization whose only AI footprint is an internal chatbot.

The scope decision therefore belongs in the risk assessment. An internal experiment without access to in-scope systems or customer data can sit outside the audit boundary, provided the rationale is documented and revisited when access changes. Production access changes the analysis. An organization becomes a Provider when an autonomous agent reads customer data or calls production tools, even if the model came from elsewhere.

CC6: why agents break the logical access assumption auditors rely on

The Cloud Security Alliance’s August 30, 2026 CISO briefing states that access criteria “assume privileged actions trace to an identifiable human”. Autonomous agents expose the weakness in that assumption because they act without a discrete human approval before every action. Permissions built for people now let machines act at their own speed. Under CC6.1–CC6.3, the evidence must identify each agent and its credentials, who approved its access, and which tools, scopes, and data it can reach. Agents must also be part of periodic access reviews and records of whose access was removed.

A shared admin key or an engineer’s personal token makes that accountability difficult to establish. If the agent keeps working after the engineer leaves, the organization has an access removal failure under CC6.3. Employee offboarding does not automatically extinguish agent OAuth access. Meanwhile, desktop assistants using personal accounts may never reach central logs, leaving the inventory incomplete before the auditor samples it.

Tool inheritance makes the problem deeper than credential bookkeeping. A tool installed and executed by an agent inherits the resources that agent can reach, including database credentials, API keys, and filesystem access. For high-risk calls such as deleting records, changing access, moving money, and emailing customers, there must be a written list of actions that need human sign-off and a technical mechanism that enforces it. “Told not to” is a prompt instruction, while “technically cannot” means the permission boundary or approval mechanism prevents the action.

CC7.2 and CC7.3: what runtime monitoring of agents requires and why logs alone don't satisfy it

Access controls define permitted behavior, but CC7.2 and CC7.3 require evidence that deviations are detected and investigated. A tool-call log must identify the agent, on whose behalf it acted, the MCP server or tool invoked, the inputs, the result, and the timestamp. Coverage must survive the agent’s operating conditions. Auto-scaling can create short-lived instances that are not consistently instrumented, breaking the record auditors need to sample. Defined alerts and investigation tickets must span the observation period.

Trend Micro found 492 MCP servers exposed to the internet with zero authentication. Invariant Labs demonstrated cross-server tool shadowing, in which a malicious MCP server weaponizes adjacent trusted servers. Individual calls can miss the larger sequence. For audit purposes, that shifts attention from whether a tool invocation was logged to whether monitoring could detect the behavior formed by several invocations.

Instruction context creates a related problem because tool descriptions and tool-result content can redirect agent behavior. A log containing only the tool name leaves out information needed to understand the action. Yet recording everything can expose sensitive content. Auditors therefore test whether log design preserves enough context and metadata to reconstruct intent without leaking protected data. Real-time behavioral monitoring adds evidence of detection and enforcement, while after-the-fact logs alone leave a harder question about whether the organization could respond at the pace its agents operate.

CC8.1: treating prompts, model versions, and tool permissions as changes that require change management evidence

CC8.1 extends the examination from what an agent does to how its authorized behavior changes. System prompts, model versions, tool definitions, permissions, and MCP server configurations all belong in change management. A prompt edit is an operational change. When a team edits a production prompt without a ticket because it considers the prompt “configuration”, the label does not supply the missing approval or test evidence.

For agents, evaluation results serve as the test artifact attached to the change ticket. Auditors look for those results and approval records before release, whether the change introduces a model version, alters a tool, or connects another MCP server. A pipeline promoting outputs on thresholds without human approval tickets leaves an evidentiary gap, and model retirements during the observation period require documented migrations. Changes to connected servers can also change what an agent does without an internal edit, so change management has to account for vendor oversight too.

CC9.2: assessing LLM providers and MCP server vendors as subservice organizations

CC9.2 applies to the outside organizations on which agent controls depend, including model API providers and third-party MCP server operators. The model provider is usually a subservice organization, most often handled through the carve-out method. Its SOC 2 report is evidence. The customer must document why it trusts that provider with customer data and which customer-side controls the provider’s report requires it to operate. Outsourcing the model does not outsource that judgment.

The vendor inventory must therefore name each model provider and third-party MCP server, with assurance that has been reviewed and written terms for data-use, training, and retention. Auditors require references to the LLM provider’s Terms of Service to be backed by an actual signed Data Processing Agreement. Community servers need a review before they are connected to production. An engineer adding one without that review creates an undocumented subprocessor whose data handling is unknown. That is not merely an untidy vendor spreadsheet, because the dependency can affect the organization’s own controls.

Evidence of confidentiality and privacy also needs to show how personal data passes through training, fine-tuning, inference, and logs. Without that lineage, the organization cannot demonstrate handling and disposal against its commitments. Processing Integrity adds another demanding scope choice. It tests whether outputs meet stated commitments, which is difficult to evidence for probabilistic models. Define a measurable commitment, such as “responses come from an approved model version that passed the release evaluation suite”.

Why SOC 2's sampling-based evidentiary model strains under probabilistic, high-frequency agent behavior

The deeper objection is that mapping criteria does not remove the mismatch in how evidence is examined. SOC 2’s historical sampling model works better for actions that humans have approved than for thousands of probabilistic actions by agents. General authorization cannot explain every individual request. An organization may have a sound policy allowing AI to perform certain tasks while lacking operational evidence of which task an agent was performing at the moment it acted.

Type II examinations test that operation. Application logs and policy documents can leave gaps when auditors try to trace a sampled action back to its authority. Auditor expectations are not uniform either. Evidence requests vary across engagements on model lineage, per-inference logging, drift monitoring, and LLM subprocessor risk, creating inconsistent experiences for organizations facing different auditors. It would be misleading to call the mapping a perfect fit.

Complete, attributed, unbroken tool-call logs give auditors a record to sample, while runtime controls produce evidence that unauthorized actions were blocked before they occurred. Prevention supplies a different kind of proof. An enforcement record supports a claim about what the system permitted, whereas a retrospective log may show only what happened. This strengthens the evidence around the boundaries imposed on probabilistic behavior.

Building the evidence package auditors now expect for autonomous agent systems

A compliance lead should sort the evidence package by criterion and require controls to keep records as they run. For CC1, CC2, and CC3, that starts with an AI acceptable use policy showing version history, approval date, and personnel acknowledgments across the review period. The risk assessment needs agent-specific entries. Those entries should cover prompt injection, output data leakage, model drift, provider outage, and tool permission inheritance, while recording what each agent can read, change, and send. Updates when tools change and ongoing monitoring of behavior and output quality keep the assessment from becoming a launch-day souvenir.

For CC6, assemble an approved inventory covering agents across engineering and other business units, with a distinct identity and documented access for each. Include periodic access reviews and records that show credentials were removed automatically when an agent was retired or its owner left. Runtime discovery helps expose unrecorded permission sets. The evidence should demonstrate technically enforced least privilege and required human approvals, rather than rely on prompt wording as the restriction.

For CC7, preserve an unbroken tool-call record with attribution, context, results, and timestamps across the observation period. Pair it with alert definitions, investigation tickets, and behavioral enforcement records. Sensitive content in that record still needs to be protected. For CC8, retain tickets for prompt edits, model switches, tool changes, and MCP connections, with evaluation results and approval attached to each. Together, those records let the auditor distinguish a behavior change from a monitoring failure.

For CC9, maintain the complete model-provider and MCP-server inventory with reviewed assurance, signed DPAs from LLM providers, and documented data-use and retention terms. Record what each vendor’s report says the customer must do. Production connections need a vendor review gate. That gate is especially important for community MCP servers that engineers might otherwise connect outside the established process. The resulting package links the agent’s permissions and observed behavior to the changes and external dependencies that shaped them.

What the AICPA–AIUC joint assurance offering signals about where AI agent compliance is heading

The AICPA and the Artificial Intelligence Underwriting Company (AIUC) announced a joint assurance offering on October 19, 2026. It bundles a SOC 2 report with AIUC-1 certification in one CPA-led engagement, with several CPA firms already delivering the offering and a full launch set for early 2027. The two examinations have different subjects. SOC 2 examines a service organization’s general controls, while AIUC-1 applies only to agentic AI systems and usually covers named agents or products.

AIUC red-teams agents with many scenarios to test how they behave under pressure from jailbreak attempts, out-of-scope requests, and unauthorized data exposure. That adds a behavioral examination alongside SOC 2. The distinction makes today’s control work reusable. Attributable identities, real-time controls, complete tool-call logs, and vendor evidence support both organizational assurance and scrutiny of the agent itself.