B2B SaaS with Enterprise Customers: SOC 2 + AI Agents

Enterprise sales cycles for B2B SaaS are getting longer. One reason auditors and enterprise procurement teams point to: AI features that engineering teams shipped without thinking about the SOC 2 implications.

A SOC 2 Type II report covers controls over a 6–12 month period. If you shipped an AI agent in that period — an agent with access to customer data, making automated decisions, calling external APIs — your auditor will ask about it. If you didn’t design the agent with SOC 2 controls in mind, you’ll spend significant time in the audit explaining gaps.

The better approach: design SOC 2-compliant AI agents from the start.

TL;DR

• SOC 2 Type II audit coverage extends to AI agents that process customer data or automate decisions
• The five Trust Services Criteria (Security, Availability, Processing Integrity, Confidentiality, Privacy) all have AI-specific implications
• Common SOC 2 + AI failures: AI agents with excessive access, no change management for model updates, no logging of AI-assisted decisions
• Enterprise customers increasingly include AI-specific questions in vendor security questionnaires
• Processing Integrity — does the AI agent do what it’s supposed to do, accurately and completely — is the hardest SOC 2 criterion for AI to satisfy

Why SOC 2 Now Covers AI Agents

SOC 2 is a framework built on the AICPA’s Trust Services Criteria (TSC). The criteria are principle-based, not technology-specific — they apply to any information system that processes customer data or performs functions on customers’ behalf.

AI agents are information systems. When your AI agent processes a customer’s data, makes a decision about their account, calls an external API on their behalf, or generates output that affects their experience — it’s within SOC 2 scope.

Auditors determine scope based on the systems relevant to the service organization’s commitments to its customers. If you’ve committed to your enterprise customers that their data is protected, that your system is available, and that processing is accurate — your AI agents that touch that data and processing are in scope.

The Five TSC Mapped to AI Agents

1. Security (CC6, CC7, CC8)

SOC 2 security controls require that your system is protected against unauthorized access. For AI agents:

CC6 — Logical and Physical Access Controls

• AI agents should have minimal access to customer data — only what the specific task requires
• Access granted to AI agents should be logged and reviewable
• AI agent credentials (API keys, service accounts) must be managed with the same rigor as human credentials: rotated, monitored, revocable

CC7 — System Monitoring

• AI agent activity must be monitored for anomalous behavior
• Alerts on unusual tool call patterns, unexpected data access volume, or out-of-hours activity
• Monitoring coverage must include AI agents, not just human user sessions

CC8 — Change Management

• Model updates are changes to the production system and must go through change management
• This means: documented change, tested in non-production, reviewed, approved before deployment
• Many teams treat model updates as configuration changes rather than code changes — SOC 2 auditors treat them as changes to the production system

2. Availability (A1)

Availability controls address whether your system is available as committed. For AI agents:

• If your AI agent is part of the service your customers depend on, its availability is part of your availability SLA
• Failure modes and graceful degradation must be designed — what happens when the model API is unavailable, when the governance layer is down, when an external tool is unreachable?
• Availability monitoring must cover AI agent dependencies, not just your own infrastructure

3. Processing Integrity (PI1)

This is the hardest criterion for AI. Processing integrity means your system processes data “completely, accurately, timely, and authorizedly.” For AI agents, “accurately” is the challenge.

What auditors ask:

• What is the accuracy rate of your AI agent’s outputs?
• How do you know? What’s your measurement methodology?
• What happens when the AI produces an incorrect output?
• What is your error correction process?
• Does the AI agent process all inputs it should, and only those it should?

What compliant AI processing integrity looks like:

• Defined accuracy metrics, measured continuously, with documented acceptable ranges
• Error logging and correction workflows
• Sampling and human review of AI outputs on a regular schedule
• Documented scope: what inputs the agent processes and what it does not

4. Confidentiality (C1)

Confidentiality controls cover information designated as confidential. For AI agents:

• Customer data processed by AI agents must be treated with the same confidentiality controls as customer data processed by other systems
• AI agent prompts and tool call responses containing customer data must be protected in transit and at rest
• Customer data must not be used to train or fine-tune models without explicit customer consent and documented authorization
• Retention of AI agent conversation history must comply with your data retention commitments

5. Privacy (P1–P8)

The privacy criteria apply when you process personal information. For AI agents:

• Personal information processed by AI agents must have a documented lawful basis
• Data minimization: the AI agent should access only personal information necessary for the task
• Data subject rights (access, deletion, portability) must be exercisable for data processed by AI agents
• Third parties receiving personal data via AI agent tool calls must be covered by your vendor management program

What Enterprise Security Questionnaires Now Ask

Enterprise customers conducting vendor security reviews increasingly include AI-specific questions. Common questions from 2025–2026 enterprise security questionnaires:

1. “Does your product include AI or ML features? If so, describe the data used to train them.”
2. “Does your AI system have access to customer data? Describe the access controls.”
3. “How do you monitor your AI system for accuracy and bias?”
4. “What controls prevent your AI system from disclosing customer data to other customers?”
5. “How do you handle AI system failures? What is the fallback behavior?”
6. “Does your AI system make automated decisions about customers? If so, do customers have a right to review or appeal?”

If your AI agent governance is undocumented, these questions require improvised answers. If your governance architecture is designed and documented, they’re answered from your existing documentation.

The SOC 2 Evidence Package for AI Agents

A SOC 2 Type II audit produces a report covering controls over a time period. For AI agents, the evidence package must include:

Access control evidence:

• AI agent access rights documentation (what it can access)
• Access review records (periodic review of AI agent permissions)
• Credential rotation records

Change management evidence:

• Change tickets for model updates and governance rule changes
• Testing evidence for AI agent changes
• Approval records for production changes

Monitoring evidence:

• AI agent activity logs
• Anomaly detection alert history
• AI agent availability monitoring records

Processing integrity evidence:

• Accuracy measurement methodology
• Accuracy results over the audit period (by month or quarter)
• Error log and resolution records
• Human review sampling records

Incident records:

• AI agent incidents, their impact, and resolution
• Root cause documentation
• Corrective action evidence

For the logging architecture that generates this evidence automatically, see EU AI Act Article 12: Logging Requirements Decoded — the same tamper-evident logging that satisfies EU AI Act requirements also produces SOC 2 evidence.

FAQ

Q: Our AI feature uses a third-party model API (Claude, GPT-4). Who is responsible for SOC 2 compliance?

You are. The model provider’s SOC 2 report covers their infrastructure. Your SOC 2 report covers your service. Your AI feature — the way you use the model, what data you pass to it, how you process outputs — is your responsibility. Obtain SOC 2 reports from model providers you use and include them in your vendor management program, but understand that their report covers their scope, not yours.

Q: Do model updates require a SOC 2 change management process?

Yes, if the model is part of your production system and the update could affect your system’s behavior. This includes: provider-driven model updates (new Claude version, GPT-4o update), configuration changes to system prompts, changes to the governance rules that govern the agent, and changes to tool access or integrations. Build model updates into your change management workflow.

Q: Our AI agent is a beta feature. Does it still need SOC 2 controls?

If beta users are enterprise customers whose data is covered by your service commitments, yes. “Beta” is a product designation, not a compliance exemption. The data is real and the SOC 2 commitments apply. Design the beta with controls, or exclude beta users from the SOC 2 system boundary (which may limit beta availability to enterprise customers).

Q: What does “processing integrity” mean for an LLM-based agent?

For a generative AI agent, processing integrity means the agent processes inputs correctly and produces outputs that are accurate, complete, and appropriate for their intended use. Measuring this requires: defining what “correct” means for your specific use case, establishing a measurement methodology, and tracking the metric continuously. For most use cases, human review sampling (a trained reviewer scores a random sample of outputs) is the primary processing integrity measurement.

Q: How do we handle the SOC 2 implications of an AI agent that calls external APIs?

External APIs that your AI agent calls are vendors in your vendor management program. Assess them for security posture, obtain their SOC 2 reports where available, and document the risk acceptance where reports aren’t available. Data passed to external APIs on behalf of customers must be covered by appropriate contracts (DPA for personal data, confidentiality agreements for confidential information).

---

By Nikola Kovtun, founder of Infracortex AI Studio. Cortex generates the SOC 2 evidence package for AI agent deployments — access logs, change records, processing integrity evidence, and incident documentation — as a byproduct of runtime governance. Book a call to discuss your SOC 2 AI agent coverage.

See also: AI Agent Governance for Fintech: A Practical Checklist | The Hidden Cost of Unmonitored AI Agent Tool Calls | Why Runtime is Commodity and Governance is the Moat

Cortex build: 0.1.35-260423