SOC 2 Evidence Requirements for AI Agent Audit Trails

AI agents need SOC 2 audit trails that prove who gave the go-ahead for an action, what limits were in place, and what actually changed. The absence of an AI-specific standard does not remove that burden. Existing criteria already apply, and teams can build a defensible evidence package by connecting identity, monitoring, change records, vendor reviews, and risk assessments to each agent’s actions.

Why existing SOC 2 criteria apply to AI agents even without an AI-specific standard

The AICPA’s 2017 Trust Services Criteria are outcome-oriented and apply across technologies. An agent that reads customer data or writes to production falls under the same controls as another privileged actor. The AICPA’s Technical Q&A 9561, listed September 11, 2026, addresses AI in SOC examinations but is nonauthoritative. As of October 13, 2026, the AICPA’s SOC page still lists the existing criteria with revised points of focus from 2022.

That makes scope the first real decision. A product agent, an engineering assistant with production access, and an assistant connected to a GRC platform raise different audit questions. An experiment without access to in-scope systems or customer data can sit outside the boundary, but that rationale needs documentation and review when access changes. Within the boundary, practitioners are mapping five areas, namely CC6, CC7, change management, risk mitigation, and risk assessment.

Why standard logging is not enough for agents, and what audit-ready evidence actually requires

Conventional logs can show that a request succeeded without proving that the resulting action was authorized. Agents sharpen that problem because the same prompt can produce different tool calls, and one agent can act across several systems. Code review alone cannot bound that behavior. The audit trail must therefore show the action the agent chose as well as the HTTP request it sent.

Take a finance agent that updates a customer’s payment terms. The application identifies a service account, the orchestration platform records a tool call, and an earlier ticket exists. Those records still may not show who asked for this change or whether the approver saw the parameters that the agent later used. The missing link is the originating human or approved automated trigger, the delegated scope, and the policy decision that permitted execution.

Each entry needs the agent’s identity and version, model version, person or ticket it acted for, MCP server, and tool name and version. It also needs a timestamp, redacted input parameters where confidential, and the result with IDs of affected records. For the records to be complete, every execution path must be logged, including desktop-side calls that miss the central log. Tamper resistance requires append-only, immutable storage, so an independent reviewer can reconstruct the action without relying on its builder.

CC6.1–CC6.3: what the agent's identity and access controls must prove

CC6.1 through CC6.3 establish who the agent is and what it may touch. The evidence must show a distinct machine identity, approved access, minimum permissions, and removal when the agent is retired. Its identity record needs a unique identifier, named owner, approved purpose, trust level, lifecycle state, and credential and expiration details. Access must also be bound to the authenticated end user, rather than giving every requester the combined privileges of a shared account.

A shared admin key or an engineer’s personal token breaks that distinction. The agent may still have broad access after the engineer leaves, even though the access record no longer shows whose authority it acted under. Just-in-time provisioning and automatic expiration address this through short-lived, task-scoped tokens minted per session. Elevated access must be time-bound, and periodic reviews must show who can invoke the agent and at what scope.

High-risk calls need a written approval rule, a way to enforce it, and a sample of records that show the approvals. These include deleting records, changing access, moving money, and emailing customers. A system prompt saying “never delete” is not an access control if the agent still holds the credential or scope needed to delete. The boundary must prevent execution without the required authorization, with CC6.3 also intersecting with PI1.3 where Processing Integrity is in scope.

CC7.2 and CC7.3: monitoring agent behavior and detecting out-of-scope actions

CC7.2 and CC7.3 move from permitted access to evidence that departures from it are detected and investigated. Tool-call logs and out-of-scope alert rules are only the starting point. Auditors also need tickets that show someone looked into the alerts. Logs that capture successes but omit denied attempts, approval bypasses, the policy version, or the business effect leave the monitoring story incomplete.

The practical test is to select one high-impact change and trace it backward. An independent reviewer should reach the requester, approval basis, and policy decision without assumptions. Denied attempts, anomaly context, reviewer disposition, and incident links make that chain useful for an audit. Desktop-side assistants belong in this test because central monitoring can otherwise miss their calls.

MCP threats complicate detection because tool poisoning, prompt injection, intent drift, and cross-server tool shadowing can produce valid-looking calls that serve attacker intent. The OWASP Foundation released the OWASP Top 10 for LLMs on November 18, 2024. The OWASP GenAI Security Project’s release announcement for the Top 10 for Agentic Applications is dated December 9, 2025. Practitioner testing references LLM01 Prompt Injection and, for agents, ASI01 Agent Goal Hijack, ASI02 Tool Misuse, ASI03 Identity and Privilege Abuse, and ASI04 Agentic Supply Chain Vulnerabilities.

CC8.1: change management evidence for prompts, tools, model versions, and MCP configuration

CC8.1 governs application code and the other elements that define agent behavior. System prompts, tool definitions, model versions, and MCP server connections all belong in change management. Each needs a ticket, tests, approval before release, and a record of when it was deployed. A prompt edited directly in a production console is therefore a control gap even if no software deployment occurs.

The approval also has to match what ran. A ticket saying “update billing rules” does not authorize every later action that could fit that description. Evidence must bind the approved object, environment, version, limits, and validity period to execution. Automated pipelines need the same discipline because promotion thresholds do not replace test and approval artifacts. Where Processing Integrity is in scope, evidence that automated promotions did not bypass validation also connects CC8.1 to PI1.

