SOC 2 Audit Evidence Collection for Agentic AI Systems

SOC 2 audit evidence collection for agentic AI systems is a runtime engineering problem. The 2017 Trust Services Criteria still govern, but agents create new obligations to show who acted, with what authority, and under which controls. That evidence must be collected when agents run. Documentation assembled after the audit window opens cannot recover a chain of authorization that was never recorded.

Why the 2017 Trust Services Criteria still govern AI agent audits in 2026

The AICPA’s 2017 Trust Services Criteria, with revised Points of Focus published in October 2022, remain the operative standard in 2026. No AI-specific edition has replaced them. Security is mandatory in every engagement, while availability, processing integrity, confidentiality, and privacy enter scope according to what the business does. An agent changes how those criteria apply to a system.

The AICPA released its first authoritative AI-specific interpretation for SOC examinations on September 11, 2026. TQA Q&A Section 9561, “SOC Examinations: Effect of the Service Organization’s Use of Artificial Intelligence on SOC 1 and SOC 2 Examinations,” interprets the existing criteria. Meanwhile, auditors have been assembling requests for model lineage, prompt and inference logs, drift monitoring, and AI subprocessor assessments. The written foundation is stable. The evidence requests are not.

That scrutiny extends beyond AI-specific records to the quality of the examination itself. The AICPA Peer Review Board’s May 2026 alert warned that practices handling many engagements could have them classified as nonconforming if they used the same reports, risk assessments, sample sizes, and testing procedures for different clients. Static screenshots are also being challenged more often in favor of timestamped continuous-monitoring exports that cover the full audit window. For organizations using agents or model APIs in customer-facing or data-processing work, AI is no longer a detail an auditor can be expected to overlook.

What makes AI agents structurally different from the human users SOC 2 controls were designed for

Access-control and change-management controls depend on privileged actions being attributable to an accountable human or a well-defined service account. Agents complicate that attribution by independently reading files, writing data, and calling tools without a discrete human request before every action. They also inherit permissions designed for human use. Employees generally exercise only a fraction of their permissions, while agents can use their granted access automatically and repeatedly. Human-scale permissions acquire machine-speed consequences.

A human request may pass through an orchestrator, a sub-agent, a retrieval agent, and a tool adapter before producing a single write. Every hop can have a valid identity without preserving the connection between the final action and the human-authorized task. Short-lived pods, serverless functions, and pipeline jobs make this harder when they act and disappear without leaving records that last.

Three production incidents show why that distinction is operational. The Replit DROP DATABASE event of July 2025, the Cursor destructive-shell-command incident of August 2025, and the Claude Code DataTalks.Club infrastructure-destruction event of February 2026 all have records of destructive actions. In each case, however, no single record answers the governance question of under what regime the action was authorized. Oleg Solozobov’s Decision Evidence Maturity Model names the underlying mistake the “container fallacy,” meaning the automatic equation of an evidence container’s presence with audit sufficiency. A log can document the wreckage without explaining who authorized the journey.

How each Trust Services Criterion generates new evidence obligations when agents are in scope

Under CC6.1–CC6.3, access-control evidence must show an agent’s own identity, what permissions it has, and who is its accountable owner. An agent authenticating through a human user’s service account inherits that user’s full permission set, creating a control design failure. A-LIGN’s May 2026 guidance says an agent should “lack the technical ability” to perform an unauthorized action. A system prompt saying “never delete” is not that restriction. The concrete evidence is an inventory of agents and credentials showing least-privilege scopes and named ownership for every agent identity.

Under CC7.2 and CC7.3, monitoring must show both that an agent ran and what it did. Tool-call records need to capture which agent acted, on whose behalf, which MCP server or tool it called, the inputs, the result, and the timestamp. Those records must cover every in-scope agent for the whole observation window. OpenTelemetry tracing is a useful place to start because it wraps each agent step in a span with the agent ID, model version, and input hash. That trace still needs the other required properties. Its existence alone does not establish sufficient monitoring.

Under CC8.1, changes to prompts, models, and tool configurations belong in production change management. A system-prompt edit can change how the system behaves without changing application code, and a model-version switch or MCP server configuration change can change the system an auditor is checking. Auditors will request change tickets and attached approvals for these changes, along with the test artifacts supporting promotion. AI pipelines that promote outputs against thresholds still need the approval and testing evidence that human-initiated tickets normally provide.

Under CC9.2, vendor assessment must cover every model provider and third-party MCP server that an agent calls. A clean SOC 2 Type II report may leave out tests of controls for model accuracy, training-data integrity, or drift detection. Auditors will ask for assurance documentation for each provider and third-party server, including SOC 2 reports or equivalents that were reviewed within the audit period. Baker Tilly’s guidance places model development, validation, and monitoring within the existing framework, particularly processing integrity and security.

