SOC 2 auditors are increasingly asking about AI agent activity — and most companies are not ready. Here is a precise breakdown of what the Trust Services Criteria demand from your AI audit infrastructure.
For the first three years of the enterprise generative AI boom, SOC 2 auditors largely treated AI systems as black boxes — interesting from a risk perspective, but not yet formally in scope for the Trust Services Criteria. That era is ending.
In 2025, the AICPA issued updated guidance clarifying that AI systems acting on behalf of an organization — particularly those with access to customer data, financial systems, or regulated infrastructure — are in scope for the Security, Availability, and Confidentiality Trust Services Criteria. Audit firms have updated their questionnaires accordingly. If your company deploys AI agents and holds a SOC 2 Type II certification, the next audit cycle will almost certainly include AI-specific inquiries.
Most engineering and compliance teams are not ready. This post breaks down exactly what the Trust Services Criteria require, translated into concrete infrastructure decisions for teams running agentic AI systems.
SOC 2 is organized around the Trust Services Criteria (TSC), which map to five service commitments: Security (CC), Availability (A), Processing Integrity (PI), Confidentiality (C), and Privacy (P). For AI agents, the most directly relevant criteria fall under the Security category.
CC6.1 requires that access to systems is restricted to authorized users, components, and programs. The "programs" qualifier is directly applicable to AI agents. Your controls must demonstrate that only authorized agents can access protected resources, and that this authorization is enforced and logged.
CC6.2 requires prior to issuing credentials to access systems, the completeness, accuracy, existence, and rights of the requesting entity are evaluated. For AI agents, this translates to a requirement that agent credentials are issued through a formal provisioning process — not ad-hoc, not via shared accounts — and that the agent's declared scope is evaluated before access is granted.
CC6.3 requires that access is removed when no longer needed. For agents, this means session-scoped credentials that expire at task completion, plus a process for deprovisioning agents that are retired or modified.
CC7.2 requires monitoring system components for anomalies that might indicate malicious acts, natural disasters, or errors. Applied to AI agents, this means your monitoring must be capable of detecting anomalous agent behavior — actions outside the agent's declared scope, unusual access patterns, unexpected resource consumption — and alerting on deviations.
CC7.3 requires evaluating security events to determine whether they could or have resulted in a failure of the entity to meet its objectives. This requires a post-incident analysis capability. If an agent behaves unexpectedly, you need to be able to reconstruct exactly what it did, in what order, and with what authorization — which requires a complete, timestamped, attributed audit trail.
CC8.1 requires that infrastructure and software changes are authorized, tested, and approved. For AI agents, model updates, prompt changes, and tool permission expansions are all changes that must go through this process. The audit evidence required is a record showing that each change was reviewed and approved before deployment.
The criteria above translate into a specific set of audit trail properties. An AI audit trail that satisfies SOC 2 requirements must be:
Every action recorded in the audit log must be attributed to a specific, non-shared agent identity. Log entries like "service-account-12 called the payments API" do not satisfy CC6 if service-account-12 is shared among multiple agents or human processes. Each entry must be attributable to a specific agent instance executing a specific task.
The log must capture every action the agent takes that touches a protected resource. Sampling, aggregation, or selective logging is insufficient. SOC 2 auditors will ask: "If an agent exfiltrated customer PII, would you have a record of every read and every transmission?" The answer must be yes.
Audit logs are only meaningful if they cannot be tampered with. This means logs must be written to a destination that the agent itself — and ideally the operator — cannot modify or delete. Cryptographic chaining (hash of each entry includes the hash of the prior entry) provides tamper-evidence. Write-once storage (object storage with object lock enabled, or an append-only database) provides tamper-resistance.
Log entries must carry timestamps from an authoritative time source that cannot be manipulated by the agent or its runtime environment. This is relevant for incident reconstruction: if timestamps are drawn from the agent's local clock, a compromised agent can falsify the temporal record.
An audit trail that exists but cannot be queried efficiently does not satisfy the audit evidence requirement. Auditors will ask for evidence demonstrating specific controls — for example, "show me all instances in the last 12 months where an agent accessed customer data outside business hours." If that query takes four days to run, the control is effectively non-functional. Your audit infrastructure must support time-bounded, identity-scoped, action-type-filtered queries with sub-minute response times.
Based on the audit inquiries that surfaced in 2025, the most common gaps in enterprise AI audit infrastructure are:
Shared service accounts. As discussed above, this fails CC6.1 and CC6.2 directly. Every agent must have its own identity.
Log forwarding without attribution. Many teams forward agent logs to a SIEM, but the logs themselves do not carry agent identity — they carry process IDs or container names that are not stable across invocations. Correlation is impossible at scale.
No coverage of tool calls. Application-level logs capture what the agent said, but not what it did. If the agent called an external API, wrote to a database, or invoked a code execution tool, those actions must be independently logged at the infrastructure level — not just derived from the agent's self-reported output.
Missing change management records for model updates. Model version updates are changes to a critical system component. They require a paper trail showing who authorized the update, what testing was performed, and what the rollback plan was. Most teams have no formal process for this.
No anomaly detection. Audit trails are retrospective by default. CC7.2 requires prospective monitoring. Real-time anomaly detection on agent behavior — flagging actions outside declared scope or access patterns that deviate from baseline — is a distinct capability from logging, and one that most teams have not built.
The practical readiness checklist for SOC 2 AI agent compliance:
None of these items require months of engineering work in isolation. But they do require deliberate infrastructure investment — infrastructure that most teams have not yet built, and that auditors are increasingly expecting to see.
The organizations that will sail through their 2026 SOC 2 audits are the ones building this foundation now, not the week before the audit window opens.
125 days until the EU AI Act applies to production AI systems — and most teams deploying agents haven't done the one thing they need to do first: check if they're classified as high-risk under Annex III.
Autonomous agents can read files, call APIs, and modify databases — all without a human in the loop. Without a stable, verifiable identity attached to each agent, your audit trail is fiction and your blast radius is unlimited.
