SOC 2 for AI Agents and LLM Features: What Auditors Will Test

SOC 2 for AI agents means applying the existing Trust Services Criteria to software that can act on its own: an agent must have its own identity and least-privilege access (CC6), its actions must be logged and monitored (CC7), and changes to its prompts, tools, and models must go through change management (CC8). There is no separate AI version of SOC 2 today, so auditors test AI features against the same criteria they use for everything else.

That sounds simple. In practice, AI agents break several assumptions that SOC 2 controls quietly rely on, and teams that add a copilot or agent in the middle of an audit window often discover the gap during fieldwork. This guide explains what auditors will look for, where the evidence usually falls short, and what the AICPA's 2026 guidance and proposed 2027 criteria change.

Is there an official SOC 2 standard for AI?

No. As of November 2026, there are no AI-specific SOC 2 criteria in force. SOC 2 examinations are performed against the 2017 Trust Services Criteria (TSP Section 100) with revised points of focus issued in 2022, and AI systems are evaluated within those existing criteria.

Two 2026 developments clarify how that works and where it is heading:

1. AICPA Technical Q&A Section 9561 (September 11, 2026). Titled "SOC Examinations: Effect of the Service Organization's Use of Artificial Intelligence on SOC 1 and SOC 2 Examinations," the Q&A explains that AI does not create a separate SOC model or new criteria. AI used only in internal processes may have no SOC 2 implications. AI embedded in customer-facing services may require changes to scope, the system description, and controls (AICPA & CIMA). AICPA Technical Q&As are nonauthoritative, but auditors use them to interpret the standards.
2. The 2027 Trust Services Criteria exposure draft (October 28, 2026). The AICPA proposed a significant update to the SOC 2 criteria, including new points of focus covering AI governance, model monitoring, prompt manipulation, data poisoning, transparency of AI-generated outputs, training data management, and the risks of automated decision-making. Comments are due January 15, 2027. If approved, the criteria would be effective for engagements beginning on or after December 31, 2027, with early adoption permitted (AICPA & CIMA).

Until the new criteria are final and effective, the result is uneven. The Cloud Security Alliance observed in August 2026 that two AI companies can each hold a clean SOC 2 Type II report while having tested very different control sets, because auditors are interpreting general criteria against new risks (Cloud Security Alliance). For buyers, that means a SOC 2 report from an AI vendor may say little about its AI controls. For vendors, it means the companies that document AI controls clearly now will have an easier time when buyers start asking.

Why do AI agents create new SOC 2 audit risk?

AI agents create new SOC 2 audit risk because most SOC 2 controls were designed for two kinds of actors: people, who log in and are reviewed by HR and managers, and deterministic software, which does the same thing every time and changes only through a deployment pipeline. An agent is neither. It acts with delegated authority, decides which tools to call at runtime, and changes behavior when someone edits a prompt.

Four patterns cause most of the trouble:

• Borrowed identity. Agents often run on a shared API key, a developer's personal token, or a broad service account. The access exists, but nobody can say which agent used it, for what, or who approved it.
• No lifecycle. Human accounts are created at onboarding and removed at termination. Agents are spun up in a sprint and forgotten. Nothing tells anyone that an agent should stop.
• Silent change. A one-line edit to a system prompt can change what an agent does with customer data. Many teams push prompt changes through a dashboard or a config file that never touches the change management process auditors test.
• Unattributable actions. When an agent modifies a record, the log often shows the service account, not the agent, the triggering user, or the prompt. That makes CC7 monitoring and incident investigation difficult to evidence.

None of these is exotic. They are ordinary access, monitoring, and change control questions, which is why CC6, CC7, and CC8 are where auditors focus.

Does adding an AI feature change your SOC 2 scope?

Adding an AI feature changes your SOC 2 scope when the feature is part of the services your customers receive or affects the systems, data, and controls already in scope. An internal coding assistant used by engineers may have little effect. A customer-facing agent that reads and writes customer data almost certainly does.

