SOC 2 and AI Agents: What AICPA's TQA 9561 Means for Your Next Examination

Buyers have started asking a new question in vendor security questionnaires: does your SOC 2 report cover the AI agents in your product, and is there an AI-specific SOC 2 now? The second half of that question comes up often enough that CPA firms publish FAQ pages answering it. Bright Defense's SOC 2 news page fields the exact phrasing, "Does the new AI guidance require a separate SOC 2 audit?"

The short answer: no. On September 11, 2026, the AICPA published TQA Section 9561, a practice aid on the effect of a service organization's use of AI on SOC 1 and SOC 2 examinations. It did not create a new report type, a new set of criteria, or a separate AI audit. What changes is how the existing criteria apply once an AI agent sits inside the system that delivers your service.

That distinction has one practical consequence that frames everything below. An auditor can only test what appears in your system description. If you can't describe the agents running inside your service, they can't be scoped, and controls you can't scope can't be examined. A complete, owned inventory of your agents is where SOC 2 readiness now starts.

Did the AICPA create AI-specific SOC 2 criteria?

No. TQA 9561 is a Technical Questions and Answers document, a nonauthoritative practice aid that helps practitioners apply existing standards. The AICPA's own page describes it as addressing "the effect of a service organization's use of AI" on SOC 1 and SOC 2 examinations under AT-C section 205, the attestation standard those examinations already run on. The full text sits behind a free AICPA login.

The named summaries from CPA firms are consistent on what it does and doesn't do. Schneider Downs puts it plainly: "AI does not create a separate SOC examination model, and the AICPA did not invent new criteria." Aprio is just as direct: "There is no '2026 Trust Services Criteria'... No new control objectives, no separate AI module."

So when a buyer asks for your "AI SOC 2," the accurate response is that SOC 2 already covers AI through the same Trust Services Criteria it has always used. The examination changes. The criteria do not.

When an AI agent is inside your SOC 2 system boundary

The system description is the scoping document for a SOC 2 examination. It defines the boundary of the system that delivers your service: the infrastructure, software, people, procedures, and data in scope. If an AI agent is part of how you deliver the service, a support agent that resolves tickets, a retrieval agent that answers product questions, a SQL-generating agent that pulls customer data, it belongs in that description, and the controls around it come into scope.

The problem most teams hit is earlier than the audit. You can't describe agents you haven't found. Agents enter an enterprise from many directions: application teams build them into new features, vendors ship them inside software you already run, and individual developers stand them up on their own. Without an inventory, the ones nobody registered become the gaps an auditor's scoping questions eventually expose.

This is where discovery does the work. Arthur runs automated, multilayered agent discovery and governance across telemetry (OpenTelemetry streams), Model Context Protocol servers, network-layer signals, and cloud platform APIs like AWS Bedrock and Google Vertex AI. Detected agents get triaged, assigned a named owner, and organized into a governed application. That inventory is the raw material for an accurate system description: you can only draw the boundary deliberately once you know what's inside it.

LLM and agent platform providers as subservice organizations

Most agents call an external model. When that external provider performs a function that is part of your system, SOC 2 already has a way to handle it. As Schneider Downs frames it, "if a third-party AI provider performs functions that are part of the service organization's system, the analysis is the same as for any other subservice organization," handled by either the inclusive or the carve-out method.

The two methods differ in how the subservice organization appears in your report:

• Carve-out method. Your report describes the functions the subservice organization performs but excludes its controls from the description and the scope of your auditor's testing. The reader knows the provider is there and is expected to rely on that provider's own report for assurance about its controls.
• Inclusive method. The subservice organization's relevant controls are included in your system description and tested as part of your examination. This is less common and requires the provider's cooperation.

Most organizations carve out their LLM and agent platform providers and point to those providers' own attestation reports. Either way, the decision belongs in the system description, and the inventory tells you which providers your agents actually depend on.

Mapping agents to CC6, CC7, and CC8

The common criteria are where agent controls land. Three sections carry most of the weight.

CC6 (logical and physical access). Agents hold credentials, call tools, and reach data sources, so they have an access footprint like any other system component. Aprio's guidance here is concrete: maintain an inventory of AI tools, service accounts, and API keys with named owners. For an agent, that means knowing which tools it can invoke, which data sources it can read, and which credentials it carries, each tied to an accountable owner.

CC7 (system operations and monitoring). This is where you show you detect and respond to anomalous behavior. Aprio explicitly calls out monitoring for threats like prompt injection. For agents, that extends to catching behavioral issues in production: hallucinated claims, actions outside intended scope, responses that drift off-topic. Continuous evaluations that run against live traffic, and guardrails that intercept bad inputs and outputs in real time, are the kind of operating controls this criterion is about.

CC8 (change management). Changes to an agent's behavior rarely look like code changes. A prompt edit, a new tool definition, or a configuration swap can alter what the agent does without touching the application. Applying CC8 to agents means treating those changes with the same discipline as any other: versioned, reviewed, and traceable. (TQA 9561's summaries focus on CC6 and CC7; mapping agent change control to CC8 is applying the existing criterion, not something the practice aid spells out.)

The evidence package your auditor will ask for

A SOC 2 Type II examination tests whether controls operated over a period, not just whether a policy existed on paper. For agents, the artifacts that demonstrate operation line up with the criteria above:

• Inventory and ownership show, for CC6, that every agent and its access footprint is accounted for and has an accountable owner.
• Continuous eval results and monitoring telemetry show, for CC7, that you were watching for anomalous behavior across the period and have the records to prove it.
• Guardrail verdicts are records of a control operating: each time a guardrail intercepted PII, flagged a hallucination, or blocked a prompt injection, that event is evidence the safeguard ran.
• Versioned prompt and configuration change history shows, for CC8, what changed, when, and who approved it.

The through-line is that these are operating records, not descriptions of intent. An auditor reviewing a Type II report wants to see the control working across the examination window. Telemetry emitted continuously from your agents produces exactly that trail.

Avoiding scope inflation

Not every AI tool belongs in your system description. A model a developer uses to draft internal documentation, or a tool that never touches the service you're attesting to, can stay outside the boundary. Sweeping every AI touchpoint into scope inflates your examination, raises cost, and creates controls you have to maintain for no assurance benefit.

The discipline that prevents this is the same inventory that makes scoping possible. When you know what every agent is, who owns it, and what it can reach, you can draw the boundary deliberately, including what delivers the service and leaving out what doesn't, rather than guessing and over-including to be safe.

Where this leaves you

The criteria didn't change. The examination did. SOC 2 covers AI agents through the Trust Services Criteria it already had, and readiness comes down to two things: knowing which agents sit inside your system boundary, and being able to show the controls on them operated across the period. Both start with a complete, owned inventory.

Arthur is not an auditor and doesn't make anyone SOC 2 compliant. What Arthur does is give you the discovered inventory that scopes the system description and the continuous evidence, eval results, guardrail verdicts, monitoring telemetry, and versioned change history, that demonstrates your agent controls operated.

To see how Arthur discovers and governs the agents in your environment, book a demo.

‍