SOC 2 Compliance for AI Agents: What Auditors Actually Want

SOC 2 was written for a world where "user" meant a human with a password. The Trust Services Criteria assume access controls govern people, that actions trace back to identifiable individuals, and that audit logs capture who did what.

AI agents don't fit that shape at all. An agent isn't a human, doesn't have a password, and can take dozens of potentially consequential actions per second with none of them tied to a human decision at the moment they happen.

If your company runs AI agents in production, there's a gap in your SOC 2 posture. There's a decent chance your auditor hasn't noticed it yet either.

What auditors are starting to ask

Security-conscious auditors in 2026 are starting to ask questions the traditional framework was never built to answer: how do you make sure agents only touch data they're authorized to touch? What actually prevents an unauthorized action, versus just discouraging it? Can you produce a complete, tamper-proof log of every action an agent took? Is there real human oversight on the decisions that matter?

CC6 (logical and physical access controls) and CC7 (system operations) are usually where this surfaces first.

Where existing controls fall short

Most teams' current answer for agent governance is some mix of API keys with scoped permissions, system prompt instructions about what not to do, and whatever logs the LLM provider's dashboard happens to give them.

An auditor will find a problem with each of these. API keys are access credentials, not behavioral controls - they define what an agent could do, not what it actually does. System prompt instructions aren't enforced; the model follows them probabilistically, which isn't the same thing as following them. And provider dashboards give you no tamper-evidence guarantee at all, plus the data belongs to the provider, not to you.

What the evidence actually needs to show

A SOC 2 auditor needs evidence of access control (unauthorized attempts got blocked and logged), continuous monitoring (every action logged in real time, not reconstructed later from memory), tamper-evidence (the log reflects what actually happened and hasn't been altered), and human oversight (consequential decisions had a human review and approve before execution, not after).

Tamper-evidence is the one most teams miss entirely. It's where a cryptographic chain earns its keep as a SOC 2 asset rather than just a technical footnote.

What the export looks like

obsvr's evidence export is a structured package built to hand straight to an auditor: a scope and controls-mapping manifest, the full integrity chain with daily Merkle roots and a verification script, storage and access-control configuration, incident detection logs, sample exports, and operating-effectiveness metrics - each file hashed in a manifest so nothing in the package can be swapped after the fact.

That's the direct answer to "can you produce a complete, tamper-proof log of every action an agent took." It's a ZIP and a script, and it takes about as long to generate as it takes to click the button.

Timing matters more than people expect

SOC 2 Type II covers a window - usually six to twelve months - and controls need to have actually been running during that window to count as evidence. If you're targeting an audit in 2027 that's supposed to cover your agent infrastructure, the instrumentation needs to start now. Controls you add after the audit period has already begun don't retroactively cover the months before you added them.

Which Trust Services Criteria the agent actually lands in

Most teams treat "AI is in scope" as one undifferentiated problem. Auditors do not. An agent with production access touches several criteria at once, and knowing which ones tells you what evidence to keep.

The bulk sits under CC6, logical and physical access controls. An agent holds credentials and acts through them, which makes it a principal in your access model whether or not anyone modeled it that way. The tool allowlist is the access control. The evidence is the record of what it was permitted to call and what it actually called, including the denials, because a control nobody ever observed rejecting anything invites hard questions about whether it was ever really in the path.

CC7, system operations, covers monitoring and incident response: whether you detect anomalous behavior and what happens when you do. For an agent that means a blocked call produces an incident record carrying enough context to investigate, and that the response is visible.

CC8, change management, is the one that surprises people. A policy change is a change to a control. If your allowlist or PII rules can be edited without a record of who changed what and when, the control's configuration is unauditable, which weakens every piece of evidence that control produced. Policy versioning is not a nice-to-have here; it is what makes the rest of the evidence mean anything.

If personal data flows through the agent, Confidentiality and Privacy come in as well, and that is where PII detection stops being a security feature and becomes a control with an evidence obligation attached.

The three artifacts that do most of the work

Auditors do not want your architecture diagram. They want to see a control operating, repeatedly, across the period. Three artifacts carry most of an agent-infrastructure audit.

The population. A complete list of agent actions in the period, from which the auditor samples. This is the artifact most teams cannot produce, and its absence is worse than it first appears: if you cannot show the list is complete, sampling from it proves nothing, because the sample may simply exclude everything that went wrong. Completeness is a property of how the record was collected, not something assertable afterward.

The exceptions. Every blocked call, every redaction, every approval. Counter-intuitively this artifact helps you most. A control with zero observed exceptions across twelve months reads as one that was never exercised. Denials are evidence of a working system.

The configuration history. What the policy was at each point in the period, not only what it is today. When the auditor samples a call from month three, the question is whether the control operating at that moment was the one you described, and answering it requires knowing what the rules were in month three.

Why the record has to resist you

There is a structural point underneath all of this, and it explains why "we have logs" keeps failing this conversation.

SOC 2 is an assurance framework. Its purpose is to let someone who does not trust your assertions verify them anyway. Evidence your own team could have edited undermines that purpose by construction, and an experienced auditor will find the write path and ask about it. The follow-up is always some version of: who has production database access, and what would stop them changing a row.

A cryptographically chained record answers with a mechanism rather than a policy. Nobody has to be trusted not to edit it, because an edit is detectable and a deletion appears as a gap. That is a materially stronger position than access controls plus good intentions, and it is the difference between evidence an auditor accepts quickly and evidence that generates a round of findings.

The same property does double duty under the EU AI Act, whose Article 12 asks for records robust against manipulation. One correctly built audit trail satisfies both, which is worth knowing before anyone builds two systems.