Work through four scoping questions:

1. Is the AI part of the service? If customers interact with it or it processes their data, it belongs in the system boundary.
2. Does the system description still hold? Under the AICPA Description Criteria (DC Section 200), the Section 3 description must accurately describe the system's components, including infrastructure, software, people, procedures, and data. A description written before you shipped an agent may now be incomplete. If the change happened during a Type 2 period, the description should also disclose significant changes during the period. See our guide to DC Section 200 system descriptions.
3. Who provides the model? Third-party model providers are evaluated like any other subservice organization, using the carve-out or inclusive method. If you carve out a model provider, the report should identify the complementary subservice organization controls (CSOCs) you rely on it to perform.
4. What do customers need to do? If customers configure the agent's permissions or connect their own data sources, you may need complementary user entity controls (CUECs). Our CUEC guide explains how to write them.

A common mistake is treating the model provider's own SOC 2 report as if it covered your agent. It does not. The provider's report covers the provider's controls. Your agent's identity, permissions, prompts, tool integrations, and logging are yours.

How does CC6 (logical access) apply to AI agents?

CC6 applies to AI agents by requiring that each agent is a known, authorized identity with only the access it needs, and that its access is reviewed and removed like any other account. The 2017 criteria do not distinguish between human and non-human identities. Auditors increasingly test both.

The criteria that matter most:

• CC6.1 requires logical access security over protected information assets. For agents, that means a distinct identity per agent or per agent function, scoped credentials, and secrets stored in a managed vault rather than in code or prompts.
• CC6.2 requires that users are registered and authorized before credentials are issued. For agents, the evidence is an approval record showing who requested the agent's access, what it was granted, and who approved it.
• CC6.3 requires access to be authorized, modified, and removed based on roles and least privilege. For agents, this covers tool permissions (which APIs and actions the agent can call), data scopes, and decommissioning.

What auditors typically ask for:

• An inventory of AI agents and the identities they use, with a named human owner for each.
• Evidence that agent credentials are unique and not shared with people or other services.
• Approval records for agent access, and evidence that permissions match the documented purpose.
• Agent accounts included in periodic user access reviews, with review decisions recorded.
• Evidence that retired agents had their credentials revoked.

The quiet gap here is the access review. Many teams run quarterly reviews that list human users from the identity provider. Agent service accounts and API keys live elsewhere, so they never appear in the review population. An auditor who compares the review population to the full list of production credentials will find the difference.

How does CC7 (system operations) apply to AI agents?

CC7 applies to AI agents by requiring that you can detect, investigate, and respond to unexpected agent behavior the same way you would for any other system event. If an agent takes an action nobody intended, you need logs that show what happened and a process that tells someone to look.

The relevant criteria:

• CC7.1 covers detecting configuration changes and vulnerabilities. For AI features, this includes monitoring for unauthorized changes to agent configurations, tool connections, and prompts.
• CC7.2 covers monitoring system components for anomalies that could indicate malicious acts or errors. For agents, that means alerting on abnormal patterns such as unusual volumes of tool calls, access to data outside the agent's normal scope, or repeated failed actions.
• CC7.3 and CC7.4 cover evaluating security events and responding to incidents. Your incident response plan should address AI-specific scenarios, including prompt injection that causes an agent to exfiltrate data, an agent making unauthorized changes, and a model update that produces harmful or incorrect output.
• CC7.5 covers recovery. Can you roll an agent back to a known-good prompt and model version?

The evidence auditors look for is an action log that ties each agent action to the agent identity, the triggering user or event, the tool called, and the time, retained for a defined period and reviewed through alerting rather than only on request. If your logs record only "service account X called API Y," you will struggle to show attribution.

How does CC8 (change management) apply to prompts and models?

CC8 applies to prompts and models because CC8.1 requires that changes to infrastructure, data, software, and procedures are authorized, designed, developed or acquired, configured, documented, tested, approved, and implemented. A system prompt, a tool definition, and a model version all determine how an AI feature behaves, so changing any of them is a change to the system.

