SOC 2 was designed for a world where humans authorize actions. A ticket is filed. A change is reviewed. An individual clicks confirm. The Trust Services Criteria (TSC) — covering security, availability, processing integrity, confidentiality, and privacy — rest on this assumption at every level.

AI agents break it.

When an autonomous agent sends an API call, modifies a record, or pulls customer data from a production system, no human authorization event occurred. There is no ticket. No named individual clicked confirm. What auditors encounter instead is a log entry from a generic service account, followed by an action, with nothing in between that constitutes an authorization chain. According to Kayne McGladrey, CISSP and former defense industrial base CISO, writing in February 2026: "Auditors will often treat 'no human request' as a major accountability gap, because SOC 2 expects privileged actions to be attributable to an accountable individual, not to an autonomous agent or generic system account."

This is the attribution problem. And it is catching organizations off guard during their first SOC 2 audit after deploying AI agents in production.

What SOC 2 Auditors Are Actually Looking For

The SOC 2 framework does not explicitly mention AI agents. What it does require — across three Trust Services Criteria in particular — is an authorization chain that proves actions were sanctioned, attributable, and governed. For traditional systems, that chain runs through IAM policies, change tickets, and access logs. For AI agents, it typically doesn't exist in a form auditors can evaluate.

CC6.3 (Logical Access): The criterion requires that privileged access to resources be authorized and attributable. Organizations are expected to configure access such that permissions match the specific task, with roles reviewed periodically and elevated rights documented. When an AI agent operates under a broad service account with no granular role definition and no approval record, auditors see the same red flag as shared credentials: no individual accountability, no audit trail back to a human decision.

CC7.2 and CC7.3 (Monitoring and Investigation): These criteria require continuous monitoring against defined thresholds, plus documented investigation workflows when anomalies occur. AI agents produce non-deterministic outputs — they may behave differently on identical inputs across runs, respond to prompt drift, or shift behavior when an underlying model version changes. None of this maps cleanly to a threshold in a conventional SIEM. Organizations often cannot define a behavioral baseline for their agents, which means the monitoring evidence CC7.2 expects is structurally difficult to produce.

CC8.1 (Change Management): SOC 2 auditors expect documented change processes: a request, an approval, validation evidence, and a rollback plan. For AI agents, changes happen continuously and at runtime — a prompt update, a model version swap, a new tool connection. These typically bypass change management systems entirely. Auditors following the evidence will find a gap between the change documentation and what agents are actually doing in production.

The Observability Gap

The instinct when facing a SOC 2 audit is to point at observability. There are traces. There are logs. The auditor can see what the agent did. The problem is that observability tells you what happened, not whether it was authorized to happen. SOC 2 auditors are not satisfied by a post-hoc log of actions. They need evidence of a pre-action authorization framework — a defined set of rules about what the agent is allowed to do, enforced at the moment of execution, with a durable record of enforcement decisions.

Observability platforms in the AI agent space — LangSmith, Helicone, Arize — provide traces and logs. They capture inputs, outputs, latency, and cost. That's operationally useful. But these tools sit outside the execution path: they observe, they don't enforce. When an agent attempts an action that should require human authorization, observability tools record it. They don't block it, and they don't generate an authorization record of the kind CC6.3 expects.

The capability gap is architectural. Tools that sit in the observability layer cannot retroactively create a pre-execution authorization framework. For SOC 2 compliance, that framework needs to exist before the agent acts.

The Vendor Agent Problem

Deploying internal AI agents is the scenario organizations plan for. Vendor agents are the one they don't.

SOC 2's CC9.2 requires organizations to manage third-party vendor risk. When a vendor deploys an AI agent that has access to a CRM, a support queue, or an internal knowledge base, the organization deploying that agent is responsible for demonstrating it operates within authorized boundaries. The TSC language is clear: the requirement extends to "the activities performed by the entity's vendors and business partners" that affect the entity's controls.

Most organizations have no mechanism for this. Vendor agents arrive with an API key and an integration guide. The question "what is this agent allowed to do, and how is that enforced?" often has no technical answer. A contractual SLA is not sufficient evidence for CC9.2. Auditors want to see technical controls, not terms of service.

This is the part of SOC 2 compliance for AI agents that catches organizations most off guard. They have instrumented their own agents. They have no governance over the agents their vendors have deployed into their environment.

How Waxell Runtime and Connect Handle This

The agentic governance plane in a Waxell-governed deployment creates the authorization framework that SOC 2 auditors are looking for — before agents act, not after.

Waxell Runtime's 50+ policy enforcement categories define what agents are allowed to do and block actions that fall outside those boundaries. Each enforcement decision generates a durable record: what was attempted, what was permitted, what was blocked, and when. This creates the authorization chain CC6.3 requires without depending on human reviewers to interpret logs after the fact. No rebuilds required — policies are enforced at the runtime layer, not embedded in agent code.