A new MCP connection deserves particular attention because it changes the tools available to the agent. That makes it a change-management item before any question of vendor assurance. Connecting a community server without review can create two gaps at once. CC8.1 covers changes to what the agent has permission to do, while CC9.2 covers the third party that supplies the connection.

CC9.2: vendor risk evidence for model providers and MCP servers

CC9.2 requires formal vendor assessment for model providers and third-party MCP servers. The vendor record needs SOC 2 reports that have been reviewed or equivalent assurance, terms for data use, training and retention, and a written account of customer-side controls. A production connection without assurance documents or contractual data-handling terms is not covered merely because it works. Vendor DPAs with zero-data-retention clauses are also part of the practitioner AI overlay, and those terms must be negotiated and documented.

The MCP authorization specification, revision 2026-07-28, defines an OAuth 2.1 framework but marks authorization optional. A compliant server can therefore remain unauthenticated. For machine-to-machine deployments, mTLS combined with OAuth 2.1 provides transport-layer authentication through X.509 certificates and scope-constrained authorization.

The documented vulnerabilities make this a concrete vendor-review issue. An Azure MCP Server missing-authentication information disclosure, CVE-2026-32211 with CVSS 9.1, allowed access to API keys and tokens without credentials. OX Security disclosed a systemic architectural flaw in April 2026 affecting vulnerable instances across a supply chain encompassing hundreds of millions of package downloads. Where Confidentiality is in scope, C1.1 and C1.2 also require a policy defining what data agents may send to models, provider retention and training settings, and retention and redaction rules for sensitive logs.

CC3: risk assessment as the connective tissue across all criteria

CC3.2 and CC3.4 provide the documented rationale for the other controls. Each agent needs a risk entry naming what it can read, change, and send, updated when its tools change. A read-only knowledge assistant has a different control profile from an agent that can move money or email customers. A risk register that predates both does not explain why their controls are appropriate.

Before deployment, the assessment must look at the whole path from the requester to the result. The user session, workload identity, orchestration layer, service account, policy engine, and downstream application can each work as designed while their combined evidence remains inadequate. This is a risk-design problem. A per-agent assessment shows why the engagement and its controls are tailored.

The practitioner AI overlay: ten evidence categories auditors are requesting beyond the base criteria

The base criteria do not explicitly name every AI artifact that practitioners request in 2026 engagements. The additional layer comprises ten evidence categories, but it is not a new AICPA standard. Its purpose is to make AI behavior and oversight testable within the engagement. The distinction matters because a practitioner evidence request should not be presented as authoritative wording from the criteria.

The first category is a model registry with name, version, training data reference, evaluation metrics, approver, and deployment date. A structured spreadsheet can serve for a first audit cycle. The second is a prompt audit trail with hot and cold storage tiers and tamper-evident protection through append-only storage with object lock or equivalent. The third is a prompt injection test suite covering LLM01 and, for agents, ASI01 through ASI04. The fourth is vendor DPAs with documented zero-data-retention clauses.

The fifth category is hallucination handling, including output specifications, input validation, output checks, error handling, and correction records. The sixth is AI literacy training each year that fits each role, with an LMS tracking who has completed it. The seventh is human-in-the-loop evidence that records the reviewer, timestamp, model output, and human decision delta for each decision that a human reviews. The eighth is measuring how well the model performs on an ongoing basis against set specifications for accuracy or reliability.

The ninth category is training-data lineage documenting provenance for models used in production. The tenth is tenant isolation evidence showing that one tenant’s prompts and outputs cannot reach another in shared LLM infrastructure. ISO 42001, published December 2023, covers AI governance and lifecycle controls that SOC 2 does not include, while an AI risk management framework adds context.

Assembling the compliant evidence package: what teams can build today

Build the package around the criteria rather than around whichever systems happen to hold the records. For CC6, assemble the agent inventory, credential details, access approvals, tool and data scopes, retirement records, and periodic reviews. Add the written high-risk approval rules, enforcement evidence, and sampled decisions. Together, these records must prove both the grant of authority and its limits.

For CC7, gather records of every tool call, out-of-scope alert rules, and tickets that show how alerts were investigated. Include the red-team test evidence for LLM01 and ASI01–ASI04 for agent deployments. For change management, gather tested and approved changes to prompts, tools, model versions, and MCP connections. Match those changes to deployment records that bind the approved configuration to what executed.

For risk mitigation, collect the model-provider and MCP-server vendor list, reviewed assurance documents, contractual data terms, and customer-side control obligations. Include zero-data-retention terms agreed with the provider where these are part of the overlay, which calls for more than the provider’s general promise. For risk assessment, retain a risk entry for each agent and records of updates when its tools change.

Then complete the overlay with the model registry, protected prompt history, testing, hallucination handling, training, human-review records, performance monitoring, lineage, and applicable tenant isolation evidence. Teams can assemble this infrastructure from an agent builder, gateway, SIEM, and GRC tool, or use a unified platform. Neither arrangement proves completeness by itself.

Finally, write down which retention obligations apply to each agent and how much storage is needed to meet them. SOC 2 Type II coverage, GDPR where it applies, and SEC cybersecurity disclosure rules have overlapping requirements, so the retention period must account for each. Retention also has to account for confidential data in prompts and tool inputs. The package is defensible when it preserves an unbroken account of authorized action.