Treat these as changes subject to your change management process:

• System prompts and prompt templates. Store them in version control, require review and approval before deployment, and keep the history.
• Tool and function definitions. Adding a new tool that lets an agent write to a database is a material change in capability. It should be approved like a new feature.
• Model versions. Pin model versions in production where your provider allows it. A switch from one model version to another should be tested and approved, not discovered.
• Retrieval sources and fine-tuning data. Changes to the data an agent retrieves from or was tuned on can change its output.
• Guardrail and filter configurations. Loosening a content filter is a change.

Testing evidence for AI changes looks different from unit tests, but it should exist. A documented evaluation set that each prompt or model change must pass before release is a reasonable, auditable form of testing. The approval record should show who reviewed the evaluation results.

Model providers sometimes update models behind a stable endpoint. That is a vendor management question as much as a change management one. Under CC9.2, you should assess and monitor vendors, and your vendor review for model providers should cover how they communicate model changes and what notice you receive.

What other Trust Services Criteria matter for AI features?

Beyond CC6, CC7, and CC8, several other criteria commonly come into play for AI features:

• CC3 (risk assessment). Your risk assessment should identify AI-specific risks such as prompt injection, data leakage through model outputs, and unintended agent actions. A risk register that predates your AI features and never mentions them is a common gap.
• CC9.2 (vendor management). Model providers, vector database vendors, and AI tooling providers are vendors. They need due diligence and ongoing monitoring.
• Confidentiality (C1), if in scope. If you send confidential customer data to a model provider, your controls should address what the provider may retain and how data is disposed of.
• Processing Integrity (PI1), if in scope. If your service commits to accurate or complete processing and AI is part of that processing, the TQA highlights model validation, output review, and error correction as relevant.
• Privacy, if in scope. AI processing of personal information raises notice, consent, and use limitation questions.

SOC 2 for AI agents: the evidence matrix

The table below maps common AI agent risks to the 2017 Trust Services Criteria, an example control, and the evidence an auditor is likely to sample. Use it as a starting point, not a complete control set.

What do the proposed 2027 Trust Services Criteria change for AI?

The proposed 2027 Trust Services Criteria would add AI-related points of focus but, based on the published exposure draft, no AI-specific criterion. Points of focus describe characteristics that help an organization and its auditor evaluate whether a criterion is met. They are not individually required, but they shape what auditors and buyers expect.

What is known so far:

• Status: An exposure draft, not a final standard. It may change after the comment period closes on January 15, 2027.
• Timing: If approved, effective for engagements beginning on or after December 31, 2027, with early adoption permitted.
• AI topics: AI governance, model monitoring, prompt manipulation, data poisoning, transparency of AI-generated outputs, training data management, and risks of automated decision-making.
• Structure: The draft restructures and renumbers the criteria. One practitioner analysis of the draft counts a reduction from 61 criteria to 50, with the common criteria renumbered so that today's CC6, CC7, and CC8 topics would sit under different numbers (SOC2Auditors.org). Verify against the AICPA's own draft before you re-map anything, since the official document controls.

What this means for you now: nothing in the draft suggests you should wait. The controls in the evidence matrix above address the AI topics the AICPA has named, and they map to today's criteria. If you build them now, the 2027 transition becomes a re-mapping exercise rather than a remediation project.

How to add an AI feature in the middle of a SOC 2 audit window

If you are adding an AI feature during a SOC 2 Type 2 observation period, follow this sequence to avoid surprises during fieldwork:

1. Tell your auditor early. Ask whether the feature changes scope and whether the system description needs to disclose it as a significant change during the period.
2. Create the agent's identity properly from day one. A unique identity, a named owner, an approval record, and scoped permissions. Retrofitting this later leaves a gap in the period.
3. Put prompts and tool definitions under version control before launch. Make the first production version the first approved change.
4. Turn on action logging before launch. Logs that start after go-live leave a period with no evidence.
5. Add the agent to your next access review. Make sure the review population includes it.
6. Update the risk register and vendor inventory. Add AI risks and the model provider.
7. Update the system description draft. Do not wait for fieldwork to discover it is out of date.

