SOC 2 was designed for cloud software companies. Its five Trust Services Criteria — Security, Availability, Processing Integrity, Confidentiality, and Privacy — provide a solid baseline for general software security, but they were written before LLMs, RAG pipelines, and AI agents existed as distinct system components. If your product is AI-powered, your SOC 2 controls need to extend beyond the standard framework to cover the AI-specific risks your auditors will increasingly ask about.
Why Standard SOC 2 Is Insufficient for AI Products
A standard SOC 2 audit will test your change management, access controls, encryption, monitoring, and incident response procedures — as applied to your infrastructure and application code. It will not test whether your LLM can be manipulated via prompt injection. It will not assess whether your RAG system leaks documents across user boundaries. It will not evaluate whether your AI agent has excessive permissions that create data exfiltration risk.
Sophisticated buyers — especially in enterprise — are beginning to ask these questions in vendor questionnaires. Auditors are increasingly aware of AI-specific risks. Getting ahead of this now positions your SOC 2 report as a meaningful trust signal rather than a checkbox.
Mapping AI Controls to Trust Services Criteria
CC6 — Logical and Physical Access Controls
Standard CC6 controls cover user authentication, access provisioning, and separation of duties. For AI systems, extend this to:
- LLM API key management: Document how API keys for foundation model providers (OpenAI, Anthropic, Google) are stored, rotated, and access-controlled. Treat these keys the same as database credentials.
- RAG access controls: Document how the knowledge base enforces document-level access controls tied to user identity. Show evidence that users cannot retrieve documents outside their permission scope.
- Agent permission scoping: Document the maximum permissions granted to AI agents and the approval process for adding tool access.
CC7 — System Operations
Standard CC7 covers monitoring and incident detection. For AI systems, extend this to:
- Prompt injection monitoring: Document controls that detect and alert on known prompt injection patterns in user inputs and model outputs.
- Anomalous output detection: Monitoring for LLM outputs that match patterns of sensitive data leakage (credential formats, PII patterns, internal document signatures).
- AI incident classification: Define what constitutes an AI security incident (successful jailbreak, data exfiltration via RAG, agent misbehaviour) and document your response procedures.
C1 — Confidentiality
Confidentiality controls must address AI-specific disclosure risks:
- Training data handling: If you fine-tune on customer data, document data processing agreements, retention limits, and the technical controls preventing that data from being extractable from the model.
- RAG confidentiality: Document how your retrieval system enforces confidentiality of documents within a multi-tenant knowledge base.
- Model output review: For high-sensitivity outputs, document whether human review is required before content is shared with end users.
PI1 — Processing Integrity
For AI products, processing integrity means your AI is doing what it claims to do — and is not being manipulated to do something else:
- Prompt integrity controls: Document how you prevent user inputs from overriding system-level instructions.
- Output validation: Document how model outputs are validated before being used to trigger downstream actions.
- Model change management: Document your process for evaluating the security impact of model updates, fine-tuning runs, and prompt changes.
Practical Steps for Your Next SOC 2 Audit
- Document your AI system architecture — data flows, model providers, retrieval systems, agent permissions. Your auditor needs to understand the system to assess it.
- Conduct an AI security risk assessment — map OWASP LLM Top 10 to your architecture and identify which categories are in scope for your product.
- Run an AI security penetration test — and include the report as evidence of security testing in your SOC 2 package. This directly satisfies CC4.1 (risk assessment) and CC7.1 (monitoring).
- Define AI-specific security policies — acceptable use, model evaluation, incident response, and access control policies for AI components.
- Add AI questions to your vendor risk assessments — if you use third-party AI services, assess them for the same controls you're implementing internally.
The Bottom Line
A SOC 2 Type II report that doesn't address AI-specific risks is increasingly insufficient for enterprise sales in an AI-first market. Starting with the control mappings above, you can extend your existing SOC 2 program to cover LLM security without rebuilding from scratch — and produce a trust signal that meaningfully differentiates your product from competitors who haven't done this work.
Key Takeaways
- This post covers practical, actionable guidance for security and engineering teams.
- All findings and techniques are mapped to recognised frameworks (OWASP, NIST, ISO).
- Contact Vynox Security to test your systems against the vulnerabilities described here.