For CC7.2, Waxell's policy boundaries constitute the behavioral baseline SOC 2 expects. When an agent operates within policy, that's evidence of controlled behavior. When it attempts a policy violation, the violation is logged and blocked. That's the monitoring posture auditors are trying to verify — not a threshold alarm, but a documented boundary and evidence that it was enforced.

Waxell Observe instruments your agent stack in 2 lines of code across 200+ libraries, capturing every action with full trace context. The audit trail is durable, structured, and queryable — producing evidence on demand rather than requiring manual log assembly under audit pressure.

For vendor agents, Waxell Connect is the answer to the CC9.2 problem. It governs agents you didn't build — vendor agents, third-party integrations, MCP-native agents — with no SDK and no code changes required on the agent side. Connect enforces the same policy boundaries as internally built agents, with the same execution records. The compliance documentation package for a vendor agent deployment looks identical to the one for an internally deployed agent. Auditors don't see a gap.

This is also what distinguishes the compliance assurance posture Waxell enables: the evidence is produced continuously across the audit observation period, not assembled retrospectively when an auditor requests it.

What to Have Ready for Your Next Audit

SOC 2 auditors evaluating a deployment that includes AI agents will typically request evidence across four areas. None of this is produced by observability tooling alone.

A logical access policy that defines what the agent identity is authorized to do, with a mechanism for enforcement (not just documentation). Evidence that the policy was enforced consistently over the audit period — not just defined and then ignored. Change management records that cover prompt updates, model version changes, and tool additions — not just infrastructure code deployments. For vendor agents: CC9.2 evidence of technical controls that limit and document what third-party agents can access and do.

Organizations that handle these requests cleanly built enforcement into the agent architecture before the audit questionnaire arrived. Not as a compliance exercise — governed agents are simply more reliable agents. The audit documentation is a byproduct of the governance posture, not a retroactive project.

FAQ

Does SOC 2 apply to AI agent deployments?
Yes. SOC 2's Trust Services Criteria apply to any system in scope, and AI agents performing actions within or on behalf of a service organization's environment are in scope. The criteria for logical access (CC6.3), change management (CC8.1), and monitoring (CC7.2/CC7.3) all carry specific implications for autonomous agent deployments that differ from traditional human-operated systems.

What does CC6.3 require for AI agents specifically?
CC6.3 requires that privileged actions be authorized and attributable to an accountable individual. For AI agents, this means having a defined authorization framework — a policy specifying what the agent is allowed to do — with a durable record of enforcement decisions. A service account with broad permissions and a post-hoc log does not satisfy this requirement; auditors need evidence that authorization was pre-established and enforced at the moment of action.

Can observability tools satisfy SOC 2 audit requirements for AI agents?
Observability tools capture what happened. SOC 2 auditors need evidence that actions were authorized before they happened. Observability and enforcement are different layers — one records, the other controls. For SOC 2 compliance, both are required: an enforcement layer that creates an authorization record pre-execution, and an observability layer that logs execution context. Observability alone does not satisfy CC6.3.

How does SOC 2 treat vendor AI agents that access our systems?
Under CC9.2, organizations are responsible for managing third-party vendor risk. When a vendor deploys an AI agent with access to your systems, your SOC 2 audit will include that agent's behavior in scope. Contracts and SLAs are not sufficient — auditors want evidence of technical controls that limit and document what vendor agents can access and do.

What's the minimum viable compliance posture for an AI agent deployment?
At minimum: a defined policy for what the agent is authorized to do, enforced at execution (not just logged after); an identity model that distinguishes agent actions from human actions; change management that covers prompt and model updates; and execution records that can be produced to an auditor without manual assembly. This is the architecture SOC 2 expects even when it doesn't name "AI agents" explicitly.

Does Waxell help with SOC 2 Type II specifically?
SOC 2 Type II examines whether controls operated consistently over an observation period — typically twelve months. Waxell's architecture generates continuous execution records and enforcement decisions throughout the observation period, producing evidence of consistent control operation rather than a point-in-time snapshot. Waxell Connect extends this to vendor agents, so the compliance posture covers the full agent fleet, not just internally built agents.

Sources:

• How AI Agents Impact SOC 2 Trust Services Criteria — Kayne McGladrey, CISSP, Teleport Engineering Blog, February 25, 2026. Primary source for CC6.3 attribution gap framing and TSC mapping. Quote ("Auditors will often treat 'no human request' as a major accountability gap...") confirmed directly via page retrieval.

• SOC 2 Compliance for AI Agents in 2026 — Blaxel Blog, 2026. Secondary source for TSC overview and AI agent compliance framing.

• SOC 2 Compliance for AI Agents: A Technical Guide — Dev.to, 2026. Secondary source for access control and least-privilege requirements discussion.

• Show HN: Open-source agent skill that automates SoC 2 audit prep — Hacker News, February 2026. Context for practitioner pain around SOC 2 audit overhead.