Common AI-related gaps to look for before fieldwork

These are the patterns most likely to surface when teams with AI features prepare for a SOC 2 examination:

• An agent runs on an engineer's personal API key, so the "agent's" access disappears when the engineer leaves, or worse, does not.
• The system prompt lives in a database table that product managers edit directly in production.
• The model provider is missing from the vendor inventory because it was set up with a company credit card.
• Access reviews cover the identity provider but not API keys, so agent credentials are never reviewed.
• Logs show every API call from a single service account, so nobody can tell which agent or user triggered an action.
• The incident response plan has no scenario for an agent behaving unexpectedly.

Each of these is fixable in weeks. Each becomes an exception if it is discovered after the period has run.

Ledger Audits' Evidence Engine is a monthly retainer that monitors operating effectiveness across the full audit window, maintains an evidence repository with chain of custody, runs a mock fieldwork dry run before your auditor arrives, and liaises directly with your auditor. For teams shipping AI features mid-period, it is designed to catch exactly these gaps before they become exceptions. Talk to us about Evidence Engine.

Related reading

• How to Write a SOC 2 System Description That Meets DC Section 200
• Complementary User Entity Controls: What DC Section 200 Actually Requires
• SOC 2 Sample Sizes: What Your Auditor Will Actually Pull
• How to Choose a SOC 2 Auditor: 12 Checks Before You Sign
• SOC 2 Exceptions vs. a Qualified Opinion

Frequently asked questions

Is there a SOC 2 standard for AI?

There is no AI-specific SOC 2 standard in force. SOC 2 examinations use the 2017 Trust Services Criteria with 2022 points of focus, and AI is evaluated within those criteria. The AICPA released a nonauthoritative Technical Q&A on AI in SOC examinations in September 2026 and an exposure draft of updated criteria with AI points of focus in October 2026.

Do AI agents need their own identities for SOC 2?

Yes, in practice. CC6.1 through CC6.3 require that access is restricted to authorized users, granted with approval, and limited by least privilege. An agent running on shared or personal credentials makes it impossible to show who authorized the access or what the agent did. A unique, managed identity per agent is the clearest way to evidence those controls.

Are prompt changes subject to SOC 2 change management?

Prompt changes that affect a production AI feature should go through change management under CC8.1, which requires changes to software and procedures to be authorized, tested, approved, and documented. A system prompt determines how the feature behaves, so editing it is a change to the system.

Does my model provider's SOC 2 report cover my AI feature?

No. Your model provider's SOC 2 report covers the provider's controls. Your agent's identity, permissions, prompts, integrations, and logging are your controls. The model provider is typically treated as a subservice organization, and your report should identify any complementary subservice organization controls you rely on.

When do the 2027 SOC 2 Trust Services Criteria take effect?

The 2027 Trust Services Criteria are currently an exposure draft with comments due January 15, 2027. If approved, they would apply to SOC 2 engagements beginning on or after December 31, 2027, with early adoption permitted. Until then, the 2017 criteria with 2022 points of focus remain in use.

Which SOC 2 criteria matter most for AI agents?

CC6 (logical access), CC7 (system operations and monitoring), and CC8 (change management) carry the most weight for AI agents, because agents need controlled identities, attributable and monitored actions, and controlled changes to prompts and models. CC3 (risk assessment) and CC9.2 (vendor management) also matter, as do Confidentiality, Processing Integrity, and Privacy when those categories are in scope.

Can I add an AI feature during my SOC 2 audit period?

Yes. Tell your auditor early, build the agent's identity, logging, and change controls before launch, include it in access reviews, and update your risk register, vendor inventory, and system description. Controls that start mid-period leave a gap in evidence, so build them before the feature goes live.

---