SOC 2 for AI Agents: What Your Auditor Will Actually Ask

Your engineers are using Cursor, Claude Code, or Copilot Workspace. Your AI pipelines are running shell commands, querying production databases, and deploying code. Your product is good, your customers are happy — and then you start the SOC 2 audit.

The auditor opens a blank document and asks: "What controls do you have over privileged access to production systems?"

If the honest answer is "AI agents have access because the engineer who ran the session has access," you have a problem. Not a theoretical problem — a documented finding that will appear in your audit report.

Why AI agents complicate SOC 2 Type II

SOC 2 Type II evaluates whether your controls operated effectively over time. The key word is "time." Your auditor will pull a sample of days across the audit period and ask for evidence that controls were actually running on those days.

For AI agent access to production, there are three TSC (Trust Services Criteria) areas that light up immediately:

• CC6.1 — Logical and physical access controls
• CC6.3 — Authorization to access information assets
• CC7.2 — System monitoring

The auditor will ask for evidence of each. Here is what "evidence" actually means for AI agent access.

What CC6.1 looks like when AI agents are in scope

CC6.1 asks: who can access production, and how is that access controlled?

For human operators, you have SSH keys, bastion hosts, VPN access logs — clear, auditable, bounded. For AI agents, the question is murkier. The agent runs as a subprocess of the engineer's terminal. It inherits the engineer's SSH keys. It can do most things the engineer can do.

The auditor will ask:

1. How do you know which commands the AI agent ran versus which commands the engineer ran directly?
2. Was every command that modified production data authorized by a human?
3. Can you produce a log of every AI-generated command that touched production over the last 6 months?

What CC6.3 demands from an approval standpoint

CC6.3 requires that access to information assets is authorized and restricted to authorized individuals. For AI agents, "authorization" becomes a two-part question:

• Session-level: Was the engineer authorized to use an AI agent with production access?
• Command-level: Was each specific command the AI ran authorized by someone with appropriate access?

Most companies have an answer to the first question (it's in their acceptable use policy). Almost none have a documented answer to the second.

Command-level authorization means: before the AI agent ran DELETE FROM sessions WHERE created_at < '2026-01-01', a human reviewed that specific command and explicitly allowed it. Not "the engineer ran a script that contained that command" — that's not command-level authorization. The human has to see the command and make a decision about it.

CC7.2: Monitoring that actually covers AI agents

CC7.2 requires that you monitor your systems for anomalies and unauthorized activity. Your SIEM probably ingests server logs. It probably doesn't know which of those server-side events were triggered by AI agents versus humans.

The auditor will ask for your detection capability: if an AI agent ran an unexpected command — something that looked like a reconnaissance scan, or a credential dump, or a bulk data export — would you have detected it? How quickly? What would have triggered the alert?

If your answer is "the SIEM would eventually flag the server-side anomaly," the follow-up question is: does the SIEM know it was an AI agent? Can you distinguish between a human engineer who ran a legitimate bulk export and a prompt-injected AI agent that ran the same command maliciously?

Building a SOC 2-ready AI agent control

The minimum viable control for AI agent access to production, from an audit perspective, has four components:

1. Command interception

Every command the AI agent sends must pass through a control point before it reaches the shell. This is not a logging requirement — it's an interception requirement. You need to be able to stop commands before they execute, not just log them after.

This typically means the AI agent connects through a proxy layer that sits between the agent and the production environment. The proxy holds each command in a queue until a human acts on it, or until the command matches an approved whitelist pattern.

2. Explicit human authorization

For commands outside the whitelist — anything touching sensitive data, anything destructive, anything that hasn't been reviewed and approved before — a named human must explicitly authorize the command before it runs. Not implicit authorization ("the engineer started the session") — explicit, timestamped, attributed authorization.

This is the audit evidence. When the auditor asks "was this command authorized?", your evidence is: Reviewer [name] approved command [exact text] at [timestamp] from [IP/device].

3. Immutable audit log

Every command — approved, denied, auto-approved via whitelist — must be in a log that cannot be retroactively modified. The log entry must include:

• Exact command text (not a summary — the exact string)
• Timestamp (millisecond precision)
• Who ran the session (engineer identity)
• Who approved (reviewer identity, or "whitelist rule #N")
• Risk score and risk factors at time of evaluation
• Whether the command was executed or denied

4. Export for auditors

The log must be exportable in a format an auditor can actually work with. CSV is fine. JSON is fine. A PDF compliance report is better — it can be attached directly to the evidence package.

When the auditor asks for "all privileged commands run by AI agents in the past 6 months," you should be able to produce that file in under 5 minutes.

How this maps to expacti

This is exactly what expacti is designed to produce. Let me walk through the mapping:

The compliance report export is specifically designed to attach to a SOC 2 evidence package. It includes the filter criteria (date range, agent session, risk threshold), summary statistics, and the full command log with all authorization data.

The whitelist as a documented control

One nuance that matters for audits: your whitelist is itself a control, and it needs documentation. The auditor may ask: who approved the entries in this whitelist? When were they reviewed? Is there a process for removing stale entries?

expacti keeps a history of whitelist changes — when each rule was added, by whom, whether it was AI-suggested or manually written, and whether it was ever modified. This whitelist audit trail is separate from the command execution log, and it's what you show when the auditor asks about your whitelist governance process.

HIPAA and GDPR: adjacent requirements

If you're in healthcare or handling EU personal data, the same control logic applies — but the stakes for a gap are higher.

Under HIPAA, accessing PHI via AI agent without explicit human authorization and a complete audit trail is a potential breach notification scenario. The question isn't just "did the AI have authorization?" — it's "can you prove it, with timestamps, for every specific record access?"

Under GDPR, Article 22 creates specific obligations around automated decision-making. While it's debated whether command execution by an AI agent constitutes "automated decision-making" in the Article 22 sense, the practical advice from DPAs is consistent: maintain human oversight over consequential automated actions and document it.

In both cases, the expacti model — every command requires human disposition, every disposition is logged — gives you a strong baseline. It's not a complete HIPAA compliance program, but it closes the specific gap that healthcare auditors and DPAs are increasingly focusing on: AI agent access to sensitive data without human authorization.

The evidence package

When you're in an active Type II audit and the auditor asks for AI agent access evidence, here is what you should be able to hand them:

1. Policy document — your AI agent access control policy (who can run agents, in what environments, with what scope)
2. Control description — a paragraph describing the technical control (expacti proxy, command queue, whitelist, reviewer requirement)
3. Compliance report — exported from expacti, covering the sample period, showing all AI agent commands with authorization status
4. Whitelist governance log — showing who created/modified each whitelist rule, reviewed and signed off
5. Anomaly log — any commands that triggered anomaly detection during the period, and how they were dispositioned

Items 3–5 are exports from expacti. Items 1–2 you write once and update annually. The audit evidence gathering, which typically takes days when done manually, becomes a 20-minute export task.

The bottom line

AI agents are not going away. Neither are SOC 2 audits. The question is whether your control environment is ready for auditors who are now specifically asking about AI tooling access to production.

The controls that satisfy this aren't exotic — they're the same principles that governed human operator access for decades: least privilege, explicit authorization, complete audit trail. The challenge is that AI agents moved fast and the controls didn't keep up.

Building the control now — before your Type II audit window opens, before the finding appears in the report — is the straightforward path. The alternative is scrambling during fieldwork, or accepting a qualified opinion while you remediate.