When Privacy is in scope, evidence must follow personal data through training, fine-tuning, inference, and logs. Without that lineage, an organization cannot demonstrate the required handling and disposal of the data. Inference logs can themselves contain personal data. This makes it harder for organizations that process customer data with AI to justify leaving Privacy out of scope. The records used to prove that controls worked may themselves need privacy controls, which adds to the work of evidence collection.

Why existing evidence collection methods fail for agents and what the container fallacy costs in practice

Records of a tool call may show that it ran without showing what authorization governed the decision to run it. The container fallacy can lead people to trust those records too much. A clean report can then be read as evidence of coverage that the tested controls did not actually establish. Logs may be present but lack the properties needed in the evidence they provide.

The model’s reconstructability framework evaluates sufficiency per governance question and per decision-evidence property. It classifies evidence into four executable categories plus a conflicting category, then aggregates the findings into a five-level capability rubric. Evidence sufficient to establish which tool ran may be insufficient to establish whether its use was authorized. Without a common AI testing baseline, two organizations can also have clean Type II reports even though the AI control sets tested for each were entirely different.

The Cloud Security Alliance/Strata 2026 survey found that only a minority of organizations could trace agent actions to a human sponsor across all environments. The practitioner response has been to define scope explicitly, restrict agents to allowlisted connectors, and use structured logging to compensate for evidence gaps. Restricting connectors reduces the audit surface, but does not make the remaining actions reconstructable. Runtime instrumentation addresses the missing chain rather than moving its loose ends outside the boundary.

Building the evidence pipeline alongside the agent, not after the audit window opens

The practical response is to design the evidence pipeline when the agent is built. Teams reconstructing records at audit time discover that logs were never retained, evaluation runs were never archived, or access records have rotated out of retention. Type II continuity depends on records showing controls operated throughout the observation window. Instrumentation added halfway through that window cannot record earlier actions it never saw.

For each action, the pipeline should retain the agent identity and credential scope, the human-authorized task, the tool or MCP server called, inputs and outputs, the model version in use, and the timestamp. The task connection is essential across delegated work. Otherwise, even detailed records of each step fail to show how the final action served the authorized request.

Technical enforcement should sit beside that recordkeeping. Distinct non-human identities need only the permissions the agent requires, so tools and scopes it does not need must be removed even if instructions already discourage their use. Before system-prompt edits and model-version switches go into production, they should have change tickets with approval records. MCP configuration changes require the same discipline. These controls establish the permissions and approved system state that runtime records must connect to an action.

Continuous collection also depends on knowing which agents exist. Audit-grade evidence depends on finding every agent, monitoring all approved AI traffic, spotting anomalous behavior and policy violations, and enforcing rules on which actions are allowed. Complete logs then document those actions across the observation window. The OWASP Top 10 for Agentic Applications 2026, published in December 2025, provides a useful free input to the risk assessment, including tool misuse and identity and privilege abuse. That assessment helps determine which behaviors the pipeline must capture, while runtime visibility makes those behaviors available for detection before they become audit findings.

How AIUC-1 and the September 2026 AICPA TQA change what auditors will ask next

The AICPA’s September interpretation gives auditors an authoritative basis for applying the unchanged criteria to AI. That can reduce the ad hoc variation behind different tested control sets, without creating a separate SOC examination model. AIUC-1 addresses a different part of the problem. It tests prompt injection, jailbreaks, hallucinations, unsafe tool calls, and data leakage on the agent itself, while SOC 2 tests whether the company’s controls are designed and operating.

Their timing differs as well as their target. AIUC-1 retests at least every quarter, whereas a SOC 2 report covers a past period. Quarterly testing fits the continuous-monitoring discipline supported by a well-instrumented evidence pipeline, but it is not the same assurance exercise. On October 19, 2026, the AICPA and AIUC announced a joint offering bundling a SOC 2 report and AIUC-1 certification in a single accountant-led engagement.

Cursor, Lovable, Harvey, ElevenLabs, KPMG, UiPath, and Fin, formerly Intercom, have certified products against AIUC-1. Schellman has held full auditor accreditation since November 1, 2025, while Coalfire, BDO, Grant Thornton, Mastermind, Sensiba, and A-LIGN have provisional accreditation. These developments establish direction for future requirements. Organizations with continuous agent inventories, property-level tool-call records, controlled prompt and model changes, and technically enforced permissions are building toward both forms of scrutiny. The next audit question may change. Recording the evidence when the action happens preserves the possibility of answering it.